diff --git a/public/content/translations/pt-br/04) Exploring/nft/index.md b/public/content/translations/pt-br/04) Exploring/nft/index.md
deleted file mode 100644
index 7e2104df9ed..00000000000
--- a/public/content/translations/pt-br/04) Exploring/nft/index.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: Tokens não fungíveis (NFT)
-description: Uma visão geral de NFTs no Ethereum
-lang: pt-br
-template: use-cases
-emoji: ":frame_with_picture:"
-sidebarDepth: 2
-image: /images/infrastructure_transparent.png
-alt: Um logotipo Eth sendo exibido via holograma.
-summaryPoint1: Uma forma de representar qualquer coisa única como um ativo baseado no Ethereum.
-summaryPoint2: Os NFTs estão dando mais poder do que nunca aos criadores de conteúdo.
-summaryPoint3: Desenvolvido por contratos inteligentes na blockchain Ethereum.
----
-
-## O que são NFTs? {#what-are-nfts}
-
-NFTs são tokens **individualmente exclusivos**. Cada NFT contém diferentes propriedades (não-fungíveis) e é comprovadamente escasso. Isso é diferente de tokens como [ETH](/glossary/#ether) ou outros tokens criados na rede Ethereum, como USDC, em que todo token é igual e tem as mesmas características ("fungíveis"). Não importa qual cédula (ou ETH) você tem na sua carteira, pois todas são idênticas e valem o mesmo. Entretanto, você _se importa_ com o NFT específico que tem, porque todos têm propriedades individuais que os distinguem dos demais ("não fungíveis").
-
-A exclusividade de cada NFT permite a tokenização de itens como arte, colecionáveis ou inclusive imóveis, em que um NFT exclusivo específico representa um item real ou digital único específico. A posse de um ativo é publicamente verificável na [blockchain](/glossary/#blockchain) Ethereum.
-
-
-
-## A Internet de ativos {#internet-of-assets}
-
-Os NFTs e Ethereum resolvem alguns dos problemas que existem na internet atualmente. À medida que tudo se torna mais digital, há uma necessidade de replicar as propriedades de itens físicos, como escassez, exclusividade e prova de posse, de uma forma que não sejam controlados por uma organização central. Por exemplo, com NFTs, você pode ter um arquivo mp3 de música por todos os aplicativos criados no Ethereum e não estar vinculado a um aplicativo específico de música como Spotify ou Apple Music. Você pode ter um nome de usuário público em uma plataforma de mídia social que você pode vender ou trocar, **mas que não pode ser tirado arbitrariamente de você por um** fornecedor de plataforma.
-
-Veja como é uma Internet de NFTs comparada à Internet que a maioria de nós usa atualmente...
-
-### Uma comparação {#nft-comparison}
-
-| Uma Internet NFT | A Internet hoje |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| ** Seus próprios ativos!** Apenas você pode vendê-los ou trocá-los. | ** Você aluga um ativo ** de alguma organização e ele pode ser retirado de você. |
-| NFTs são ** digitalmente únicos **. Não há dois NFTs iguais. | **Normalmente uma cópia não pode ser distinguida** do original. |
-| A propriedade de um NFT é armazenada na blockchain para que qualquer um **possa verificá-la publicamente**. | O acesso aos registros da propriedade de itens digitais é ** controlado por instituições**. Você deve confiar nelas. |
-| NFTs são [contratos inteligentes](/glossary/#smart-contract) em Ethereum. Isso significa que eles **podem ser facilmente utilizados em outros contratos inteligentes** e aplicativos em Ethereum! | Empresas com produtos digitais geralmente **necessitam de sua própria infraestrutura "fechada"**. |
-| Criadores de **conteúdo podem vender seu trabalho onde quiserem** e se inserir no mercado global. | Os criadores dependem da infraestrutura e da distribuição das plataformas que utilizam. Geralmente, estão sujeitos a termos de uso e **restrições geográficas**. |
-| Criadores que utilizam NFT **podem manter os direitos de propriedade** sobre seu próprio trabalho e programar "royalties" diretamente no contrato NFT. | Plataformas de**streaming de música, por exemplo, ficam com a maior parte do lucro das vendas**. |
-
-## Para que são utilizados os NFTs? {#nft-use-cases}
-
-NFTs são utilizados para diversos fins, incluindo:
-
-- comprovar que você participou de um evento
-- certificar que você concluiu um curso
-- itens que podem ser adquiridos em jogos
-- arte digital
-- tokenização de ativos reais
-- comprovar a sua identidade online
-- obter acesso a conteúdo
-- emissão de ingressos
-- nomes de domínios de internet descentralizados
-- garantias em [ finanças descentralizadas](/glossary/#defi)
-
-Você talvez seja um artista que deseja compartilhar seu trabalho usando NFTs, sem perder o controle e sacrificar seus lucros para intermediários. Você pode criar um novo contrato e especificar o número de NFTs, as propriedades e um link para um trabalho artístico específico. Como artista, ** você pode programar em um contrato inteligente** os "royalties" que você deve receber (por exemplo, 5% do valor da venda estipulado pelo proprietário sempre que um NFT for transferido). Você também pode provar que criou de fato o NFT, porque você é quem detém a [carteira](/glossary/#wallet) que implantou o contrato. Os compradores podem facilmente provar que eles são donos de um ** NFT autêntico** da sua coleção porque os [endereços](/glossary/#address) da carteira deles está associado com o token do seu contrato inteligente. Eles podem usá-lo em todo o ecossistema Ethereum, com certeza da autenticidade.
-
-
-
Conheça, compre ou crie seus próprios colecionáveis/arte de NFT...
-
- Conheça a arte NFT
-
-
-
-Ou, por exemplo, considere um ingresso para um evento esportivo. Assim como o **organizador de um evento pode escolher quantos ingressos vai vender**, o criador de um NFT pode decidir quantas cópias existem. Às vezes, são réplicas exatas, como 5 mil ingressos de acesso geral. Por vezes, são mintados diversos ingressos muito semelhantes, mas cada um ligeiramente diferente, como um ingresso com um assento designado. Esses podem ser comprados e vendidos de pessoa para pessoa sem pagar intermediários de ingressos, e o comprador sempre tem a garantia da autenticidade do ingresso ao verificar o endereço do contrato.
-
-Em ethereum.org, **os NFTs são usados para demonstrar que as pessoas contribuíram de forma significativa** para nosso repositório do GitHub (programaram o site, escreveram ou modificaram um artigo...), traduziram nosso conteúdo ou participaram de nossas chamadas comunitárias. Temos até mesmo nosso próprio nome de domínio NFT. Se você contribui com ethereum.org, pode reivindicar um NFT [POAP](/glossary/#poap). Alguns encontros de criptomoedas usam POAPs como ingresso. [Mais sobre como contribuir](/contributing/#poap).
-
-
-
-Este site também tem um nome de domínio alternativo com tecnologia NFT, **ethereum.eth**. Nosso endereço `.org` é gerenciado centralmente por um sistema de nomes de domínio (DNS), enquanto ethereum`.eth` está registrado na Ethereum por meio do Serviço de Nome Ethereum (ENS). Nós somos os titulares e responsáveis pela administração do site. [Confira nosso registro ENS](https://app.ens.domains/name/ethereum.eth)
-
-[Mais sobre ENS](https://app.ens.domains)
-
-
-
-## Como funcionam os NFTs? {#how-nfts-work}
-
-NFTs, como quaisquer itens digitais na blockchain Ethereum, são criados através de um programa especial, situado no Ethereum, chamado de "contrato inteligente." Esses contratos seguem certas regras, como os padrões [ERC-721](/glossary/#erc-721) ou [ERC-1155](/glossary/#erc-1155), que determinam o que o contrato pode fazer.
-
-O contrato inteligente do NFT pode fazer algumas coisas importantes:
-
-- **Criar NFTs**: pode criar novos NFTs.
-- **Designar propriedade:** mantém a rastreabilidade de quem possui NFTs, vinculando-os a endereços específicos do Ethereum.
-- **Dar a cada NFT um ID**: cada NFT tem um número que o faz único. Além disso, geralmente há algumas informações (metadados) anexadas, descrevendo o que o NFT representa.
-
-Quando alguém "cria" ou "minta" (cunha) um NFT, está basicamente dizendo ao contrato inteligente para que conceder a essa pessoa a propriedade de um determinado NFT. Essas informações são armazenadas de forma segura e pública na blockchain.
-
-Além disso, o criador do contrato pode adicionar regras extras. Eles podem limitar quantos de um determinado NFT podem ser produzidos ou decidir que devem receber uma pequena taxa de "royalties" sempre que o NFT mudar de mãos.
-
-### Segurança do NFT {#nft-security}
-
-A segurança do Ethereum vem da [prova de participação](/glossary/#pos). O sistema foi projetado para desencorajar economicamente ações maliciosas, o que faz com que o Ethereum seja à prova de adulteração. É isso que possibilita a existência dos NFTs. Uma vez que o [bloco](/glossary/#block) contendo sua transação de NFT fosse[finalizado](/glossary/#finality), alterá-lo custaria milhões de ETH para um atacante. Qualquer pessoa executando software Ethereum seria imediatamente capaz de detectar adulteração desonesta em um NFT, e o ator mal-intencionado seria penalizado economicamente e expulso.
-
-Os problemas de segurança vinculados a NFTs são, na maioria das vezes, relacionados a golpes de phishing, vulnerabilidades de contratos inteligentes ou erros do usuário (como a exposição inadvertida de chaves privadas), o que torna a segurança adequada da carteira essencial para os proprietários de NFTs.
-
-
- Mais sobre segurança
-
-
-## Leitura adicional {#further-reading}
-
-- [Um guia sobre NFTs para iniciantes](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _Linda Xie, janeiro de 2020_
-- [Rastreador de NFT Etherscan](https://etherscan.io/nft-top-contracts)
-- [Padrão de token ERC-721](/developers/docs/standards/tokens/erc-721/)
-- [Padrão de token ERC-1155](/developers/docs/standards/tokens/erc-1155/)
-- [Aplicativos e ferramentas populares NFT](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts)
-
-## Outros recursos {#other-resources}
-
-- [NFTScan](https://nftscan.com/)
-
-
-
-
diff --git a/public/content/translations/pt-br/05) Use Ethereum Pages/dao/index.md b/public/content/translations/pt-br/05) Use Ethereum Pages/dao/index.md
deleted file mode 100644
index 20521b6ba85..00000000000
--- a/public/content/translations/pt-br/05) Use Ethereum Pages/dao/index.md
+++ /dev/null
@@ -1,166 +0,0 @@
----
-title: Organizações autônomas descentralizadas (DAOs)
-description: Uma visão geral de DAOs no Ethereum
-lang: pt-br
-template: use-cases
-emoji: ":handshake:"
-sidebarDepth: 2
-image: /images/use-cases/dao-2.png
-alt: Uma representação de uma votação DAO em uma proposta.
-summaryPoint1: Comunidades de membros sem liderança centralizada.
-summaryPoint2: Uma maneira segura de colaborar com desconhecidos na Internet.
-summaryPoint3: Um local seguro para destinar fundos para uma causa específica.
----
-
-## O que são DAOs? {#what-are-daos}
-
-Uma DAO é uma organização de propriedade coletiva que trabalha para uma missão comum.
-
-As DAOs permitem-nos trabalhar com pessoas que pensam da mesma maneira em todo o mundo sem confiar em um líder benevolente para gerenciar os fundos ou as operações. Não há CEO que possa gastar fundos por impulso ou CFO que capaz de manipular as contas. Em vez disso, as regras baseadas em blockchain incorporadas ao código definem como a organização funciona e como os fundos são gastos.
-
-Elas possuem receitas integradas que não podem ser acessadas por ninguém sem a aprovação do grupo. As decisões são regidas por propostas e votações para garantir que todos na organização tenham voz e que tudo aconteça de forma transparente [na blockchain](/glossary/#on-chain).
-
-## Por que precisamos de DAOs? {#why-dao}
-
-Começar uma organização com alguém que envolva financiamento e dinheiro requer muita confiança nas pessoas com as quais você está trabalhando. Mas é difícil confiar em alguém que você só interagiu pela Internet. Com DAOs você não precisa confiar em mais ninguém no grupo, apenas no código da DAO, que é 100% transparente e verificável por todos.
-
-Isto abre muitas novas oportunidades para a colaboração e coordenação globais.
-
-### Uma comparação {#dao-comparison}
-
-| DAO | Uma empresa tradicional |
-| --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
-| Hierarquia horizontal e totalmente democratizada. | Hierarquia vertical. |
-| Votação exigida pelos membros para que quaisquer alterações sejam implementadas. | Dependendo da estrutura, as mudanças podem ser requeridas por uma única parte, ou ter opção de voto. |
-| Votos conhecidos e resultados implementados automaticamente sem intermediário confiável. | Se a votação é permitida, os votos são homologados internamente e o resultado da votação tem de ser tratado manualmente. |
-| Os serviços oferecidos são tratados automaticamente de forma descentralizada (por exemplo, distribuição de fundos filantrópicos). | Requer manipulação humana, ou automação controlada centralmente, propensa a manipulação. |
-| Toda a atividade é transparente e totalmente pública. | A atividade é tipicamente privada e limitada ao público. |
-
-### Exemplos de DAOs {#dao-examples}
-
-Para dar um pouco de contexto, veja alguns exemplos de como você poderia usar uma DAO:
-
-- **Uma instituição de caridade** - você pode aceitar doações de qualquer pessoa no mundo e votar em quais causas financiar.
-- **Propriedade coletiva** - você pode comprar ativos físicos ou digitais, e os membros podem votar sobre como utilizá-los.
-- **Empreendimentos e subsídios** - você pode criar um fundo de investimentos que reúna capital e decida coletivamente quais projetos apoiar. O rendimento do dinheiro aplicado poderia mais tarde ser redistribuído entre os membros da DAO.
-
-
-
-## Como funcionam as DAOs? {#how-daos-work}
-
-A base de uma DAO é seu [contrato inteligente](/glossary/#smart-contract), que define as regras da organização e mantém os bens do grupo. Quando o contrato for publicado no Ethereum, ninguém poderá alterar as regras, exceto por votação. Se alguém tentar fazer algo que não esteja coberto pelas regras e lógica do código, não terá sucesso. E como a tesouraria é definida pelo contrato inteligente, também significa que ninguém pode gastar o dinheiro sem a aprovação do grupo. Isso significa que as DAOs não precisam de uma autoridade central. Em vez disso, o grupo toma decisões coletivas e os pagamentos são autorizados automaticamente quando os votos são aprovados.
-
-Isso é possível porque os contratos inteligentes são imunes a adulterações quando são implementados no Ethereum. Você não pode simplesmente editar o código (as regras das DAOs) sem que as pessoas percebam porque tudo é público.
-
-## Ethereum e DAOs {#ethereum-and-daos}
-
-O Ethereum é a base perfeita para DAOs por várias razões:
-
-- O próprio consenso do Ethereum é descentralizado e estabelecido o suficiente para que as organizações confiem na rede.
-- O código do contrato inteligente não pode ser modificado uma vez lançado, nem mesmo por seus proprietários. Isto permite que a DAO funcione segundo as regras com que foi programada.
-- Os contratos inteligentes podem enviar/receber fundos. Sem isso, você precisaria de um intermediário confiável para gerenciar os fundos do grupo.
-- A comunidade Ethereum provou ser mais colaborativa do que competitiva, permitindo que as melhores práticas e sistemas de suporte surjam rapidamente.
-
-## Governança DAO {#dao-governance}
-
-Há muitas considerações ao gerenciar uma DAO, como o funcionamento da votação e das propostas.
-
-### Delegação {#governance-delegation}
-
-A delegação é como a versão DAO da democracia representativa. Os detentores de tokens delegam votos a usuários que se autonomeiam e se comprometem a administrar o protocolo e permanecer informados.
-
-#### Um exemplo famoso {#governance-example}
-
-[ENS](https://claim.ens.domains/delegate-ranking) - os detentores de ENS podem delegar seus votos a membros da comunidade engajados para representá-los.
-
-### Governança automática de transações {#governance-example}
-
-Em muitas DAOs, as transações serão executadas automaticamente se um quórum de membros votar a favor.
-
-#### Um exemplo famoso {#governance-example}
-
-[Nouns](https://nouns.wtf) - no Nouns DAO, uma transação é automaticamente executada se um quórum de votos for realizado e a maioria dos votos for a favor, desde que não seja vetada pelos fundadores.
-
-### Governança Multisig {#governance-example}
-
-Embora as DAOs possam ter milhares de membros votantes, os fundos podem ficar em uma [carteira](/glossary/#wallet) compartilhada por 5-20 membros ativos da comunidade que são confiáveis e conhecidos publicamente (identidades públicas conhecidas pela comunidade). Após uma votação, os assinantes [multisig](/glossary/#multisig) executam a vontade da comunidade.
-
-## Leis DAO {#dao-laws}
-
-Em 1977, Wyoming inventou a LLC, que protege os empreendedores e limita a responsabilidade deles. Mais recentemente, eles foram pioneiros na lei DAO que estabelece o status legal para DAOs. Atualmente Wyoming, Vermont e as Ilhas Virgens têm alguma legislação que regula a DAO.
-
-### Um exemplo famoso {#law-example}
-
-[CityDAO](https://citydao.io) – CityDAO usou a lei DAO do Wyoming para comprar 40 acres de terra perto do Parque Nacional de Yellowstone.
-
-## Adesão à DAO {#dao-membership}
-
-Existem diferentes modelos para a adesão à DAO. A adesão pode determinar como funciona a votação e outras partes fundamentais da DAO.
-
-### Adesão baseada em token {#token-based-membership}
-
-Normalmente, não precisa de [permissão](/glossary/#permissionless) para ser usada, dependendo do token usado. A maioria desses tokens de governança podem ser trocados sem permissão em uma [corretora descentralizada](/glossary/#dex). Outros devem ser obtidos através do fornecimento de liquidez ou alguma outra “prova de trabalho”. De qualquer forma, a simples detenção do token permite o acesso à votação.
-
-_Normalmente usado para governar amplos protocolos descentralizados e/ou tokens._
-
-#### Um exemplo famoso {#token-example}
-
-[MakerDAO](https://makerdao.com) – O token MKR do MakerDAO está amplamente disponível em corretoras descentralizadas e qualquer pessoa pode comprar o poder de voto no futuro do protocolo Maker.
-
-### Adesão compartilhada {#share-based-membership}
-
-As DAOs compartilhadas são mais restritas, mas ainda bem abertas. Qualquer membro potencial pode apresentar uma proposta para participar da DAO, geralmente com uma contribuição sob a forma de tokens ou trabalho. Cotas representam o poder de voto e a propriedade. Os membros podem sair a qualquer momento, com a sua parte proporcional da receita.
-
-_Normalmente utilizado em organizações mais coesas e com abordagem humanitária, como instituições de caridade, cooperativas e clubes de investimento. Também podem controlar protocolos e tokens._
-
-#### Um exemplo famoso {#share-example}
-
-[MolochDAO](http://molochdao.com/) – MolochDAO foca no financiamento dos projetos Ethereum. Exigem uma proposta de adesão para que o grupo possa avaliar se você dispõe dos conhecimentos especializados e do capital necessários para fazer considerações fundamentadas sobre potenciais donatários. Você não pode simplesmente comprar acesso à DAO no mercado aberto.
-
-### Adesão baseada em reputação {#reputation-based-membership}
-
-A reputação representa a prova de participação e concede poder de voto na DAO. Diferentemente de adesões baseadas em ações ou tokens, as DAOs baseadas em reputação não transferem a propriedade para seus colaboradores. Reputação não pode ser comprada, transferida ou delegada; os membros da DAO devem ganhar reputação por meio de participação. A votação em cadeia não requer permissão e os potenciais membros podem apresentar propostas livremente para ingressar na DAO e solicitar o recebimento de reputação e tokens como recompensa em troca de suas contribuições.
-
-_Tipicamente usados para descentralizar desenvolvimentos e protocolos de governança e [dApps](/glossary/#dapp), mas também se adapta bem a uma grande variedade de organizações, como instituições de caridade, cooperativas, clubes de investimento, etc._
-
-#### Um exemplo famoso {#reputation-example}
-
-[DXdao](https://DXdao.eth.limo) -- DXdao é uma comunidade global e soberana que cria e controla protocolos e aplicativos descentralizados desde 2019. Usa governança baseada em reputação e [consenso holográfico](/glossary/#holographic-consensus) para coordenar e gerenciar fundos, o que significa que ninguém pode de alguma maneira tentar influenciar o futuro ou a governança.
-
-## Iniciar/participar de uma DAO {#join-start-a-dao}
-
-### Participe de uma DAO {#join-a-dao}
-
-- [DAOs da comunidade Ethereum](/community/get-involved/#decentralized-autonomous-organizations-daos)
-- [Lista DAOHaus's de DAOs](https://app.daohaus.club/explore)
-- [Lista Tally.xyz de DAOs](https://www.tally.xyz)
-
-### Inicie uma DAO {#start-a-dao}
-
-- [Comece uma DAO com DAOHaus](https://app.daohaus.club/summon)
-- [Inicie uma DAO de Governança com sistema de contagem](https://www.tally.xyz/add-a-dao)
-- [Criar uma DAO suportada por Aragon](https://aragon.org/product)
-- [Inicie uma colônia](https://colony.io/)
-- [Crie uma DAO com o consenso holográfico de DAOstack](https://alchemy.daostack.io/daos/create)
-
-## Leitura adicional {#further-reading}
-
-### Artigos sobre DAOs {#dao-articles}
-
-- [O que é uma DAO?](https://aragon.org/dao) – [Aragon](https://aragon.org/)
-- [Casa das DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
-- [O que é uma DAO e para que serve?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
-- [Como começar uma comunidade digital alimentada por DAO](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
-- [O que é uma DAO?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
-- [O que é Consenso Holográfico?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
-- [DAOs não são corporações: onde a descentralização em organizações autônomas é importante para Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html)
-- [DAOs, DACs, DAs e mais: Um Guia Terminológico Incompleto](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [Blog Ethereum](https://blog.ethereum.org)
-
-### Vídeos {#videos}
-
-- [O que é uma DAO em cripto?](https://youtu.be/KHm0uUPqmVE)
-- [Uma DAO pode construir uma cidade?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
-
-
-
-
diff --git a/public/content/translations/pt-br/06) Use Cases/defi/index.md b/public/content/translations/pt-br/06) Use Cases/defi/index.md
deleted file mode 100644
index 965e6fae369..00000000000
--- a/public/content/translations/pt-br/06) Use Cases/defi/index.md
+++ /dev/null
@@ -1,357 +0,0 @@
----
-title: Finanças descentralizadas (DeFi)
-description: Uma visão geral do DeFi na Ethereum
-lang: pt-br
-template: use-cases
-emoji: ":money_with_wings:"
-image: /images/use-cases/defi.png
-alt: Um logotipo Eth feito de blocos de lego.
-sidebarDepth: 2
-summaryPoint1: Uma alternativa global e aberta ao sistema financeiro atual.
-summaryPoint2: Produtos que deixam você pedir emprestado, economizar, investir, comercializar e muito mais.
-summaryPoint3: Com base na tecnologia de código aberto com a qual qualquer pessoa pode programar.
----
-
-A DeFi é um sistema financeiro aberto e global criado para a era da Internet – uma alternativa a um sistema que não é transparente, controlado rigorosamente e mantido por infraestruturas e processos com décadas de existência. Oferece controle e visibilidade sobre o seu dinheiro. Ela fornece exposição aos mercados globais e alternativas a sua moeda local ou opções bancárias. Os produtos DeFi oferecem serviços financeiros a qualquer pessoa com uma conexão com a Internet e são em grande parte de propriedade e mantidos por seus usuários. Até agora, dezenas de bilhões de dólares de criptos foram transacionados através de aplicativos DeFi e seguem crescendo todos os dias.
-
-## O que é DeFi? {#what-is-defi}
-
-DeFi é um termo coletivo para produtos e serviços financeiros que são acessíveis a qualquer um que possa usar Ethereum – qualquer pessoa com uma conexão com a Internet. Com as DeFi, os mercados estão sempre abertos e não há autoridades centralizadas que possam bloquear pagamentos ou negar o seu acesso a qualquer coisa. Serviços que eram anteriormente lentos e com risco de falha humana se tornam automáticos e mais seguros, agora que são processados por código que qualquer um pode inspecionar e auditar.
-
-Há uma economia cripto em expansão, na qual você pode emprestar, operar long/short, ganhar juros e muito mais. Os argentinos experientes em criptomoedas usaram as DeFi para escapar da inflação devastadora. Empresas começaram a transferir os salários de seus colaboradores em tempo real. Algumas pessoas contrataram e pagaram empréstimos, na casa dos milhões de dólares, sem necessidade de qualquer identificação pessoal.
-
-
-
-## DeFi vs. finanças tradicionais {#defi-vs-tradfi}
-
-Uma das melhores maneiras de avaliar o potencial das DeFi é compreender os problemas que existem hoje.
-
-- Algumas pessoas não têm acesso para abrir uma conta bancária ou usar serviços financeiros.
-- A falta de acesso a serviços financeiros pode comprometer a empregabilidade das pessoas.
-- A falta de acesso a serviços financeiros pode impedir que você seja pago.
-- Uma cobrança oculta dos serviços financeiros são os seus dados pessoais.
-- Os governos e as instituições centralizadas podem fechar os mercados de forma arbitrária.
-- Os horários de negociação geralmente são limitados ao horário comercial de um fuso horário específico.
-- Transferências de dinheiro podem levar dias devido a processos humanos internos.
-- Há um prêmio para operar os serviços financeiros porque as instituições intermediárias cobram a parte delas.
-
-### Uma comparação {#defi-comparison}
-
-| DeFi | Finanças tradicionais |
-| ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Você detém seu dinheiro. | Seu dinheiro é controlado por empresas. |
-| Você controla a destinação de seu dinheiro e como será gasto. | Você precisa confiar que as empresas não administrarão os seus fundos indevidamente, como, por exemplo, fazer empréstimos a tomadores de risco. |
-| Transferências de dinheiro acontecem em minutos. | Os pagamentos podem levar dias devido a processos manuais. |
-| A transação é anônima. | A operação financeira é fortemente ligada à sua identidade. |
-| A DeFi é aberta a qualquer pessoa. | Você deve se cadastrar para usar os serviços financeiros. |
-| Os mercados estão sempre abertos. | Mercados fecham porque os empregados cumprem horários. |
-| Construído com base na transparência – qualquer pessoa pode ver os dados de um produto e inspecionar como o sistema funciona. | As instituições financeiras são livros fechados: não se pode pedir para ver o histórico de empréstimos, um registro dos seus ativos gerenciados, e assim por diante. |
-
-
- Ver aplicativos DeFi
-
-
-## Tudo começou com o Bitcoin... {#bitcoin}
-
-O Bitcoin, de muitas maneiras, foi a primeira aplicação DeFi. O Bitcoin permite que você realmente tenha e controle valores e os envie para qualquer lugar ao redor do mundo. Isso é feito oferecendo uma maneira para que um grande número de pessoas, que não confiam umas nas outras, concordem com um livro de contas sem a necessidade de um intermediário confiável. O Bitcoin é aberto a qualquer um e ninguém tem autoridade para alterar suas regras. As regras do Bitcoin, como sua escassez e acessibilidade, estão incorporadas na tecnologia. Não funciona como nas finanças tradicionais, em que os governos podem imprimir moeda que desvaloriza as suas economias e as empresas podem fechar os mercados.
-
-Ethereum baseia-se nisso. Como o Bitcoin, as regras não mudam por você, e todos têm acesso. Mas ele também torna esse dinheiro digital programável, usando [contratos inteligentes](/glossary/#smart-contract), para que você possa fazer mais do que guardar e enviar valores.
-
-
-
-## Dinheiro programável {#programmable-money}
-
-Isso soa estranho... "Por que eu gostaria de programar meu dinheiro"? No entanto, esta é mais uma característica padrão dos tokens no Ethereum. Qualquer um pode programar a lógica em pagamentos. Assim, você pode ter o controle e a segurança do Bitcoin somados aos serviços fornecidos por instituições financeiras. Isso permite fazer coisas com criptomoedas que você não poderia fazer com o Bitcoin, tais como emprestar e tomar empréstimos, agendar pagamentos, investir em fundos de índices e mais.
-
-
-
Explore nossas sugestões de aplicativos DeFi para iniciar se você é novo no Ethereum.
-
- Ver aplicativos DeFi
-
-
-
-## O que você pode fazer com DeFi? {#defi-use-cases}
-
-Há uma alternativa descentralizada para a maioria dos serviços financeiros. Mas o Ethereum também cria oportunidades para a criação de produtos financeiros completamente novos. Esta lista está em constante crescimento.
-
-- [Envie dinheiro para qualquer lugar do mundo](#send-money)
-- [Pagamentos em tempo real ao redor do mundo](#stream-money)
-- [Acesso a moedas estáveis](#stablecoins)
-- [Empréstimos com garantia](#lending)
-- [Empréstimos sem garantias](#flash-loans)
-- [Poupança com criptomoedas](#saving)
-- [Negociar tokens](#swaps)
-- [Aumente seu portfólio](#investing)
-- [Financie seus projetos](#crowdfunding)
-- [Compra de seguros](#insurance)
-- [Gerenciamento de portfolio](#aggregators)
-
-
-
-### Envie dinheiro ao redor do mundo rapidamente {#send-money}
-
-Como um blockchain, o Ethereum foi concebido para o envio de transações de forma segura e de modo global. Assim como o Bitcoin, o Ethereum torna o envio de dinheiro ao redor do mundo tão fácil quanto enviar um e-mail. Basta digitar o [nome ENS](/glossary/#ens) do seu beneficiário, por exemplo, bob.eth, ou o endereço de conta da respectiva carteira e seu pagamento será enviado em minutos, normalmente. Para enviar ou receber pagamentos, você precisará de uma [carteira](/wallets/).
-
-
- Ver dapps de pagamento
-
-
-#### Pagamentos em tempo real ao redor do mundo... {#stream-money}
-
-Você também pode transferir dinheiro através da Ethereum. Isso permite que você pague imediatamente o salário de alguém, dando a essa pessoa acesso ao valor devido sempre que preciso. Ou alugue algo de forma imediata, como um guarda-volume ou uma moto elétrica.
-
-E se você não quiser enviar ou transferir [ETH](/glossary/#ether) devido à flutuação de valor que pode sofrer, existem outras moedas alternativas no Ethereum: as [stablecoins](/glossary/#stablecoin).
-
-
-
-### Acesso a moedas estáveis {#stablecoins}
-
-A volatilidade das criptomoedas é um problema para muitos produtos financeiros e gastos em geral. A comunidade DeFi resolveu isso por meio das stablecoins. O valor delas permanece vinculado a outro ativo, geralmente uma moeda popular como o dólar.
-
-Moedas como Dai ou USDC têm um valor que não superam alguns centavos de dólar. Isso as torna perfeitas para rendimentos ou varejo. Muitas pessoas na América Latina utilizaram as stablecoins como forma de proteger suas poupanças, em tempos de grande incerteza com as moedas emitidas pelos governos.
-
-
- Mais sobre moedas estáveis
-
-
-
-
-### Empréstimos {#lending}
-
-Empréstimos de recursos de fornecedores descentralizados se dão de duas formas principais.
-
-- Ponto a ponto, quando um mutuário pede emprestado diretamente de um mutuante específico.
-- Pool de fundos, onde credores fornecem fundos (liquidez) a um pool do qual os mutuários podem tomar empréstimo.
-
-
- Ver dapps de empréstimos
-
-
-Há diversas vantagens em usar um financiador descentralizado...
-
-#### Empréstimos com privacidade {#borrowing-privacy}
-
-Hoje, pegar dinheiro emprestado ou emprestar gira em torno dos indivíduos envolvidos. Os bancos precisam saber se você terá condições de pagar um empréstimo antes de concedê-lo.
-
-Os empréstimos descentralizados funcionam sem que as partes tenham que se identificar. Em vez disso, o mutuário deve oferecer uma garantia colateral que o credor receberá automaticamente se o empréstimo não for pago. Alguns credores até aceitam [NFTs](/glossary/#nft) como garantia. Os NFTs são escrituras de ativos únicos, como uma pintura. [Mais sobre NFTs](/nft/)
-
-Isso permite que você tome empréstimo de dinheiro sem checagem de crédito ou fornecimento de dados pessoais.
-
-#### Acesso a fundos globais {#access-global-funds}
-
-Quando você usa um mutuante descentralizado, você tem acesso a fundos depositados de todo o mundo, não apenas os fundos em custódia de seu banco ou instituição escolhida. Isto torna os empréstimos mais acessíveis e melhora as taxas de juro.
-
-#### Eficiência tributária {#tax-efficiencies}
-
-Pedir empréstimo pode dar a você acesso aos fundos de que você precisa sem precisar vender seus ETHs (um evento tributável). Em vez disso, você pode usar ETH como garantia colateral de um empréstimo em stablecoin. Isso dá a você acesso ao fluxo de caixa de que você precisa sem abrir mão de seus ETHs. Stablecoins são tokens muito melhores quando você precisa de dinheiro, já que elas não oscilam tanto quanto o ETH. [Mais sobre stablecoins](#stablecoins)
-
-#### Empréstimos rápidos {#flash-loans}
-
-Empréstimos rápidos são uma forma mais experimental de empréstimos descentralizados que permite que você peça empréstimo sem garantia ou sem fornecer qualquer informação pessoal.
-
-Neste momento, não estão amplamente acessíveis a pessoas não técnicas, mas dão uma ideia do que poderá ser possível a todos no futuro.
-
-Funciona com base no princípio de que o empréstimo é tomado e pago na mesma transação. Se não puder ser pago, a transação retroage como se nada tivesse acontecido.
-
-Os fundos que são mais frequentemente utilizados são mantidos em pools de liquidez (grandes pools de fundos utilizados para empréstimos). Se não estiverem sendo utilizados em um dado momento, isso cria uma oportunidade para alguém pedir esses fundos emprestados, fazer negócio com eles e devolver o valor integral literalmente no mesmo momento em que se toma emprestado.
-
-Isto significa que muita lógica tem de ser incluída em uma transação sob medida. Um exemplo simples pode ser alguém pedir um empréstimo rápido para adquirir um ativo a um preço para vendê-lo em outra exchange (corretora) onde o preço seja mais alto.
-
-Portanto, em uma única transação, ocorre o seguinte:
-
-- Você pega emprestado a quantia X de um ativo $asset por $ 1,00 de uma exchange A
-- Você vende X do $asset na exchange B por $ 1,10
-- Então, você paga o empréstimo na exchange A
-- Você embolsa o lucro menos a taxa de transação
-
-Se o estoque da exchange B cair de repente e o usuário não conseguir comprar o suficiente para cobrir o empréstimo original, a transação simplesmente não acontecerá.
-
-Para ser capaz de fazer o exemplo acima no mundo financeiro tradicional, você precisaria de uma quantidade enorme de dinheiro. Estas estratégias de fazer dinheiro só são acessíveis aos que já possuem economias. Os empréstimos rápidos são um exemplo do futuro em que possuir dinheiro não é necessariamente uma condição prévia para se fazer dinheiro.
-
-
- Mais sobre empréstimos rápidos
-
-
-
-
-### Comece a poupar com criptomoedas {#saving}
-
-#### Empréstimos {#lending}
-
-Você pode ganhar juros sobre suas criptomoedas emprestando-as e vendo seus fundos crescerem em tempo real. No momento, as taxas de juros são muito mais altas do que as que você pode obter no seu banco local (se você tiver sorte o suficiente para ter acesso a um). Aqui está um exemplo:
-
-- Você empresta 100 Dai, uma [stablecoin](/stablecoins/), a um produto como Aave.
-- Você recebe 100 Aave Dai (aDai) que é um token que representa seus Dai emprestados.
-- Seu aDai aumentará com base nas taxas de juros e você poderá ver o saldo crescendo na sua carteira. Dependendo da [APR](/glossary/#apr), o saldo da sua carteira será algo como 100.1234 depois de alguns dias ou até horas!
-- Você pode retirar uma quantidade de Dai regular, igual ao seu saldo em aDai, a qualquer momento.
-
-
- Ver dapps de empréstimos
-
-
-#### Loterias sem perda {#no-loss-lotteries}
-
-Loterias sem perda como a PoolTogether são uma divertida e inovadora maneira de economizar dinheiro.
-
-- Você compra 100 bilhetes usando 100 tokens Dai.
-- Você recebe 100 plDai representando os seus 100 bilhetes.
-- Se um de seus bilhetes for escolhido como vencedor, seu saldo plDai aumentará na proporção do dinheiro acumulado para premiação.
-- Se você não vencer, os seus 100 plDai vão para o sorteio da próxima semana.
-- Você pode retirar uma quantidade de Dai regular, que é igual ao seu saldo plDai, a qualquer momento.
-
-O dinheiro acumulado para premiação é gerado por todos os juros gerados pelo empréstimo dos bilhetes depositados, como no exemplo de empréstimo acima.
-
-
- Experimente o PoolTogether
-
-
-
-
-### Negociar tokens {#swaps}
-
-Existem milhares de tokens no Ethereum. Exchanges descentralizadas (DEXs) permitem que você opere diferentes tokens sempre que quiser. Você nunca entrega o controle de seus ativos. Isso é como usar uma exchange quando você visita um país diferente. Mas a versão de DeFi nunca fecha. Os mercados funcionam de maneira ininterrupta e a tecnologia garante que sempre haverá alguém disposto a fazer negociações.
-
-Por exemplo, se você quiser usar a loteria sem perda PoolTogether (descrita acima), você precisará de um token como Dai ou USDC. Estas DEXs permitem que você troque seus ETH por esses tokens e reverta novamente quando terminar.
-
-
- Exibir exchanges de token
-
-
-
-
-### Negociações avançadas {#trading}
-
-Existem opções mais avançadas para traders que gostam de um pouco mais de controle. Limitar ordens, contratos futuros sem vencimento, trading alavancado e muito mais é possível. Com negociações descentralizadas você obtém acesso à liquidez global, o mercado nunca fecha e você está sempre no controle de seus ativos.
-
-Quando você usa uma exchange centralizada, tem que depositar seus ativos antes da negociação e confiar a ela o cuidado dos ativos. Embora seus ativos estejam depositados, eles estão em risco, uma vez que as exchanges centralizadas são alvos atraentes para os hackers.
-
-
- Ver dapps de trading
-
-
-
-
-### Aumente seu portfolio {#investing}
-
-Existem produtos de gestão de fundos na Ethereum que tentarão aumentar a sua carteira com base em uma estratégia à sua escolha. Isto é automático, aberto a todos, e não precisa de um gerente humano pegando uma fatia de seus lucros.
-
-Um bom exemplo é o [fundo DeFi Pulse Index (DPI)](https://defipulse.com/blog/defi-pulse-index/). Esse é um fundo com balanceamento automático, de forma a garantir que o seu portfólio sempre inclua os principais tokens de DeFi por capitalização de mercado. Nunca é necessário gerenciar nenhum dos detalhes e é possível sacar do fundo sempre que quiser.
-
-
- Ver dapps de investimento
-
-
-
-
-### Financie suas ideias {#crowdfunding}
-
-Ethereum é uma plataforma ideal para financiamento colaborativo:
-
-- Potenciais financiadores podem vir de qualquer lugar – a Ethereum e seus tokens estão abertos a qualquer pessoa, em qualquer lugar do mundo.
-- É transparente para que os captadores de recursos possam provar quanto dinheiro foi levantado. Você pode até rastrear como os fundos estão sendo gastos posteriormente.
-- Os captadores de recursos podem criar reembolsos automáticos se, por exemplo, houver um prazo específico e um montante mínimo que não seja cumprido.
-
-
- Ver dapps de captação de recursos
-
-
-#### Financiamento quadrático {#quadratic-funding}
-
-O Ethereum é um software de código aberto, e muito do trabalho até agora tem sido financiado pela comunidade. A essência do código aberto do Ethereum levou ao crescimento de um modelo interessante de captação de recursos: financiamento quadrático. Isto tem o potencial de melhorar a forma como financiamos todos os tipos de bens públicos no futuro.
-
-O financiamento quadrático assegura que os projetos que recebem mais recursos sejam aqueles com a maior procura. Em outras palavras, projetos que contribuem para melhorar a vida da maioria das pessoas. Funciona assim:
-
-1. Há um pool correspondente de fundos doados.
-2. Começa uma rodada de financiamento público.
-3. As pessoas podem sinalizar a demanda por um projeto através da doação de dinheiro.
-4. Uma vez terminada a rodada, a reserva de fundos correspondente será distribuída aos projetos. Aqueles com a demanda mais alta obtêm o maior valor da reserva de fundos correspondente.
-
-Isso significa que o Projeto A com suas 100 doações de 1 dólar poderia acabar com mais financiamento que o Projeto B com uma única doação de 10.000 dólares (sujeito ao tamanho do pool correspondente).
-
-
- Mais sobre financiamento quadrático
-
-
-
-
-### Seguros {#insurance}
-
-Seguros descentralizados visam tornar o seguro mais barato, mais rápido para pagar e mais transparente. Com mais automação, a cobertura é mais acessível e os pagamentos são muito mais rápidos. Os dados utilizados para decidir sobre a sua reivindicação são completamente transparentes.
-
-Os produtos Ethereum, como qualquer software, estão propensos a bugs e exploits. Então, atualmente, muitos produtos na área de seguros visam proteger seus usuários contra a perda de fundos. Entretanto, há projetos que estão começando a criar cobertura para tudo o que a vida pode nos oferecer. Um bom exemplo disto é a cobertura para o cultivo do Etherisc, que visa [proteger os pequenos agricultores do Quênia contra secas e inundações](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc). Um seguro descentralizado pode proporcionar cobertura mais barata aos agricultores que são frequentemente deixados de fora do seguro tradicional.
-
-
- Ver dapps de seguros
-
-
-
-
-### Agregadores e gerenciadores de portfolio {#aggregators}
-
-Com tanta coisa acontecendo, você precisará de uma maneira de acompanhar todos os seus investimentos, empréstimos e operações. Há uma série de produtos que permitem coordenar todas as atividades DeFi de um só lugar. Esta é a beleza da arquitetura aberta do DeFi. Equipes podem construir interfaces onde você não somente vê os saldos entre produtos, mas também pode usar os recursos correspondentes. Você vai achar isso útil enquanto aprende mais sobre DeFi.
-
-
- Ver dapps de portfolio
-
-
-
-
-## Como o funciona Defi? {#how-defi-works}
-
-O DeFi usa criptomoedas e contratos inteligentes para fornecer serviços que não precisam de intermediários. No mundo financeiro de hoje, as instituições financeiras atuam como garantidoras das transações. Isto confere a essas instituições um poder enorme, porque seu dinheiro flui por elas. Além disso, bilhões de pessoas ao redor do mundo não têm acesso a uma conta bancária.
-
-No DeFi, um contrato inteligente substitui a instituição financeira na transação. Um contrato inteligente é um tipo de conta Ethereum que pode ter fundos e enviá-los/reembolsá-los com base em certas condições. Ninguém pode alterar esse contrato inteligente quando estiver ativo – ele sempre será executado conforme o programado.
-
-Um contrato que foi concebido para distribuir um subsídio ou mesada poderia ser programado para enviar dinheiro da Conta A para Conta B todas as sextas-feiras. E isso só poderá acontecer enquanto a Conta A tiver os fundos necessários. Ninguém pode alterar o contrato e adicionar Conta C como beneficiário para roubar fundos.
-
-Os contratos também são públicos para qualquer pessoa inspecionar e auditar. Isto significa que os contratos pouco confiáveis passarão frequentemente a estar sob escrutínio comunitário muito rapidamente.
-
-Isto significa que atualmente há uma necessidade de confiar nos membros mais técnicos da comunidade Ethereum, que podem ler códigos. A comunidade baseada em código aberto ajuda a manter os desenvolvedores sob controle, mas esta necessidade diminuirá ao longo do tempo, à medida que os contratos inteligentes se tornem mais fáceis de ler e que se desenvolvam outras formas de provar a confiança no código.
-
-## Ethereum e DeFi {#ethereum-and-defi}
-
-O Ethereum é a base perfeita para DeFi por várias razões:
-
-- Ninguém é proprietário do Ethereum ou dos contratos inteligentes que existem nele – isso dá a todos uma oportunidade de usar o DeFi. Isto também significa que ninguém pode alterar as regras que são aplicadas a ele.
-- Os produtos de DeFi falam todos o mesmo idioma nos bastidores: Ethereum. Isto significa que muitos dos produtos funcionam muito bem em conjunto. Você pode emprestar tokens em uma plataforma e negociar os juros do token em um mercado diferente através de uma aplicação totalmente distinta. Isso é como juntar pontos de fidelidade em seu banco.
-- Tokens e criptomoedas estão integrados no Ethereum, um registro compartilhado – manter o controle das transações e a propriedade são a área de domínio do Ethereum.
-- O Ethereum permite a liberdade financeira total – a maioria dos produtos nunca terá a custódia dos seus fundos, deixando você no controle.
-
-Pense no DeFi como camadas:
-
-1. O blockchain: Ethereum contém o histórico das transações e o estado das contas.
-2. Os ativos: [ETH](/eth/) e outros tokens (moedas).
-3. Os protocolos, [contratos inteligentes](/glossary/#smart-contract) que oferecem a funcionalidade, por exemplo, um serviço que permite o empréstimo descentralizado de ativos.
-4. [As aplicações](/dapps/): os produtos que usamos para gerenciar e acessar os protocolos.
-
-Nota: grande parte do DeFi usa o [padrão ERC-20](/glossary/#erc-20). Aplicações em DeFi usam um encapsulamento para ETH chamado Wrapped Ether (WETH). [Saiba mais sobre o Wrapped Ether](/wrapped-eth).
-
-## Criar Defi {#build-defi}
-
-DeFi é um movimento de código aberto. Os protocolos e aplicações DeFi são todos abertos, para você inspecionar, fazer updates e inovar. Por causa dessa pilha em camadas (todos compartilham o mesmo blockchain e ativos base), os protocolos podem ser combinados para proporcionar oportunidades únicas.
-
-
- Mais sobre como criar Dapps
-
-
-## Leitura adicional {#further-reading}
-
-### Dados DeFi {#defi-data}
-
-- [DeFi Prime](https://defiprime.com/)
-- [DeFi Llama](https://defillama.com/)
-
-### Artigos sobre DeFi {#defi-articles}
-
-- [Um guia de DeFi para iniciantes](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6 de janeiro de 2020_
-
-### Vídeos {#videos}
-
-- [Finematics - Informações sobre finanças descentralizadas](https://finematics.com/) – _Vídeos sobre DeFi_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _Fundamentos DeFi: Tudo o que você precisa saber para começar neste espaço às vezes desconcertante._
-- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _O que é DeFi?_
-
-### Comunidades {#communities}
-
-- [Servidor DeFi Llama no Discord](https://discord.defillama.com/)
-- [Servidor DeFi Pulse no Discord](https://discord.gg/Gx4TCTk)
diff --git a/public/content/translations/pt-br/06) Use Cases/smart-contracts/index.md b/public/content/translations/pt-br/06) Use Cases/smart-contracts/index.md
deleted file mode 100644
index 02a1962aaeb..00000000000
--- a/public/content/translations/pt-br/06) Use Cases/smart-contracts/index.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Contratos inteligentes
-description: Uma introdução não técnica aos contratos inteligentes
-lang: pt-br
----
-
-# Introdução aos contratos inteligentes {#introduction-to-smart-contracts}
-
-Os contratos inteligentes são os elementos fundamentais da camada de aplicativos Ethereum. Estes são programas de computador armazenados na [blockchain](/glossary/#blockchain) que seguem a lógica “se não isso, então aquilo” e têm a garantia de que serão executados de acordo com as regras definidas por seu código, que não pode ser alterado depois de criado.
-
-Nick Szabo cunhou o termo "contrato inteligente". Em 1994, ele escreveu [uma introdução ao conceito](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html) e, em 1996, [uma análise sobre o que os contratos inteligentes poderiam fazer](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html).
-
-Szabo imaginou um mercado digital em que processos automáticos e [protegidos com criptografia](/glossary/#cryptography) permitem que transações e funções comerciais aconteçam sem intermediários confiáveis. Os contratos inteligentes no Ethereum colocam em prática essa visão.
-
-Assista à explicação de contratos inteligentes disponibilizada pelo canal Finematics:
-
-
-
-## Confiança em contratos convencionais {#trust-and-contracts}
-
-Um dos maiores problemas de um contrato tradicional é a necessidade de se ter indivíduos confiáveis para acompanhar os resultados do contrato.
-
-Exemplo:
-
-Alice e Bob estão fazendo uma corrida de bicicleta. Digamos que Alice aposte R$ 10 com Bob que ela vencerá corrida. Bob está confiante que será o vencedor e aceita a aposta. No final, Alice termina a corrida bem à frente de Bob e vence. Mas Bob se recusa a pagar a aposta, alegando que Alice deve ter trapaceado.
-
-Esse exemplo ilustra o problema com qualquer contrato não inteligente. Mesmo que as condições do contrato sejam cumpridas (ou seja, você é o vencedor da corrida), você ainda precisa confiar que a outra pessoa cumprirá o contrato (ou seja, pagar a aposta).
-
-## Uma máquina de vendas digitais {#vending-machine}
-
-Uma metáfora simples de um contrato inteligente é como se fosse uma máquina de venda automática, que funciona de forma semelhante a um contrato inteligente – você insere algo específico e isso garante um produto predeterminado.
-
-- Você seleciona um produto
-- A máquina de venda automática mostra o preço
-- Você paga o preço
-- A máquina de venda automática confirma que você pagou o valor correto
-- A máquina de venda automática entrega o item comprado
-
-A máquina de venda automática só entregará o produto após o cumprimento de todas as exigências. Se você não selecionar um produto ou não inserir dinheiro suficiente, a máquina de venda automática não entrega o produto.
-
-## Execução automática {#automation}
-
-O principal benefício de um contrato inteligente é que ele executa, de maneira determinística, um código inequívoco quando determinadas condições são atendidas. Não há necessidade de esperar que um ser humano interprete ou negocie o resultado. Isso elimina a necessidade de intermediários confiáveis.
-
-Por exemplo, você pode redigir um contrato inteligente que mantenha fundos em depósito para uma criança e que permitirá que ela retire os fundos após uma data específica. Se a criança tentar retirar os fundos antes dessa data, o contrato inteligente não permitirá. Ou você pode redigir um contrato que entrega automaticamente uma versão digital do documento de propriedade de um carro assim que você pagar o valor à concessionária.
-
-## Resultados previsíveis {#predictability}
-
-Os contratos tradicionais são ambíguos porque dependem de seres humanos para interpretá-los e implementá-los. Por exemplo, dois juízes podem interpretar um contrato de forma diferente, o que pode resultar na tomada de decisões incoerentes e resultados desproporcionais. Os contratos inteligentes eliminar essa possibilidade. Em vez disso, os contratos inteligentes são executados precisamente com base nas condições escritas no código do contrato. Essa exatidão significa que, se as circunstâncias forem idênticas, o contrato inteligente produzirá o mesmo resultado.
-
-## Registro público {#public-record}
-
-Os contratos inteligentes são úteis para auditorias e rastreamento. Como os contratos inteligentes do Ethereum estão em um blockchain público, qualquer pessoa pode rastrear instantaneamente as transferências de ativos e outras informações relacionadas. Por exemplo, você pode verificar se alguém enviou fundos para o seu endereço.
-
-## Proteção de privacidade {#privacy-protection}
-
-Os contratos inteligentes também protegem a sua privacidade. Como o Ethereum é uma rede pseudônima (as suas transações são vinculadas publicamente a um único endereço criptográfico, não à sua identidade), você pode proteger a sua privacidade de observadores.
-
-## Termos visíveis {#visible-terms}
-
-Por último, como os contratos tradicionais, você pode verificar o conteúdo de um contrato inteligente antes de assiná-lo (ou interagir com ele de outra forma). A transparência de um contrato inteligente garante que qualquer pessoa pode analisar o conteúdo.
-
-## Casos de uso de contrato inteligente {#use-cases}
-
-Os contratos inteligentes podem fazer essencialmente qualquer coisa que os programas informáticos podem fazer.
-
-Eles podem realizar cálculos, criar moeda, armazenar dados, cunhar [NFTs](/glossary/#nft), enviar comunicações e até mesmo gerar gráficos. Apresentamos alguns exemplos reais e populares:
-
-- [Stablecoins](/stablecoins/)
-- [Criação e distribuição de ativos digitais únicos](/nft/)
-- [Uma negociação de moeda automática e aberta](/get-eth/#dex)
-- [Jogos descentralizados](/dapps/?category=gaming#explore)
-- [Uma apólice de seguro que paga automaticamente](https://etherisc.com/)
-- [Um padrão que permite que pessoas criem moedas personalizadas e interoperáveis](/developers/docs/standards/tokens/)
-
-## Leitura adicional {#further-reading}
-
-- [Como os Contratos Inteligentes irão mudar o mundo](https://www.youtube.com/watch?v=pA6CGuXEKtQ)
-- [Contratos Inteligentes: A Tecnologia Blockchain que substituirá os Advogados](https://blockgeeks.com/guides/smart-contracts/)
-- [Contratos inteligentes para desenvolvedores](/developers/docs/smart-contracts/)
-- [Aprenda a escrever contratos inteligentes](/developers/learning-tools/)
-- [Dominando o Ethereum – O que é um Contrato Inteligente?](https://github.com/ethereumbook/ethereumbook/blob/develop/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract)
diff --git a/public/content/translations/pt-br/06) Use Cases/web3/index.md b/public/content/translations/pt-br/06) Use Cases/web3/index.md
deleted file mode 100644
index 0ffc6c44361..00000000000
--- a/public/content/translations/pt-br/06) Use Cases/web3/index.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-title: O que é Web3 e por que é importante?
-description: Uma introdução à Web3 — a próxima evolução da Internet — e por que ela é importante.
-lang: pt-br
----
-
-# Introdução à Web3 {#introduction}
-
-A centralização ajudou a integrar bilhões de pessoas à World Wide Web e criou a infraestrutura estável e robusta em que ela vive. Ao mesmo tempo, um punhado de entidades centralizadas tem uma fortaleza em grandes áreas da World Wide Web, decidindo unilateralmente o que deve e o que não deve ser permitido.
-
-Web3 é a resposta para este dilema. Em vez de uma Web monopolizada por grandes empresas de tecnologia, a Web3 adota a descentralização e está sendo construída, operada e de propriedade de seus usuários. A Web3 coloca o poder nas mãos dos indivíduos e não das corporações. Antes de falarmos sobre Web3, vamos explorar como chegamos aqui.
-
-
-
-## O início da Web {#early-internet}
-
-A maioria das pessoas pensa na Web como um pilar contínuo da vida moderna – ela foi inventada e existe desde então. No entanto, a Web que a maioria de nós conhece hoje é bem diferente da imaginada originalmente. Para entender isso melhor, é útil dividir a breve história da Web em períodos separados — Web 1.0 e Web 2.0.
-
-### Web 1.0: Somente leitura (1990-2004) {#web1}
-
-Em 1989, no CERN, em Genebra, Tim Berners-Lee estava ocupado desenvolvendo os protocolos que se tornariam a World Wide Web. Sua ideia? Criar protocolos abertos e descentralizados que permitissem o compartilhamento de informações de qualquer lugar da Terra.
-
-O primeiro início da criação de Berners-Lee, agora conhecido como 'Web 1.0', ocorreu aproximadamente entre 1990 e 2004. A Web 1.0 era principalmente sites estáticos sob propriedade de empresas, e havia quase zero interação entre os usuários – indivíduos raramente produziam conteúdo – levando-o a ser conhecido como a web somente leitura.
-
-
-
-### Web 2.0: Leitura-escrita (2004-agora) {#web2}
-
-O período da Web 2.0 começou em 2004 com o surgimento das plataformas de mídia social. Em vez de apenas leitura, a web evoluiu para ser de leitura-escrita. Em vez de empresas que fornecem conteúdo aos usuários, elas também começaram a fornecer plataformas para compartilhar conteúdo gerado pelo usuário e se envolver em interações de usuário para usuário. À medida que mais pessoas se tornaram on-line, um punhado de grandes empresas começou a controlar uma quantidade desproporcional do tráfego e do valor gerado na web. A Web 2.0 também deu origem ao modelo de receita baseado em publicidade. Embora os usuários pudessem criar conteúdo, eles não o possuíam ou se beneficiavam de sua monetização.
-
-
-
-
-
-## Web 3.0: Leitura-escrita {#web3}
-
-A premissa da 'Web 3.0' foi criada pelo cofundador do [Ethereum](/what-is-ethereum/), Gavin Wood, logo após o lançamento do Ethereum em 2014. Gavin colocou em palavras uma solução para um problema que muitos dos primeiros adeptos de criptomoedas sentiram: a Web exigia muita confiança. Ou seja, a maior parte da Web que as pessoas conhecem e usam hoje depende da confiança em um punhado de empresas privadas para agir no melhor interesse do público.
-
-
-
-### O que é Web3? {#what-is-web3}
-
-A Web 3 tornou-se um termo abrangente para a visão de uma Internet nova e melhor. Na sua essência, a Web3 usa blockchains, criptomoedas e NFTs para devolver poder aos usuários sob a forma de propriedade. [Uma publicação de 2021 no Twitter](https://twitter.com/j1mmyeth/status/1459003044067258370) resumiu bem: Web1 foi somente leitura, Web2 é leitura/escrita, Web3 será leitura/escrita/própria.
-
-#### Principais ideias da Web3 {#core-ideas}
-
-Embora seja um desafio fornecer uma definição rígida do que é Web3, alguns princípios básicos orientam sua criação.
-
-- **Web3 é descentralizada:** em vez de grandes áreas da Internet controladas e de propriedade de entidades centralizadas, a propriedade é distribuída entre seus criadores e usuários.
-- **Web3 não tem permissão:** todos têm acesso igual para participar da Web3 e ninguém é excluído.
-- **A Web3 possui pagamentos nativos:** ela usa criptomoeda para gastar e enviar dinheiro on-line em vez de depender da infraestrutura desatualizada de bancos e processadores de pagamento.
-- **A Web3 tem com necessidade mínima de confiança:** ela opera usando incentivos e mecanismos econômicos em vez de depender de terceiros confiáveis.
-
-### Porque a Web3 é importante? {#why-is-web3-important}
-
-Embora os recursos matadores do Web3 não sejam isolados e não se encaixem em categorias limpas, por simplicidade, tentamos separá-los para torná-los mais fáceis de entender.
-
-#### Propriedade {#ownership}
-
-a Web3 dá-lhe posse dos seus ativos digitais de uma forma sem precedentes. Por exemplo, digamos que você está jogando um jogo web2. Se você comprar um item no jogo, ele ficará vinculado diretamente à sua conta. Se os criadores do jogo apagarem sua conta, você perderá esses itens. Ou, se você parar de jogar o jogo, você perde o valor que investiu nos seus itens no jogo.
-
-A Web3 permite a propriedade direta por meio de [tokens não fungíveis (NFTs)](/glossary/#nft). Ninguém, nem mesmo os criadores do jogo, consegue tirar sua propriedade. E, se você parar de jogar, pode vender ou trocar seus itens no jogo em mercados abertos e recuperar o seu valor.
-
-
-
Saiba mais sobre NFTs
-
- Mais sobre NFTs
-
-
-
-#### Resistência à censura {#censorship-resistance}
-
-A dinâmica de poder entre plataformas e criadores de conteúdo é massivamente desequilibrada.
-
-OnlyFans é um site de conteúdo adulto gerado pelo usuário com mais de 1 milhão de criadores de conteúdo, muitos dos quais usam a plataforma como sua principal fonte de renda. Em agosto de 2021, o OnlyFans anunciou planos para banir conteúdo sexualmente explícito. O anúncio provocou indignação entre os criadores na plataforma, que sentiram que estavam sendo privados de uma renda na plataforma que ajudaram a criar. Após a repercussão, a decisão foi rapidamente revertida. Apesar dos criadores vencerem essa batalha, isso destaca um problema para os criadores da Web 2.0: você perde a reputação e o número de seguidores acumulados se sair de uma plataforma.
-
-Na Web3, seus dados vivem no blockchain. Quando você decide sair de uma plataforma, pode levar sua reputação com você, conectando-a a outra interface que se alinhe mais claramente aos seus valores.
-
-A Web 2.0 exige que os criadores de conteúdo confiem nas plataformas para não alterar as regras, mas a resistência à censura é uma característica nativa de uma plataforma Web3.
-
-#### Organizações autônomas descentralizadas (DAOs) {#daos}
-
-Além de possuir seus dados na Web3, você pode possuir a plataforma como um coletivo, utilizando tokens que atuam como ações em uma empresa. As DAOs permitem que você coordene a propriedade descentralizada de uma plataforma e tome decisões sobre seu futuro.
-
-DAOs são definidos tecnicamente como [contratos inteligentes](/glossary/#smart-contract) acordados que automatizam a tomada de decisões descentralizada sobre um conjunto de recursos (tokens). Os usuários com tokens votam sobre como os recursos são gastos e o código executa automaticamente o resultado da votação.
-
-No entanto, as pessoas definem muitas comunidades Web3 como DAOs. Todas essas comunidades têm diferentes níveis de descentralização e automação por código. Atualmente, estamos explorando o que são DAOs e como elas podem evoluir no futuro.
-
-
-
Saiba mais sobre DAOs
-
- Mais sobre DAOs
-
-
-
-### Identidade {#identity}
-
-Geralmente, você cria uma conta para cada plataforma que usa. Por exemplo, você pode ter uma conta no Twitter, uma no YouTube e uma no Reddit. Deseja mudar o seu nome de exibição ou foto de perfil? Você tem que fazer isso em cada conta. Você pode usar logins sociais em alguns casos, mas isso apresenta um problema familiar: a censura. Em um único clique, estas plataformas podem bloquear você de toda sua vida on-line. Pior ainda, muitas plataformas exigem que você confie nelas informações de identificação pessoal para criar uma conta.
-
-A Web3 resolve esses problemas permitindo que você controle sua identidade digital com um endereço Ethereum e um perfil de [Serviço de Nomes Ethereum(ENS)](/glossary/#ens). O uso de um endereço Ethereum fornece um único login entre plataformas seguras, resistentes à censura e anônimas.
-
-### Pagamentos nativos {#native-payments}
-
-A infraestrutura de pagamento da Web2 depende de bancos e processadores de pagamento, excluindo pessoas sem contas bancárias ou aquelas que vivem dentro das fronteiras do país errado. A Web3 usa tokens como [ETH](/glossary/#ether) para enviar dinheiro diretamente no navegador e não requer terceiros confiáveis.
-
-
- Mais sobre ETH
-
-
-## Limitações da Web3 {#web3-limitations}
-
-Apesar dos inúmeros benefícios da Web3 em sua forma atual, ainda existem muitas limitações que o ecossistema deve abordar para que floresça.
-
-### Acessibilidade {#accessibility}
-
-Recursos importantes da Web3, como Entrar com Ethereum, ou seja, fazer login com o Ethereum, já estão disponíveis para qualquer pessoa usar a custo zero. Mas, o custo relativo das transações ainda é proibitivo para muitos. É menos provável que a Web3 seja utilizada em países menos ricos e em desenvolvimento devido às altas taxas de transação. No Ethereum, esses desafios estão sendo resolvidos por meio do [roteiro](/roadmap/) e das [soluções de dimensionamento da camada 2](/glossary/#layer-2). A tecnologia está pronta, mas precisamos de níveis mais altos de adoção na camada 2 para tornar a Web3 acessível a todos.
-
-### Experiência do usuário {#user-experience}
-
-A barreira técnica de entrada para o uso da Web3 é, atualmente, muito alta. Os usuários devem compreender as preocupações de segurança, entender a documentação técnica complexa e navegar por interfaces de usuário não intuitivas. Os [provedores de carteiras](/wallets/find-wallet/), em particular, estão trabalhando para resolver isso, mas é necessário um progresso maior para que a Web3 seja adotada em massa.
-
-### Instrução {#education}
-
-A Web3 introduz novos paradigmas que requerem o aprendizado de diferentes modelos mentais quando comparado com os usados na Web2.0. Uma motivação instrucional similar aconteceu quando a Web1.0 ganhou popularidade no final da década de 1990; os defensores da World Wide Web utilizaram uma grande quantidade de técnicas acadêmicas para instruir o público usando metáforas simples (a autoestrada da informação, navegadores, navegando na web) para [transmissões de televisão](https://www.youtube.com/watch?v=SzQLI7BxfYI). A Web3 não é difícil, mas é diferente. As iniciativas educacionais que informam os usuários da Web2 sobre esses paradigmas da Web3 são vitais para o seu sucesso.
-
-O Ethereum.org contribui para a instrução em Web3 através do nosso [Programa de Tradução](/contributing/translation-program/), que possui o objetivo de traduzir importantes conteúdos do Ethereum para o maior número possível de idiomas.
-
-### Infraestrutura centralizada {#centralized-infrastructure}
-
-O ecossistema Web3 é jovem e está evoluindo rapidamente. Como resultado, atualmente, depende principalmente de uma infraestrutura centralizada (GitHub, Twitter, Discord etc.). Muitas empresas Web3 estão correndo para preencher essas lacunas, mas, construir uma infraestrutura confiável e de alta qualidade, leva tempo.
-
-## Um futuro descentralizado {#decentralized-future}
-
-A Web3 é um ecossistema jovem e em evolução. Gavin Wood criou o termo em 2014, mas muitas destas ideias só recentemente se tornaram uma realidade. Somente no ano passado, houve um aumento considerável no interesse em criptomoedas, melhorias nas soluções de dimensionamento da camada 2, experimentos maciços com novas formas de governança e revoluções na identidade digital.
-
-Estamos apenas no início da criação de uma Web melhor com a Web3, mas à medida que continuamos a melhorar a infraestrutura que a suportará, o futuro da Web parece brilhante.
-
-## Como posso participar {#get-involved}
-
-- [Obtenha uma carteira](/wallets/)
-- [Encontre uma comunidade](/community/)
-- [Explore aplicativos Web3](/dapps/)
-- [Participe de uma DAO](/dao/)
-- [Construir na Web3](/developers/)
-
-## Leitura adicional {#further-reading}
-
-Web3 não é rigidamente definida. Vários participantes da comunidade têm diversas perspectivas sobre isso. Veja aqui alguns deles:
-
-- [O que é Web3? A Internet Descentralizada do Futuro Explicada](https://www.freecodecamp.org/news/what-is-web3/) – _Nader Dabit_
-- [Compreendendo a Web 3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _Josh Stark_
-- [Por que a Web3 é Importante?](https://future.a16z.com/why-web3-matters/) — _Chris Dixon_
-- [Por que a descentralização é importante?](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) _Feb-, - Chris Dixon_
-- [O Cenário Web3](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_
-- [O Debate Web3](https://www.notboring.co/p/the-web3-debate?s=r) – _Packy McCormick_
-
-
diff --git a/public/content/translations/pt-br/07) Staking Pages/staking/dvt/index.md b/public/content/translations/pt-br/07) Staking Pages/staking/dvt/index.md
deleted file mode 100644
index a23dcc47052..00000000000
--- a/public/content/translations/pt-br/07) Staking Pages/staking/dvt/index.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Tecnologia de validador distribuído
-description: A tecnologia de validador distribuído permite a operação distribuída de um validador Ethereum por diversas partes.
-lang: pt-br
----
-
-# Tecnologia de validador distribuído {#distributed-validator-technology}
-
-A tecnologia de validador distribuído (DVT) é uma abordagem à segurança do validador que distribui as responsabilidades de assinatura e gerenciamento de chaves entre diversas partes para reduzir pontos únicos de falha e aumentar a resiliência do validador.
-
-Ela faz isso ao **dividir a chave privada** usada para proteger um validador **em muitos computadores** organizados em um "cluster". A vantagem disso é que fica muito difícil para os invasores obterem acesso à chave, pois ela não é armazenada integralmente em um único computador. Ele também permite que alguns nós fiquem offline, pois a assinatura necessária pode ser feita por um subconjunto de computadores em cada cluster. Isso reduz os pontos únicos de falha da rede e faz com que todo o conjunto de validadores seja mais eficiente.
-
-
-
-## Por que precisamos de DVT? {#why-do-we-need-dvt}
-
-### Segurança {#security}
-
-Os validadores geram dois pares de chaves público-privadas: chaves de validador para participar do consenso e chaves de saque para acessar os fundos. Embora os validadores possam proteger as chaves de saque em armazenamento a frio, as chaves privadas do validador devem estar online 24 horas por dia, 7 dias por semana. Se uma chave privada do validador for comprometida, um invasor poderá controlar o validador, o que pode causar o corte ou a perda da ETH do participante. A DVT pode ajudar a mitigar esse risco. Veja como:
-
-Ao usar o DVT, os stakers podem participar da participação e, ao mesmo tempo, manter a chave privada do validador em um armazenamento a frio. Isso é feito por meio da criptografia da chave original e completa do validador e, em seguida, dividindo-a em compartilhamentos de chave. Os compartilhamentos de chaves ficam online e são distribuídos a diversos nós, o que permite a operação distribuída do validador. Isso é possível porque os validadores Ethereum utilizam assinaturas BLS que são aditivas, o que significa que a chave completa pode ser reconstruída pela soma das respectivas partes componentes. Isso permite que o participante mantenha a chave validadora "mestre" original completa e segura offline.
-
-### Sem pontos únicos de falha {#no-single-point-of-failure}
-
-Quando um validador é dividido entre diversos operadores e vários computadores, ele pode resistir a falhas individuais de hardware e software sem ficar offline. Também é possível reduzir o risco de falhas ao utilizar diversas configurações de hardware e software nos nós de um cluster. Essa resiliência não está disponível para configurações de validador de um único nó, pois deriva da camada DVT.
-
-Se um dos componentes de um computador em um cluster ficar inoperante (por exemplo, se houver quatro operadores em um cluster de validadores e um deles utilizar um cliente específico com um bug), os outros garantem que o validador continue funcionando.
-
-### Descentralização {#decentralization}
-
-O cenário ideal para o Ethereum é ter o maior número possível de validadores operados de maneira independente. Entretanto, alguns provedores de participação se tornaram muito populares e respondem por uma parte considerável do total de ETH em participação na rede. A DVT pode permitir a existência desses operadores e, ao mesmo tempo, manter a descentralização da participação. Isso ocorre porque as chaves de cada validador são distribuídas em diversos computadores e seria necessária uma conspiração muito maior para que um validador se tornasse mal-intencionado.
-
-Sem a DVT, é mais fácil para os provedores de participação oferecerem suporte a apenas uma ou duas configurações de cliente a todos os validadores, o que aumenta o impacto de um bug no cliente. A DVT pode ser utilizada para distribuir o risco entre diversas configurações de clientes e diferentes hardwares, criando resiliência por meio da diversidade.
-
-**A DVT oferece os seguintes benefícios ao Ethereum:**
-
-1. **Descentralização** do consenso da prova de participação do Ethereum
-2. Garante a **vivacidade** da rede
-3. Cria a **tolerância a falhas** do validador
-4. **Operação do validador** com confiança minimizada
-5. Riscos **minimizados de remoção** e tempo de inatividade
-6. **Melhora a diversidade** (cliente, centro de dados, localização, regulação etc.)
-7. **Segurança aprimorada** do gerenciamento de chaves do validador
-
-## Como a DVT funciona? {#how-does-dvt-work}
-
-Uma solução DVT contém os seguintes componentes:
-
-- **[Compartilhamento secreto Shamir](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - Os validadores utilizam [chaves BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). O "compartilhamento de chaves" BLS individuais ("key shares") pode ser combinado em uma única chave agregada (assinatura). Na DVT, a chave privada de um validador é a assinatura BLS combinada de cada operador no cluster.
-- **[O esquema de assinatura com limite](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** - Determina o número de compartilhamentos de chaves individuais que são necessárias para funções de assinatura, por exemplo, 3 de 4.
-- **[Geração distribuída de chaves (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** - Processo criptográfico que gera os compartilhamentos de chaves e é usado para distribuir os compartilhamentos de uma chave do validador existente ou nova para os nós em um cluster.
-- **[Computação multipartidária (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** - A chave completa do validador é gerada em segredo por meio de computação multipartidária. A chave completa nunca é conhecida por nenhum operador individual, cada validador conhece apenas a sua própria parte dela (o "compartilhamento").
-- **Protocolo de consenso** - O protocolo de consenso seleciona um nó para ser o proponente do bloco. Eles compartilham o bloco com os outros nós do cluster, que adicionam seus compartilhamentos de chave à assinatura agregada. Após a agregação de um número suficiente de compartilhamentos de chaves, o bloco é proposto no Ethereum.
-
-Os validadores distribuídos têm tolerância a falhas incorporada e podem continuar funcionando mesmo com alguns dos nós individuais offline. Isso significa que o cluster é resiliente mesmo que alguns dos nós sejam mal-intencionados ou preguiçosos.
-
-## Casos de uso de DVT {#dvt-use-cases}
-
-A DVT tem implicações significativas para o setor mais amplo de participação:
-
-### Participantes (stakers) individuais {#solo-stakers}
-
-A DVT também possibilita a participação sem custódia, o que permitindo distribuir a chave do validador entre nós remotos, mantendo a chave completa completamente offline. Isso significa que os participantes internos não precisam necessariamente investir em hardware, enquanto a distribuição dos compartilhamentos de chaves pode ajudar a fortalecê-los contra possíveis hacks.
-
-### Participação como Serviço (SaaS) {#saas}
-
-Os operadores (como pools de participação e participantes institucionais) que gerenciam muitos validadores podem utilizar a DVT para reduzir o risco. Ao distribuir a infraestrutura, eles podem adicionar redundância às operações e diversificar os tipos de hardware utilizado.
-
-A DVT compartilha a responsabilidade pelo gerenciamento de chaves em diversos nós, ou seja, alguns custos operacionais também podem ser compartilhados. A DVT também pode reduzir o risco operacional e os custos de seguro para os provedores de participação.
-
-### Pools de participação (staking) {#staking-pools}
-
-Devido às configurações padrão dos validadores, os pools de participação e os provedores de participação líquida têm a obrigação de ter níveis variados de confiança em um único operador, uma vez que os ganhos e as perdas são socializados em todo o pool. Também dependem dos operadores para proteger as chaves de assinatura porque, até agora, não havia outra opção disponível.
-
-Embora tradicionalmente sejam feitos esforços para distribuir o risco por meio da distribuição de participações entre diversos operadores, cada operador ainda gerencia uma participação considerável de maneira independente. Depender de um único operador representa riscos imensos se o desempenho for abaixo do esperado, se enfrentar um período de inatividade, se for comprometido ou agir de maneira mal-intencionada.
-
-Ao utilizar a DVT, a confiança exigida dos operadores reduz consideravelmente. **Os pools podem permitir que os operadores mantenham participações sem a necessidade de custódia de chaves de validador** (pois apenas os compartilhamentos da chave são utilizados). Também permite que as participações gerenciadas sejam distribuídas entre mais operadores (por exemplo, em vez de um único operador gerenciar mil validadores, a DVT permite que esses validadores sejam executados coletivamente por diversos operadores). Diversas configurações de operador garantirão que, se um operador ficar inoperante, os outros ainda poderão atestar. Isso resulta em redundância e diversificação, o que permite um melhor desempenho e resiliência, ao mesmo tempo em que maximiza as recompensas.
-
-Outra vantagem de minimizar a confiança em um único operador é que os pools de participação podem permitir um envolvimento mais aberto e sem necessidade de permissão do operador. Ao fazer isso, os serviços podem reduzir os riscos e apoiar a descentralização do Ethereum ao utilizar conjuntos de operadores selecionados e sem permissão, por exemplo, ao emparelhar participantes internos ou secundários com participantes maiores.
-
-## Possíveis desvantagens do uso da DVT {#potential-drawbacks-of-using-dvt}
-
-- **Componente adicional** - a introdução de um nó da DVT adiciona outra parte que pode estar com defeito ou vulnerável. Uma forma de atenuar esse problema é buscar várias implementações de um nó da DVT, o que significa vários clientes de DVT (da mesma forma que há vários clientes para as camadas de consenso e execução).
-- **Custos operacionais** - como a DVT distribui o validador entre diversas partes, são necessários mais nós para a operação, em vez de apenas um único nó, o que aumenta os custos operacionais.
-- **Latência potencialmente maior** - como a DVT utiliza um protocolo de consenso para obter consenso entre os diversos nós que operam um validador, é possível ocorrer um aumento da latência.
-
-## Leitura adicional {#further-reading}
-
-- [Especificações do validador distribuído no Ethereum (detalhadas)](https://github.com/ethereum/distributed-validator-specs)
-- [Especificações técnicas do validador distribuído no Ethereum](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec)
-- [Aplicativo de demonstração de compartilhamento secreto Shamir](https://iancoleman.io/shamir/)
diff --git a/public/content/translations/pt-br/07) Staking Pages/staking/pools/index.md b/public/content/translations/pt-br/07) Staking Pages/staking/pools/index.md
deleted file mode 100644
index 151d6735e49..00000000000
--- a/public/content/translations/pt-br/07) Staking Pages/staking/pools/index.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Staking em pool (combinado)
-description: Uma visão geral de como começar com pools de staking de ETH
-lang: pt-br
-template: staking
-emoji: ":money_with_wings:"
-image: /images/staking/leslie-pool.png
-alt: Leslie, o rinoceronte, nadando na piscina
-sidebarDepth: 2
-summaryPoints:
- - Faça staking e ganhe recompensas com qualquer quantia de ETH unindo forças com outros
- - Pule a parte difícil e delegue a operação de validação a terceiros
- - Mantenha os tokens participados na sua carteira
----
-
-## O que são pools de participação? {#what-are-staking-pools}
-
-Os pools de participação são uma abordagem colaborativa para permitir que muitos com quantidades menores de ETH obtenham os 32 ETH necessários para ativar um conjunto de chaves de validador. A funcionalidade de pooling não é nativamente suportada no protocolo, então soluções foram construídas separadamente para resolver essa necessidade.
-
-Alguns pools operam usando contratos inteligentes, onde os fundos podem ser depositados em um contrato, que gerencia e controla com necessidade mínima de confiança seu stake, e lhe emite um token que representa esse valor. Outros pools podem não envolver contratos inteligentes e, em vez disso, são mediadas fora da cadeia.
-
-## Por que fazer participação com um pool? {#why-stake-with-a-pool}
-
-Além dos benefícios delineados em nossa [introdução ao staking](/staking/), fazer stake em um pool traz alguns benefícios distintos.
-
-
-
-
-
-
-
-
-
-## O que considerar {#what-to-consider}
-
-Staking delegado ou em pools não é nativamente suportado pelo protocolo Ethereum, mas dada a demanda para que os usuários façam staking com menos de 32 ETH, um número crescente de soluções para servir esta demanda foram construídas.
-
-Cada pool, assim como as ferramentas ou contratos inteligentes que eles usam, foram construídos por diferentes times, e cada um tem seus benefícios e riscos. Os pools permitem que os usuários troquem ETH por um token representativo do ETH em depósito. O token é útil porque permite que os usuários troquem qualquer quantidade de ETH por uma quantidade equivalente de um token com rendimento que gera um retorno das recompensas de staking (participação) aplicadas ao ETH subjacente participado (e vice-versa) em corretoras descentralizadas, embora o ETH real permaneça em staking na camada de consenso. Isso significa que a troca de um produto ETH com rendimento em participação e “ETH bruto” é rápido, fácil e não apenas disponível em múltiplos de 32 ETH.
-
-Entretanto, esses tokens de ETH participado tendem a criar comportamentos semelhantes a cartéis, em que uma grande quantidade de ETH participado acaba sob o controle de algumas organizações centralizadas, em vez de ser distribuída entre diversos indivíduos independentes. Isso cria condições para censura ou extração de valor. O padrão ouro para participação deveria sempre ser indivíduos executando validadores em seu próprio hardware sempre que possível.
-
-[Mais sobre os riscos de tokens em participação](https://notes.ethereum.org/@djrtwo/risks-of-lsd).
-
-Os indicadores de atributo são usados abaixo para sinalizar notáveis pontos fortes ou fracos que um staking pool listado pode ter. Utilize esta seção como referência de como definimos estes atributos enquanto você está escolhendo participar de um pool.
-
-
-
-## Explore pools de participação {#explore-staking-pools}
-
-Há uma variedade de opções disponíveis para ajudá-lo na sua configuração. Use os indicadores acima para guiá-lo pelas ferramentas abaixo.
-
-
-
-
-
-Observe a importância de escolher um serviço que leve a sério a [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity/), pois isso aumenta a segurança da rede e limita seu risco. Os serviços que têm evidências de limitação do uso do cliente majoritário são indicados com "diversidade do cliente de execução" e "diversidade do cliente de consenso".
-
-Alguma sugestão de ferramenta de participação que não mencionamos? Leia a nossa [política de listagem de produtos](/contributing/adding-staking-products/) para ver se a sugestão é pertinente e para enviá-la para análise.
-
-## Perguntas frequentes {#faq}
-
-
-Normalmente, os tokens de participação ERC-20 são emitidos para participantes (stakers) e representam o valor de ETH em stake, mais as recompensas. Lembre-se de que diferentes pools distribuirão recompensas de staking para seus usuários por meio de métodos minimamente diferentes, mas esse é o assunto comum.
-
-
-
-Agora mesmo! A atualização da rede Shanghai/Capella ocorreu em abril de 2023 e introduziu saques de staking. As contas dos validadores que dão suporte aos pools de staking agora têm a capacidade de sair e sacar ETH para o endereço de saque designado. Isso permite resgatar sua parte do stake para o ETH subjacente. Verifique com o seu provedor para ver como eles dão suporte a essa funcionalidade.
-
-Como alternativa, os pools que utilizam um token de participação ERC-20 permitem que os usuários negociem esse token no mercado aberto, o que possibilita a venda da posição de participação, com "saque" sem realmente remover o ETH do contrato de participação.
-
-Mais sobre retirada de participação
-
-
-
-Existem muitas semelhanças entre essas opções de staking em pools agrupadas e trocas centralizadas, como a capacidade de fazer entrega de pequenas quantidades de ETH e fazê-los juntar para ativar validadores.
-
-Ao contrário das corretoras centralizadas, muitas outras opções de participação em pool utilizam contratos inteligentes e/ou tokens em participação, que normalmente são tokens ERC-20 que podem ser mantidos na sua carteira, e comprados ou vendidos como qualquer outro token. Isso oferece uma camada de soberania e segurança, dando-lhe controle sobre seus tokens, mas ainda não lhe dá controle direto sobre o cliente validador atestando em seu nome em segundo plano.
-
-Algumas opções de pooling são mais descentralizadas do que outras quando se trata dos nós que os sustentam. Para promover a saúde e a descentralização da rede, os participantes são sempre encorajados a selecionar um serviço de pooling (compartilhamento) que ofereça um conjunto descentralizado de operadores de nós sem permissão.
-
-
-## Leitura adicional {#further-reading}
-
-- [O diretório de staking Ethereum](https://www.staking.directory/) - _Eridian e Spacesider_
-- [Fazendo stake com a Rocket Pool – Visão global de staking](https://docs.rocketpool.net/guides/staking/overview.html) - _Documentação do Rocket Pool_
-- [Staking Ethereum com Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _Documentação de ajuda Lido_
diff --git a/public/content/translations/pt-br/07) Staking Pages/staking/saas/index.md b/public/content/translations/pt-br/07) Staking Pages/staking/saas/index.md
deleted file mode 100644
index a22a65a437a..00000000000
--- a/public/content/translations/pt-br/07) Staking Pages/staking/saas/index.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Staking como um serviço
-description: Uma visão geral de como começar com os pools de staking de ETH
-lang: pt-br
-template: staking
-emoji: ":money_with_wings:"
-image: /images/staking/leslie-saas.png
-alt: Leslie, o rinoceronte, flutuando nas nuvens
-sidebarDepth: 2
-summaryPoints:
- - Operadores de nó terceirizados lidam com a operação de seu cliente validador
- - Uma ótima opção para qualquer pessoa com 32 ETH que não se sinta confortável em lidar com a complexidade técnica da execução de um nó
- - Reduza a confiança, e mantenha a posse de suas chaves de saque
----
-
-## O que é staking como um serviço? {#what-is-staking-as-a-service}
-
-Staking como um serviço ("SaaS") representa uma categoria de serviços de staking onde você deposita seus próprios 32 ETH para um validador, mas delega operações de nó para um operador terceirizado. Este processo geralmente envolve ser guiado pela configuração inicial, incluindo a geração de chaves e depósito, e depois enviar suas chaves de assinatura para o operador. Isso permite que o serviço opere seu validador em seu nome, geralmente com uma taxa mensal.
-
-## Por que fazer staking com um serviço? {#why-stake-with-a-service}
-
-O protocolo Ethereum não suporta nativamente a delegação de stake, portanto esses serviços foram construídos para cumprir esta demanda. Se você tem 32 ETH para stake, mas não se sente à vontade para lidar com hardware, os serviços SaaS permitem que você delegue a parte difícil enquanto ganha recompensas nativas do bloco.
-
-
-
-
-
-
-
-
-
-## O que considerar {#what-to-consider}
-
-Há um número cada vez maior de provedores de SaaS para ajudar você a fazer participação com os seus ETH, mas todos têm benefícios e riscos. Todas as opções de SaaS exigem uma confiança adicional em comparação a fazer staking internamente. As opções SaaS podem ter código adicional envolvendo os clientes Ethereum que não são abertos ou auditáveis. O SaaS também tem um efeito prejudicial na descentralização da rede. Dependendo da configuração, você pode não controlar seu validador — o operador pode agir de forma desonesta usando seu ETH.
-
-Os indicadores de atributo são usados abaixo para sinalizar os pontos fortes ou fracos notáveis que um pool de staking pode ter. Utilize esta seção como referência de como definimos estes atributos enquanto você está escolhendo um serviço para auxiliar em sua jornada de staking.
-
-
-
-## Explore provedores de serviços de staking {#saas-providers}
-
-Abaixo estão alguns provedores de SaaS disponíveis. Use os indicadores acima para guiá-lo pelos serviços abaixo
-
-
-
-### Provedores de SaaS
-
-
-
-Observe a importância de escolher um serviço que leve a [diversidade de cliente](/developers/docs/nodes-and-clients/client-diversity/) a sério, à medida que melhora a segurança da rede e limita o seu risco. Os serviços que têm evidências de limitação do uso do cliente majoritário são indicados com "diversidade do cliente de execução" e "diversidade do cliente de consenso".
-
-### Geradores de chaves
-
-
-
-Alguma sugestão de um provedor de SaaS que não foi mencionado? Leia a nossa [política de listagem de produtos](/contributing/adding-staking-products/) para ver se a sugestão é pertinente e para enviá-la para análise.
-
-## Perguntas frequentes {#faq}
-
-
-As disposições diferem de provedor para provedor, mas geralmente você será guiado pela configuração de quaisquer chaves de assinatura que você precise (uma a cada 32 ETH), e terá que enviar estas para o seu provedor para permitir que validem em seu nome. Só as chaves de assinatura não oferecem nenhuma possibilidade de saque, transferência ou gasto dos seus fundos. Entretanto, elas proporcionam a capacidade de votar em consensos, o que, se não for feito adequadamente, pode resultar em sanções ou em cortes off-line.
-
-
-
-Sim. Cada conta é composta por ambas chaves de assinatura BLS, e as chaves de saque BLS. Para que um validador ateste o estado da cadeia, participe de comitês de sincronização e proponha blocos, as chaves de assinatura devem estar prontamente acessíveis por um cliente validador. Elas devem estar conectadas à internet de alguma forma, portanto, são inerentemente consideradas chaves "quentes". Este é um requisito para as confirmações do seu validador, portanto, as chaves usadas para transferir ou sacar fundos são separadas por razões de segurança.
-
-As chaves de retirada BLS são usadas para assinar uma mensagem de uso único que declara para qual conta de execução de uma conta de recompensas de participação e fundos sacados elas devem ir. Uma vez que essa mensagem é transmitida, as chaves de saque de BLS não são mais necessárias. Em vez disso, o controle sobre os fundos retirados é permanentemente delegado ao endereço que você forneceu. Isso permite que você defina um endereço de retirada protegido por meio do seu próprio armazenamento frio, minimizando o risco para seus fundos de validador, mesmo se outra pessoa controlarem suas chaves de assinatura de validador.
-
-A atualização das credenciais de saque é uma etapa necessária para habilitar saques\*. Esse processo envolve gerar as chaves de retirada usando sua frase semente mnemônica.
-
-Certifique-se de fazer backup dessa frase de recuperação com segurança ou você não conseguirá gerar suas chaves de saque quando precisar.
-
-\*Os stakers que forneceram um endereço de saque com depósito inicial não precisam definir isso. Consulte com seu provedor SaaS para obter suporte sobre como preparar seu validador.
-
-
-
-Os saques de staking foram implementados na atualização Shanghai/Capella em abril de 2023. Os stakers precisam fornecer um endereço de saque (se não tiver sido fornecido no depósito inicial) e os pagamentos de recompensa começarão a ser distribuídos de forma automática periodicamente em intervalos de alguns dias.
-
-Os validadores também podem sair totalmente como validadores, o que desbloqueará seus saldos de ETH restantes para saque. As contas que forneceram um endereço de saque para execução e concluíram o processo de saída receberão todo o seu saldo no endereço de saque fornecido durante a próxima varredura do validador.
-
-Mais sobre saques de participação
-
-
-
-Usando um provedor SaaS, você está confiando a operação do seu nó a um terceiro. Isto implica o risco de um desempenho deficiente, que não está sob o seu controle. Caso seu validador seja cortado, seu saldo do validador será penalizado e removido à força da pool do validador.
-
-Após a conclusão do processo de remoção/saída, esses fundos serão transferidos para o endereço de saque atribuído ao validador. Para isso, é necessário habilitar um endereço de saque. Ela pode ter sido fornecida no depósito inicial. Caso contrário, será necessário usar as chaves de saque do validador para assinar uma mensagem declarando um endereço de saque. Os fundos permanecerão bloqueados até um endereço de saque ser fornecido.
-
-Entre em contato com o provedor de SaaS para obter mais detalhes sobre quaisquer garantias ou opções de seguro e instruções sobre como fornecer um endereço de saque. Se você preferir estar no controle total da sua configuração do validador, saiba mais sobre como fazer staking individual de seu ETH.
-
-
-## Leitura adicional {#further-reading}
-
-- [O diretório de staking Ethereum](https://www.staking.directory/) - _Eridian e Spacesider_
-- [Avaliando os Serviços de Staking](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_
diff --git a/public/content/translations/pt-br/07) Staking Pages/staking/solo/index.md b/public/content/translations/pt-br/07) Staking Pages/staking/solo/index.md
deleted file mode 100644
index b9d786ee6b8..00000000000
--- a/public/content/translations/pt-br/07) Staking Pages/staking/solo/index.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-title: Faça staking indivual com seu ETH
-description: Uma visão geral de como começar a fazer staking individual com seu ETH
-lang: pt-br
-template: staking
-emoji: ":money_with_wings:"
-image: /images/staking/leslie-solo.png
-alt: Leslie, o rinoceronte, em seu próprio chip de computador
-sidebarDepth: 2
-summaryPoints:
- - Receba recompensas máximas diretamente do protocolo para manter seu validador funcionando corretamente e on-line
- - Execute o hardware local e adicione pessoalmente à segurança e descentralização da rede Ethereum
- - Remova a confiança e nunca desista do controle das chaves dos seus fundos
----
-
-## O que é staking individual? {#what-is-solo-staking}
-
-O staking individual é o ato de [executar um nó Ethereum](/run-a-node/) conectado à Internet e depositar 32 ETH para ativar um [validador](#faq), dando a você a capacidade de participar diretamente do consenso da rede.
-
-**A participação individual aumenta a descentralização da rede Ethereum**, tornando o Ethereum mais resistente a censura e ataques. Outros métodos de participação podem não ajudar a rede da mesma maneira. A participação individual é a melhor opção de participação para proteger o Ethereum.
-
-Um nó Ethereum consiste em um cliente de camada de execução (EL) e em um cliente de camada de consenso (CL). Esses clientes são softwares que trabalham em conjunto, juntamente com um conjunto válido de chaves de assinatura, para verificar transações e blocos, atestar o bloco correto no topo da cadeia, agregar atestações e propor blocos.
-
-Os stakers individuais são responsáveis por operar o hardware necessário para executar esses clientes. É altamente recomendável usar uma máquina dedicada para isso, que você opera em casa – isso é extremamente benéfico para a saúde da rede.
-
-Um staker individual recebe recompensas diretamente do protocolo por manter seu validador funcionando corretamente e on-line.
-
-## Por que fazer staking individual? {#why-stake-solo}
-
-A participação individual vem com mais responsabilidades, mas fornece o máximo de controle sobre seus fundos e configuração de participação.
-
-
-
-
-
-
-
-## Considerações antes de fazer staking individual {#considerations-before-staking-solo}
-
-Por mais que desejemos que o staking individual fosse acessível e sem riscos para todos, isso não é a realidade. Existem algumas considerações práticas e sérias a serem lembradas antes de optar por fazer staking individual de seu ETH.
-
-
-
-Ao operar seu próprio nó, você deve gastar algum tempo aprendendo a usar o software que escolheu. Isso envolve ler a documentação relevante e estar em sintonia com os canais de comunicação dessas equipes de desenvolvimento.
-
-Quanto mais você entender sobre o software que está executando e como funciona a prova de participação (proof of sake), menos arriscado será como um staker e mais fácil será corrigir quaisquer problemas que possam surgir ao longo do caminho como operador de nó.
-
-
-
-A configuração do nó requer um nível de conforto razoável ao trabalhar com computadores, embora novas ferramentas estejam tornando isso mais fácil com o tempo. A compreensão da interface de linha de comando é útil, mas não é mais estritamente necessária.
-
-Também requer uma configuração de hardware muito básica e alguma compreensão das especificações mínimas recomendadas.
-
-
-
-Assim como as chaves privadas protegem seu endereço Ethereum, você precisará gerar chaves especificamente para seu validador. Você precisa compreender como manter qualquer frase semente ou chave privada protegida e segura.{' '}
-
-Segurança Ethereum e prevenção à fraude
-
-
-
-O hardware falha ocasionalmente, as conexões de rede falham e o software cliente ocasionalmente precisa ser atualizado. A manutenção do nó é inevitável e ocasionalmente exigirá sua atenção. Você deve estar ciente de quaisquer informações de atualizações de rede ou outras atualizações críticas de clientes.
-
-
-
-Suas recompensas são proporcionais ao tempo que seu validador está on-line e atestando corretamente. O tempo de inatividade incorre em penalidades proporcionais a quantos outros validadores estão off-line ao mesmo tempo, mas não resulta em cortes. A largura de banda também é importante, pois as recompensas são reduzidas para declarações que não são recebidos a tempo. Os requisitos variam, mas é recomendado um mínimo de 10 Mb/s de upload e download.
-
-
-
-Diferente das penalidades de inatividade por estar off-line, o corte é uma penalidade muito mais séria reservada para infrações maliciosas. Ao executar um cliente minoritário com suas chaves carregadas em apenas uma máquina por vez, o risco de ser cortado é minimizado. Dito isto, todos os stakers devem estar cientes dos riscos de serem cortados.
-
- Mais informações sobre o ciclo de vida do validador e remoção
-
-
-
-
-
-## Como funciona {#how-it-works}
-
-
-
-Enquanto ativo, você ganhará recompensas ETH, que serão depositadas periodicamente no seu endereço de saque.
-
-Se desejar, você pode parar suas atividades como um validador, o que elimina a necessidade de estar on-line e interrompe outras recompensas. O seu saldo restante será sacado para o endereço de saque que você indicou durante a configuração.
-
-[Mais sobre saques de participação](/staking/withdrawals/)
-
-## Comece a usar o Staking Launchpad {#get-started-on-the-staking-launchpad}
-
-O Staking Launchpad é um aplicativo de código aberto que o ajudará a se tornar um staker. Ele o guiará na escolha de seus clientes, gerará suas chaves e depositará seu ETH no contrato de depósito de staking. Uma lista de verificação é fornecida para garantir que você cobriu tudo para configurar seu validador com segurança.
-
-
-
-## O que considerar com ferramentas de configuração de nó e cliente {#node-tool-considerations}
-
-Há um número crescente de ferramentas e serviços para ajudá-lo a fazer staking individualmente de seu ETH, mas cada um vem com diferentes riscos e benefícios.
-
-Os indicadores de atributo são usados abaixo para sinalizar pontos fortes ou fracos notáveis que uma ferramenta de staking listada pode ter. Use esta seção como referência de como definimos esses atributos enquanto você escolhe quais ferramentas ajudarão em sua jornada de staking.
-
-
-
-## Explore as ferramentas de configuração de nós e clientes {#node-and-client-tools}
-
-Há uma variedade de opções disponíveis para ajudá-lo na sua configuração. Use os indicadores acima para guiá-lo pelas ferramentas abaixo.
-
-
-
-### Ferramentas do nó
-
-
-
-Observe a importância de escolher um [cliente minoritário](/developers/docs/nodes-and-clients/client-diversity/), pois melhora a segurança da rede e limita seu risco. As ferramentas que permitem configurar um cliente minoritário são descritas como "multicliente."
-
-### Geradores de chaves
-
-Essas ferramentas podem ser utilizadas como uma alternativa à [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) para ajudar na geração de chaves.
-
-
-
-Alguma sugestão de ferramenta de participação que não mencionamos? Leia a nossa [política de listagem de produtos](/contributing/adding-staking-products/) para ver se a sugestão é pertinente e para enviá-la para análise.
-
-## Explore os guias de staking individual {#staking-guides}
-
-
-
-## Perguntas frequentes {#faq}
-
-Apresentamos algumas das perguntas mais comuns sobre staking (participação) que vale a pena saber.
-
-
-
-Um validador é uma entidade virtual que vive no Ethereum e participa no consenso do protocolo Ethereum. Os validadores são representados por um saldo, chave pública e outras propriedades. Um cliente validador é o software que atua em nome do validador mantendo e usando sua chave privada. Um único cliente validador pode conter muitos pares de chaves, controlando muitos validadores.
-
-
-
-
-Cada par de chaves associado a um validador requer exatamente 32 ETH para ser ativado. Mais ETH depositado em um único conjunto de chaves não aumenta o potencial de recompensas, pois cada validador está limitado a um saldo efetivo de 32 ETH. Isso significa que o staking é feito em 32 incrementos de ETH, cada um com seu próprio conjunto de chaves e saldo.
-
-Não deposite mais de 32 ETH para um único validador. Isso não aumentará suas recompensas. Se um endereço de saque tiver sido definido para o validador, os fundos excedentes acima de 32 ETH serão automaticamente sacados para esse endereço durante a próxima varredura do validador.
-
-Se o staking individual demandar muito de você, considere usar um provedor de staking-as-a-service (staking como um serviço) ou, se estiver trabalhando com menos de 32 ETH, verifique as staking pools (pools de staking).
-
-
-
-Ficar off-line quando a rede estiver finalizando corretamente NÃO resultará em cortes. Pequenas penalidades por inatividade são incorridas se o seu validador não estiver disponível para atestar determinado período (cada um com 6,4 minutos de duração), mas isso é muito diferente de um corte. Essas penalidades são um pouco menores do que a recompensa que você ganharia se o validador estivesse disponível para atestar, e as perdas podem ser recuperadas com aproximadamente a mesma quantidade de tempo novamente on-line.
-
-Observe que as penalidades por inatividade são proporcionais a quantos validadores estão off-line ao mesmo tempo. Nos casos em que uma grande parte da rede estiver toda off-line ao mesmo tempo, as penalidades para cada um desses validadores serão maiores que quando um único validador estiver indisponível.
-
-Em casos extremos, se a rede parar de finalizar como resultado de mais de um terço dos validadores estarem off-line, esses usuários sofrerão o sendo conhecido como vazamento de inatividade quadrática, sendo um dreno exponencial de ETH de contas de validador off-line. Isso permite que a rede se recupere eventualmente queimando o ETH de validadores inativos até que seu saldo atinja 16 ETH, momento em que eles serão automaticamente ejetados da pool de validadores. Os validadores on-line restantes acabarão por abranger mais de 2/3 da rede novamente, satisfazendo a maioria qualificada necessária para finalizar mais uma vez a cadeia.
-
-
-
-Em resumo, isso nunca pode ser totalmente garantido, mas se você agir de boa-fé, executar um cliente minoritário e manter suas chaves de assinatura em apenas uma máquina por vez, o risco de ser cortado é quase zero.
-
-Existem apenas algumas maneiras específicas que podem resultar em um corte e expulsão de um validador da rede. No momento da redação deste texto, os cortes que ocorreram foram exclusivamente um produto de configurações de hardware redundantes onde as chaves de assinatura são armazenadas em duas máquinas separadas ao mesmo tempo. Isso pode resultar inadvertidamente em um voto duplo de suas chaves, o que é uma infração passível de corte.
-
-A execução de um cliente supermajoritário (qualquer cliente usado por mais de 2/3 da rede) também apresenta o risco de cortes em potencial caso esse cliente tenha uma falha que resulte em uma bifurcação da cadeia. Isso pode resultar em uma bifurcação com falha que será finalizada. Para corrigir de volta para a cadeia pretendida, seria necessário enviar um voto cercado (surround vote), na tentativa de desfazer um bloco finalizado. Essa também é uma infração que pode incorrer em um corte e pode ser evitada simplesmente por executar um cliente minoritário.
-
-Falhas equivalentes em um cliente minoritário jamais seriam finalizadas, portanto, nunca resultariam em um voto cercado, e simplesmente resultariam em penalidades de inatividade, não em cortes.
-
-
-
-
-
-Os clientes individuais podem variar um pouco em desempenho e interface do usuário, pois cada um é desenvolvido por equipes diferentes usando uma variedade de linguagens de programação. Assim sendo, nenhum deles é "melhor". Todos os clientes de implantação são excelentes softwares, que executam as mesmas funções principais para sincronizar e interagir com o blockchain.
-
-Como todos os clientes de implantação fornecem a mesma funcionalidade básica, é muito importante que você escolha um cliente minoritário, ou seja, qualquer cliente que NÃO esteja sendo usado pela maioria dos validadores na rede. Isso pode parecer contraintuitivo, mas executar um cliente majoritário ou supermajoritário aumenta o risco de cortes no caso de uma falha nesse cliente. A execução de um cliente minoritário limita drasticamente esses riscos.
-
-Saiba mais sobre a razão de a diversidade de clientes ser fundamental
-
-
-
-Embora um servidor virtual privado (VPS) possa ser usado como substituto do hardware doméstico, o acesso físico e a localização do seu cliente validador importam. Soluções em nuvem centralizadas como Amazon Web Services ou Digital Ocean permitem a conveniência de não ter que obter e operar hardware, à custa da centralização da rede.
-
-Quanto mais clientes validadores forem executados em uma única solução centralizada de armazenamento em nuvem, mais perigoso se torna para esses usuários. Qualquer evento que coloque esses provedores off-line, seja por um ataque, demandas regulatórias ou apenas quedas de energia/internet, fará com que todos os clientes validadores que dependem desse servidor fiquem off-line ao mesmo tempo.
-
-As penalidades por ficar off-line são proporcionais a quantos outros estão off-line ao mesmo tempo. O uso de um VPS aumenta muito o risco de que as penalidades por ficar offl-ine sejam mais severas e aumenta o risco de vazamento ou corte quadrático no caso de a interrupção ser grande o suficiente. Para minimizar seu próprio risco e o risco para a rede, os usuários são fortemente encorajados a obter e operar seu próprio hardware.
-
-
-
-
-Saques de qualquer tipo da Beacon Chain exigem que sejam definidas credenciais de retirada.
-
-Os novos participantes estabeleceram isso no momento da geração da chave e do depósito. Os stakers existentes que ainda não definiram isso podem atualizar suas chaves para dar suporte a essa funcionalidade.
-
-Depois que as credenciais de saque estiverem definidas, os pagamentos de recompensa (ETH acumulado sobre os 32 iniciais) serão periodicamente distribuídos para o endereço de saque automaticamente.
-
-Para desbloquear e receber todo o seu saldo de volta, você deve concluir o processo de saída de seu validador.
-
-Mais sobre saques de participação
-
-
-## Leitura adicional {#further-reading}
-
-- [O diretório de staking Ethereum](https://www.staking.directory/) - _Eridian e Spacesider_
-- [Problema de diversidade de clientes da Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
-- [Ajudando a diversidade dos clientes](https://www.attestant.io/posts/helping-client-diversity/) - _Jim McDonald 2022_
-- [Diversidade de clientes na camada de consenso do Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_
-- [Como comprar o hardware validador do Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) - _EthStaker 2022_
-- [Passo a passo: Como ingressar na rede de testes da Ethereum 2.0](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) - _ Butta_
-- [Dicas de prevenção de cortes Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _Raul Jordan 2020 _
-
-
diff --git a/public/content/translations/pt-br/07) Staking Pages/staking/withdrawals/index.md b/public/content/translations/pt-br/07) Staking Pages/staking/withdrawals/index.md
deleted file mode 100644
index 0285ba67113..00000000000
--- a/public/content/translations/pt-br/07) Staking Pages/staking/withdrawals/index.md
+++ /dev/null
@@ -1,218 +0,0 @@
----
-title: Saque de staking
-description: Página que resume o que são os saques por staking, como eles funcionam e o que os stakers (participantes) precisam fazer para obter suas recompensas
-lang: pt-br
-template: staking
-image: /images/staking/leslie-withdrawal.png
-alt: Leslie, o rinoceronte, com suas recompensas de staking
-sidebarDepth: 2
-summaryPoints:
- - A atualização Shanghai/Capella permitiu saques de stake no Ethereum
- - Os operadores validadores devem fornecer um endereço de saque para ativá-los
- - As recompensas são distribuídas automaticamente a cada dois ou três dias
- - Validadores que saírem por completo do staking receberão o seu saldo restante
----
-
-
-Os saques de stake foram ativados com a atualização Shanghai/Capella, que ocorreu em 12 de abril de 2023. Mais sobre Shanghai/Capella
-
-
-**Saques de stake** referem-se a transferências de ETH de uma conta do validador na camada de consenso do Ethereum (a Beacon Chain) para a camada de execução na qual ela pode efetuar a transação.
-
-**Pagamentos de recompensas de saldo excedente** acima de 32 ETH serão enviados de forma automática e regular para um endereço de saque vinculado a cada validador, uma vez fornecido pelo usuário. Usuários também podem **sair totalmente do staking**, desbloqueando seu saldo total do validador.
-
-## Recompensas de staking {#staking-rewards}
-
-Os pagamentos de recompensa são processados automaticamente para contas validadoras ativas, com um saldo efetivo máximo de 32 ETH.
-
-Qualquer saldo acima de 32 ETH ganho por meio de recompensas, não contribui realmente para o principal, ou aumenta o peso desse validador na rede e, portanto, é retirado automaticamente como pagamento de recompensa a cada dois ou três dias. Além de fornecer um endereço de saque uma vez, essas recompensas não exigem nenhuma ação do operador validador. Tudo isso é iniciado na camada de consenso, portanto, nenhum gás (taxa de transação) é necessário em nenhuma etapa.
-
-### Como chegamos aqui? {#how-did-we-get-here}
-
-Nos últimos anos, o Ethereum passou por várias atualizações de rede, fazendo a transição para uma rede protegida pelo próprio ETH, em vez da mineração intensiva de energia, como era antes. A participação em consenso no Ethereum agora é conhecida como "staking", pois os participantes têm bloqueado voluntariamente o ETH, colocando-o "em stake" para poder participar da rede. Os usuários que seguem as regras serão recompensados, enquanto as tentativas de trapaça podem ser penalizadas.
-
-Desde o lançamento do contrato de depósito de staking em novembro de 2020, alguns corajosos pioneiros do Ethereum bloquearam voluntariamente fundos para ativar “validadores”, contas especiais que têm o direito de atestar formalmente e propor blocos, seguindo as regras da rede.
-
-Antes da atualização Shanghai/Capella, não era possível usar ou acessar seu ETH em stake. Mas agora, você pode optar por receber automaticamente suas recompensas em uma conta escolhida, e também pode sacar seu ETH em stake sempre que quiser.
-
-### Como me preparo? {#how-do-i-prepare}
-
-
-
-### Avisos importantes {#important-notices}
-
-Fornecer um endereço de saque é uma etapa necessária para qualquer conta de validador, antes que ele seja elegível para sacar ETH de seu saldo.
-
-
- Cada conta de validador pode ser atribuída a um único endereço de saque, uma única vez. Após a seleção e envio do endereço à camada de consenso, isso não pode ser desfeito ou alterado novamente. Verifique a propriedade e a precisão do endereço fornecido antes de enviar.
-
-
-Não há nenhuma ameaça aos seus fundos enquanto não fornecer essa conta, contanto que sua frase mnemônica/de recuperação tenha permanecido segura offline e não tenha sido comprometida de nenhuma forma. A falha em adicionar credenciais de saque simplesmente deixará o ETH bloqueado na conta do validador como tem estado até que um endereço de saque seja fornecido.
-
-## Saindo do staking por completo {#exiting-staking-entirely}
-
-Fornecer um endereço de saque é necessário antes que _quaisquer_ fundos possam ser transferidos de um saldo de uma conta do validador.
-
-Os usuários que procuram sair totalmente do staking e sacar seu saldo total de volta, também devem assinar e transmitir uma mensagem de "saída voluntária", com as chaves do validador que iniciarão o processo de saída do staking. Isso é feito com o seu cliente validador e enviado ao seu nó de consenso, e não exige gás.
-
-O processo de saída de um validador do staking leva uma quantidade variável de tempo, dependendo de quantos outros estão saindo ao mesmo tempo. Uma vez concluída, esta conta não será mais responsável por executar as obrigações de rede do validador, não será mais elegível para recompensas e não terá mais seu ETH "em stake". Nesse momento, a conta será marcada como totalmente “sacável”.
-
-Uma vez que uma conta é marcada como "sacável" e as credenciais de saque são fornecidas, não há mais nada que o usuário precise fazer além de esperar. As contas são automática e continuamente varridas por proponentes de bloco para fundos elegíveis de saída, e o saldo da sua conta será transferido integralmente (também conhecido como "saque total") durante a próxima varredura.
-
-## Quando os saques de staking são ativados? {#when}
-
-Os saques de stake já estão disponíveis! A funcionalidade de saque foi habilitada como parte da atualização Shanghai/Capella que ocorreu em 12 de abril de 2023.
-
-A atualização Shanghai/Capella permitiu que o ETH previamente em stake fosse recuperado em contas normais do Ethereum. Isso fechou o ciclo de liquidez de stake e trouxe o Ethereum a um passo mais perto de sua jornada para a construção de um ecossistema descentralizado sustentável, dimensionável e seguro.
-
-- [Mais sobre a história do Ethereum](/history/)
-- [Mais sobre o roteiro do Ethereum](/roadmap/)
-
-## Como funcionam os pagamentos de saque? {#how-do-withdrawals-work}
-
-Se um determinado validador é elegível para um saque ou não é determinado pelo estado da própria conta do validador. Nenhuma entrada de usuário é necessária a um dado momento para determinar se uma conta deveria ter um saque iniciado ou não — todo o processo é realizado automaticamente pela camada de consenso em um loop contínuo.
-
-### Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner}
-
-Confira esta explicação sobre saques de staking do Ethereum pela Finematics:
-
-
-
-### Validador de "varredura" {#validator-sweeping}
-
-Quando um validador está agendado para propor o próximo bloco, ele é necessário para construir uma fila de saque de até 16 saques elegíveis. Isso é feito originalmente começando com o validador de índice 0, determinando se há um saque elegível para essa conta, conforme as regras do protocolo, e adicionando-o à fila, se houver. O validador definido para propor o bloco seguinte continuará de onde o último parou, progredindo em ordem indefinidamente.
-
-
-Pense em um relógio analógico. O ponteiro no relógio aponta para a hora, avança em uma direção, não pula nenhuma hora e, por fim, volta ao início após alcançar o último número.
-Agora, em vez de 1 a 12, imagine que o relógio é de 0 a N (o total de números de contas de validador que foram registradas na camada de consenso, mais de 500 mil em janeiro de 2023).
-O ponteiro do relógio aponta para o próximo validador que precisa ser verificado quanto a saques elegíveis. Começa em 0 e avança ao longo de todo o caminho sem pular nenhuma conta. Quando o último validador é alcançado, o ciclo continua de volta ao início.
-
-
-#### Verificando os saques de uma conta {#checking-an-account-for-withdrawals}
-
-Enquanto um proponente está verificando os validadores para possíveis saques, cada validador que está sendo verificado é avaliado em relação a uma pequena série de perguntas para determinar se um saque deve ser acionado e, em caso afirmativo, o quanto de ETH deve ser sacado.
-
-1. **Foi fornecido um endereço para saque?** Se nenhum endereço para saque foi fornecido, a conta é ignorada e nenhum saque é iniciado.
-2. **O validador saiu e pode ser sacado?** Se o validador saiu completamente, e chegamos à época em que sua conta é considerada "sacável", então um saque total será processado. Isso transferirá todo o saldo restante para o endereço de saque.
-3. **O saldo efetivo é maximizado em 32?** Se a conta que tiver credenciais de saque não for completamente encerrada e tiver recompensas acima de 32 em espera, um saque parcial será processado, o qual transfere apenas as recompensas acima de 32 para o endereço de saque do usuário.
-
-Existem apenas duas ações tomadas pelos operadores do validador ao longo do seu ciclo de vida que influenciam diretamente esse fluxo:
-
-- Fornecer credenciais de saque para habilitar qualquer forma de saque
-- Sair da rede, o que desencadeará um saque total
-
-### Gás gratuito {#gas-free}
-
-Essa abordagem para saques de staking evita exigir que os stakers (participantes) enviem manualmente uma transação solicitando que uma quantia específica de ETH seja sacada. Isso significa que **nenhum gás (taxa de transação) é necessário** e os saques também não competem pelo espaço do bloco da camada de execução existente.
-
-### Com que frequência receberei minhas recompensas de staking? {#how-soon}
-
-Um máximo de 16 saques pode ser processado em um único bloco. A esse ritmo, 115.200 saques de validadores podem ser processados por dia (supondo que não haja slots perdidos). Conforme observado acima, os validadores sem saques elegíveis serão ignorados, diminuindo o tempo para concluir a varredura.
-
-Expandindo esse cálculo, podemos estimar o tempo que levará para processar um determinado número de saques:
-
-
-
-| Número de saques | Tempo de execução |
-| :-------------------: | :--------------: |
-| 400.000 | 3,5 dias |
-| 500.000 | 4,3 dias |
-| 600.000 | 5,2 dias |
-| 700.000 | 6,1 dias |
-| 800.000 | 7,0 dias |
-
-
-
-Como você poder ver, isso fica lento à medida que mais validadores estão na rede. Um aumento nos slots perdidos poderia diminuir proporcionalmente, mas isso geralmente representará o lado mais lento dos resultados possíveis.
-
-## Perguntas frequentes {#faq}
-
-
-Não, o processo para fornecer credenciais de saque é um processo único e não pode ser modificado após o envio.
-
-
-
-Ao definir um endereço de saque da camada de execução, as credenciais de saque para esse validador foram permanentemente alteradas. Isso significa que as credenciais antigas não funcionarão mais, e as novas credenciais serão direcionadas para uma conta de camada de execução.
-
-Os endereços de saque podem ser ou um contrato inteligente (controlado por seu código), ou uma conta de propriedade externa (EOA, controlada por sua chave privada). Atualmente, essas contas não têm como comunicar uma mensagem de volta para a camada de consenso, que sinalizaria uma mudança nas credenciais do validador, e adicionar essa funcionalidade aumentaria a complexidade do protocolo desnecessariamente.
-
-Uma alternativa para mudar o endereço de saque de um validador específico implicaria os usuários poderem optar por definir um contrato inteligente como seu endereço de saque, o que permitiria lidar com a rotação de chaves, como um cofre. Os usuários que definem seus fundos para seu próprio EOA podem realizar uma saída completa para sacar todos os seus fundos em stake e, em seguida, refazer o stake usando novas credenciais.
-
-
-
-
-Se você faz parte de uma participação combinada (participação em pool) ou mantém tokens participados, deve solicitar ao seu provedor mais detalhes sobre o processamento de saques de participação, pois cada serviço funciona de maneira diferente.
-
-Em geral, os usuários podem recuperar seu ETH subjacente em stake ou alterar o provedor de stake que utilizam quando quiserem. Se um pool em particular estiver ficando muito grande, os fundos podem ser encerrados, resgatados e reinvestidos com um provedor menor. Ou então, se você acumulou ETH suficiente, pode fazer stake em casa.
-
-
-
-
-Sim, desde que seu validador forneça um endereço de saque. Isso deve ser fornecido uma vez para permitir, inicialmente, quaisquer saques. Em seguida, os pagamentos de recompensa serão acionados automaticamente em poucos dias a cada varredura do validador.
-
-
-
-
-Não, se o seu validador ainda estiver ativo na rede, um saque total não acontecerá automaticamente. Isso exige iniciar manualmente uma saída voluntária.
-
-Após um validador ter concluído o processo de saída, e presumindo que a conta tenha credenciais de saque, o saldo restante será então sacado durante a próxima varredura do validador.
-
-
-
-
-Os saques foram projetados para serem enviados automaticamente, transferindo qualquer ETH que não esteja contribuindo ativamente para o stake. Isso inclui saldos completos das contas que completaram o processo de saída.
-
-Não é possível solicitar manualmente o saque de quantidades específicas de ETH.
-
-
-
-
-É recomendável que os operadores de validadores visitem a página Retiradas do Staking Launchpad, onde você encontrará mais detalhes sobre como preparar seu validador para retiradas, o momento dos eventos e mais detalhes sobre como as retiradas funcionam.
-
-Para testar sua configuração em uma rede de teste primeiro, visite o Holesky Testnet Staking Launchpad para começar.
-
-
-
-
-Não. Uma vez que um validador tenha saído e seu saldo completo tenha sido sacado, quaisquer fundos adicionais depositados nesse validador serão automaticamente transferidos para o endereço de saque durante a próxima varredura do validador. Para recolocar o ETH em stake, um novo validador deve ser ativado.
-
-
-## Leitura adicional {#further-reading}
-
-- [Saques da plataforma de staking](https://launchpad.ethereum.org/withdrawals)
-- [EIP-4895: Saques por push da Beacon chain como operações](https://eips.ethereum.org/EIPS/eip-4895)
-- [Ethereum Cat Herders - Shanghai](https://www.ethereumcatherders.com/shanghai_upgrade/index.html)
-- [PEEPanEIP #94: Saque de ETH em skate (teste) com Potus e Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE)
-- [PEEPanEIP#68: EIP-4895: Beacon chain envia as retiradas como operações com Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs)
-- [Compreendendo como o Saldo Efetivo do Validador funciona](https://www.attestant.io/posts/understanding-validator-effective-balance/)
diff --git a/public/content/translations/pt-br/08) Use cases 2/decentralized-identity/index.md b/public/content/translations/pt-br/08) Use cases 2/decentralized-identity/index.md
deleted file mode 100644
index 353f427a090..00000000000
--- a/public/content/translations/pt-br/08) Use cases 2/decentralized-identity/index.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: Identidade descentralizada
-description: O que é uma identidade descentralizada e por que isso importa?
-lang: pt-br
-template: use-cases
-emoji: ":id:"
-sidebarDepth: 2
-image: /images/eth-gif-cat.png
-summaryPoint1: Os sistemas de identidade tradicionais centralizaram a emissão, manutenção e controle de seus identificadores.
-summaryPoint2: A identidade descentralizada elimina a dependência de terceiros centralizados.
-summaryPoint3: Graças à criptografia, os usuários agora têm as ferramentas para emitir, manter e controlar seus próprios identificadores e atestações novamente.
----
-
-A identidade sustenta virtualmente todos os aspectos da sua vida hoje. Usar serviços on-line, abrir uma conta bancária, votar em eleições, comprar propriedades, garantir um emprego – todas essas coisas exigem que você prove sua identidade.
-
-Entretanto, os sistemas tradicionais de gerenciamento de identidade há muito tempo dependem de intermediários centralizados que emitem, mantêm e controlam seus identificadores e [atestados](/glossary/#attestation). Isso significa que você não pode controlar as informações relacionadas à sua identidade ou decidir quem tem acesso às informações de identificação pessoal (PII) e quanto acesso essas partes têm.
-
-Para resolver esses problemas, temos sistemas de identidade descentralizados construídos em blockchains públicos como o Ethereum. A identidade descentralizada permite que indivíduos gerenciem informações relacionadas à sua identidade. Com soluções de identidade descentralizadas, _você_ pode criar identificadores e reivindicar e manter seus atestados sem depender de autoridades centrais, como provedores de serviços ou governos.
-
-## O que é identidade? {#what-is-identity}
-
-Identidade significa o sentido de si próprio de um indivíduo, definido por características únicas. Identidade refere-se a ser um _indivíduo_, ou seja, uma entidade humana distinta. A identidade também pode se referir a outras entidades não humanas, como uma organização ou autoridade.
-
-
-
-## O que são identificadores? {#what-are-identifiers}
-
-Um identificador é uma informação que atua como um ponteiro para uma identidade ou identidades específicas. Identificadores comuns incluem:
-
-- Nome
-- Número da seguro social/número de identificação fiscal
-- Número de celular
-- Data e local de nascimento
-- Credenciais de identificação digital, por exemplo, endereços de e-mail, nomes de usuário, avatares
-
-Esses exemplos tradicionais de identificadores são emitidos, mantidos e controlados por entidades centrais. Você precisa de permissão do seu governo para alterar seu nome ou de uma plataforma de mídia social para alterar seu nome.
-
-## Benefícios da identidade descentralizada {#benefits-of-decentralized-identity}
-
-1. A identidade descentralizada aumenta o controle individual de identificação da informação. Identificadores e atestados descentralizados podem ser verificados sem depender de autoridades centralizadas e serviços de terceiros.
-
-2. As soluções de identidade descentralizadas facilitam um método com necessidade mínima de confiança, sem interrupções e de proteção de privacidade para verificar e gerenciar a identidade do usuário.
-
-3. A identidade descentralizada aproveita a tecnologia blockchain, que cria confiança entre diferentes partes e fornece garantias criptográficas para provar a validade dos atestados.
-
-4. A identidade descentralizada torna os dados de identidade portáteis. Os usuários armazenam atestados e identificadores na carteira móvel e podem compartilhar com qualquer parte de sua escolha. Identificadores e atestados descentralizados não são bloqueados no banco de dados da organização emissora.
-
-5. A identidade descentralizada deve funcionar bem com tecnologias emergentes de [conhecimento zero](/glossary/#zk-proof), que permitirão que indivíduos provem que possuem ou fizeram algo sem revelar o que é essa coisa. Isso pode se tornar uma maneira poderosa de combinar confiança e privacidade para aplicações como votação.
-
-6. A identidade descentralizada permite que mecanismos [anti-Sybil](/glossary/#anti-sybil) identifiquem quando um humano individual está fingindo ser vários humanos para jogar ou enviar spam a algum sistema.
-
-## Casos de uso de identidade descentralizadas {#decentralized-identity-use-cases}
-
-A identidade descentralizada tem muitos casos de uso em potencial:
-
-### 1. Logins universais {#universal-dapp-logins}
-
-A identidade descentralizada pode ajudar a substituir os logins baseados em senha pela autenticação descentralizada. Os provedores de serviços podem emitir atestados aos usuários, aos que podem ser armazenados em uma carteira Ethereum. Um exemplo de atestado seria uma [NFT](/glossary/#nft) concedendo ao titular acesso a uma comunidade on-line.
-
-Uma função [Entrar com Ethereum](https://login.xyz/) permitiria que os servidores confirmassem a conta Ethereum do usuário e buscassem o atestado necessário de seu endereço de conta. Isso significa que os usuários podem acessar plataformas e sites sem precisar memorizar senhas longas e melhorar a experiência on-line dos usuários.
-
-### 2. Autenticação KYC {#kyc-authentication}
-
-O uso de muitos serviços on-line exige que os indivíduos forneçam atestados e credenciais, como carteira de motorista ou passaporte nacional. Mas essa abordagem é problemática porque as informações privadas do usuário podem ser comprometidas e os provedores de serviços não podem verificar a autenticidade do atestado.
-
-A identidade descentralizada permite que as empresas ignorem os processos convencionais de [Conheça seu Cliente (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) e autentiquem identidades de usuários por meio de credenciais verificáveis. Isso reduz o custo de gerenciamento de identidade e previne o uso de documentação falsa.
-
-### 3. Votação e comunidades on-line {#voting-and-online-communities}
-
-A votação on-line e as mídias sociais são duas novas aplicações para a identidade descentralizada. Esquemas de votação on-line são suscetíveis à manipulação, especialmente se atores mal-intencionados criarem identidades falsas para votar. Pedir a indivíduos que apresentem atestados on-chain pode melhorar a integridade dos processos de votação on-line.
-
-A identidade descentralizada pode ajudar a criar comunidades on-line livres de contas falsas. Por exemplo, cada usuário pode ter que autenticar sua identidade usando um sistema de identidade on-chain, como o Nomes de Serviço Ethereum, reduzindo a possibilidade de bots.
-
-### 4. Proteção Anti-Sybil {#sybil-protection}
-
-Os aplicativos de atribuição de concessões que usam [votação quadrática](/glossary/#quadratic-voting) são vulneráveis a [ataques Sybil](/glossary/#sybil-attack) porque o valor de uma concessão aumenta quando mais indivíduos votam nela, incentivando os usuários a dividir suas contribuições entre várias identidades. As identidades descentralizadas ajudam a evitar isso, aumentando o ônus de cada participante para provar que eles são realmente humanos, embora muitas vezes sem ter que revelar informações particulares específicas.
-
-## O que são atestados? {#what-are-attestations}
-
-Um atestado é uma reivindicação feita por uma entidade sobre outra entidade. Se você mora nos Estados Unidos, a carteira de motorista emitida a você pelo Departamento de Veículos Motorizados (uma entidade) atesta que você (outra entidade) tem permissão legal para dirigir um carro.
-
-Atestados são diferentes de identificadores. Um atestado _contém_ identificadores para referir-se a uma identidade específica e faz uma declaração sobre um atributo relacionado a essa identidade. Portanto, sua carteira de motorista possui identificadores (nome, data de nascimento, endereço), mas também é o atestado sobre seu direito legal de dirigir.
-
-### O que são identificadores descentralizados? {#what-are-decentralized-identifiers}
-
-Identificadores tradicionais como seu nome legal ou endereço de e-mail dependem de terceiros – governos e provedores de e-mail. Os identificadores descentralizados (DIDs) são diferentes — eles não são emitidos, gerenciados ou controlados por qualquer entidade central.
-
-Os identificadores descentralizados são emitidos, mantidos e controlados por indivíduos. Uma [conta Ethereum](/glossary/#account) é um exemplo de identificador descentralizado. Você pode criar quantas contas quiser sem permissão de ninguém e sem a necessidade de armazená-las em um registro central.
-
-Os identificadores descentralizados são armazenados em registros distribuídos ([blockchains](/glossary/#blockchain)) ou [redes ponto a ponto](/glossary/#peer-to-peer-network). Isso torna os DIDs [globalmente exclusivos, solucionáveis com alta disponibilidade e verificáveis criptograficamente](https://w3c-ccg.github.io/did-primer/). Um identificador descentralizado pode ser associado a diferentes entidades, incluindo pessoas, organizações ou instituições governamentais.
-
-## O que torna os identificadores descentralizados possíveis? {#what-makes-decentralized-identifiers-possible}
-
-### 1. Criptografia de chave pública {#public-key-cryptography}
-
-A criptografia de chave pública é uma medida de segurança de informações que gera uma [chave pública](/glossary/#public-key) e uma [chave privada](/glossary/#private-key) para uma entidade. A [criptografia de chave pública](/glossary/#cryptography) é usada em redes de blockchain para autenticar identidades de usuários e comprovar a propriedade de ativos digitais.
-
-Alguns identificadores descentralizados, como uma conta Ethereum, possuem chaves públicas e privadas. A chave pública identifica o controlador da conta, enquanto as chaves privadas podem assinar e descriptografar mensagens para essa conta. A criptografia de chave pública fornece as provas necessárias para autenticar entidades e evitar a falsificação de identidade e o uso de identidades falsas, usando [assinaturas criptográficas](https://andersbrownworth.com/blockchain/public-private-keys/) para verificar todas as reclamações.
-
-### 2. Armazenamentos de dados descentralizados {#decentralized-datastores}
-
-Um blockchain serve como um registro de dados verificável: um repositório de informações aberto, com necessidade mínima de confiança e descentralizado. A existência de blockchains públicos elimina a necessidade de armazenar identificadores em registros centralizados.
-
-Se alguém precisar confirmar a validade de um identificador descentralizado, ele poderá procurar a chave pública associada no blockchain. Isso difere dos identificadores tradicionais que exigem autenticação de terceiros.
-
-## Como os identificadores e atestados descentralizados permitem a identidade descentralizada? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
-
-A identidade descentralizada é a ideia de que as informações relacionadas à identidade devem ser autocontroladas, privadas e portáteis, com identificadores descentralizados e atestações sendo os principais blocos de construção.
-
-No contexto da identidade descentralizada, os atestados (também conhecidos como [Credenciais verificáveis](https://www.w3.org/TR/vc-data-model/)) são declarações à prova de adulteração e criptograficamente verificáveis feitas pelo emissor. Cada atestado ou credencial verificável de uma entidade (por exemplo, uma organização) está associada ao seu DID.
-
-Como os DIDs são armazenados no blockchain, qualquer pessoa pode verificar a validade de um atestado verificando o DID do emissor no Ethereum. Essencialmente, o blockchain Ethereum atua como um diretório global que permite a verificação de DIDs associados a determinadas entidades.
-
-Os identificadores descentralizados são o motivo de os atestados serem autocontrolados e verificáveis. Mesmo que o emissor não exista mais, o titular sempre tem a comprovação da procedência e validade do atestado.
-
-Os identificadores descentralizados também são cruciais para proteger a privacidade das informações pessoais por meio da identidade descentralizada. Por exemplo, se um indivíduo apresentar prova de um atestado (carteira de motorista), a parte verificadora não precisa verificar a validade das informações na prova. Em vez disso, o verificador precisa apenas de garantias criptográficas da autenticidade do atestado e da identidade da organização emissora para determinar se a prova é válida.
-
-## Categorias de atestados na identidade descentralizada {#types-of-attestations-in-decentralized-identity}
-
-Como as informações de atestado são armazenadas e recuperadas em um ecossistema de identidade baseado em Ethereum difere do gerenciamento de identidade tradicional. Aqui está uma visão geral das várias abordagens para emitir, armazenar e verificar atestados em sistemas de identidade descentralizados:
-
-### Atestados Off-Chain {#off-chain-attestations}
-
-Uma das preocupações com o armazenamento de certificados na cadeia é que eles podem conter informações que os usuários queiram manter privadas. A natureza pública da blockchain Ethereum a torna não atraente armazenar tais atestações.
-
-A solução é emitir atestados, mantidos por usuários off-chain em carteiras digitais, mas assinados com o DID do emissor armazenado on-chain. Esses atestados são codificados como [JSON Web Tokens](https://en.wikipedia.org/wiki/JSON_Web_Token) e contêm a assinatura digital do emissor, que permite a verificação fácil de reivindicações off-chain.
-
-Aqui está um cenário hipotético para explicar os atestados off-chain:
-
-1. Uma universidade (o emissor) gera um atestado (um certificado acadêmico digital), assina com suas chaves e o emite para Bob (o proprietário da identidade).
-
-2. Bob se candidata a um emprego e quer provar suas qualificações acadêmicas a um empregador, então ele compartilha o atestado de sua carteira móvel. A empresa (o verificador) pode então confirmar a validade do atestado verificando o DID do emissor (ou seja, sua chave pública no Ethereum).
-
-### Atestados off-chain com acesso persistente {#offchain-attestations-with-persistent-access}
-
-Sob esse arranjo, os atestados são transformados em arquivos JSON e armazenados off-chain (idealmente em uma plataforma de [armazenamento em nuvem descentralizado](/developers/docs/storage/), como IPFS ou Swarm). Entretanto, um [hash](/glossary/#hash) do arquivo JSON é armazenado on-chain e vinculado a um DID por meio de um registro on-chain. O DID associado pode ser o do emissor do atestado ou o do destinatário.
-
-Essa abordagem permite que os atestados obtenham persistência baseada em blockchain, mantendo as informações de declarações criptografadas e verificáveis. Ele também permite a divulgação seletiva, visto que o titular da chave privada pode descriptografar as informações.
-
-### Atestados on-chain {#onchain-attestations}
-
-Os atestados on-chain são mantidos em [contratos inteligentes](/glossary/#smart-contract) na blockchain Ethereum. O contrato inteligente (agindo como um registro) mapeará um atestado para um identificador descentralizado on-chain correspondente (uma chave pública).
-
-Aqui está um exemplo para mostrar como os atestados on-chain podem funcionar na prática:
-
-1. Uma empresa (XYZ Corp) planeja vender ações de propriedade usando um contrato inteligente, mas quer apenas compradores que concluíram uma verificação de fundo.
-
-2. A empresa XYZ pode fazer com que a empresa realize verificações de fundo para emitir atestados on-chain no Ethereum. Este atestado certifica que um indivíduo passou na verificação de fundo sem expor nenhuma informação pessoal.
-
-3. O contrato inteligente de venda de ações pode verificar no contrato de registro as identidades dos compradores selecionados, possibilitando que o contrato inteligente determine quem tem permissão para comprar ações ou não.
-
-### Tokens Soulbound e identidade {#soulbound}
-
-[Tokens Soulbound](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([NFTs intransferíveis](/glossary/#nft)) podem ser usados para coletar informações exclusivas de uma carteira específica. Isso cria efetivamente uma identidade única on-chain vinculada a um endereço Ethereum específico que pode incluir tokens que representam conquistas (por exemplo, terminar algum curso on-line específico ou passar uma pontuação mínima em um jogo) ou participação da comunidade.
-
-## Use identidade descentralizada {#use-decentralized-identity}
-
-Existem muitos projetos ambiciosos usando Ethereum como base para soluções de identidade descentralizadas:
-
-- **[Nomes de Serviço Ethereum (ENS)](https://ens.domains/)** - _ Um sistema de nomes descentralizado para identificadores legíveis por máquina on-chain, como endereços de carteira Ethereum, hashes de conteúdo e metadados._
-- **[SpruceID](https://www.spruceid.com/)** - _Um projeto de identidade descentralizada que permite aos usuários controlar a identidade digital com contas Ethereum e perfis ENS em vez de depender de serviços de terceiros._
-- **[Serviço de Atestação do Ethereum (EAS)](https://attest.sh/)** - _ Um ledger/protocolo descentralizado para fazer atestações on-chain ou off-chain sobre qualquer coisa._
-- **[Prova de Humanidade](https://www.proofofhumanity.id)** - _Prova de Humanidade (ou PoH) é um sistema de verificação de identidade social construído no Ethereum._
-- **[BrightID](https://www.brightid.org/)** - _Uma descentralizada, rede de identidade social de código aberto que busca reformar a verificação de identidade por meio da criação e análise de um grafo social._
-- **[walt.id](https://walt.id)** — _Identidade descentralizada de código aberto e infraestrutura de carteira que permite que desenvolvedores e organizações usem identidade autosoberana e NFTs/SBTs._
-- **[Veramo](https://veramo.io/)** - _Uma estrutura JavaScript que facilita o uso de dados criptograficamente verificáveis nos próprios aplicativos por qualquer pessoa._
-
-## Leitura adicional {#further-reading}
-
-### Artigos {#articles}
-
-- [Casos de uso de blockchain: Blockchain em identidade digital](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_
-- [O que é Ethereum ERC725? Gerenciamento de identidade autossoberana no Blockchain](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_
-- [Como o Blockchain pode resolver o problema da identidade digital](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Comida_
-- [O que é identidade descentralizada e por que você deve se importar?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_
-- [Introdução à identidade descentralizada](https://walt.id/white-paper/digital-identity) — _Dominik Beron_
-
-### Vídeos {#videos}
-
-- [Identidade descentralizada (bônus sessão de transmissão ao vivo)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Um ótimo vídeo explicativo sobre identidade descentralizada por Andreas Antoniopolitas_
-- [Faça login com o Ethereum e identidade descentralizada com Ceramic, IDX, React e 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Tutorial do YouTube sobre como criar um sistema de gerenciamento de identidade para criar, ler e atualizar o perfil de um usuário usando sua carteira Ethereum por Nader Dabit_
-- [BrightID - Identidade descentralizada no Ethereum](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Episódio de podcast sem banco discutindo o BrightID, uma solução de identidade descentralizada para Ethereum_
-- [A Internet off-chain: identidade descentralizada & Credenciais verificáveis](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — apresentação EthDenver 2022 por Evin McMullen
-- [Credenciais verificáveis explicadas](https://www.youtube.com/watch?v=ce1IdSr-Kig) - vídeo explicativo do YouTube com demonstração de Tamino Baumann
-
-### Comunidades {#communities}
-
-- [Aliança ERC-725 no GitHub](https://github.com/erc725alliance) — _Apoiadores do padrão ERC725 para gerenciamento de identidade no blockchain Ethereum_
-- [Servidor do Discord do SpruceID](https://discord.com/invite/Sf9tSFzrnt) — _Comunidade para entusiastas e desenvolvedores que trabalham no Entrar com Ethereum_
-- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _Uma comunidade de desenvolvedores contribuindo para criar um framework de dados verificáveis para aplicativos_
-- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _ Uma comunidade de desenvolvedores e construtores trabalhando em casos de uso de identidade descentralizada em vários setores_
diff --git a/public/content/translations/pt-br/08) Use cases 2/desci/index.md b/public/content/translations/pt-br/08) Use cases 2/desci/index.md
deleted file mode 100644
index cc2debdedc4..00000000000
--- a/public/content/translations/pt-br/08) Use cases 2/desci/index.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Ciência descentralizada (DeSci)
-description: Uma visão geral da ciência descentralizada no Ethereum
-lang: pt-br
-template: use-cases
-emoji: ":microscope:"
-sidebarDepth: 2
-image: /images/future_transparent.png
-alt: ""
-summaryPoint1: Uma alternativa global e aberta ao sistema científico atual.
-summaryPoint2: Tecnologia que permite aos cientistas levantar fundos, realizar experimentos, compartilhar dados, distribuir informações e muito mais.
-summaryPoint3: Constrói o movimento de ciência aberta.
----
-
-## O que é ciência descentralizada (DeSci)? {#what-is-desci}
-
-Ciência descentralizada (DeSci) é um movimento cujo objetivo é construir infraestrutura pública para financiar, criar, revisar, atribuir autoria, armazenar e disseminar conhecimento científico de forma justa e equitária usando a pilha [Web3](/glossary/#web3).
-
-A DeSci visa criar um ecossistema em que os cientistas sejam incentivados a partilhar abertamente a sua pesquisa e a receber crédito pelo seu trabalho, enquanto permite a qualquer pessoa acessar e contribuir para a pesquisa com facilidade. A DeSci parte da ideia de que o conhecimento científico deve ser acessível a todos e de que o processo de pesquisa científica deve ser transparente. A DeSci está criando um modelo de pesquisa científica mais descentralizado e distribuído, tornando-o mais resistente à censura e ao controle das autoridades centrais. A DeSci espera criar um ambiente no qual possam florescer novas ideias não convencionais por meio da descentralização do acesso ao financiamento, ferramentas científicas e canais de comunicação.
-
-A ciência descentralizada possibilita mais diversas fontes de financiamento (de [DAOs](/glossary/#dao), [doações quadráticas](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) a financiamento colaborativo, entre outros), mais acessibilidade de dados e métodos, além de fornecer incentivos para reprodutibilidade.
-
-### Juan Benet — O Movimento DeSci
-
-
-
-## Como a DeSci melhora a ciência {#desci-improves-science}
-
-Uma lista incompleta dos principais problemas encontrados pela ciência e como a ciência descentralizada pode ajudar a resolver esses problemas
-
-| **Ciência descentralizada** | **Ciência tradicional** |
-| ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
-| A distribuição de fundos é **determinada pelo público** usando mecanismos como as doações quadráticas ou DAOs. | **Grupos centralizados** pequenos e fechados controlam a distribuição de fundos. |
-| Você colabora com pares ao **redor do mundo** em equipes dinâmicas. | Organizações de financiamento e instituições domésticas **limitam** suas colaborações. |
-| Decisões de financiamento são feitos online e **de maneira transparente**. São explorados novos mecanismos de financiamento. | As decisões de financiamento levam muito tempo e são**pouco transparentes**. Existem poucos mecanismos de financiamento. |
-| Compartilhar os serviços laboratoriais ficou mais fácil e mais transparente usando tecnologia [Web3](/glossary/#web3). | O compartilhamento de recursos laboratoriais é frequentemente **lento e difuso**. |
-| **Novos modelos para publicação** podem ser desenvolvidos por Web3 primitivos para certificar confiança, transparência e acesso universal. | A publicação é feita de formas frequentemente consideradas **ineficientes, tendenciosas e abusivas**. |
-| Você pode **ganhar tokens e consolidar sua reputação ao avaliar o trabalho de outros**. | O**trabalho de avaliação por pares não é remunerado**, o que beneficia os editores com fins lucrativos. |
-| **Você é dono da propriedade intelectual (PI)** que gera e a distribui conforme termos transparentes. | **Sua instituição doméstica é dona da propriedade intelectual (IP)** que você gera. O acesso ao IP não é transparente. |
-| **Compartilhar toda a pesquisa**, incluindo os dados de pesquisas que não deram certo, ao ter todas as etapas em cadeia. | **Bias de publicação** significa que pesquisadores são mais propensos a compartilhar experimentos que tiveram bons resultados. |
-
-## Ethereum e DeSci {#ethereum-and-desci}
-
-Um sistema de ciência descentralizada exigirá segurança sólida, custos monetários e de transações mínimos, e um rico ecossistema para o desenvolvimento de aplicativos. Ethereum proporciona tudo o que é preciso para construir uma tecnologia científica descentralizada.
-
-## Casos de uso da DeSci {#use-cases}
-
-A DeSci está criando um conjunto de ferramentas científicas para levar o meio acadêmico tradicional ao mundo digital. Veja abaixo uma amostra de casos de uso que a Web3 pode oferecer à comunidade científica.
-
-### Publicação {#publishing}
-
-A publicação científica é notoriamente problemática por ser gerida por editoras que dependem do trabalho gratuito de cientistas, revisores e editores para produzir os artigos, mas, em seguida, cobram taxas de publicação exorbitantes. O público, que geralmente pagou indiretamente pelo trabalho e os custos de publicação por meio de impostos, muitas vezes, não conseguem acessar esse mesmo trabalho sem pagar novamente ao editor. As taxas totais para a publicação de artigos científicos individuais frequentemente somam dezenas de milhares de dólares, minando todo o conceito de conhecimento científico como um [bem público](/glossary/#public-goods), enquanto gera enormes lucros para um pequeno grupo de editoras.
-
-Plataformas de acesso aberto e gratuito existem na forma de servidores de pré-impressão, [como o ArXiv](https://arxiv.org/). No entanto, essas plataformas carecem de controle de qualidade, [mecanismos anti-sybil](/glossary/#anti-sybil) e geralmente não rastreiam métricas de nível de artigo, ou seja, são geralmente usadas apenas para divulgar o trabalho antes do envio a uma editora tradicional. O SciHub também disponibiliza os artigos publicados gratuitamente, mas não de forma legal, e apenas após os editores já terem pago e protegido o trabalho a uma rigorosa legislação de direitos autorais. Isso deixa uma lacuna grave nos artigos científicos e dados acessíveis com um mecanismo de legitimidade e um modelo de incentivos. As ferramentas para a construção desse sistema existem na Web3.
-
-### Reprodutibilidade e replicabilidade {#reproducibility-and-replicability}
-
-Reprodutibilidade e replicabilidade são os fundamentos da descoberta científica de qualidade.
-
-- Resultados reprodutíveis podem ser alcançados várias vezes seguidas pela mesma equipe usando a mesma metodologia.
-- Resultados replicáveis podem ser alcançados por um grupo diferente usando a mesma configuração experimental.
-
-As novas ferramentas nativas da Web3 podem garantir que a reprodutibilidade e a replicabilidade sejam a base da descoberta. Dessa forma, é possível tecer ciência de qualidade no tecido tecnológico do mundo acadêmico. Web3 oferece a capacidade de criar [atestações](/glossary/#attestation) para cada componente de análise: os dados brutos, o mecanismo computacional e o resultado do aplicativo. A beleza dos sistemas de consenso é que quando uma rede confiável é criada para manter esses componentes, cada participante da rede pode ser responsável por reproduzir o cálculo e validar cada resultado.
-
-### Financiamento {#funding}
-
-O modelo padrão atual para o financiamento da ciência é que indivíduos ou grupos de cientistas façam solicitações por escrito a uma agência de financiamento. Um pequeno painel de indivíduos de confiança avaliam as inscrições e, em seguida, entrevistam os candidatos antes de conceder fundos a uma pequena porção de candidatos. Além de criar gargalos que levam, às vezes, a **anos de espera** entre a solicitação e o recebimento de um subsídio, acredita-se que esse modelo seja altamente **vulnerável aos biases, aos interesses próprios e às políticas** do painel de avaliação.
-
-Estudos mostraram que os painéis de revisão de bolsas fazem um trabalho ruim na seleção de propostas de alta qualidade, pois as mesmas propostas apresentadas a diferentes painéis têm resultados totalmente diferentes. Como o financiamento se tornou mais escasso, ele se concentrou em um grupo menor de pesquisadores mais experientes com projetos mais intelectualmente conservadores. O efeito criou um cenário de financiamento hipercompetitivo, entrincheirando incentivos perversos e asfixiando a inovação.
-
-A Web3 tem o potencial de interromper este modelo de financiamento quebrado, experimentando diferentes modelos de incentivo desenvolvidos pelos DAOs e Web3 mais amplos. [Financiamento retroativo de bens públicos](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [financiamento quadrático](https://papers.ssrn. com/sol3/papers.cfm?abstract_id=2003531), [governança DAO](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) e [estruturas de incentivo tokenizadas](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) são algumas das ferramentas Web3 que podem revolucionar o financiamento da ciência.
-
-### Propriedade e desenvolvimento de IP {#ip-ownership}
-
-A propriedade intelectual (IP) é um grande problema na ciência tradicional: de ficar presa em universidades ou não utilizada em biotecnologia, a ser notoriamente difícil de avaliar. No entanto, a propriedade de ativos digitais (como dados ou artigos científicos) é algo que a Web3 faz excepcionalmente bem usando [tokens não fungíveis (NFTs)](/glossary/#nft).
-
-Da mesma forma que os NFTs podem repassar receitas para transações futuras de volta ao criador original, você pode estabelecer cadeias de atribuição de valor transparentes para recompensar pesquisadores, órgãos governamentais (como DAOs) ou até mesmo as pessoas de cujos dados são coletados.
-
-[IP-NFTs](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) também podem funcionar como elemento de acesso a um repositório descentralizado de dados referentes a experimentos de pesquisa sendo realizados e se integrar ao NFT e ao financiamento de [DeFi](/glossary/#defi) (de fracionamento aos pools de empréstimo e avaliação de valor). Ele também permite que entidades nativamente em cadeia, como DAOs do tipo [VitaDAO](https://www.vitadao.com/), conduzam pesquisas diretamente em cadeia. Os [tokens "soulbound" intransferíveis](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) também podem desempenhar um papel importante na DeSci, permitindo que indivíduos provem sua experiência e credenciais vinculadas ao seu endereço Ethereum.
-
-### Armazenamento de dados, acesso e arquitetura {#data-storage}
-
-Os dados científicos podem se tornar muito mais acessíveis usando padrões Web3, e o armazenamento distribuído permite que a pesquisa sobreviva a eventos cataclísmicos.
-
-O ponto de partida deve ser um sistema acessível por qualquer identidade descentralizada que possua as credenciais verificáveis adequadas. Isso permite que dados confidenciais sejam replicados com segurança por partes confiáveis, permitindo redundância e resistência à censura, reprodução de resultados e até mesmo a capacidade de várias partes colaborarem e adicionarem novos dados ao conjunto de dados. Métodos de computação confidenciais como [compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol) fornecem mecanismos alternativos de acesso à replicação de dados brutos, criando ambientes de pesquisa confiáveis para os dados mais confidenciais. Ambientes de pesquisa confiáveis foram [citados pelo NHS](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) como uma solução voltada para o futuro para privacidade e colaboração de dados, criando um ecossistema no qual os pesquisadores podem trabalhar em segurança com dados no local usando ambientes padronizados para compartilhamento de código e práticas.
-
-As soluções flexíveis de dados Web3 suportam os cenários acima e fornecem a base para a verdadeira Ciência Aberta, na qual os pesquisadores podem criar bens públicos sem permissões ou taxas. Soluções de dados públicos da Web3 como IPFS, Arweave e Filecoin são otimizadas para descentralização. O dClimate, por exemplo, fornece acesso universal a dados climáticos e meteorológicos, inclusive de estações meteorológicas e modelos climáticos preditivos.
-
-## Participe {#get-involved}
-
-Explore projetos e junte-se à comunidade DeSci.
-
-- [DeSci.Global: eventos globais e calendário de encontros](https://desci.global)
-- [Cadeia de blocos para o Science Telegram](https://t.me/BlockchainForScience)
-- [Molecule: financie e obtenha financiamento para seus projetos de pesquisa](https://www.molecule.xyz/)
-- [Virotada: receba financiamento por meio de acordos de pesquisa patrocinados para pesquisas sobre longevidade](https://www.vitadao.com/)
-- [ResearchHub: publique um resultado científico e converse com colegas](https://www.researchhub.com/)
-- [LabDAO: dobre uma proteína in-silico](https://alphafodl.vercel.app/)
-- [dClimate API: consulte dados climáticos coletados por uma comunidade descentralizada](https://api.dclimate.net/)
-- [DeSci Foundation: construtor de ferramentas de publicação DeSci](https://descifoundation.org/)
-- [DeSci.World: balcão único para os usuários visualizarem e interagirem com a ciência descentralizada](https://desci.world)
-- [OceanDAO: financiamento governado pela DAO para ciência relacionada a dados](https://oceanprotocol.com/)
-- [Opscientia: fluxos de trabalho de ciência descentralizados abertos](https://opsci.io/research/)
-- [Bio.xyz: obtenha financiamento para sua DAO de biotecnologia ou projeto desci](https://www.bio.xyz/)
-- [Fleming Protocol: economia de dados de código aberto que alimenta a descoberta biomédica colaborativa](http://flemingprotocol.io/)
-- [Active Inference Institute](https://www.activeinference.org/)
-- [IdeaMarkets: para uma credibilidade científica descentralizada](https://ideamarket.io/)
-- [DeSci Labs](https://www.desci.com/)
-- [ValleyDAO: uma comunidade aberta e global que oferece financiamento e suporte translacional para pesquisas em biologia sintética](https://www.valleydao.bio)
-- [Cerebrum DAO: buscando e promovendo soluções para melhorar a saúde cerebral e prevenir a neurodegeneração](https://www.cerebrumdao.com/)
-- [CryoDAO: financiando pesquisas inovadoras na área de criopreservação](https://www.cryodao.org)
-
-Agradecemos o envio de sugestões para novos projetos a serem listados — veja nossa [política de listagem](/contributing/adding-desci-projects/) para começar!
-
-## Leitura adicional {#further-reading}
-
-- [DeSci Wiki por Jocelynn Pearl e Ultrarare](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
-- [Um guia sobre biotecnologia descentralizada por Jocelynn Pearl para o futuro a16z](https://future.a16z.com/a-guide-to-decentralized-biotech/)
-- [O caso da DeSci](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
-- [Guia para a DeSci](https://future.com/what-is-decentralized-science-aka-desci/)
-- [Recursos científicos descentralizados](https://www.vincentweisser.com/decentralized-science)
-- [IP-NFTs Bio-Farmacêuticas da Molecule — Uma descrição técnica](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
-- [Construindo sistemas de ciência sem confiança, de Jon Arrastar](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [Paul Kohlhaas — DeSci: O Futuro da ciência descentralizada (podcast)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
-- [Uma ontologia de inferência ativa para a ciência descentralizada: da criação de sentido situada aos comuns epistêmicos](https://zenodo.org/record/6320575)
-- [DeSci: O futuro da pesquisa por Samuel Azinhoso](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
-- [Financiamento de ciência (Epílogo: DeSci e novas criptoprimitivas) por Nadia](https://nadia.xyz/science-funding)
-- [A descentralização está perturbando o desenvolvimento de medicamentos](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
-
-### Vídeos {#videos}
-
-- [O que é ciência descentralizada?](https://www.youtube.com/watch?v=-DeMklVWNdA)
-- [Conversa entre Vitalik Buterin e o cientista Aubrey de Gray sobre a interseção de pesquisas de longevidade e criptomoedas](https://www.youtube.com/watch?v=x9TSJK1widA)
-- [A publicação científica está em pane. A Web3 pode resolver isso?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
-- [Juan Benet - DeSci, Laboratórios Independentes, & Ciência de Dados em Grande Escala](https://www.youtube.com/watch?v=zkXM9H90g_E)
-- [Sebastian Brunemeier — Como a DeSci pode transformar a Pesquisa Biomédica e o Capital de Risco](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
diff --git a/public/content/translations/pt-br/08) Use cases 2/refi/index.md b/public/content/translations/pt-br/08) Use cases 2/refi/index.md
deleted file mode 100644
index 584b1fabf36..00000000000
--- a/public/content/translations/pt-br/08) Use cases 2/refi/index.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Finanças regenerativas (ReFi)
-description: Uma visão geral de ReFi e casos de uso atuais.
-lang: pt-br
-template: use-cases
-emoji: ":recycle:"
-sidebarDepth: 2
-image: /images/future_transparent.png
-alt: ""
-summaryPoint1: Um sistema econômico alternativo desenvolvido com base em princípios regenerativos
-summaryPoint2: Uma tentativa de aproveitar o Ethereum para resolver crises de coordenação em nível global, como, por exemplo, a mudança climática
-summaryPoint3: Uma ferramenta para dimensionar drasticamente ativos de benefícios ecológicos, como créditos de carbono verificados
----
-
-## O que é ReFi? {#what-is-refi}
-
-**Finanças regenerativas (ReFi, em inglês)** é um conjunto de ferramentas e ideias criadas com base em [blockchains](/glossary/#blockchain) cujo objetivo é criar economias que sejam regenerativas, em vez de extrativas ou exploradoras. No final das contas, os sistemas extrativistas esgotam os recursos disponíveis e entram em colapso; sem mecanismos regenerativos, eles não têm resiliência. O sistema ReFi opera com base no pressuposto de que a criação de valor monetário deve ser dissociada da extração insustentável dos recursos do nosso planeta e das nossas comunidades.
-
-Em vez disso, o ReFi tem como objetivo solucionar problemas ambientais, comunitários ou sociais por meio da criação de ciclos regenerativos. Esses sistemas criam valor para os participantes e, ao mesmo tempo, beneficiam os ecossistemas e as comunidades.
-
-Um dos fundamentos da ReFi é o conceito de economia regenerativa criado por John Fullerton, do Capital Institute. Ele propôs [ oito princípios interconectados](https://capitalinstitute.org/8-principles-regenerative-economy/) que fundamentam a saúde de todo o sistema:
-
-
-
-Os projetos ReFi cumprem esses princípios por meio de [contratos inteligentes](/glossary/#smart-contract) e aplicativos de [finanças descentralizadas (DeFi)](/glossary/#defi) para incentivar comportamentos regenerativos, por exemplo, a recuperação de ecossistemas degradados, e facilitar a colaboração em larga escala em relação a problemas globais, como a mudança climática e a perda de biodiversidade.
-
-O sistema ReFi também se sobrepõe ao movimento [ciência descentralizada (DeSci)](/desci/), que utiliza Ethereum como plataforma para financiar, criar, revisar, prestar crédito, armazenar e disseminar o conhecimento científico. As ferramentas DeSci podem ser úteis no desenvolvimento de padrões e práticas verificáveis para a implementação e o monitoramento de atividades regenerativas, como o plantio de árvores, a remoção de plástico dos oceanos ou a recuperação de um ecossistema degradado.
-
-
-
-## Tokenização de créditos de carbono {#tokenization-of-carbon-credits}
-
-O **[mercado voluntário de carbono (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** é um mecanismo para financiar projetos que provem afetar de maneira positiva as emissões de carbono atuais, seja por meio da redução de emissões ou da remoção de gases de efeito estufa já emitidos na atmosfera. Esses projetos recebem um ativo denominado "créditos de carbono" após serem verificados, que podem ser vendidos para pessoas físicas e jurídicas que queiram apoiar a ação climática.
-
-Além do VCM, há também diversos mercados de carbono exigidos pelo governo ("mercados de conformidade") que visam estabelecer um preço de carbono por meio de leis ou regulamentos em uma jurisdição específica (por exemplo, país ou região), por meio do controle do fornecimento das permissões que são distribuídas. Os mercados de conformidade incentivam os poluidores na respectiva jurisdição a reduzir as emissões, mas não têm a capacidade de remover gases de efeito estufa que já foram emitidos.
-
-Apesar do respectivo desenvolvimento ao longo das últimas décadas, o VCM continua a enfrentar diversos problemas:
-
-1. Liquidez altamente fragmentada
-2. Mecanismos de transação obscuros
-3. Altas taxas
-4. Velocidade de negociação muito baixa
-5. Falta de escalabilidade
-
-A transição do VCM para o novo **mercado digital de carbono (DCM)** com base em blockchain pode ser uma oportunidade para melhoria da tecnologia existente para validação, transação e consumo de créditos de carbono. As blockchains permitem obter dados publicamente verificáveis, acesso a uma ampla variedade de usuários e mais liquidez.
-
-Os projetos ReFi utilizam tecnologia blockchain para mitigar muitos dos problemas do mercado tradicional:
-
-- **A liquidez está concentrada em um pequeno número de pools de liquidez** que podem ser negociados livremente por qualquer pessoa. As grandes organizações, assim como usuários individuais, podem utilizar essas pools sem pesquisas manuais de vendedores/compradores, taxas de participação ou registro prévio.
-- **Todas as transações são registradas em blockchains públicas**. Assim que o crédito é disponibilizado no DCM, será sempre possível rastrear o caminho que cada crédito de carbono percorre devido à atividade de negociação.
-- **A velocidade da transação é quase instantânea**. A obtenção de grandes quantidades de créditos de carbono por meio dos mercados tradicionais pode demorar dias ou semanas, mas isso pode ser feito no DCM em poucos segundos.
-- **A atividade de negociação ocorre sem intermediários**, que cobram altas taxas. Os créditos de carbono digitais representam uma redução de custo significativa em comparação com os créditos tradicionais.
-- **O DCM é dimensionável** e pode atender às demandas de indivíduos e de sociedades multinacionais.
-
-### Os principais componentes do DCM {#key-components-dcm}
-
-Quatro principais componentes compõem o cenário atual do DCM:
-
-1. Registros como [Verra](https://verra.org/project/vcs-program/registry-system/) e [Gold Standard](https://www.goldstandard.org/) garantem que os projetos que criam créditos de carbono são confiáveis. Eles também podem operar os bancos de dados nos quias os créditos de carbono digitais se originam e podem ser transferidos ou utilizados (desativados).
-
-Há uma nova onda de projetos inovadores baseados em blockchain que buscam desafiar os atores dominantes neste setor.
-
-2. As carbon bridges ("pontes de carbono"), também conhecidas como tokenizadoras, oferecem tecnologia para representar ou transferir créditos de carbono de registros tradicionais para o DCM. Alguns exemplos importantes incluem [Toucan Protocol](https://toucan.earth/), [C3](https://c3.app/) e [Moss.Earth](https://moss.earth/).
-3. Os serviços integrados oferecem créditos de prevenção e/ou remoção de carbono aos usuários finais para que possam reivindicar o benefício ambiental de um crédito e compartilhar seu apoio à ação climática com o mundo.
-
-Alguns, como [Klima Infinity](https://www.klimadao.finance/infinity) e [Senken](https://senken.io/), oferecem uma ampla variedade de projetos desenvolvidos por terceiros e emitidos de acordo com padrões estabelecidos, como o Verra; outros, como [Nori](https://nori.com/), oferecem apenas projetos específicos, desenvolvidos de acordo com o respectivo padrão de crédito de carbono, que eles emitem e para os quais têm seu próprio mercado exclusivo.
-
-4. Os trilhos e a infraestrutura subjacentes que facilitam a escalabilidade dos impactos e da eficiência de toda a cadeia de suprimentos do mercado de carbono. A [KlimaDAO](http://klimadao.finance/) oferece liquidez como um bem público (o que permite que qualquer pessoa compre ou venda créditos de carbono a um preço transparente), incentiva o aumento do rendimento dos mercados de carbono e retiradas com recompensas, oferece ferramentas interoperáveis e fáceis de usar para acessar dados, bem como adquirir e retirar uma ampla variedade de créditos de carbono tokenizados.
-
-## O sistema ReFi além dos mercados de carbono {#refi-beyond}
-
-Embora atualmente haja uma forte ênfase nos mercados de carbono em geral e na transição do VCM para o DCM especificamente nesse espaço, o termo "ReFi" não se limita estritamente ao carbono. É possível desenvolver e tokenizar outros ativos ambientais, além dos créditos de carbono, o que significa que outras externalidades negativas também podem ser precificadas nas camadas básicas de futuros sistemas econômicos. Além disso, o aspecto regenerativo desse modelo econômico pode ser aplicado a outras áreas, como o financiamento de bens públicos por meio de plataformas de financiamento quadrático, como a [Gitcoin](https://gitcoin.co/). As organizações desenvolvidas com base na ideia de participação aberta e distribuição equitativa de recursos capacitam qualquer pessoa a canalizar fundos para projetos de software de código aberto, bem como projetos educacionais, ambientais e voltados à comunidade.
-
-Ao desviar a direção do capital das práticas extrativistas para um fluxo regenerativo, os projetos e as empresas que proporcionam benefícios sociais, ambientais ou comunitários, e que talvez não consigam obter financiamentos tradicionais, podem sair do papel e gerar externalidades positivas para a sociedade com muito mais rapidez e facilidade. A transição para esse modelo de financiamento também abre as portas para sistemas econômicos muito mais inclusivos, em que pessoas de todos os grupos demográficos podem se tornar participantes ativos em vez de observadores passivos. O sistema ReFi oferece uma visão do Ethereum como um mecanismo para coordenar ações em relação aos desafios existenciais enfrentados pela nossa espécie e por toda a vida no nosso planeta, como a camada de base de um novo paradigma econômico, possibilitando um futuro mais inclusivo e sustentável nos próximos séculos.
-
-## Leitura adicional sobre ReFi
-
-- [Uma visão geral detalhada de moedas de carbono e seu lugar na economia](https://www.klimadao.finance/blog/the-vision-of-a-carbon-currency)
-- [O livro “The Ministry for the Future“ (O Ministério do Futuro) é um romance que retrata o papel de moedas com base em carbono no combate às mudanças climáticas](https://en.wikipedia.org/wiki/The_Ministry_for_the_Future)
-- [Um relatório detalhado do Taskforce for Scaling Voluntary Carbon Markets](https://www.iif.com/Portals/1/Files/TSVCM_Report.pdf)
-- [A entrada sobre Refi de Kevin Owocki e Evan Miyazono no CoinMarketCap Glossary](https://coinmarketcap.com/alexandria/glossary/regenerative-finance-refi)
diff --git a/public/content/translations/pt-br/08) Use cases 2/social-networks/index.md b/public/content/translations/pt-br/08) Use cases 2/social-networks/index.md
deleted file mode 100644
index 154413c5504..00000000000
--- a/public/content/translations/pt-br/08) Use cases 2/social-networks/index.md
+++ /dev/null
@@ -1,113 +0,0 @@
----
-title: Redes sociais descentralizadas
-description: Uma visão geral das redes sociais descentralizadas no Ethereum
-lang: pt-br
-template: use-cases
-emoji: ":mega:"
-sidebarDepth: 2
-image: /images/ethereum-learn.png
-summaryPoint1: Plataformas baseadas em blockchain para interação social, criação e distribuição de conteúdo.
-summaryPoint2: As redes de mídia social descentralizadas protegem a privacidade do usuário e aumentam a segurança dos dados.
-summaryPoint3: Tokens e NFTs criam formas de monetizar conteúdo.
----
-
-As redes sociais desempenham um papel enorme em nossas comunicações e interações diárias. Entretanto, o controle centralizado dessas plataformas criou muitos problemas: violações de dados, interrupções de servidores, "desplataformalizações", censuras e violações de privacidade são algumas das ações negativas que as mídias sociais costumam executar. Para combater esses problemas, os desenvolvedores estão construindo redes sociais no Ethereum. As redes sociais descentralizadas podem resolver muitos dos problemas das plataformas de redes sociais tradicionais e melhorar a experiência geral dos usuários.
-
-## O que são as redes sociais descentralizadas? {#what-are-decentralized-social-networks}
-
-Redes sociais descentralizadas são plataformas [baseadas em blockchains](/glossary/#blockchain) que permitem os usuários trocarem informações assim como publicar e distribuir conteúdo para audiências. Como esses aplicativos são executados no blockchain, eles são capazes de ser descentralizados e resistentes à censura e controle indevido.
-
-Muitas redes sociais descentralizadas existem como alternativas aos serviços já estabelecidos de mídia social, como Facebook, LinkedIn, Twitter e Medium. Mas as redes sociais baseadas em blockchain têm vários recursos que as colocam à frente das plataformas sociais tradicionais.
-
-
-
-### Como funcionam as redes sociais descentralizadas? {#decentralized-social-networks-overview}
-
-As redes sociais descentralizadas são uma classe de [aplicativos descentralizados (dapps)](/dapps/) — aplicativos sustentados por [contratos inteligentes](/glossary/#smart-contract) a> implantados na blockchain. O código do contrato serve como back-end para esses aplicativos e define a lógica de negócios deles.
-
-As plataformas tradicionais de mídia social dependem de bancos de dados para armazenar informações do usuário, códigos do programa e outras formas de dados. Mas isso cria pontos únicos de falha e introduz um risco significativo. Por exemplo, os servidores do Facebook são célebres por [terem ficado offline por horas](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) em outubro de 2021, cortando seus usuários das plataformas.
-
-As redes sociais descentralizadas existem com base em [redes ponto a ponto](/glossary/#peer-to-peer-network), formadas por milhares de nós pelo planeta. Mesmo que alguns nós falhem, a rede funcionará ininterruptamente, tornando os aplicativos resistentes a falhas e interrupções.
-
-Usando sistemas de armazenamento descentralizados como o [ Sistema Interplanetário de Arquivos (IPFS)](https://ipfs.io/), as redes sociais criadas no Ethereum podem proteger as informações do usuário contra exploração e uso malicioso. Ninguém venderá suas informações pessoais para anunciantes, nem mesmo os hackers poderão roubar seus dados confidenciais.
-
-Muitas plataformas sociais baseadas em blockchain possuem tokens nativos que potencializam a monetização na ausência de receita de publicidade. Os usuários podem comprar esses tokens para acessar determinados recursos, concluir compras no aplicativo ou dar gorjetas a seus criadores de conteúdo favoritos.
-
-## Benefícios das redes sociais descentralizadas {#benefits}
-
-1. As redes sociais descentralizadas são resistentes à censura e abertas a todos. Isso significa que **usuários não podem ser banidos**, censurados ou restringidos de forma arbitrária.
-
-2. As redes sociais descentralizadas são de **código aberto**e deixam o código-fonte dos aplicativos visível para inspeção pública. Ao eliminar a implementação de algoritmos opacos comuns nas mídias sociais tradicionais, as redes sociais baseadas em blockchain podem alinhar os interesses de usuários e criadores de plataformas.
-
-3. As redes sociais descentralizadas eliminam o “intermediário”. Os **criadores de conteúdo têm propriedade direta sobre seu conteúdo** e se envolvem diretamente com seguidores, fãs, compradores e outras partes, sem nada além de um contrato inteligente entre eles.
-
-4. Como dapps executados na rede Ethereum, que é sustentada por uma rede global de nós ponto a ponto, as redes sociais descentralizadas são **menos suscetíveis a paralisações e interrupções do servidor**.
-
-5. As plataformas sociais descentralizadas oferecem uma estrutura de **monetização aprimorada** para criadores de conteúdo por meio de [tokens não fungíveis (NFTs)](/glossary/#nft), pagamentos criptográficos no aplicativo e muito mais.
-
-6. As redes sociais descentralizadas proporcionam aos usuários **um alto nível de privacidade e anonimato**. Por exemplo, um indivíduo pode fazer login em uma rede social baseada em Ethereum usando um perfil [ENS](/glossary/#ens) ou [carteira](/glossary/#wallet), sem ter que compartilhar informações de identificação pessoal (PII), como nomes, endereços de e-mail etc.
-
-7. As redes sociais descentralizadas contam com armazenamento descentralizado, e não com bancos de dados centralizados, sendo consideravelmente melhores para proteger os dados do usuário.
-
-## Redes sociais descentralizadas no Ethereum {#ethereum-social-networks}
-
-A rede Ethereum se tornou a ferramenta preferida dos desenvolvedores que criam redes sociais descentralizadas graças à popularidade dos tokens e à base massiva de usuários. Veja alguns exemplos de redes sociais baseadas no Ethereum:
-
-### Mirror {#mirror}
-
-[Mirror](https://mirror.xyz/) é uma plataforma de escrita habilitada para web3 que visa ser descentralizada e de propriedade do usuário. Os usuários podem ler e escrever gratuitamente na Mirror simplesmente conectando suas carteiras. Os usuários também podem coletar textos e assinar seus escritores favoritos.
-
-As postagens publicadas no Mirror são armazenadas permanentemente no Arweave, uma plataforma de armazenamento descentralizada, e podem ser cunhadas como [tokens não fungíveis (NFTs)](/nft/) colecionáveis, conhecidos como Writing NFTs. Os Writing NFTs são totalmente gratuitos para os redatores criarem, e a cobrança ocorre em um Ethereum [L2](/glossary/#layer-2), tornando as transações econômicas, rápidas e ecologicamente corretas.
-
-### MINDS {#minds}
-
-[MINDS](https://www.minds.com/) é uma das redes sociais descentralizadas mais utilizadas. Funciona como o Facebook e já conseguiu milhões de usuários.
-
-Os usuários usam o token nativo da plataforma [ERC-20](/glossary/#erc-20) $MIND para pagar pelos itens. Os usuários também podem ganhar tokens $MIND publicando conteúdo popular, contribuindo para o ecossistema e indicando outras pessoas para a plataforma.
-
-## Utilize redes sociais descentralizadas {#use-decentralized-social-networks}
-
-- **[Status.im](https://status.im/)** - _Status é um aplicativo de mensagens seguro que usa um protocolo ponto a ponto de código aberto e criptografia de ponta a ponta para proteger suas mensagens de terceiros._
-- **[Mirror.xyz](https://mirror.xyz/)** - _Mirror é uma plataforma de publicação descentralizada e de propriedade do usuário, construída no Ethereum para que os usuários financiem ideias, monetizem conteúdo e construam comunidades de alto valor._
-- **[Protocolo Lens](https://lens.xyz/)** - _Protocolo Lens é um gráfico social combinável e descentralizado que ajuda os criadores a se apropriarem de seu conteúdo onde quer que estejam no ambiente digital da internet descentralizada._
-- **[Farcaster](https://farcaster.xyz/)** — _Farcaster é uma rede social suficientemente descentralizada. É um protocolo aberto que pode oferecer suporte a muitos clientes, como o e-mail._
-
-## Redes sociais Web2 no Ethereum {#web2-social-networks-and-ethereum}
-
-As plataformas sociais nativas [Web3](/glossary/#web3) não são as únicas que tentam incorporar a tecnologia blockchain nas mídias sociais. Muitas plataformas centralizadas também planejam integrar o Ethereum em sua infraestrutura:
-
-### Reddit {#reddit}
-
-O Reddit [criou o programa Pontos da Comunidade](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) (Community Points, em inglês), que são tokens ERC-20 que os usuários podem ganhar publicando conteúdo de qualidade e contribuindo para as comunidades on-line (subreddits). Você pode resgatar esses tokens em um subreddit para obter privilégios e vantagens exclusivos. Para esse projeto, o Reddit está trabalhando com a Arbitrum, uma rede de [camada 2](/glossary/#layer-2) projetada para dimensionar as transações do Ethereum.
-
-O programa já está ativo, com o subreddit r/CryptoCurrency [executando sua versão desse programa chamada "Moons"](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki). Segundo a descrição oficial, Moons “recompensa pôsteres, comentaristas e moderadores por suas contribuições ao subreddit” Como esses tokens estão no blockchain (usuários os recebem em carteiras), eles são independentes do Reddit e não podem ser retirados.
-
-Além de usar o programa Pontos da Comunidade para desbloquear recursos especiais, os usuários também podem trocar os pontos por moeda fiduciária em exchanges. Além disso, a quantidade de Pontos da Comunidade que um usuário possui determina sua influência no processo de tomada de decisão na comunidade.
-
-## Leitura adicional {#further-reading}
-
-### Artigos {#articles}
-
-- [Descentralizando mídias sociais: um guia para a pilha social da Web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) — _Coinbase Ventures _
--
-
-As redes sociais são a próxima grande oportunidade de descentralização< /a> — _Ben Goertzel_
-
- - [A Web3 mantém a promessa de redes sociais descentralizadas e sustentadas pela comunidade.](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_
-- [Uma visão geral do cenário de mídia social do Blockchain](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — *Gemini Cryptopedia*
-- [Como o Blockchain pode resolver a privacidade das mídias sociais](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_
-- [Descentralização suficiente para as redes sociais](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_
-
-
-
-### Vídeos {#videos}
-
-- [Mídia social descentralizada explicada](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_
-- [DeSo Blockchain quer descentralizar as mídias sociais](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_
-- [O futuro das mídias sociais descentralizadas com Balaji Srinivasan, Vitalik Buterin, Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) — *ETHGlobal*
-
-
-
-### Comunidades {#communities}
-
-- [Subreddit r/CryptoCurrency](https://www.reddit.com/r/CryptoCurrency/)
diff --git a/public/content/translations/pt-br/09) Learn Pages/bridges/index.md b/public/content/translations/pt-br/09) Learn Pages/bridges/index.md
deleted file mode 100644
index 1a2fd71148d..00000000000
--- a/public/content/translations/pt-br/09) Learn Pages/bridges/index.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Introdução às pontes de blockchain
-description: Pontes permitem que os usuários movam seus fundos entre blockchains diferentes
-lang: pt-br
----
-
-# Pontes de blockchains {#prerequisites}
-
-_Web3 evoluiu para um ecossistema de soluções de escala L1 e L2, cada uma projetada com capacidades e escolhas únicas. À medida que o número de protocolos da blockchain aumenta, consequentemente aumenta a necessidade de mover ativos entre cadeias. Para atender a essa demanda, precisamos de pontes._
-
-
-
-## O que são pontes? {#what-are-bridges}
-
-As pontes de blockchain funcionam como as pontes que conhecemos no mundo físico. Assim como uma ponte física conecta dois locais físicos, uma ponte blockchain conecta dois ecossistemas do blockchain. **Pontes facilitam a comunicação entre a blockchain através da transferência de informações e de ativos**.
-
-Vejamos um exemplo:
-
-Você é dos EUA e está planejando uma viagem à Europa. Você tem Dólar, mas precisa de Euro para gastar. Para trocar seus Dólares por Euros, você pode usar uma corretora de câmbio por uma pequena taxa.
-
-Mas o que fazer se você quiser fazer uma troca semelhante para usar uma [blockchain](/glossary/#blockchain) diferente? Digamos que você queira trocar [ETH](/glossary/#ether) na rede principal do Ethereum por ETH na [Arbitrum](https://arbitrum.io/). Como o câmbio de moedas que fizemos por Euro, precisamos de um mecanismo para mover nosso ETH do Ethereum para o Arbitrum. As pontes tornam essa transação possível. Neste caso, a [Arbitrum tem uma ponte nativa](https://bridge.arbitrum.io/) que pode transferir o ETH da rede principal para o Arbitrum.
-
-## Por que precisamos de pontes? {#why-do-we-need-bridges}
-
-Todos os blockchains têm suas limitações. Para que o Ethereum seja dimensionado e acompanhe a demanda, foram necessários [rollups](/glossary/#rollups). Em alternativa, L1s como Javier Solana e Avalanche são concebidos de forma diferente para permitir uma taxa de transferência mais elevada, mas à custa de descentralização.
-
-No entanto, todas as blockchains são desenvolvidas em ambientes isolados e têm regras e mecanismos de [consenso](/glossary/#consensus) diferentes. Isso significa que eles não podem se comunicar nativamente e os tokens não podem se mover livremente entre os blockchains.
-
-Pontes existem para conectar os blockchains, permitindo a transferência de informações e tokens entre elas.
-
-**Pontes possibilitam**:
-
-- a transferência de ativos e informações entre cadeias.
-- [dapps](/glossary/#dapp) para acessar os pontos fortes de várias blockchains, fortalecendo assim seus recursos (já que os protocolos agora têm mais espaço para a inovação).
-- Usuários para acessar novas plataformas e alavancar os benefícios de cadeias diferentes.
-- Desenvolvedores de diferentes ecossistemas do blockchain para colaborar e construir novas plataformas para os usuários.
-
-[Como fazer bridge de tokens para a camada 2](/guides/how-to-use-a-bridge/)
-
-
-
-## Casos de utilização de pontes {#bridge-use-cases}
-
-Seguem alguns cenários onde você pode usar uma ponte:
-
-### Diminuir as taxas de transação {#transaction-fees}
-
-Digamos que você tenha ETH na mainnet (rede principal) Ethereum, mas queira taxas de transação mais baratas para explorar diferentes dapps. Ao fazer uma ponte do seu ETH da Mainnet para uma rollup Ethereum L2, você poderá usufruir de taxas de transação mais baixas.
-
-### Dapps em outros blockchains {#dapps-other-chains}
-
-Se você usa o Aave na rede principal Ethereum para emprestar Dólar Herete, mas a taxa de juros para empréstimos Dólar Herete usando Aave no Polygon é maior.
-
-### Explorar os ecossistemas de blockchain {#explore-ecosystems}
-
-Se você tiver o ETH na Ethereum Mainnet e quiser explorar um alt L1 para experimentar seus dapps nativos. Você pode usar uma ponte para transferir o seu ETH da rede principal Ethereum para o alt L1.
-
-### Possuir ativos nativos de cripto {#own-native}
-
-Digamos que você queira possuir Bitcoin nativo (BTC), mas você só tem fundos na rede principal Ethereum. Para ganhar exposição à BTC na Ethereum, você pode comprar Bitcoin Envolvido (WBTC). No entanto, o WBTC é um token [ERC-20](/glossary/#erc-20) nativo da rede Ethereum, o que significa que é uma versão Ethereum do Bitcoin e não o ativo original na blockchain do Bitcoin. Para possuir BTC nativa, você teria que ligar os seus ativos do Ethereum para Bitcoin usando uma ponte. Isso converter suas WBTC em BTC nativa, por meio da ponte. Como alternativa, você pode possuir BTC e querer usá-lo nos protocolos[DeFi](/glossary/#defi) do Ethereum. Isso exigiria fazer uma ponte no caminho inverso, de BTC para WBTC, que logo poderia ser usada como um ativo no Ethereum.
-
-
- Você também pode fazer tudo acima usando uma exchange centralizada. No entanto, a menos que seus fundos já estejam em uma exchange (corretora), isso envolveria vários passos, e você provavelmente estaria melhor usando uma ponte.
-
-
-
-
-## Tipos de pontes {#types-of-bridge}
-
-As pontes têm muitos tipos de desenhos e complexidades. Em geral, as pontes caem em duas categorias: pontes confiáveis e não confiáveis.
-
-| Pontes confiáveis | Pontes não confiáveis |
-| -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Pontes confiáveis dependem de uma entidade ou sistema central para suas operações. | As pontes não confiáveis operam usando contratos e algoritmos inteligentes. |
-| Elas pressupõem confiança relativa à custódia de fundos e à segurança da ponte. Os usuários dependem, principalmente, da reputação do operador da ponte. | Elas não são confiáveis, ou seja, a segurança da ponte é a mesma que a do blockchain subjacente. |
-| Os usuários precisam abrir mão do controle de seus ativos criptos. | Graças aos [contratos inteligentes](/glossary/#smart-contract), as pontes independentes de confiança permitem que os usuários permaneçam no controle de seus fundos. |
-
-Em poucas palavras, podemos dizer que pontes confiáveis têm pressupostos de confiança, enquanto pontes não confiáveis tem confiança mínima e não fazem novas suposições de confiança além das dos domínios subjacentes. Veja como esses termos podem ser descritos:
-
-- **Necessidade mínima de confiança**: com segurança equivalente aos domínios subjacentes. Conforme descrito por [Arjun Bhuptani neste artigo.](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17)
-- **Suposições de confiança:** afastando-se da segurança dos domínios subjacentes, adicionando verificadores externos no sistema, tornando-o menos seguro em termos criptoeconômicos.
-
-Para desenvolver uma melhor compreensão das principais diferenças entre as duas abordagens, vamos dar um exemplo:
-
-Imagine que esteja no checkpoint de segurança do aeroporto. Existem dois tipos de checkpoint:
-
-1. Checkpoint manual – operado por funcionários que verificam manualmente todos os detalhes da sua passagem e identidade antes de entregar o bilhete de embarque.
-2. Check-in automático — operado por uma máquina onde você coloca os detalhes do voo e recebe o bilhete de embarque se tudo estiver correto.
-
-Um ponto de verificação manual é semelhante a um modelo confiável, pois depende de um terceiro, por exemplo, os funcionários, para suas operações. Como usuário, você confia nos funcionários para tomar as decisões certas e usar suas informações privadas corretamente.
-
-O check-in automático é semelhante a um modelo sem confiança, pois remove o papel do operador e usa tecnologia para operar. Os usuários sempre permanecem no controle de seus dados e não precisam confiar suas informações privadas a terceiros.
-
-Muitas soluções de ponte adotam modelos entre esses dois extremos, com graus variados de necessidade mínima de confiança.
-
-
-
-## Riscos ao usar pontes {#bridge-risk}
-
-As pontes estão nos estágios iniciais de desenvolvimento. É provável que o projeto ideal de ponte ainda não tenha sido descoberto. Interagir com qualquer tipo de ponte traz riscos:
-
-- **Risco de contrato inteligente —** o risco de uma falha no código que pode causar a perda de fundos do usuário
-- **Risco de tecnologia —** falha de software, código com erros, erro humano, spam e ataques maliciosos podem interromper as operações do usuário
-
-Além disso, como as pontes confiáveis adicionam suposições de confiança, elas carregam riscos adicionais, como:
-
-- **Risco de censura —** os operadores da ponte teoricamente podem impedir que os usuários transfiram seus ativos usando a ponte
-- **Risco de custódia —** os operadores da ponte podem conspirar para roubar os fundos dos usuários
-
-Os fundos do usuário estão em risco se:
-
-- houver uma falha no contrato inteligente
-- o usuário cometer um erro
-- o blockchain subjacente for hackeado
-- os operadores da ponte tiverem intenção maliciosa em uma ponte confiável
-- a ponte for hackeada
-
-Um ataque hacker recente foi a ponte Wormhole da Solana, [onde 120k wETH (US$ 325 milhões) foram roubados durante o ataque hacker](https://rekt.news/wormhole-rekt/). Muitos dos [principais hacks em blockchains envolveram pontes](https://rekt.news/leaderboard/).
-
-As pontes são cruciais para integrar usuários às camadas 2 do Ethereum e até mesmo para usuários que desejam explorar diferentes ecossistemas. Entretanto, dados os riscos envolvidos na interação com as pontes, os usuários devem entender as trocas que as pontes estão fazendo. Estas são algumas [estratégias para segurança entre cadeias](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946).
-
-
-
-## Leitura adicional {#further-reading}
-
-- [EIP-5164: Execução entre cadeias](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) *18 de junho de 2022 - Brendan Asselstine*
-- [L2Bridge Risk Framework](https://gov.l2beat.com/t/l2bridge-risk-framework/31) _5 de julho de 2022 - Bartek Kiepuszewski_
-- ["Por que o futuro será multi-chain, mas não será cross-chain."](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/)_8 de janeiro de 2022 - Vitalik Buterin_
diff --git a/public/content/translations/pt-br/09) Learn Pages/energy-consumption/index.md b/public/content/translations/pt-br/09) Learn Pages/energy-consumption/index.md
deleted file mode 100644
index e70fbba0c8d..00000000000
--- a/public/content/translations/pt-br/09) Learn Pages/energy-consumption/index.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Consumo de energia do Ethereum
-description: As informações básicas que você precisa para entender o consumo de energia do Ethereum.
-lang: pt-br
----
-
-# Gasto de energia do Ethereum {#proof-of-stake-energy}
-
-Ethereum é uma cadeia de blocos verde. A [prova de participação](/developers/docs/consensus-mechanisms/pos) do Ethereum usa o ETH como mecanismo de consenso ao invés de [energia para proteger a rede](/developers/docs/consensus-mechanisms/pow). O consumo de energia do Ethereum é de aproximadamente [~0,0026 TWh/ano](https://carbon-ratings.com/eth-report-2022) em toda a rede global.
-
-O consumo de energia estimado para o Ethereum vem de um estudo do [CCRI (Crypto Carbon Ratings Institute)](https://carbon-ratings.com). Eles geraram uma estimativa detalhada do consumo de eletricidade e da pegada de carbono da rede Ethereum ([ veja o relatório](https://carbon-ratings.com/eth-report-2022)). Eles mediram o consumo de eletricidade de diferentes nós com várias configurações de hardware e software cliente. A estimativa de **2,601 MWh** (0,0026 TWh) para o consumo anual de eletricidade da rede é correspondente a emissões anuais de carbono de **870 toneladas de CO2e**, aplicando fatores de intensidade de carbono específicas de uma região. Esse valor muda à medida que os nós entram e saem da rede. Você pode acompanhar esta variação graças ao [Índice de Sustentabilidade da Cambridge para a rede Blockchain](https://ccaf.io/cbnsi/ethereum), que oferece uma estimativa média de sete dias corridos (observe que eles usam um método ligeiramente diferente para suas estimativas — detalhes disponíveis no site).
-
-Para contextualizar o consumo de energia do Ethereum, nós podemos fazer a comparação com estimativas anuais de outros produtos e indústrias. Isso nos ajuda a entender melhor se a estimativa do Ethereum é alta ou baixa.
-
-
-
-O gráfico acima mostra o consumo de energia estimado em TWh/ano para o Ethereum, comparado a diversos produtos e indústrias. As estimativas fornecidas são derivadas de fontes públicas de informação, acessadas em julho de 2023, com links das fontes disponíveis na tabela abaixo.
-
-| | Consumo de energia anualizado (TWh) | Comparação com a PoS Ethereum | Fonte |
-|:------------------------ |:-----------------------------------:|:-----------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
-| Centros de dados globais | 190 | 73.000x | [fonte](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) |
-| Bitcoin | 149 | 53.000x | [fonte](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| Mineração de ouro | 131 | 50.000x | [fonte](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| Jogos nos EUA\* | 34 | 13.000x | [fonte](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) |
-| PoW Ethereum | 21 | 8.100x | [fonte](https://ccaf.io/cbnsi/ethereum/1) |
-| Google | 19 | 7.300x | [fonte](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) |
-| Netflix | 0,457 | 176x | [fonte](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
-| PayPal | 0,26 | 100x | [fonte](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-(1).pdf) |
-| AirBnB | 0,02 | 8x | [fonte](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-(Final).pdf) |
-| **PoS Ethereum** | **0,0026** | **1x** | [fonte](https://carbon-ratings.com/eth-report-2022) |
-
-\*Inclui dispositivos de usuários finais, como PCs, laptops e consoles de jogos.
-
-Obter estimativas precisas do consumo de energia é complicado, especialmente quando o que está sendo avaliado apresenta uma cadeia de fornecimento complexa ou detalhes de implementação que influenciam a sua eficiência. Por exemplo, estimar o consumo de energia para o Netflix e o Google varia de acordo com os seguintes fatores, por exemplo: se incluem a energia usada para manter seu sistema funcional e a entrega de conteúdo aos usuários (_despesas diretas_) ou se incluem as despesas necessárias para criar conteúdo, administrar escritórios corporativos, anuncios, etc (_despesas indiretas_). As despesas indiretas podem incluir também a energia necessária para o consumo do conteúdo pelos dispositivos do usuário final, como TVs, computadores e celulares.
-
-A estimativa acima não é uma comparação perfeita. O montante das despesas indiretas contabilizadas varia de acordo com a fonte, e raramente inclui a energia dos dispositivos do usuário final. Cada fonte subjacente inclui mais detalhes sobre o que está sendo avaliado.
-
-A tabela e o gráfico acima também incluem comparações com o Bitcoin e a prova de trabalho do Ethereum. É importante notar que o consumo de energia das redes de prova de trabalho não é estático e muda a cada dia. As estimativas podem variar amplamente entre as fontes. O tema atrai [debates](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) moderados, não apenas sobre a quantidade de energia consumida, mas também a fonte dessa energia e a ética relacionada. O consumo de energia não corresponde necessariamente à pegada ambiental, porque diferentes projetos podem utilizar diferentes fontes de energia, incluindo uma proporção menor ou maior de energias renováveis. Por exemplo, o [Índice de Consumo de Eletricidade do Bitcoin de Cambridge](https://ccaf.io/cbnsi/cbeci/comparisons) indica que a demanda da rede Bitcoin poderia, teoricamente, ser alimentada pela queima de gás ou eletricidade que, de outra forma, seria perdida na transmissão e distribuição. O caminho do Ethereum para a sustentabilidade foi substituir a parte da rede que consome muita energia por uma alternativa ecológica.
-
-Você pode consultar as estimativas do consumo de energia e emissão de carbono no [site Índice de Sustentabilidade de Cambridge para a rede Blockchain](https://ccaf.io/cbnsi/ethereum).
-
-## Estimativas por transação {#per-transaction-estimates}
-
-Muitos artigos estimam o gasto de energia “por transação” para blockchains. Isso pode ser enganoso, porque a energia necessária para propor e validar um bloco é independente do número de transações dentro dele. Uma unidade de gasto energético por transação implica que menos transações levariam a um gasto energético menor and vice-versa, o que não é o caso. Além disso, as estimativas por transação são muito sensíveis a como uma taxa de transferência de transação da blockchain é definida, e o ajuste dessa definição pode ser burlado para fazer o valor parecer maior ou menor.
-
-No Ethereum, por exemplo, a taxa de transferência não é apenas a da camada base – é também a soma da taxa de transferência de todos os dois rollups da "[camada 2](/layer-2/)". Geralmente, as camadas 2 não são incluídas nos cálculos, mas contabilizar a energia adicional consumida pelos sequenciadores (pequenos) e o número de transações que eles processam (grandes) provavelmente reduziria drasticamente as estimativas por transação. Esta é a razão pela qual as comparações do consumo de energia por transação entre plataformas podem ser enganosas.
-
-## Deficit de carbono do Ethereum {#carbon-debt}
-
-O gasto de energia do Ethereum é muito baixo, mas nem sempre foi o caso. Originalmente, o Ethereum usava prova de trabalho, que tinha um custo ambiental muito maior do que o mecanismo atual de prova de participação.
-
-Desde o início, o Ethereum planejou implementar um mecanismo de consenso baseado em prova de participação, mas fazer isso sem sacrificar a segurança e a descentralização levou anos de pesquisa e desenvolvimento focados. Portanto, um mecanismo de prova de trabalho foi usado para iniciar a rede. A prova de trabalho exige que mineradores usem seu hardware de computação para calcular um valor, gastando energia no processo.
-
-
-
-CCRI estimou que A Fusão reduziu o consumo anual de eletricidade do Ethereum em mais de **99,988%**. Da mesma forma, a emissão de carbono do Ethereum foi reduzido em aproximadamente **99,992%** (de 11.016.000 para 870 toneladas de CO2e). Para colocar isso em perspectiva, a redução das emissões é como ir da altura da Torre Eiffel para um brinquedinho de plástico, como ilustrado na figura acima. Como resultado, o custo ambiental para manter a segurança da rede é consideravelmente reduzido. Ao mesmo tempo, acredita-se que a segurança da rede tenha melhorado.
-
-## Uma camada de aplicação ecológica {#green-applications}
-
-Embora o consumo de energia do Ethereum seja muito baixo, também há uma comunidade de [**finanças regenerativas (ReFi)**](/refi/) considerável, crescente e altamente ativa sendo desenvolvida no Ethereum. Os aplicativos ReFi usam componentes DeFi para criar aplicativos financeiros com externalidades positivas benéficas para o ambiente. O ReFi faz parte de um movimento mais amplo [“solarpunk”](https://en.wikipedia.org/wiki/Solarpunk), que está estreitamente alinhado com o Ethereum e visa unir o avanço tecnológico e a gestão ambiental. A natureza descentralizada, sem necessidade de permissão e composta do Ethereum faz dele a camada base ideal para as comunidades ReFi e solarpunk.
-
-As plataformas nativas de financiamento de bens públicos da Web3, como [Gitcoin](https://gitcoin.co), executam rodadas climáticas para estimular a criação ambientalmente consciente na camada de aplicativos do Ethereum. Através do desenvolvimento dessas iniciativas (e outras, por exemplo, [DeSci](/desci/)), o Ethereum está se tornando uma tecnologia ambiental e socialmente positiva.
-
-
- Se você acha que esta página pode ser mais precisa, comunique o problema ou PR. As estatísticas nesta página são estimativas baseadas em dados disponíveis publicamente – elas não representam uma declaração oficial ou promessa da equipe ethereum.org ou da Ethereum Foundation.
-
-
-## Leitura adicional {#further-reading}
-
-- [Índice de Sustentabilidade da rede Cambridge Blockchain](https://ccaf.io/cbnsi/ethereum)
-- [Relatório da Casa Branca sobre blockchains de prova de trabalho](https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
-- [Emissões do Ethereum: uma estimativa ascendente](https://kylemcdonald.github.io/ethereum-emissions/) - _Kyle McDonald_
-- [Índice de consumo de energia do Ethereum](https://digiconomist.net/ethereum-energy-consumption/) – _Digiconomist_
-- [ETHMerge.com](https://ethmerge.com/) - _[@InsideTheSim](https://twitter.com/InsideTheSim)_
-- [A Fusão — As Implicações no Consumo de Eletricidade e Emissão de Carbono da Rede Ethereum](https://carbon-ratings.com/eth-report-2022) - _CCRI_
-- [Consumo de energia do Ethereum](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8)
-
-## Tópicos relacionados {#related-topics}
-
-- [Visão do Ethereum](/roadmap/vision/)
-- [A Beacon Chain](/roadmap/beacon-chain)
-- [The Merge (A Fusão)](/roadmap/merge/)
diff --git a/public/content/translations/pt-br/09) Learn Pages/governance/index.md b/public/content/translations/pt-br/09) Learn Pages/governance/index.md
deleted file mode 100644
index 5d8cd1291d9..00000000000
--- a/public/content/translations/pt-br/09) Learn Pages/governance/index.md
+++ /dev/null
@@ -1,182 +0,0 @@
----
-title: Governança Ethereum
-description: Uma introdução à forma como as decisões sobre a Ethereum são tomadas.
-lang: pt-br
----
-
-# Introdução à governança Ethereum {#introduction}
-
-_Se ninguém é proprietário da Ethereum, como são feitas as decisões sobre mudanças passadas e futuras na Ethereum? A governança Ethereum refere-se ao processo que permite que tais decisões sejam tomadas._
-
-
-
-## O que é governança? {#what-is-governance}
-
-Governança é o sistema em vigor que permite a tomada de decisões. Em uma estrutura típica organizacional, a equipe executiva ou o conselho de administração podem ter a última palavra sobre o processo decisório. Ou talvez os acionistas votem propostas para adoção de mudanças. Em um sistema político, os funcionários eleitos podem aprovar legislação que tenta representar os desejos dos seus eleitores.
-
-## Governança descentralizada {#decentralized-governance}
-
-Ninguém possui ou controla o protocolo Ethereum, mas ainda é necessário tomar decisões sobre a implementação de mudanças para garantir da melhor forma a longevidade e a prosperidade da rede. Esta falta de propriedade faz da governança organizacional tradicional uma solução incompatível.
-
-## Governança Ethereum {#ethereum-governance}
-
-A governança Ethereum é o processo pelo qual as alterações no protocolo são feitas. É importante salientar que este processo não está relacionado à maneira como as pessoas e os aplicativos usam o protocolo – o Ethereum é sem restrições. Qualquer pessoa de qualquer lugar do mundo pode participar de atividades on-chain. Não há regras definidas para quem pode ou não desenvolver um aplicativo ou enviar uma transação. No entanto, existe um processo para propor alterações no protocolo principal, que é executado em cima de aplicações descentralizadas. Uma vez que tantas pessoas dependem da estabilidade do Ethereum, existe uma limitação de coordenação muito alta para mudanças principais, incluindo processos sociais e técnicos, para garantir que quaisquer alterações no Ethereum sejam seguras e amplamente suportadas pela comunidade.
-
-### Governança on-chain versus off-chain {#on-chain-vs-off-chain}
-
-A tecnologia Blockchain permite novos recursos de governança, conhecidos como governança on-chain. A governança on-chain é quando as alterações propostas no protocolo são decididas por votação das partes interessadas, geralmente por detentores de um token de governança, e a votação acontece no blockchain. Com algumas formas de governança on-chain, as mudanças de protocolo propostas já são escritas em código e implementadas automaticamente, se as partes interessadas aprovarem as mudanças por meio da assinatura de uma transação.
-
-A abordagem oposta, a governança off-chain, é quando quaisquer decisões de mudança de protocolo acontecem por meio de um processo informal de discussão social que, se aprovado, é implementado no código.
-
-**A governança da Ethereum acontece de maneira off-chain**, com uma grande variedade de partes interessadas envolvidas no processo.
-
-_Embora no protocolo a governança Ethereum seja off-chain, muitos casos de uso com base em Ethereum, como DAOs, usam a governação on-chain._
-
-
- Mais sobre DAOs
-
-
-
-
-## Quem está envolvido? {#who-is-involved}
-
-Existem vários interessados na [comunidade Ethereum](/community/), cada um desempenhando um papel no processo de governança. Começando pelas partes interessadas mais distantes do protocolo e ampliando, temos:
-
-- **Detentores de Ether**: essas pessoas têm uma quantidade arbitrária de ETH. [Mais sobre ETH](/eth/).
-- **Usuários da aplicação**: essas pessoas interagem com aplicativos no blockchain Ethereum.
-- **Desenvolvedores de aplicativos/ferramentas**: estas pessoas escrevem aplicativos que são executados no blockchain Ethereum (por exemplo, DeFi, NFTs etc.) ou criam ferramentas para interagir com a Ethereum (por exemplo, carteiras, suíte de testes etc.). [Mais sobre dapps](/dapps/).
-- **Operadores de nós**: essas pessoas executam nós que propagam blocos e transações, rejeitando qualquer transação ou bloco inválido que eles encontrem. [Mais sobre nós](/developers/docs/nodes-and-clients/).
-- **Autores do EIP**: estas pessoas propõem alterações no protocolo Ethereum, na forma de propostas de aprimoramento do Ethereum (EIPs). [Mais sobre EIPs](/eips/).
-- **Validadores**: essas pessoas executam nós que podem adicionar novos blocos à blockchain Ethereum.
-- **Desenvolvedores de protocolo** (conhecido como "Desenvolvedores principais": essas pessoas mantêm as várias implementações do Ethereum (por exemplo, go-ethereum, Nethermind, Besu, Erigon, Reth na camada de execução; ou Prysm, Lighthouse, Nimbus, Teku, Lodestar, na camada de consenso). [Mais sobre clientes Ethereum](/developers/docs/nodes-and-clients/).
-
-_Nota: qualquer indivíduo pode fazer parte de vários desses grupos (por exemplo, um desenvolvedor de protocolo pode ganhar um EIP e executar uma Beacon Chain validadora e usar aplicativos DeFi). Mas, para clareza conceitual, é mais fácil distinguir entre eles._
-
-
-
-## O que é um EIP? {#what-is-an-eip}
-
-Um processo importante usado na governança Ethereum é a sugestão de **Propostas de melhoria Ethereum (EIPs)**. EIPs são padrões que especificam novos recursos ou processos potenciais para a Ethereum. Qualquer um dentro da comunidade Ethereum pode criar um EIP. Caso tenha interesse em escrever uma EIP, participar em revisão por pares e/ou governança, consulte:
-
-
- Mais sobre EIPs
-
-
-
-
-## Processo formal {#formal-process}
-
-O processo formal para a introdução de alterações no protocolo Ethereum é o seguinte:
-
-1. **Propor um EIP principal**: como descrito em [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips), o primeiro passo para propor formalmente uma alteração no Ethereum é detalhá-la em um EIP principal. Isto funcionará como a especificação oficial de um EIP que os desenvolvedores do protocolo irão implementar, se aceitarem.
-
-2. **Apresentar seu EIP aos desenvolvedores do protocolo**: uma vez que você tiver um EIP principal para o qual você coletou informações da comunidade, você deve apresentá-lo aos desenvolvedores do protocolo. Você pode fazer isso propondo-a para discussão em uma chamada [AllCoreDevs](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status). É provável que algumas discussões já tenham acontecido de forma assíncrona no [fórum da Ethereum Magician](https://ethereum-magicians.org/) ou no [Ethereum R&D Discord](https://discord.gg/mncqtgVSVw).
-
-> Os resultados potenciais desta fase são:
-
-> - O EIP será considerado para uma atualização futura da rede
-> - Serão solicitadas mudanças técnicas
-> - Pode ser rejeitado se não for uma prioridade ou se a melhoria não for o suficientemente grande em relação ao esforço de desenvolvimento
-
-3. **Refazer a proposta final:** depois de receber feedback de todas as partes interessadas relevantes, você provavelmente precisará fazer alterações em sua proposta inicial para melhorar a segurança dela ou atender melhor às necessidades de vários usuários. Depois que sua EIP tiver incorporado todas as mudanças que você acredita serem necessárias, precisará apresentá-la novamente aos desenvolvedores do protocolo. Em seguida, você avançará para o próximo passo deste processo, ou surgirão novas preocupações, exigindo outra rodada de iterações sobre sua proposta.
-
-4. **EIP incluída na atualização de rede**: assumindo que a EIP seja aprovada, testada e implementada, ela é programada como parte de uma atualização de rede. Tendo em conta os altos custos de coordenação das atualizações da rede (todos precisam ser atualizados simultaneamente), as EIPs geralmente são agrupadas nas atualizações.
-
-5. **Atualização de rede ativada**: após a atualização de rede ser ativada, a EIP estará disponível na rede Ethereum. _Nota: atualizações de rede geralmente são ativadas nas redes de teste antes de serem ativadas na rede principal de Ethereum._
-
-Este fluxo, embora muito simplificado, fornece uma visão geral das etapas relevantes para alteração do protocolo que será ativado em Ethereum. Vejamos agora os fatores informais em jogo durante este processo.
-
-## Processo informal {#informal-process}
-
-### Entendendo o trabalho anterior {#prior-work}
-
-Os ganhadores da EIP devem se familiarizar com o trabalho prévio e as propostas antes de criar uma EIP que pode ser seriamente considerada para implantação na rede principal Ethereum. Desta forma, a EIP traz algo novo que não foi rejeitado antes. Os três principais lugares para pesquisar isso são o [repositório EIP](https://github.com/ethereum/EIPs), [Ethereum Magicians](https://ethereum-magicians.org/) e [ethresear.ch](https://ethresear.ch/).
-
-### Grupos de trabalho {#working-groups}
-
-É improvável que o rascunho inicial de uma EIP seja implementado na rede principal Ethereum sem edições ou alterações. Geralmente, os ganhadores da EIP trabalharão com um subconjunto de desenvolvedores de protocolo para especificar, implementar, testar, iterar e finalizar sua proposta. Historicamente, estes grupos de trabalho exigiram vários meses (e as vezes anos!) de trabalho. Da mesma forma, para tais mudanças, os ganhadores da EIP devem envolver, logo nos estágios iniciais, desenvolvedores relevantes de aplicativos e ferramentas em seus esforços para reunir feedback do usuário final e mitigar quaisquer riscos de implementação.
-
-### Consenso da comunidade {#community-consensus}
-
-Embora alguns EIPs sejam melhorias técnicas simples com nuances mínimas, alguns são mais complexos e vêm com tradeoffs que afetarão diferentes partes interessadas de maneiras diferentes. Isso significa que alguns EIPs são mais controversos dentro da comunidade do que outros.
-
-Não existe um roteiro claro sobre a forma de lidar com propostas controversas. Isso é resultado do design descentralizado do Ethereum, pelo qual nenhum grupo de participantes pode coagir o outro por meio de força bruta: os desenvolvedores de protocolo podem escolher não implementar mudanças de código; os operadores de nó podem escolher não executar o cliente Ethereum mais recente; equipes de aplicativos e usuários podem escolher não realizar transações na cadeia. Uma vez que os desenvolvedores do protocolo não têm como forçar as pessoas a adotarem atualizações de rede, geralmente evitarão a implementação de EIPs se os pontos controversos superarem os benefícios para a comunidade em geral.
-
-Espera-se que os campeões da EIP solicitem feedback de todas as partes interessadas relevantes. Se você encontrar o ganhador de uma EIP controversa, você deve tentar resolver objeções para criar consenso em torno da sua EIP. Dado o tamanho e a diversidade da comunidade Ethereum, não existe uma única métrica (por exemplo, uma votação de moeda) que pode ser usada para medir o consenso da comunidade e espera-se que os ganhadores do EIP se adaptem às circunstâncias da sua proposta.
-
-Além da segurança da rede Ethereum, os desenvolvedores de protocolo dão muita importância ao que os desenvolvedores de aplicativos/ferramentas e os usuários de aplicativos valorizam, dado que o uso que eles dão e o desenvolvimento que fazem na Ethereum é o que torna o ecossistema atraente para outras partes interessadas. Além disso, as EIPs precisam ser implementadas em todas as implementações do cliente, que são gerenciadas por equipes distintas. Parte deste processo geralmente significa convencer várias equipes de desenvolvedores do protocolo de que uma determinada mudança é valiosa e que ajuda usuários finais ou resolve um problema de segurança.
-
-
-
-## Tratamento de discordâncias {#disagreements}
-
-Ter muitas partes interessadas com motivações e convicções diferentes significa que as divergências não são incomuns.
-
-De um modo geral, os desacordos são tratados com discussões de longo prazo em fóruns públicos para compreender a raiz do problema e permitir que qualquer um faça ponderações. Normalmente, um grupo concede ou um meio termo é alcançado. Se houver um grupo que se sinta suficientemente forte, a imposição de uma determinada mudança poderá resultar em uma divisão da cadeia. Uma divisão da cadeia é quando algumas partes interessadas protestam pela implementação de uma mudança no protocolo, resultando em algo diferente, versões incompatíveis do protocolo que opera, do qual emergem dois blockchains distintos.
-
-### Bifurcação (Fork) de DAO {#dao-fork}
-
-Forks são quando é necessário fazer grandes melhorias técnicas ou alterações na rede e modificar as "regras" do protocolo. [Os clientes da Ethereum](/developers/docs/nodes-and-clients/) devem atualizar seu software para implementar as novas regras do fork.
-
-O fork da DAO foi em resposta ao [ataque da DAO de 2016](https://www.coindesk.com/understanding-dao-hack-journalists) no qual um contrato inseguro de [DAO](/glossary/#dao) foi drenado em mais de 3 milhões de ETH em um hack. O fork transferiu os fundos do contrato falho para um novo contrato, permitindo que qualquer um que perdeu fundos no hack os recuperasse.
-
-Este curso de ação foi votado pela comunidade Ethereum. Qualquer titular de ETH pôde votar por meio de uma transação em [uma plataforma de votação](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). A decisão de criar fork ultrapassou 85% dos votos.
-
-É importante notar que enquanto o protocolo fez um fork para reverter o hack, o peso que a votação teve na decisão de criar fork é discutível por algumas razões:
-
-- A participação na votação foi incrivelmente baixa
-- A maioria das pessoas não sabia que a votação estava acontecendo
-- O voto somente representou os titulares de ETH, e nenhum dos outros participantes no sistema
-
-Um subconjunto da comunidade se recusou a fazer um fork, principalmente por sentirem que o incidente da DAO não era um defeito no protocolo. Eles começaram a formar a [Ethereum Classic](https://ethereumclassic.org/).
-
-Hoje, a comunidade Ethereum adotou uma política de não intervenção em casos de erros contratuais ou perda de fundos para manter a neutralidade verossímil do sistema.
-
-Veja mais sobre o hack DAO:
-
-
-
-
-
-### A utilidade do forking {#forking-utility}
-
-O fork Ethereum/Ethereum Classic é um excelente exemplo de um fork íntegro. Houve dois grupos que não chegaram a um consenso com respeito a alguns valores fundamentais, pois sentiram que prosseguir com suas ações específicas valia o risco.
-
-A capacidade de criar forks em face de diferenças políticas, filosóficas ou econômicas desempenha um papel importante no sucesso da governança Ethereum. Sem capacidade de lançar fork, a alternativa era a luta interna contínua, participação relutante forçada para aqueles que eventualmente formaram o Ethereum Classic e uma visão cada vez mais diferente do sucesso para o Ethereum.
-
-
-
-## Governança da Beacon Chain {#beacon-chain}
-
-O processo de governança Ethereum muitas vezes troca velocidade e eficiência por abertura e inclusão. A fim de acelerar o desenvolvimento da Beacon Chain, esta foi lançada separadamente da prova de trabalho da rede Ethereum e seguiu suas próprias práticas de governança.
-
-Embora as implementações de especificação e desenvolvimento sempre tenham sido totalmente de código aberto, os processos formais usados para propor as atualizações descritas acima não foram usados. Isso permitiu que as alterações fossem especificadas e acordadas mais rapidamente por pesquisadores e implementadores.
-
-Quando ocorreu a fusão da Beacon Chain com a camada de execução do Ethereum em 15 de setembro de 2022, a transação foi concluída como parte da [melhoria da rede Paris](/history/#paris). A proposta [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) foi alterada de "Última Chamada" para "Final", completando a transição para o prova de participação.
-
-
- Mais sobre a integração
-
-
-
-
-## Como posso participar? {#get-involved}
-
-- [Propor um EIP](/eips/#participate)
-- [Discutir as propostas atuais](https://ethereum-magicians.org/)
-- [Envolver-se na discussão de R&D](https://ethresear.ch/)
-- [Unir-se ao Discord da Ethereum R&D](https://discord.gg/mncqtgVSVw)
-- [Executar um nó](/developers/docs/nodes-and-clients/run-a-node/)
-- [Contribuir para o desenvolvimento do cliente](/developers/docs/nodes-and-clients/#execution-clients)
-- [Programa de aprendizagem de desenvolvimento principal](https://blog.ethereum.org/2021/09/06/core-dev-apprenticeship-second-cohort/)
-
-## Leitura adicional {#further-reading}
-
-A governança na Ethereum não está definida de forma rígida. Vários participantes da comunidade têm diversas perspectivas sobre isso. Aqui estão alguns deles:
-
-- [Notas sobre governança da blockchain](https://vitalik.eth.limo/general/2017/12/17/voting.html) - _Vitalik Buterin_
-- [Como funciona a governança Ethereum?](https://cryptotesters.com/blog/ethereum-governance) – _Criptotesters_
-- [Como funciona a governança Ethereum](https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a) – _Micah Zoltu_
-- [O que é um desenvolvedor principal Ethereum?](https://hudsonjameson.com/2020-06-22-what-is-an-ethereum-core-developer/) – _Hudson Jameson_
-- [Governança, Parte 2: a plutocracia ainda é uma desvantagem](https://vitalik.eth.limo/general/2018/03/28/plutocracy.html) – _Vitalik Buterin_
-- [Indo além da governança por meio da votação com moedas.](https://vitalik.eth.limo/general/2021/08/16/voting3.html) – _Vitalik Buterin_
diff --git a/public/content/translations/pt-br/09) Learn Pages/security/index.md b/public/content/translations/pt-br/09) Learn Pages/security/index.md
deleted file mode 100644
index 7a9e2f6081b..00000000000
--- a/public/content/translations/pt-br/09) Learn Pages/security/index.md
+++ /dev/null
@@ -1,293 +0,0 @@
----
-title: Segurança e prevenção de fraude do Ethereum
-description: Como manter a segurança no Ethereum
-lang: pt-br
----
-
-# Segurança e prevenção de fraude do Ethereum {#introduction}
-
-O crescente interesse em criptomoedas traz consigo um risco crescente de golpistas e hackers. Este artigo apresenta algumas práticas recomendadas para mitigar esses riscos.
-
-
-
-## Noções básicas sobre segurança de criptomoedas {#crypto-security}
-
-### Aumente o seu nível de conhecimento {#level-up-your-knowledge}
-
-Uma má compreensão de como as criptomoedas funcionam pode levar a erros caros. Por exemplo, se alguém finge ser um agente de atendimento ao cliente que pode devolver ETH perdido em troca de suas chaves privadas, ele está se aproveitando de pessoas que não entendem que o Ethereum é uma rede descentralizada que não possui esse tipo de funcionalidade. Educar-se sobre como o Ethereum funciona é um investimento valioso.
-
-
- O que é Ethereum?
-
-
-
- O que é ether?
-
-
-
-## Segurança da carteira {#wallet-security}
-
-### Não divulgue suas chaves privadas {#protect-private-keys}
-
-**Nunca, em hipótese alguma, compartilhe suas chaves privadas!**
-
-A chave privada para sua carteira é também uma senha para sua carteira Ethereum. É a única coisa que impede que alguém que conheça o endereço de sua carteira drene todos os ativos da sua conta!
-
-
- O que é uma carteira Ethereum?
-
-
-#### Não faça capturas de tela das suas frases de recuperação/chaves privadas {#screenshot-private-keys}
-
-Fazer uma captura de tela de suas frases de recuperação ou chaves privadas pode sincronizá-las com um provedor de dados em nuvem, o que pode torná-las acessíveis a hackers. Obter as chaves privadas da nuvem é um vetor de ataque comum para os hackers.
-
-### Use uma carteira de hardware {#use-hardware-wallet}
-
-Uma carteira de hardware fornece armazenamento off-line para chaves privadas. Elas são consideradas a opção de carteira mais segura para armazenar suas chaves privadas, pois elas nunca entram em contato com a Internet e permanecem completamente locais em seu dispositivo.
-
-Manter chaves privadas off-line reduz maciçamente o risco de serem hackeadas, mesmo que um hacker tenha controle de seu computador.
-
-#### Experimente uma carteira de hardware: {#try-hardware-wallet}
-
-- [Ledger](https://www.ledger.com/)
-- [Trezor](https://trezor.io/)
-
-### Verifique duas vezes as transações antes de enviar {#double-check-transactions}
-
-Enviar criptomoedas acidentalmente para um endereço de carteira errado é um erro comum. **Uma transação enviada no Ethereum é irreversível.** A menos que você conheça o proprietário do endereço e consiga convencê-lo a enviar o dinheiro de volta, você não será capaz de reaver seus fundos.
-
-Certifique-se sempre de que o endereço de destino corresponde exatamente ao endereço do destinatário desejado antes de enviar uma transação. Ler a mensagem da transação antes de assiná-la é uma prática recomendada quando interagir com um contrato inteligente.
-
-### Defina limites de gastos para contratos inteligentes {#spend-limits}
-
-Ao interagir com contratos inteligentes, não permita limites de gastos ilimitados. Uma despesa ilimitada poderia permitir que o contrato inteligente drenasse a sua carteira. Em vez disso, defina limites de gastos apenas na quantidade necessária para a transação.
-
-Muitas carteiras Ethereum oferecem proteção de limites para evitar que as contas sejam drenadas.
-
-[Como revogar o acesso ao contrato inteligente aos seus fundos cripto](/guides/how-to-revoke-token-access/)
-
-
-
-## Fraudes comuns {#common-scams}
-
-É impossível deter os fraudadores por completo, mas é possível fazer com que eles sejam menos eficazes ao conhecer as técnicas mais usadas deles. Existem muitas variações dessas fraudes, mas elas geralmente seguem os mesmos padrões de alto nível. Em todo caso, lembre-se:
-
-- sempre seja cético
-- Ninguém vai te dar ETH de graça ou com desconto
-- ninguém precisa acessar suas chaves privadas ou informações pessoais
-
-### Phishing via anúncio no Twitter {#ad-phishing}
-
-
-
-Há um método para falsificar o recurso de pré-visualização de links (desenrolar) do Twitter (também conhecido como X) para potencialmente enganar os usuários, fazendo-os pensar que estão acessando um site verdadeiro. Esta técnica explora o mecanismo do Twitter para gerar pré-visualizações de URLs compartilhados em tweets e mostra _de ethereum.org_, por exemplo (mostrado acima), quando na verdade eles estão sendo redirecionados para um site malicioso.
-
-Sempre verifique que você está no domínio correto, especialmente depois de clicar em um link.
-
-[Mais informações aqui](https://harrydenley.com/faking-twitter-unfurling).
-
-### Golpe de doação {#giveaway}
-
-Uma das fraudes mais comuns com criptomoedas é o golpe de sorteio. O golpe de sorteio pode ter várias formas. Mas a ideia geral é que se você enviar ETH para um endereço de carteira oferecido, receberá o dobro dos ETH que enviou. *Por esta razão, esse golpe também é conhecido como "golpe dois em um".*
-
-Estes golpes geralmente estipulam um tempo limite para receber seu prêmio, para criar uma falsa sensação de urgência.
-
-### Hacks de mídia social {#social-media-hacks}
-
-Um exemplo notório desses ocorreu em julho de 2020, quando as contas do Twitter de celebridades e organizações foram hackeadas. O hacker publicou simultaneamente uma doação de Bitcoins nas contas hackeadas. Embora os tweets enganosos tenham sido rapidamente detectados e excluídos, os hackers ainda conseguiram levar 11 bitcoins (ou US$ 500.000 em setembro de 2021) e saíram impunes.
-
-
-
-### Golpe de doação usando celebridades {#celebrity-giveaway}
-
-O golpe de sorteio usando celebridades é outra variável comum do golpe sorteio. Os golpistas pegarão uma entrevista de vídeo ou uma palestra gravada dada por uma celebridade e a transmitirão ao vivo no YouTube, fazendo parecer que a celebridade estava dando uma entrevista ao vivo promovendo um sorteio de criptomoedas.
-
-Vitalik Buterin é frequentemente usado nessa fraude, mas muitas outras pessoas famosas envolvidas com criptomoedas também são usadas (por exemplo, Elon Musk ou Charles Hoskinson). Incluir uma pessoa conhecida dá às transmissões ao vivo dos golpistas um sentido de legitimidade (isso parece suspeito, mas como Vitalik está envolvido, então deve ser bom!).
-
-**Os sorteios são sempre fraudes. Se você enviar seus fundos para essas contas, os perderá para sempre.**
-
-
-
-### Golpes de suporte {#support-scams}
-
-Criptomoeda é uma tecnologia relativamente jovem e mal compreendida. Uma fraude comum que tira vantagem disso é a fraude de suporte, na qual os golpistas se personificam como equipe de suporte de carteiras, agências de câmbio ou blockchains populares.
-
-A maior parte da discussão sobre Ethereum acontece no Discord. Os golpistas de suporte normalmente encontrarão seu alvo em canais públicos do Discord, nos quais procurarão questões de suporte e enviarão ao usuário uma mensagem privada oferecendo suporte. Ao criar segurança, os golpistas de suporte tentarão induzir você a revelar suas chaves privadas ou a enviar seus fundos para as carteiras deles.
-
-
-
-Como regra geral, o pessoal de suporte nunca se comunicará com você por meio de canais privados não oficiais. Algumas coisas simples a ter em mente ao lidar com o suporte:
-
-- Nunca compartilhe suas chaves privadas, frases semente ou senhas
-- Nunca permita que alguém acesse remotamente o seu computador
-- Nunca comunicar fora dos canais designados por uma organização
-
-
-
- Cuidado: embora fraudes ao estilo de suporte ocorram normalmente no Discord, elas também podem acontecer em qualquer aplicativo de bate-papo onde ocorram discussões sobre criptomoedas, incluindo e-mail.
-
-
-
-### Golpe com o token 'Eth2' {#eth2-token-scam}
-
-Na fase de preparação para [The Merge](/roadmap/merge/) (A Fusão), os golpistas aproveitaram a confusão em torno do termo "Eth2" para tentar fazer com que os usuários resgatassem seu ETH por um token "ETH2". Não há "ETH2" e nenhum outro token legítimo foi introduzido com a A Fusão. O ETH que você possuía antes da fusão é o mesmo ETH agora. Não há **necessidade de realizar nenhuma ação relacionada ao seu ETH para contabilizar a mudança de prova de trabalho para prova de participação**.
-
-Os golpistas podem aparecer como "suporte", informando que, se você depositar seu ETH, você receberá de volta "ETH2". Não há [suporte oficial ao Ethereum](/community/support/)e não há nenhum novo token. Jamais compartilhe a frase de recuperação de sua carteira com ninguém.
-
-_Nota: existem tokens/rótulos derivados que podem representar ETH em participação (ou seja, rETH do Rocket Pool, stETH de Lido, ETH2 do Coinbase), mas você não precisa "migrar" para algum eles._
-
-### Golpes de “phishing” {#phishing-scams}
-
-Golpes de “phishing” são outra abordagem cada vez mais comum que os golpistas usarão para tentar roubar os fundos da sua carteira.
-
-Alguns e-mails de “phishing” pedem aos usuários que cliquem em links que os redirecionarão para sites falsos, pedindo para inserir a frase de recuperação, redefinir sua senha ou enviar ETH. Outros podem induzir você a instalar “malwares” inadvertidamente para infectar seu computador e dar aos golpistas acesso aos arquivos do seu computador.
-
-Se você receber um e-mail de um remetente desconhecido, lembre-se:
-
-- Nunca abrir um link ou anexo dos endereços de correio eletrônio que você não reconheça
-- Nunca divulgue suas informações pessoais ou senhas para ninguém
-- Exclua toda correspondência eletrônica de remetentes desconhecidos
-
-[Mais sobre como evitar golpes de “phishing”](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico)
-
-### Golpes de corretores de criptomoedas {#broker-scams}
-
-Corretores de criptomoedas fraudulentos afirmam ser especialistas em criptomoedas e se oferecerão para pegar seu dinheiro e investir em seu nome. Depois que o golpista recebe seus fundos, ele pode persuadir você a enviar mais fundos, para que você não perca mais ganhos de investimento, ou pode desaparecer por completo.
-
-Esses fraudadores geralmente encontram alvos usando contas falsas no YouTube para iniciar conversas aparentemente naturais sobre o "corretor". Essas conversas geralmente têm muitas curtidas para aumentar a legitimidade, mas elas são todas de contas de robôs.
-
-**Não confie em estranhos na Internet para investir em seu nome. Você perderá suas criptomoedas.**
-
-
-
-### Golpes de pool (consórcio) de mineração de criptomoedas {#mining-pool-scams}
-
-A partir de setembro de 2022, não será mais possível realizar mineração no Ethereum. No entanto, os golpes de pool de mineração ainda existem. Os golpes de pool de mineração envolvem pessoas que entram em contato com você, sem a sua solicitação, alegando que você pode obter grandes retornos juntando-se a um pool de mineração Ethereum. O golpista continuará fazendo afirmações e permanecerá em contato com você pelo tempo que for necessário. Essencialmente, o golpista tentará convencê-lo de que, quando você se juntar a um pool de mineração de Ethereum, sua criptomoeda será usada para criar ETH e que você receberá dividendos em ETH. Você verá então que sua criptomoeda está gerando pequenos retornos. Isso é simplesmente uma isca para induzi-lo a investir mais. Por fim, todos os seus fundos serão enviados para um endereço desconhecido e o golpista desaparecerá ou, em alguns casos, ele continuará mantendo contato, como aconteceu em um caso recente.
-
-Resumindo: tenha cuidado com pessoas que entram em contato com você nas redes sociais pedindo para você fazer parte de um pool de mineração. Uma vez que você perde a sua criptomoeda, não há como recuperá-la.
-
-Algumas coisas para você se lembrar:
-
-- Desconfie de qualquer pessoa que entre em contato com você oferecendo maneiras de ganhar dinheiro com sua criptomoeda
-- Faça sua pesquisa sobre staking, pools de liquidez ou outras formas de investir sua criptomoeda
-- Raramente, ou nunca, tais esquemas são legítimos. Se fossem, provavelmente seriam bastante conhecidos e você já deveria ter ouvido falar deles.
-
-[Homem perde 200.000 dólares em golpe de pool de mineração](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/)
-
-### Golpes de airdrop {#airdrop-scams}
-
-As fraudes com airdrop envolvem um projeto fraudulento que lança um ativo (NFT, token) em sua carteira e o redireciona para um site fraudulento para você reivindicar o ativo lançado. Você será solicitado a entrar com a sua carteira Ethereum e "aprovar" uma transação ao tentar reivindicar o ativo falso. Essa transação compromete a sua conta enviando suas chaves públicas e privadas para o golpista. Uma forma alternativa dessa fraude pode fazer com que você confirme uma transação que enviará fundos para a conta do golpista.
-
-[Mais sobre fraudes com airdrop](https://www.youtube.com/watch?v=LLL_nQp1lGk)
-
-
-
-## Noções básicas de segurança na web {#web-security}
-
-### Use senhas fortes {#use-strong-passwords}
-
-[Mais de 80% da usurpação de contas são um resultado de senhas fracas ou roubadas](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Uma longa combinação de caracteres, números e símbolos ajudará a manter suas contas seguras.
-
-Um erro comum é usar uma combinação de algumas palavras comuns e relacionadas. Senhas como essas são inseguras porque são propensas a uma técnica de invasão chamada ataque de dicionário.
-
-```md
-Exemplo de uma senha fraca: CuteFluffyKittens!
-
-Exemplo de uma senha forte: ymv\*azu.EAC8eyp8umf
-```
-
-Outro erro comum é usar senhas que podem ser facilmente adivinhadas ou descobertas por meio de [engenharia social](https://wikipedia.org/wiki/Social_engineering_(security)). Incluir o nome de solteira da sua mãe, os nomes dos seus filhos ou animais de estimação, ou datas de nascimento na sua senha aumentará o risco de ser hackeado.
-
-#### Práticas recomendadas relacionadas a senhas: {#good-password-practices}
-
-- Crie senhas tão extensas quanto permitidas pelo gerador de senhas ou pelo formulário que você está preenchendo
-- Use uma combinação de maiúsculas, minúsculas, números e símbolos
-- Não use detalhes pessoais, como nomes de membros da família, em sua senha
-- Evite palavras comuns
-
-[Mais sobre a criação de senhas fortes](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/)
-
-### Use senhas exclusivas para tudo {#use-unique-passwords}
-
-Uma senha forte que foi revelada em uma violação de dados não é mais uma senha forte. O site [Have I Been Pwned](https://haveibeenpwned.com) permite que você verifique se suas contas foram envolvidas em alguma violação de dados públicos. Se este tiver sido o caso, ** altere essas senhas imediatamente**. Usar senhas exclusivas para cada conta diminui o risco de hackers terem acesso a todas as suas contas caso uma delas seja comprometida.
-
-### Use um gerenciador de senhas {#use-password-manager}
-
-
-
- Usar um gerenciador de senhas faz com que ele crie senhas fortes, únicas e que sejam lembradas! Nós fortemente recomendamos usar um, e a maioria deles é gratuita!
-
-
-
-Lembrar de senhas fortes e exclusivas para cada conta que você possui não é o ideal. Um gerenciador de senhas oferece um cofre seguro e criptografado para todas as suas senhas que você pode acessar por meio de uma senha mestra forte. Eles também sugerem senhas fortes quando você se inscreve em um novo serviço, para que você não precise criar as suas próprias. Muitos gerenciadores de senhas também irão informar se você esteve envolvido em uma violação de dados, permitindo que você altere as senhas antes de qualquer ataque malicioso.
-
-
-
-#### Experimente um gerenciador de senha: {#try-password-manager}
-
-- [Bitwarden](https://bitwarden.com/)
-- [KeePass](https://keepass.info/)
-- [1Password](https://1password.com/)
-- Ou confira outros [gerenciadores de senhas recomendados](https://www.privacytools.io/secure-password-manager)
-
-### Use autenticação de dois fatores {#two-factor-authentication}
-
-Às vezes, você pode ser solicitado a autenticar sua identidade por meio de provas exclusivas. Essas são conhecidas como **fatores**. Os três principais fatores são:
-
-- Algo que você saiba (como uma senha ou uma pergunta de segurança)
-- Algo que você seja (como uma impressão digital ou uma varredura facial)
-- Algo que você possui (uma chave de segurança ou aplicativo de autenticação no seu telefone)
-
-Usar a **Autenticação de dois fatores (2FA)** fornece um *fator de segurança* adicional para suas contas online. A 2FA garante que o fato de ter somente a senha não é suficiente para acessar uma conta. Mais comumente, o segundo fator é um código de 6 dígitos aleatórios, conhecido como **uma senha de uso único (TOTP, na sigla em inglês)**, que você pode acessar através de um aplicativo de autenticação, como o Google Authenticator ou Authy. Estes funcionam como um fator de "algo que você possui" porque a seed que gera o código temporizado é armazenado em seu dispositivo.
-
-
-
- Observação: usar 2FA baseada em SMS é suscetível a sequestro de SIM e não é seguro. Para melhor segurança, use um serviço como o Google Authenticator ou o Authy.
-
-
-
-#### Chaves de segurança {#security-keys}
-
-Uma chave de segurança é um tipo mais avançado e seguro de 2FA. Chaves de segurança são dispositivos de autenticação de hardware físico que funcionam como aplicativos autenticadores. A utilização de uma chave de segurança é a forma mais segura para a 2FA. Muitas dessas chaves utilizam o padrão FIDO Universal 2nd Factor (U2F). [Aprenda mais sobre FIDO U2F](https://www.yubico.com/authentication-standards/fido-u2f/).
-
-Veja mais sobre 2FA:
-
-
-
-### Desinstale extensões de navegador {#uninstall-browser-extensions}
-
-Extensões do navegador, como extensões do Chrome ou complementos para o Firefox, podem melhorar a funcionalidade do navegador, mas também apresentam riscos. Por padrão, a maioria das extensões de navegador solicita acesso para "ler e alterar dados do site", permitindo que elas façam quase tudo com seus dados. As extensões do Chrome são sempre atualizadas automaticamente, portanto, uma extensão previamente segura pode ser atualizada mais tarde para incluir código malicioso. A maioria das extensões de navegador não está tentando roubar seus dados, mas você deve estar ciente de que elas podem.
-
-#### Mantenha a segurança: {#browser-extension-safety}
-
-- Somente instale extensões de navegador de fontes confiáveis
-- Remova extensões de navegador que não sejam utilizadas
-- Instale extensões do Chrome localmente para interromper a atualização automática (Avançado)
-
-[Mais sobre os riscos das extensões do navegador](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/)
-
-
-
-## Leia mais {#further-reading}
-
-### Segurança na web {#reading-web-security}
-
-- [Até 3 milhões de dispositivos infectados por complementos do Chrome e Edge com malware](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) - _Dan Goodin_
-- [Como criar uma senha forte — que você não vai esquecer](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) - _AVG_
-- [O que é uma chave de segurança?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) - _Coinbase_
-
-### Segurança de criptomoedas {#reading-crypto-security}
-
-- [Protegendo você e seus fundos](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) - _MyCrypto_
-- [Problemas de segurança em software de comunicação criptográfica comum](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) - _Salus_
-- [Guia de segurança para leigos e pessoas inteligentes também](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) - _MyCrypto_
-- [Segurança de criptomoedas: senhas e autenticação](https://www.youtube.com/watch?v=m8jlnZuV1i4) - _Andreas M. Antonopoulos_
-
-### Informações sobre golpes {#reading-scam-education}
-
-- [Guia: Como identificar tokens fraudulentos](/guides/how-to-id-scam-tokens/)
-- [Como se proteger: golpes comuns](https://support.mycrypto.com/staying-safe/common-scams) - _MyCrypto_
-- [Como evitar golpes](https://bitcoin.org/en/scams) - _Bitcoin.org_
-- [Discussão no Twitter sobre e-mails e mensagens comuns de phishing de criptografia](https://twitter.com/tayvano_/status/1516225457640787969) - _Taylor Monahan_
-
-
diff --git a/public/content/translations/pt-br/09) Learn Pages/zero-knowledge-proofs/index.md b/public/content/translations/pt-br/09) Learn Pages/zero-knowledge-proofs/index.md
deleted file mode 100644
index 9c6034793a5..00000000000
--- a/public/content/translations/pt-br/09) Learn Pages/zero-knowledge-proofs/index.md
+++ /dev/null
@@ -1,214 +0,0 @@
----
-title: Prova de conhecimento zero
-description: Uma introdução não técnica às provas de conhecimento zero para iniciantes.
-lang: pt-br
----
-
-# O que são provas de conhecimento zero? {#what-are-zk-proofs}
-
-Uma prova de conhecimento zero é uma forma de provar a validade de uma afirmação sem a revelar. O “provador” é a parte que tenta provar uma reivindicação, enquanto o “verificador” é responsável pela validação da reivindicação.
-
-As provas de conhecimento zero apareceram pela primeira vez em um artigo de 1985, “[A complexidade conhecida dos sistemas de prova interativos](http://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf)que fornece uma definição de provas de conhecimento zero amplamente utilizadas hoje:
-
-> Um protocolo de conhecimento zero é um método pelo qual uma parte (o provador) **pode comprovar** a outra parte (o verificador) **que algo é verdadeiro, sem revelar nenhuma informação** além do fato de que essa declaração específica é verdadeira.
-
-As provas de conhecimento zero melhoraram ao longo dos anos e agora estão sendo usadas em várias aplicações do mundo real.
-
-
-
-## Por que precisamos de provas de conhecimento zero? {#why-zero-knowledge-proofs-are-important}
-
-As provas de conhecimento zero representaram um avanço na criptografia aplicada, pois prometeram melhorar a segurança da informação para os indivíduos. Considere como você pode provar uma reivindicação (por exemplo, "sou um cidadão do país X") para outra parte (por exemplo, um provedor de serviços). Você precisaria fornecer "provas" para sustentar sua reivindicação, como um passaporte ou uma carteira de motorista.
-
-Porém, há problemas com esta abordagem, principalmente com a falta de privacidade. Informações de identificação pessoal (PII) compartilhadas com serviços de terceiros são armazenadas em bancos de dados centrais, que são vulneráveis a hacks. Com o fato de o roubo de identidade ter se tornado um problema crítico, existe uma demanda por mais meios de proteção da privacidade no compartilhamento de informações confidenciais.
-
-As provas de conhecimento zero resolvem esse problema ao **eliminar a necessidade de revelar informações para provar a validade das afirmações**. O protocolo de conhecimento zero usa a declaração (chamada "testemunha") como entrada para gerar uma prova sucinta de sua validade. Essa prova oferece fortes garantias de que uma declaração é verdadeira sem expor a informação utilizada na sua criação.
-
-Voltando ao nosso exemplo anterior, a única evidência de que é necessário provar a sua reivindicação de cidadania é uma prova de conhecimento zero. O verificador só precisa verificar se certas propriedades da prova em questão são verdadeiras para estar convencido de que a declaração subjacente também é verdadeira.
-
-## Casos de uso para provas de conhecimento zero {#use-cases-for-zero-knowledge-proofs}
-
-### Pagamentos anônimos {#anonymous-payments}
-
-Pagamentos com cartão de crédito são frequentemente visíveis para várias partes, incluindo o provedor de pagamentos, bancos e outras partes interessadas (por exemplo, autoridades do governo). Embora a supervisão financeira tenha benefícios ao identificar atividades ilegais, ela também prejudica a privacidade dos cidadãos comuns.
-
-O objetivo das criptomoedas era fornecer um meio para os usuários realizarem transações privadas entre pares. Mas a maioria das transações de criptomoedas são abertamente visíveis em blockchains públicas. Identidades de usuário são muitas vezes pseudônimo e ambos intencionalmente ligados a identidades do mundo real (por exemplo, incluindo endereços ETH nos perfis do Twitter ou GitHub) ou pode ser associado com identidades no mundo real usando análises de dados básicas dentro e fora da cadeia.
-
-Existem "moedas de privacidade" específicas desenhadas para transações completamente anônimas. Blockchains focadas na privacidade, como Zcash e Monero, protegem detalhes da transação, incluindo endereços do remetente/destinatário, tipo de ativo, quantidade e linha do tempo da transação.
-
-Ao incorporar a tecnologia de conhecimento zero ao protocolo, as redes [blockchain](/glossary/#blockchain) voltadas para a privacidade permitem que os [nós](/glossary/#node) validem as transações sem precisar acessar os dados da transação.
-
-<0>Provas de conhecimento zero também estão sendo aplicadas para tornar anônimas transações em blockchains públicas. Um exemplo é o Tornado Cash, um serviço descentralizado e sem custódia que permite aos usuários realizar transações privadas no Ethereum. O Tornado Cash usa provas de conhecimento zero para ofuscar os detalhes das transações e garantir privacidade financeira. Infelizmente, por se tratar de ferramentas de privacidade "opt-in", elas estão associadas a atividades ilícitas. Para superar isso, a privacidade deve se tornar o padrão em blockchains públicas.
-
-### Proteção de identidade {#identity-protection}
-
-Os atuais sistemas de gestão de identidade colocam em risco a informação pessoal. Provas de conhecimento zero podem ajudar os indivíduos a validar a identidade enquanto protegem detalhes confidenciais.
-
-Provas de conhecimento zero são particularmente úteis no contexto de uma [identidade descentralizada](/decentralized-identity/). Identidade descentralizada (também descrita como "identidade autossoberana") dá ao indivíduo a capacidade de controlar o acesso aos identificadores pessoais. Prover a sua cidadania sem revelar o seu documento de identidade fiscal ou detalhes do seu passaporte é um bom exemplo de como a tecnologia de conhecimento zero permite a identidade descentralizada.
-
-### Autenticação {#authentication}
-
-Para usar os serviços online é necessário provar sua identidade e o direito de acesso a essas plataformas. Isso requer, frequentemente, o fornecimento de informações pessoais, como nomes, endereços de e-mail, datas de nascimento e assim por diante. Você também poderá precisar decorar senhas longas ou correr o risco de perder o acesso.
-
-No entanto, provas de conhecimento zero podem simplificar a autenticação para plataformas e usuários. Uma vez que uma prova de ZK foi gerada usando entradas públicas (por exemplo, dados que atestam que o membro é usuário da plataforma) e entradas privadas (por exemplo, os detalhes do usuário), o usuário pode simplesmente apresentá-lo para autenticar sua identidade quando ele precisar acessar o serviço. Isso melhora a experiência para usuários e libera as empresas da necessidade de armazenar grandes quantidades de informação do usuário.
-
-### Computação verificável {#verifiable-computation}
-
-Computação verificável é outra aplicação de tecnologia de conhecimento zero para melhorar os projetos de blockchain. A computação verificável nos permite terceirizar a computação para outra entidade, mantendo resultados verificáveis. A entidade envia o resultado juntamente com uma prova verificando que o programa foi executado corretamente.
-
-A computação verificável é **crítica para melhorar as velocidades de processamento em blockchains** sem reduzir a segurança. Compreender isso requer conhecer as diferenças nas soluções propostas para dimensionar o Ethereum.
-
-[Soluções de dimensionamento em cadeia](/developers/docs/scaling/#on-chain-scaling), como fragmentação, exigem ampla modificação da camada base da blockchain. No entanto, essa abordagem é altamente complexa e erros na implementação podem comprometer o modelo de segurança do Ethereum.
-
-As [soluções de dimensionamento fora da cadeia](/developers/docs/scaling/#off-chain-scaling) não exigem a reformulação do protocolo central do Ethereum. Em vez disso, elas contam com um modelo de computação terceirizado para melhorar a taxa de transferência na camada base do Ethereum.
-
-Veja como isso funciona na prática:
-
-- Em vez de processar todas as transações, o Ethereum transfere a execução para uma cadeia separada.
-
-- Após o processamento das transações, a outra cadeia retorna os resultados para serem aplicados ao estado do Ethereum.
-
-A vantagem aqui é que o Ethereum não precisa fazer nenhuma execução e só precisa aplicar os resultados da computação terceirizada ao seu estado. Isso reduz o congestionamento da rede e também melhora as velocidades de transação (protocolos fora da cadeia otimizados para execução mais rápida).
-
-A cadeia precisa de uma maneira de validar transações fora da cadeia sem reexecutá-las, caso contrário, o valor da execução fora da cadeia é perdido.
-
-É aqui que a computação verificável entra em jogo. Quando um nó executa uma transação fora do Ethereum, ele envia uma prova de conhecimento zero para provar a correção da execução fora da cadeia. Essa prova (chamada [prova de validação](/glossary/#validity-proof)) garante que uma transação é válida, permitindo que o Ethereum aplique o resultado ao seu estado, sem esperar que alguém conteste.
-
-[Roll-ups de conhecimento zero](/developers/docs/scaling/zk-rollups) e [validos](/developers/docs/scaling/validium/) são duas soluções de escalabilidade fora de cadeia que usam provas de validação para fornecer escalabilidade segura. Esses protocolos executam milhares de transações fora da cadeia e enviam provas para verificação no Ethereum. Esses resultados podem ser aplicados imediatamente após a verificação da prova, permitindo que o Ethereum processe mais transações sem aumentar a computação na camada base.
-
-### Redução do suborno e conivência na votação em cadeia {#secure-blockchain-voting}
-
-Os esquemas de votação em blockchain têm muitas características favoráveis: eles são totalmente auditáveis, protegidos contra ataques, resistentes à censura e livres de restrições geográficas. Mas mesmo os esquemas de votação em cadeia não são imunes ao problema de **conluio**.
-
-Definido como “coordenar para limitar a concorrência aberta enganando, defraudando e enganando os outros”, um conluio pode assumir a forma de uma pessoa maliciosa que influencia os votos oferecendo subornos. Por exemplo, Alice pode receber um suborno de Bob para votar na `opção B` em uma cédula, mesmo que ela prefira a `opção A`.
-
-Suborno e conluio limitam a efetividade de qualquer processo que use a votação como um mecanismo de sinalização (especialmente quando os usuários podem provar como votaram). Isso pode ter consequências significativas, especialmente quando os votos são responsáveis pela alocação de recursos escassos.
-
-Por exemplo, [mecanismos de financiamento quadráticos](https://www.radicalxchange.org/concepts/plural-funding/) dependem de doações para medir a preferência por certas opções entre diferentes projetos de bem público. Cada doação conta como um “voto” para um projeto específico, com os projetos que recebem mais votos obtendo mais fundos do pool correspondente.
-
-O uso da votação em cadeia torna o financiamento quadrático suscetível a conluio: as transações de blockchain são públicas, portanto os subornadores podem inspecionar a atividade em cadeia de um subornado para ver como eles “votaram”. Dessa forma, o financiamento quadrático deixa de ser um meio eficaz de alocação de fundos com base nas preferências agregadas da comunidade.
-
-Felizmente, soluções mais recentes, como MACI (Minimum Anti-Collusion Infrastructure) estão usando provas de conhecimento zero para tornar a votação em cadeia (por exemplo, mecanismos de financiamento quadráticos) resistente a suborno e conluio. MACI é um conjunto de contratos inteligentes e scripts que permitem a um administrador central (chamado de “coordenador”) agregar votos e contar os resultados _sem_ revelar especificidades sobre como cada indivíduo votou. Mesmo assim, ainda é possível verificar se os votos foram devidamente contados, ou confirmar que um determinado indivíduo participou da rodada de votação.
-
-#### Como a MACI funciona com provas de conhecimento zero? {#how-maci-works-with-zk-proofs}
-
-No início, o coordenador implanta o contrato MACI no Ethereum, após o qual os usuários podem se inscrever para votação (registrando sua chave pública no contrato inteligente). Os usuários votam enviando mensagens criptografadas com sua chave pública para o contrato inteligente (um voto válido deve ser assinado com a chave pública mais recente associada à identidade do usuário, entre outros critérios). Em seguida, o coordenador processa todas as mensagens quando o período de votação termina, contabiliza os votos e verifica os resultados em cadeia.
-
-Na MACI, as provas de conhecimento zero são usadas para garantir a exatidão do cálculo, tornando impossível para o coordenador processar os votos e apurar os resultados incorretamente. Isto é alcançado exigindo que o coordenador gere provas ZK-SNARK verificando se a) todas as mensagens foram processadas corretamente b) o resultado final corresponde à soma de todos os votos _válidos_.
-
-Assim, mesmo sem compartilhar a divisão dos votos por usuário (como costuma acontecer), a MACI garante a integridade dos resultados durante o processo de contagem. Esse recurso serve para reduzir a eficácia de esquemas básicos de conluio. Podemos explorar essa possibilidade usando o exemplo anterior com o Bob subornando a Alice para votar em uma opção:
-
-- Alice se registra para votar enviando sua chave pública para um contrato inteligente.
-- Alice concorda em votar na `opção B` em troca de um suborno de Bob.
-- Alice vota na `opção B`.
-- Alice envia secretamente uma transação criptografada para alterar a chave pública associada à sua identidade.
-- Alice envia outra mensagem (encriptada) para o contrato inteligente votando na `opção A` usando a nova chave pública.
-- Alice mostra a Bob uma transação que mostra que ela votou a favor da `opção B` (que é inválida já que a chave pública não está mais associada à identidade de Alice no sistema).
-- Ao processar mensagens, o coordenador ignora o voto de Alice para a `opção B` e conta apenas o voto na `opção A`. Assim, a tentativa de Bob de fazer conluio com Alice e manipular o voto em cadeia falha.
-
-O uso da MACI _faz_ requer confiança no coordenador para não conspirar com subornos ou tentativas de suborno dos próprios eleitores. O coordenador pode descriptografar as mensagens do usuário (necessário para criar a prova), para que ele possa verificar com precisão como cada pessoa votou.
-
-Porém, nos casos em que o coordenador seja honesto, a MACI representa uma ferramenta poderosa para garantir a inviolabilidade da votação em cadeia. Isso explica sua popularidade entre as aplicações de financiamento quadrático (por exemplo, [clr.fund](https://clr.fund/#/about/maci)) que dependem fortemente da integridade das escolhas de voto de cada indivíduo.
-
-[Saiba mais sobre a MACI](https://privacy-scaling-explorations.github.io/maci/).
-
-## Como funcionam as provas de conhecimento zero? {#how-do-zero-knowledge-proofs-work}
-
-Uma prova de conhecimento zero permite que você prove a verdade de uma afirmação sem compartilhar o conteúdo da declaração ou revelar como você descobriu a verdade. Para tornar isso possível, os protocolos de conhecimento zero dependem de algoritmos que utilizam alguns dados como entrada e retornam "verdadeiro" ou "falso" como saída.
-
-Um protocolo de conhecimento zero deve satisfazer os seguintes critérios:
-
-1. **Completude**: Se a entrada for válida, o protocolo de conhecimento zero sempre retorna "verdadeiro". Portanto, se a declaração subjacente for verdadeira, e o provador verificar agir honestamente, a prova pode ser aceita.
-
-2. **Solidez**: se a entrada for inválida, é teoricamente impossível enganar o protocolo de conhecimento zero para retornar "verdadeiro". Portanto, um provador mentiroso não pode enganar um verificador honesto fazendo-o acreditar que uma declaração inválida é válida (exceto com uma pequena margem de probabilidade).
-
-3. **Conhecimento-zero**: O verificador não aprende nada sobre uma declaração para além de sua validade ou falsidade (eles têm "conhecimento zero" da declaração). Essa exigência também impede que o verificador obtenha a entrada original (o conteúdo da declaração) da prova.
-
-Na forma básica, uma prova de conhecimento zero é composta de três elementos: **testemunha**, **desafio**, e **resposta**.
-
-- **Testemunha**: Com uma prova de conhecimento zero, o provador quer provar o conhecimento de algumas informações ocultas. A informação secreta é a “testemunha” para a prova, e o presumido conhecimento do provador da testemunha estabelece um conjunto de questões que só podem ser respondidas por uma parte com conhecimento da informação. Assim, a prova inicia o processo de provação escolhendo aleatoriamente uma questão, calculando a resposta e enviando-a para o verificador.
-
-- **Desafio**: O verificador escolhe aleatoriamente outra questão do conjunto e pede ao provador para respondê-la.
-
-- **Resposta**: O provador aceita a pergunta, calcula a resposta e a retorna-a ao verificador. A resposta do provador permite que o verificador verifique se o primeiro tem realmente acesso à testemunha. Para garantir que o provador não esteja “chutando” e obtendo as respostas corretas por acaso, o verificador escolhe mais perguntas a fazer. Repetindo muitas vezes essa interação, a possibilidade de o provador falsificar o conhecimento da testemunha cai significativamente até que o verificador esteja satisfeito.
-
-O exemplo acima descreve a estrutura de uma "prova de conhecimento zero interativa". Os protocolos de conhecimento zero usaram a prova interativa, na qual a verificação da validade de uma declaração exigia retroceder e avançar na comunicação entre os provadores e os verificadores.
-
-Um bom exemplo que ilustra como as provas interativas funcionam é a famosa história da [caverna do Ali Baba](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave) de Jean-Jacques Quisquater. Na história, Peggy (o provador) quer provar a Victor (o verificador) que ela sabe a frase secreta para abrir uma porta mágica, sem revelar a frase.
-
-### Provas não interativas de conhecimento zero {#non-interactive-zero-knowledge-proofs}
-
-Embora revolucionária, a prova interativa tinha uma utilidade limitada, uma vez que exigia que as duas partes estivessem disponíveis e interagissem repetidamente. Mesmo que um verificador estivesse convencido da honestidade de um provador, a prova não estaria disponível para verificação independente (calcular uma nova prova exigia um novo conjunto de mensagens entre o provador e o verificador).
-
-Para resolver esse problema, Manuel Blum, Paul Feldman e Silvio Micali sugeriram as primeiras [provas de conhecimento zero não interativas](https://dl.acm.org/doi/10.1145/62212.62222), nas quais o provador e o verificador têm uma chave compartilhada. Isso permite que o provador demonstre seu conhecimento de algumas informações (ou seja, testemunha) sem fornecer a informação em si.
-
-Ao contrário de provas interativas, as provas não interativas exigiam apenas uma rodada de comunicação entre os participantes (revisor e verificador). O provador passa as informações secretas para um algoritmo especial para calcular uma prova de conhecimento zero. Essa prova é enviada para o verificador, que verifica se o provador conhece as informações secretas usando outro algoritmo.
-
-Provas não interativas reduzem a comunicação entre provador e verificador, tornando a prova de ZK mais eficiente. Além disso, uma vez que uma prova é gerada, ela fica disponível para qualquer pessoa (com acesso à chave compartilhada e ao algoritmo de verificação) verificar.
-
-As provas não interativas representaram um progresso enorme para a tecnologia do conhecimento zero e estimularam o desenvolvimento de sistemas provas usados atualmente. Discutimos esses tipos de provas abaixo:
-
-### Tipos de provas de conhecimento zero {#types-of-zero-knowledge-proofs}
-
-#### ZK-SNARKs {#zk-snarks}
-
-ZK-SNARK é uma sigla para **Zero-Knowledge Succinct Non-Interative Argument of Knowledge** (Argumento de conhecimento sucinto não interativo de conhecimento zero). O protocolo ZK-SNARK tem as seguintes qualidades:
-
-- **Conhecimento-zero**: Um verificador pode validar a integridade de uma afirmação sem saber mais sobre essa afirmação. O único conhecimento que o verificador tem da afirmação é se ela é verdadeira ou falsa.
-
-- **Sucinto**: A prova de conhecimento zero é menor do que a testemunha e pode ser verificada rapidamente.
-
-- **Não interativo**: A prova é "não-interativa" porque o provador e verificador só interagem uma vez, ao contrário das provas interativas que exigem várias rodadas de comunicação.
-
-- **Argumento**: A prova satisfaz o requisito de "solidez", então trapaça é extremamente improvável.
-
-- **(Des) Conhecimento**: A prova de conhecimento zero não pode ser construída sem acesso às informações secretas (testemunha). É difícil, se não impossível, para um provador que não tem a testemunha calcular uma prova válida de conhecimento zero.
-
-A "chave compartilhada" mencionada anteriormente refere-se a parâmetros públicos que o provador e o verificador concordam em usar na geração e verificação de provas. Gerar os parâmetros públicos (coletivamente conhecidos como String de Referência Comum (CRS)) é uma operação sensível devido à sua importância na segurança do protocolo. Se a entropia (aleatoriedade) usada para gerar o CRS chegar nas mãos de um provador desonesto, eles poderão produzir provas falsas.
-
-[Computação multipartidária (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) é uma forma de reduzir os riscos na geração de parâmetros públicos. Várias partes participam de uma [cerimônia de configuração confiável](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), na qual cada pessoa contribui com alguns valores aleatórios para gerar o CRS. Enquanto uma parte honesta destrói sua porção da entropia, o protocolo ZK-SNARK mantém a solidez computacional.
-
-As configurações confiáveis exigem que os usuários confiem nos participantes na geração de parâmetros. No entanto, o desenvolvimento do ZK STARKs possibilitou protocolos de prova que funcionam com uma configuração não confiável.
-
-#### ZK-STARKs {#zk-starks}
-
-ZK-STARK é um acrônimo para **Zero-Knowledge Scalable Transparent Argument of Knowledge (Argumento de conhecimento transparente escalável de conhecimento zero)**. Os ZK-STARKs são semelhantes aos ZK-SNARKs, exceto que eles são:
-
-- **Escalável**: ZK-STARK é mais rápido que ZK-SNARK ao gerar e verificar provas quando o tamanho da testemunha é maior. Com as provas STARK, os tempos de prova e verificação só aumentam ligeiramente à medida que a testemunha cresce (os tempos do provador e verificador SNARK aumentam linearmente com o tamanho das testemunhas).
-
-- **Transparente**: ZK-STARK depende de uma aleatoriedade publicamente verificável para gerar parâmetros públicos para prova e verificação em vez de uma configuração confiável. Assim, eles são mais transparentes em comparação com os ZK-SNARKs.
-
-Os ZK-STARKs produzem provas maiores do que os ZK-SNARKs, o que significa que eles geralmente têm sobrecargas de verificação maiores. No entanto, existem casos (como provar grandes conjuntos de dados) em que os ZK-STARKs podem ser mais rentáveis do que os ZK-SNARKs.
-
-## Desvantagens do uso das provas de conhecimento zero {#drawbacks-of-using-zero-knowledge-proofs}
-
-### Custos de hardware {#hardware-costs}
-
-Gerar provas de conhecimento zero envolve cálculos muito complexos que funcionam melhor em computadores especializados. Como esses computadores são caros, eles estão muitas vezes fora do alcance de indivíduos normais. Além disso, os aplicativos que querem usar tecnologia de conhecimento zero devem considerar os custos de hardware, o que pode aumentar os custos para os usuários finais.
-
-### Custos da prova de verificação {#proof-verification-costs}
-
-A verificação de provas também requer um cálculo complexo e aumenta os custos de implementação da tecnologia de conhecimento zero nos aplicativos. Esse custo é particularmente relevante no contexto de comprovação da computação. Por exemplo, os roll-ups ZK pagam cerca de 500.000 de gás para verificar uma única prova de ZK-SNARK no Ethereum, sendo que os ZK-STARKs precisam de taxas ainda maiores.
-
-### Suposições de confiança {#trust-assumptions}
-
-No ZK-SNARK, a String de Referência Comum (parâmetros públicos) é gerada uma vez e disponível para ser reutilizada pelas partes que desejam participar do protocolo de conhecimento zero. Parâmetros públicos são criados por meio de uma cerimônia de configuração confiável, na qual se presume que os participantes são honestos.
-
-Mas realmente não há nenhuma maneira de os usuários avaliarem a honestidade dos participantes, e os usuários devem acreditar nos desenvolvedores. Os ZK-STARKs são livres de suposições de confiança, já que a aleatoriedade usada na geração da sequência é publicamente verificável. Enquanto isso, pesquisadores estão trabalhando em configurações não confiáveis para que ZK-SNARKs aumentem a segurança dos mecanismos de prova.
-
-### Ameaças da computação quântica {#quantum-computing-threats}
-
-O ZK-SNARK usa criptografia de curva elíptica para criptografia. Por enquanto, o problema do logaritmo discreto da curva elíptica é considerado sem solução, mas o desenvolvimento de computadores quânticos pode quebrar esse modelo de segurança no futuro.
-
-O ZK-STARK é considerado imune à ameaça da computação quântica, pois depende apenas de funções hash resistentes a colisões para sua segurança. Ao contrário dos pares de chaves público-privadas usados na criptografia de curva elíptica, o hashing resistente a colisões é mais difícil para os algoritmos de computação quânticos quebrarem.
-
-## Leitura adicional {#further-reading}
-
-- [Visão geral dos casos de uso para provas de conhecimento zero](https://pse.dev/projects) — _Equipe de exploração de privacidade e dimensionamento_
-- [SNARKs vs. STARKS vs. SNARKs recursivos](https://www.alchemy.com/overviews/snarks-vs-starks) — _Visão geral do Alchemy_
-- [Uma prova de conhecimento zero: melhorando a privacidade em uma blockchain](https://www.altoros.com/blog/zero-knowledge-proof-improving-privacy-for-a-blockchain/) — _Dmitry Lavrenov_
-- [zk-SNARKs — Um exemplo realista de conhecimento zero e aprofundamento](https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c) — _Adam Luciano_
-- [ZK-STARKs — Crie confiança verificável, mesmo contra computadores quânticos](https://medium.com/coinmonks/zk-starks-create-verifiable-trust-even-against-quantum-computers-dd9c6a2bb13d) — _Adão Luciano_
-- [Uma introdução aproximada de como os zk-SNARKs são possíveis](https://vitalik.eth.limo/general/2021/01/26/snarks.html) — _Vitalik Buterin_
-- [Por que as provas de conhecimento zero (ZKPs, em inglês) são um divisor de águas para a identidade autônoma](https://frankiefab.hashnode.dev/why-zero-knowledge-proofs-zkps-is-a-game-changer-for-self-sovereign-identity) - _Franklin Ohaegbulam_
-
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md
deleted file mode 100644
index 9a720c76836..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Como "criar" uma conta Ethereum
-description: Um guia passo a passo sobre como criar uma conta Ethereum usando uma carteira.
-lang: pt-br
----
-
-# Como criar uma conta Ethereum
-
-**Qualquer pessoa pode criar uma conta na Ethereum de graça.** Você só precisa instalar um aplicativo de carteira de criptomoedas. As carteiras criam e gerenciam sua conta Ethereum. Eles podem enviar transações, verificar seus saldos e conectá-lo a outros aplicativos desenvolvidos no Ethereum.
-
-Com uma carteira, você também pode fazer login em qualquer câmbio de tokens, jogos e mercados [NFT](/glossary/#nft) instantaneamente. Não há necessidade de inscrição individual, uma conta é compartilhada por todos os aplicativos construídos na Ethereum.
-
-## Etapa 1: Escolha uma carteira
-
-Uma carteira é um aplicativo que ajuda você controlar a sua conta Ethereum. Existem dezenas de carteiras diferentes para escolher: extensões para celular, desktop ou até mesmo para navegador.
-
-
-
- Lista de carteiras
-
-
-Se for iniciante, poderá selecionar o filtro "New to crypto" (Novo em cripto) na página "find a wallet" (encontrar uma carteira) para identificar carteiras que incluam todos os recursos necessários e adequados para iniciantes.
-
-
-
-Também existem outros filtros de perfil para atender às suas necessidades. Esses são exemplos de carteiras utilizadas normalmente. Você deve fazer a sua própria pesquisa antes de confiar em qualquer software.
-
-## Etapa 2: Baixar e instalar o aplicativo da carteira
-
-Após escolher sua carteira, visite o site oficial ou a loja de aplicativos, baixe e instale-a. Todas elas são gratuitas.
-
-## Etapa 3: Abra o aplicativo e crie sua conta Ethereum
-
-Ao abrir uma nova carteira pela primeira vez, será necessário escolher entre criar uma nova conta ou importar uma já existente. Clique em criação de nova conta. **Esta é a etapa durante a qual o software da carteira gera sua conta Ethereum.**
-
-## Etapa 4: Salvar a frase de recuperação
-
-Alguns aplicativos vão te pedir para salvar uma "chave de recuperação" secreta (algumas vezes chamada de "frase semente" ou de "mnemônico"). Manter essa frase a salvo é extremamente importante! Ela é usada para gerar sua conta Ethereum e pode ser usada para fazer transações.
-
-**Qualquer pessoa que conheça essa frase pode tomar o controle de todos os seus fundos.** Nunca compartilhe ela com ninguém. Essa frase deve conter entre 12 e 24 palavras geradas aleatoriamente (a ordem das palavras importa).
-
-
-
-
Carteira instalada? Aprenda como usá-la.
-
- Como usar uma carteira
-
-
-
-
-Tem interesse em outros guias? Verifique os nossos: [Guias passo a passo](/guides/)
-
-## Perguntas frequentes
-
-### Uma carteira e uma conta Ethereum são o mesmo?
-
-Não. A carteira é uma ferramenta de gerenciamento que ajuda você a gerenciar contas. Uma única carteira pode acessar várias contas, e uma única conta pode ser acessada por várias carteiras. A frase de recuperação é usada para criar contas e dá permissão ao aplicativo de carteira para gerenciar ativos.
-
-### Posso enviar bitcoins para uma conta/endereço Ethereum ou enviar ethers para uma conta/endereço Bitcoin?
-
-Não, não é possível. O Bitcoin e o ether existem em duas redes separadas (ou seja, blockchains diferentes), cada uma com seus próprios formatos de contabilidade e endereço. Houve várias tentativas de unir as duas redes diferentes, das quais a mais ativa atualmente é a [Wrapped Bitcoin ou WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Isso não é uma recomendação, pois o WBTC é uma solução de custódia (ou seja, um único grupo de pessoas controla determinadas funções críticas) e é fornecido aqui apenas a título informativo.
-
-### Se eu tenho um endereço de ETH, o endereço é o mesmo para outras blockchains?
-
-Você pode usar o mesmo [endereço](/glossary/#address) em todos os blockchains que usam software subjacente semelhante ao Ethereum (conhecido como "compatível com EVM"). Esta [lista](https://chainlist.org/) mostra quais blockchains você pode usar com o mesmo endereço. Algumas blockchains, como o Bitcoin, implementam um conjunto completamente separado de regras de rede e você precisará de um endereço diferente com um formato diferente. Se você tem uma carteira de contrato inteligente então deve verificar o Website do produto para mais informações sobre quais blockchains são permitidas porque geralmente elas têm uma abrangência limitada, mas mais segura.
-
-### Ter a minha própria carteira é mais seguro do que manter os meus fundos em uma corretora?
-
-Ter a sua própria carteira significa que você assume a responsabilidade pela segurança dos seus ativos. Infelizmente, há muitos exemplos de corretoras que cometeram erros e perderam o dinheiro dos clientes. Possuir uma carteira (com uma frase de recuperação) elimina o risco associado à confiança em alguma entidade para manter seus ativos. No entanto, você precisa protegê-lo por conta própria e evitar golpes de phishing, aprovação acidental de transações ou exposição da frase de recuperação, interação com sites falsos e outros riscos de autocustódia. Os riscos e benefícios são diferentes.
-
-### Se eu perder minha carteira de celular/hardware, eu preciso usar o mesmo aplicativo de carteira novamente para recuperar os fundos perdidos?
-
-Não, você pode utilizar outra carteira. Desde que você tenha a frase semente, poderá inseri-la na maioria das carteiras e a sua conta será restaurada. Tenha cuidado se precisar fazer isso: é melhor certificar-se de que você não está conectado à Internet ao recuperar a sua carteira para não vazar a sua frase semente acidentalmente. Muitas vezes, é impossível recuperar fundos perdidos sem a frase de recuperação.
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md
deleted file mode 100644
index 7aacaca8806..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: Como identificar tokens fraudulentos
-description: Compreender tokens fraudulentos, como se fazem passar por legítimos e como evitá-los.
-lang: pt-br
----
-
-# Como identificar tokens fraudulentos {#identify-scam-tokens}
-
-Um dos usos mais comuns do Ethereum é a criação por um grupo de pessoas de um token negociável que, de certa forma, criam sua própria moeda. Esses tokens normalmente seguem um padrão, [ERC-20](/developers/docs/standards/tokens/erc-20/). Entretanto, sempre onde há casos de uso legítimos que agregam valor, também haverá criminosos que tentam roubar esse valor.
-
-É possível enganar você de duas formas:
-
-- **Por meio da venda de um token fraudulento**, que pode se parecer com o token legítimo que você quer comprar, mas que é emitido por golpistas e não vale nada.
-- **Enganar você para assinar transações inadequadas**, geralmente direcionando você para a interface de usuário da fraude. Eles podem tentar convencer você a permitir que os contratos deles acessem os tokens ERC-20, o que poderá expor informações confidenciais com as quais eles terão acesso aos seus ativos etc. Essas interfaces de usuário podem ser clones quase perfeitos de sites honestos, mas com truques ocultos.
-
-Para ilustrar o que são tokens fraudulentos e como identificá-los, veremos um exemplo: [`wARB`](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82). Esse token tenta se parecer com o token [`ARB`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) legítimo.
-
-
-
-Arbitrum é uma organização que desenvolve e gerencia rollups otimistas. Inicialmente, a Arbitrum foi organizada como uma empresa com fins lucrativos, mas depois tomou medidas para se descentralizar. Como parte desse processo, a empresa emitiu um token de governança negociável.
-
-
-
-
-
-Há uma convenção no Ethereum de que, quando um ativo não está em conformidade com o ERC-20, criamos uma versão "enrolada" dele, com o nome começando com "w". Por exemplo, temos wBTC para bitcoin e wETH para ether.
-
-Não faz sentido criar uma versão enrolada de um token ERC-20 que já está no Ethereum, mas os golpistas confiam na aparência de legitimidade em vez da realidade subjacente.
-
-
-
-## Como funcionam os tokens fraudulentos? {#how-do-scam-tokens-work}
-
-O ponto principal do Ethereum é a descentralização. Isso significa que não há uma autoridade central que possa confiscar os seus ativos ou impedir você de implantar um contrato inteligente. Mas isso também significa que os golpistas podem implementar qualquer contrato inteligente.
-
-
-
-Os contratos inteligentes são programas que são executados no blockchain Ethereum. Cada token ERC-20, por exemplo, é implementado como um contrato inteligente.
-
-
-
-Especificamente, a Arbitrum implantou um contrato que utiliza o símbolo `ARB`. Mas isso não impede que outras pessoas também implantem um contrato que use exatamente o mesmo símbolo, ou um semelhante. Quem elabora o contrato pode definir o que o contrato fará.
-
-## Aparência de legitimidade {#appearing-legitimate}
-
-Os criadores de tokens fraudulentos têm diversos truques para fazer com que os tokens passem por legítimos.
-
-- **Nome e símbolo legítimos**. Conforme mencionado anteriormente, os contratos ERC-20 podem ter o mesmo símbolo e nome que outros contratos ERC-20. Você não pode confiar na segurança desses campos.
-
-- **Proprietários legítimos**. Os tokens fraudulentos geralmente lançam saldos significativos em endereços que deveriam ser titulares legítimos do token real.
-
- Por exemplo, vamos ver o `wARB` novamente. [Cerca de 16% dos tokens](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82?a=0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f) são mantidos por um endereço cuja tag pública é [Arbitrum Foundation: Deployer](https://etherscan.io/address/0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f). Isso _não_ é um endereço falso, na verdade é o endereço que [implantou o contrato ARB real na rede principal do Ethereum](https://etherscan.io/tx/0x242b50ab4fe9896cb0439cfe6e2321d23feede7eeceb31aa2dbb46fc06ed2670).
-
- Como o saldo ERC-20 de um endereço faz parte do armazenamento do contrato ERC-20, ele pode ser especificado pelo contrato como sendo o que o desenvolvedor do contrato desejar. Também é possível um contrato proibir transferências, fazendo com que os usuários legítimos não consigam eliminar esses tokens fraudulentos.
-
-- **Transferências legítimas**. _Os proprietários legítimos não pagarão terceiros para transferir um token fraudulento. Portanto, se há transferências, elas devem ser legítimas, certo?_ **Errado**. Eventos de `transferência` são produzidos pelo contrato ERC-20. Um golpista pode facilmente elaborar o contrato de forma que ele produza essas ações.
-
-## Sites fraudulentos {#websites}
-
-Os golpistas também podem criar sites muito convincentes, às vezes até clones exatos de sites autênticos, com interfaces de usuário idênticas, mas com truques sutis. Os exemplos podem incluir links externos que parecem legítimos e que, na verdade, enviam o usuário para um site externo fraudulento, ou instruções incorretas que orientam o usuário a expor as chaves ou enviar fundos para o endereço de um invasor.
-
-A melhor prática para evitar isso é verificar cuidadosamente o URL dos sites que você visita e salvar os endereços de sites autênticos conhecidos nos seus favoritos. Assim, você pode acessar o site real por meio dos seus favoritos, sem cometer erros de ortografia acidentalmente ou depender de links externos.
-
-## Como você pode se proteger? {#protect-yourself}
-
-1. **Verificação do endereço do contrato**. Os tokens legítimos derivam de organizações legítimas, e você pode ver os endereços do contrato no site da organização. Por exemplo, [do `ARB`, os endereços legítimos estão disponíveis aqui](https://docs.arbitrum.foundation/deployment-addresses#token).
-
-2. **Os tokens reais têm liquidez**. Outra opção é observar o tamanho do pool de liquidez no [Uniswap](https://uniswap.org/), um dos protocolos de troca de tokens mais comuns. Esse protocolo funciona usando pools de liquidez, nos quais os investidores depositam os tokens na esperança de obter um retorno das taxas de negociação.
-
-Os tokens fraudulentos normalmente têm pools de liquidez minúsculos, quando têm, porque os golpistas não querem arriscar ativos reais. Por exemplo, o pool `ARB`/`ETH` do Uniswap detém aproximadamente um milhão de dólares ([consulte o valor atualizado aqui](https://info.uniswap.org/#/pools/0x755e5a186f0469583bd2e80d1216e02ab88ec6ca)) e comprar ou vender uma pequena quantidade não mudará o preço:
-
-
-
-Mas quando você tenta comprar o token fraudulento `wARB`, mesmo uma compra minúscila alterará o preço em mais de 90%:
-
-
-
-Essa é outra evidência que nos mostra que esse `wARB` provavelmente não é um token legítimo.
-
-3. **Confira no Etherscan**. Muitos tokens fraudulentos já foram identificados e denunciados pela comunidade. Esses tokens estão [marcados no Etherscan](https://info.etherscan.com/etherscan-token-reputation/). Embora o Etherscan não seja uma fonte de verdade autorizada (é da natureza das redes descentralizadas não poder haver uma fonte de legitimidade autorizada), os tokens identificados pelo Etherscan como fraudes provavelmente serão fraudes.
-
- 
-
-## Conclusão {#conclusion}
-
-Enquanto houver valor no mundo, haverá golpistas que tentarão roubá-lo e, em um mundo descentralizado, não há ninguém para protegê-lo além de você. Esperamos que você se lembre desses pontos para ajudar a distinguir os tokens legítimos dos fraudulentos:
-
-- Os tokens fraudulentos se fazem passar por tokens legítimos, podendo usar o mesmo nome, símbolo etc.
-- Os tokens fraudulentos _não podem_ utilizar o mesmo endereço de contrato.
-- A melhor fonte do endereço do token legítimo é a organização proprietária do token.
-- Caso contrário, você pode usar aplicativos populares e confiáveis, como [Uniswap](https://app.uniswap.org/#/swap) e [Etherscan](https://etherscan.io/).
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md
deleted file mode 100644
index 1af9935d1c5..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Como revogar o acesso ao contrato inteligente aos seus fundos cripto
-description: Um guia sobre como revogar o acesso explorativo ao token de contrato inteligente
-lang: pt-br
----
-
-# Como revogar o acesso ao contrato inteligente aos seus fundos cripto
-
-Este guia ensinará como visualizar uma lista de todos os [contratos inteligentes](/glossary/#smart-contract) aos quais você permitiu acesso aos seus fundos e como cancelá-los.
-
-Às vezes, desenvolvedores maliciosos constroem backdoors em contratos inteligentes que permitem acesso aos fundos de usuários desinformados que interagem com contratos inteligentes. O que acontece com frequência é que essas plataformas pedem permissão ao usuário para gastar um **número ilimitado de tokens** na tentativa de economizar pequenas quantidades de [gás](/glossary/#gas) no futuro, mas isso acarreta um risco maior.
-
-Quando uma plataforma tiver direitos de acesso ilimitados a um token em sua [carteira](/glossary/#wallet), ela poderá gastar todos esses tokens mesmo que você tenha retirado os fundos da plataforma dela para sua carteira. Atores maliciosos ainda podem acessar seus fundos e retirá-los para suas carteiras sem uma opção de recuperação para você.
-
-As únicas proteções são deixar de usar novos projetos não testados, aprovar apenas o que você precisa, ou revogar o acesso regularmente. Então, como fazer isso?
-
-## Passo 1: Usar ferramentas de revogação de acesso
-
-Vários sites permitem que você veja e revogue os contratos inteligentes conectados ao seu endereço. Visite o site e conecte sua carteira:
-
-- [Ethallowance](https://ethallowance.com/) (Ethereum)
-- [Etherscan](https://etherscan.io/tokenapprovalchecker) (Ethereum)
-- [Cointool](https://cointool.app/approve/eth) (múltiplas redes)
-- [Revoke](https://revoke.cash/) (múltiplas redes)
-- [Unrekt](https://app.unrekt.net/) (múltiplas redes)
-- [EverRevoke](https://everrise.com/everrevoke/) (múltiplas redes)
-
-## Passo 2: Conecte sua carteira
-
-Assim que estiver no site, clique em “Conectar carteira”. O site deverá solicitar que você conecte sua carteira.
-
-Certifique-se de usar a mesma rede em sua carteira e site. Você verá apenas os contratos inteligentes relacionados à rede selecionada. Por exemplo, se você se conectar à Ethereum Mainnet (Rede principal do Ethereum), você verá apenas contratos do Ethereum, não contratos de outras redes, como a Polygon.
-
-## Passo 3: Selecione um contrato inteligente que deseja revogar
-
-Você deve ver todos os contratos aos quais é permitido acesso a seus tokens e seus limites de gastos. Encontre aquele que você deseja encerrar.
-
-Se você não sabe qual contrato escolher, você pode revogar todos eles. Isso não criará nenhum problema para você, mas terá que conceder um novo conjunto de permissões na próxima vez que interagir com qualquer um desses contratos.
-
-## Passo 4: Revogar o acesso aos seus fundos
-
-Ao clicar em revogar, você verá uma nova sugestão de transação na sua carteira. Isso é o que se espera que aconteça. Você terá que pagar a tarifa para o cancelamento ser bem-sucedido. Dependendo da rede, isso pode levar de um a vários minuto para ser processado.
-
-Aconselhamos que você atualize a ferramenta de revogação após alguns minutos e conecte sua carteira novamente para ter certeza de que o contrato revogado desapareceu da lista.
-
-Recomendamos que você nunca permita que seus projetos tenham acesso ilimitado aos seus tokens e revogue toda permissão de acesso aos seus tokens regularmente. Revogar o acesso ao token nunca deve resultar na perda de fundos, especialmente se você usar as ferramentas listadas acima.
-
-
-
-
-
Quer saber mais?
-
- Veja nossos outros guias
-
-
-
-## Perguntas frequentes
-
-### A revogação do acesso ao token também encerrará staking, pooling, empréstimo, etc?
-
-Não, isso não afetará nenhuma de suas estratégias [DeFi](/glossary/#defi). Você permanecerá em suas posições e continuará recebendo recompensas, etc.
-
-### Desconectar uma carteira de um projeto é o mesmo que remover a permissão para usar meus fundos?
-
-Não, se você desconectar sua carteira do projeto, mas tiver concedido permissões de acesso aos tokens, eles ainda podem usar esses tokens. Você precisa revogar esse acesso.
-
-### Quando a permissão do contrato expirará?
-
-Não há datas de validade nas permissões do contrato. Se você conceder permissões contratuais, elas podem ser usadas, mesmo anos após serem concedidas.
-
-### Por que os projetos definem a permissão de token ilimitada?
-
-Projetos muitas vezes fazem isso para minimizar o número de solicitações necessárias, ou seja, o usuário só tem que aprovar uma vez e pagar a taxa de transação apenas uma vez. Embora conveniente, isso pode ser perigoso para os usuários aprovarem descuidadamente, em sites que não são comprovados com o tempo ou auditados. Algumas carteiras permitem que você restrinja manualmente a quantidade de tokens a serem aprovados para limitar o seu risco. Contate seu provedor de carteira para obter mais informações.
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md
deleted file mode 100644
index 515269f077f..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Como trocar tokens
-description: Um guia sobre como fazer swap de tokens no Ethereum.
-lang: pt-br
----
-
-# Como trocar tokens
-
-Está cansado de procurar por uma corretora que lista todos os seus tokens favoritos? Você pode trocar a maior parte dos tokens usando [corretoras descentralizadas](/glossary/#dex).
-
-Uma troca de tokens envolve a troca de dois ativos diferentes que existem na rede Ethereum, por exemplo, trocando ETH por DAI (um token [ERC-20](/glossary/#erc-20)). O processo é muito rápido e barato. Você precisará ter uma carteira de criptomoedas para trocar tokens.
-
-**Pré-requisitos:**
-
-- tiver uma [carteira de criptografia](/glossary/#wallet), você pode seguir este tutorial: [Como: "Registrar" uma conta Ethereum](/guides/how-to-create-an-ethereum-account/)
-- adicionar fundos à sua carteira
-
-## 1. Conecte sua carteira à corretora descentralizada (DEX) de sua escolha
-
-Algumas corretoras populares são:
-
-- [Uniswap](https://app.uniswap.org/#/swap)
-- [Sushiswap](https://www.sushi.com/swap)
-- [1Inch](https://app.1inch.io/#/1/unified/swap/ETH/DAI)
-- [Curve](https://curve.fi/#/ethereum/swap)
-
-Interessante? Saiba mais sobre o que é [finanças descentralizadas (DeFi)](/defi/) e como funcionam esses novos tipos de trocas.
-
-## 2. Selecione o par de tokens que deseja trocar
-
-Por exemplo, ETH e DAI. Certifique-se de ter fundos em um dos dois tokens. 
-
-## 3. Digite a quantidade de tokens que você deseja trocar e clique em swap
-
-A corretora calculará automaticamente quantos tokens você terá.
-
-
-
-## 4. Confirme a transação
-
-Revise os detalhes da transação. Confira a taxa da corretora e quaisquer outras taxas para evitar surpresas ruins.
-
-
-
-## 5. Espere a transação ser processada
-
-Você pode ver o progresso da transação em qualquer explorador de blockchain. Esse processo não deve demorar mais do que 10 minutos.
-
-Você receberá automaticamente os tokens trocados em sua carteira assim que a transação for processada.
-
-
-
-
Quer saber mais?
-
- Veja nossos outros guias
-
-
-
-## Perguntas frequentes
-
-### Posso trocar ETH por BTC na minha carteira?
-
-Não, você pode apenas trocar tokens que são nativos da rede Ethereum, como ETH, tokens ERC-20 ou NFTs. Você só pode trocar formas “wrapped” de Bitcoin que vivem no Ethereum.
-
-### O que é derrapagem?
-
-É a diferença entre a taxa de troca esperada e a taxa real.
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md
deleted file mode 100644
index a5bf839b679..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: Como fazer transferir tokens para a camada 2
-description: Um guia explicando como mover tokens do Ethereum para a camada 2 usando uma ponte.
-lang: pt-br
----
-
-# Como fazer transferir tokens para a camada 2
-
-Se houver muito tráfego no Ethereum, isso pode ficar caro. Uma solução para isto é criar novas “camadas”: ou seja, diferentes redes que operam de forma similar ao próprio Ethereum. Estas chamadas de Camada 2s ajudam a reduzir o congestionamento e o custo no Ethereum, processando muito mais transações com taxas mais baixas e armazenando apenas o resultado delas no Ethereum de vez em quando. Como tal, essas camadas 2s nos permitem fazer transações com maior velocidade e custos reduzidos. Muitos projetos populares de criptomoedas estão se movendo para as camadas 2 devido a esses benefícios. A maneira mais simples de mover tokens do Ethereum para a camada 2 é usar uma ponte.
-
-**Pré-Requisitos:**
-
-- ter uma carteira de criptomoedas. Você pode seguir este tutorial: [Como “registrar” uma conta Ethereum](/guides/how-to-create-an-ethereum-account/)
-- adicione fundos à sua carteira
-
-## 1. Determinar qual rede de camada 2 você deseja usar
-
-Você pode aprender mais sobre os diferentes projetos e links importantes em nossa [página de camada 2](/layer-2/).
-
-## 2. Ir para a ponte selecionada
-
-Algumas camadas 2 populares são:
-
-- [Arbitrum bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
-- [Optimism bridge](https://app.optimism.io/bridge/deposit)
-- [Boba network bridge](https://gateway.boba.network/)
-
-## 3. Conecte-se à ponte com sua carteira
-
-Certifique-se de que a sua carteira está conectada à rede principal Ethereum. Se não estiver, o site avisará você automaticamente para trocar de rede.
-
-
-
-## 4. Especifique o montante e mova os fundos
-
-Revise o valor que você obterá em troca na rede da camada 2 e as taxas para evitar surpresas desagradáveis.
-
-
-
-## 5. Confirme a transação na sua carteira
-
-Você terá que pagar uma taxa sob a forma de ETH para processar a transação.
-
-
-
-## 6. Aguarde a transferência dos seus fundos
-
-Esse processo não deve demorar mais do que 10 minutos.
-
-## 7. Adicione a rede selecionada da camada 2 à sua carteira (opcional)
-
-Você pode usar [chainlist.org](http://chainlist.org) para encontrar os detalhes do RPC da rede. Quando a rede for adicionada e a transação terminada, você deverá ver os tokens na sua carteira.
-
-
-
-
Quer saber mais?
-
- Veja nossos outros guias
-
-
-
-## Perguntas frequentes
-
-### E se eu tiver fundos em uma empresa de câmbio?
-
-Você poderá retirar para alguma camada 2 diretamente de uma empresa de câmbio. Confira a seção “Mover para a camada 2” de nossa [Página da camada 2](/layer-2/) para obter mais informações.
-
-### Posso voltar à mainnet da Ethereum depois que eu vincular meus tokens à L2?
-
-Sim, você sempre pode mover seus fundos de volta para a mainnet usando o mesmo vínculo.
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md
deleted file mode 100644
index 53de7298c02..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Como usar uma carteira
-description: Uma guia explicando como enviar, receber tokens e conectar-se aos projetos da web3.
-lang: pt-br
----
-
-# Como usar uma carteira
-
-Aprenda como operar todas as funções básicas de uma carteira. Se você ainda não tem uma conta, confira o nosso guia [ Como criar uma conta Ethereum](/guides/how-to-create-an-ethereum-account/).
-
-## Abra sua conta
-
-Você verá um painel que provavelmente mostrará seu saldo e os botões para enviar e receber tokens.
-
-## Receber criptomoedas
-
-Você quer receber criptomoedas na sua carteira?
-
-Cada conta do Ethereum possui seu próprio endereço de recebimento, que é uma sequência única de números e letras. O endereço funciona como um número de conta bancária ou chave pix. Os endereços Ethereum sempre começarão com “0x”. Você pode compartilhar esse endereço com qualquer pessoa: é seguro fazê-lo.
-
-O seu endereço é como o endereço da sua casa: você precisa dizer às pessoas para que elas possam encontrar você. É seguro fazer isso, porque você ainda pode trancar a porta da frente com outra chave que só você controla para que ninguém possa entrar, mesmo que saibam onde você mora.
-
-Você precisa fornecer seu endereço público a quem desejar enviar dinheiro a você. Muitos aplicativos de carteira permitem que você copie seu endereço ou mostre um código QR para facilitar o uso. Evite digitar qualquer endereço Ethereum manualmente. Isso pode facilmente levar a erros administrativos e perda de fundos.
-
-Aplicativos diferentes podem variar ou usar linguagens diferentes, mas devem conduzir você por um processo semelhante se estiver tentando transferir fundos.
-
-1. Abra o aplicativo da sua carteira.
-2. Clique em “Receber” (ou na opção com palavras semelhantes).
-3. Copie o seu endereço Ethereum para a área de transferência.
-4. Forneça ao remetente o seu endereço Ethereum.
-
-## Enviar criptomoeda
-
-Deseja enviar ETH para outra carteira?
-
-1. Abra o aplicativo da sua carteira.
-2. Obtenha o endereço de recebimento e verifique se está conectado à mesma rede do destinatário.
-3. Insira o endereço de recebimento ou digitalize um código QR com a sua câmera para que você não precise escrever o endereço manualmente.
-4. Clique no botão “Enviar” em sua carteira (ou uma alternativa com palavras semelhantes).
-
-
-
-
-5. Muitos ativos, como DAI e USDC, existem em várias redes. Ao transferir tokens de criptomoedas, certifique-se de que o destinatário está usando a mesma rede que você, já que isso não pode ser alterado.
-6. Certifique-se de que sua carteira tenha ETH suficiente para cobrir a taxa de transação, que varia dependendo das condições da rede. A maioria das carteiras adicionará automaticamente a taxa sugerida para a transação. Em seguida, você pode confirmar.
-7. Uma vez que a transação é processada, o valor de cripto correspondente aparecerá na conta do destinatário. Isso pode demorar de alguns segundos a alguns minutos, dependendo do quanto a rede está sendo usada atualmente.
-
-## Conectando-se a projetos
-
-Seu endereço será o mesmo em todos os projetos do Ethereum. Você não precisa se registrar individualmente em nenhum projeto. Quando tiver uma carteira, você poderá se conectar a qualquer projeto na rede Ethereum sem quaisquer informações adicionais. Não são necessários e-mails ou outras informações pessoais.
-
-1. Visite o website do projeto.
-2. Se a página inicial do projeto for apenas uma descrição estática do projeto, você deve poder clicar em um botão “Abrir o App” no menu que irá navegar para o aplicativo web real.
-3. Quando estiver no aplicativo, clique em “Conectar”.
-
-
-
-4. Selecione sua carteira da lista de opções fornecidas. Se você não conseguir ver sua carteira, ela pode estar escondida na a opção “WalletConnect”.
-
-
-
-5. Confirme o pedido de assinatura na sua carteira para estabelecer a conexão. **A assinatura desta mensagem não dever exigir o gasto de nenhum ETH**.
-6. É isso! Comece a usar o app. Você pode encontrar alguns projetos interessantes em nossa [página de dApps](/dapps/#explore).
-
-
-
Quer saber mais?
-
- Veja nossos outros guias
-
-
-
-## Perguntas frequentes
-
-### Se eu tenho um endereço de ETH, o endereço é o mesmo para outras blockchains?
-
-Você pode utilizar o mesmo endereço em todos os blockchains compatíveis com EVM (se você tiver o tipo de carteira com uma frase de recuperação). Esta [lista](https://chainlist.org/) mostra quais blockchains você pode usar com o mesmo endereço. Algumas blockchains, como o Bitcoin, implementam um conjunto completamente separado de regras de rede e você precisará de um endereço diferente com um formato diferente. Se você tem uma carteira de contrato inteligente, você deve verificar o site do produto para mais informações sobre quais blockchains são suportadas.
-
-### Posso usar o mesmo endereço em vários dispositivos?
-
-Sim, você pode utilizar o mesmo endereço em diversos dispositivos. Tecnicamente, carteiras são apenas uma interface para mostrar o seu saldo e fazer transações — sua conta não está armazenada na carteira, mas na blockchain.
-
-### Eu não recebi a criptomoeda. Onde posso verificar o status da transação?
-
-Você pode usar [exploradores de blocos](/developers/docs/data-and-analytics/block-explorers/) para ver o status de qualquer transação em tempo real. Tudo o que você precisa fazer é pesquisar o endereço da sua carteira ou o ID da transação.
-
-### Posso cancelar ou retornar transações?
-
-Não, uma vez que uma transação é confirmada, você não pode cancelá-la.
diff --git a/public/content/translations/pt-br/10) Guides and Quizzes/guides/index.md b/public/content/translations/pt-br/10) Guides and Quizzes/guides/index.md
deleted file mode 100644
index 9dc981a64b2..00000000000
--- a/public/content/translations/pt-br/10) Guides and Quizzes/guides/index.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Guias sobre o Ethereum
-description: Uma coleção de guias práticos explicando os conceitos básicos de como usar o Ethereum para iniciantes.
-lang: pt-br
----
-
-# Guias Ethereum
-
-Quer iniciar a sua jornada no Ethereum? Os nossos guias práticos oferecem orientação passo a passo sobre como começar e facilitam a navegação nessa nova tecnologia.
-
-## Introdução
-
-1. [Como "criar" uma conta Ethereum](/guides/how-to-create-an-ethereum-account/) - Qualquer pessoa pode criar uma carteira, gratuitamente. Este guia mostrará por onde começar.
-
-2. [Como usar uma carteira](/guides/how-to-use-a-wallet/) — Uma introdução aos recursos básicos de qualquer carteira e como usá-los.
-
-## Noções básicas de segurança
-
-1. [Como revogar o acesso do contrato inteligente aos seus fundos cripto](/guides/how-to-revoke-token-access/) — Se encontrar uma transação na sua carteira que você não iniciou, este guia ensinará a evitar que isso ocorra novamente.
-
-2. [Como identificar tokens fraudulentos](/guides/how-to-id-scam-tokens/) - O que são tokens fraudulentos, como se fazem passar por legítimos e como identificá-los para se proteger e evitar ser enganado.
-
-## Como utilizar o Ethereum
-
-1. [Como levar os tokens para a camada 2](/guides/how-to-use-a-bridge/) — As transações Ethereum são muito caras? Considere mudar para soluções de escalabilidade Ethereum chamadas de camada 2.
-
-2. [Como trocar tokens](/guides/how-to-swap-tokens/) — Deseja trocar seus tokens por um diferente? Este guia simples mostrará como fazer isso.
diff --git a/public/content/translations/pt-br/11) Roadmap/eips/index.md b/public/content/translations/pt-br/11) Roadmap/eips/index.md
deleted file mode 100644
index 669ba2c0e13..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/eips/index.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Propostas de Melhorias do Ethereum (EIPs)
-description: As informações básicas de que você precisa para entender as EIPs
-lang: pt-br
----
-
-# Introdução às Propostas de Melhorias do Ethereum (EIPs) {#introduction-to-ethereum-improvement-proposals}
-
-## O que são EIPs? {#what-are-eips}
-
-[Propostas de Melhorias do Ethereum (EIPs)](https://eips.ethereum.org/) são padrões especificando novos potenciais recursos ou processos para o Ethereum. As EIPs contêm especificações técnicas para as mudanças propostas e agem como a "fonte da verdade" para a comunidade. Atualizações de rede e padrões de aplicativos para Ethereum são discutidos e desenvolvidos através do processo EIP.
-
-Qualquer um da comunidade Ethereum tem a capacidade de criar uma EIP. Diretrizes para escrever EIPs estão incluídas na [EIP 1](https://eips.ethereum.org/EIPS/eip-1). Uma EIP deve fornecer principalmente uma especificação técnica concisa com um pouco de motivação. O autor da EIP é responsável por obter consenso dentro da comunidade e documentar opiniões alternativas. Dada a alta barreira técnica para enviar uma EIP bem-elaborada, historicamente, a maioria dos autores de EIP são geralmente desenvolvedores de aplicativos ou protocolos.
-
-## Por que as EIPs são importantes? {#why-do-eips-matter}
-
-As EIPs desempenham um papel central em como as mudanças acontecem e são documentadas no Ethereum. São a forma de as pessoas proporem, debaterem e adoptarem alterações. Existem [diferentes tipos de EIPs](https://eips.ethereum.org/EIPS/eip-1#eip-types), incluindo EIPs centrais para alterações de protocolo de baixo nível, que afetam o consenso e exigem uma atualização de rede como [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) e ERCs para padrões de aplicativos como [EIP-20](https://eips.ethereum.org/EIPS/eip-20) e [EIP-721](https://eips.ethereum.org/EIPS/eip-721).
-
-Cada atualização de rede consiste em um conjunto de EIPs que precisam ser implementadas por cada [cliente Ethereum](/learn/#clients-and-nodes) na rede. Isso significa que para estar em consenso com outros clientes na rede principal do Ethereum, os desenvolvedores do cliente precisam ter certeza de que todos implementaram as EIPs necessárias.
-
-Além de fornecer uma especificação técnica para mudanças, as EIPs são a unidade em torno da qual a governança acontece no Ethereum: qualquer um pode propor uma EIP e, em seguida, vários stakeholders da comunidade discutirão para determinar se ela deve ser adotada como padrão ou incluída em uma melhoria da rede. Como as EIPs não centrais não precisam ser adotadas por todos os aplicativos (por exemplo, é possível criar um token diferente do ERC20), embora as EIPs centrais devam ser amplamente adotadas (porque todos os nós devem ser atualizados para se manterem parte da mesma rede), as EIPs centrais exigem um consenso mais amplo dentro da comunidade do que as EIPs não centrais.
-
-## Histórico de EIPs {#history-of-eips}
-
-O repositório Github [Propostas de Melhorias do Ethereum (EIPs)](https://github.com/ethereum/EIPs) foi criado em outubro de 2015. O processo EIP é baseado no processo de [Propostas de Melhorias do Bitcoin (BIPs)](https://github.com/bitcoin/bips) que, por sua vez, é baseado no processo [Propostas de Melhorias do Python (PEPs)](https://www.python.org/dev/peps/).
-
-Os editores de EIP têm a tarefa de revisar os processos das EIPs quanto a coerência técnica, problemas de formatação e correção de ortografia, gramática e estilo de código. Martin Becze, Vitalik Buterin, Gavin Wood e alguns outros foram os editores originais de EIP de 2015 até o final de 2016.
-
-Os editores atuais de EIP são
-
-- Alex Beregszaszi (@axic)
-- Gavin John (@Pandapip1)
-- Greg Colvin (@gcolvin)
-- Matt Garnett (@lightclient)
-- Sam Wilson (@SamWilsn)
-
-Os editores eméritos da EIP são
-
-- Casey Detrio (@cdetrio)
-- Hudson Jameson (@Souptacular)
-- Martin Becze (@wanderer)
-- Micah Zoltu (@MicahZoltu)
-- Nick Johnson (@arachnid)
-- Nick Savers (@nicksavers)
-- Vitalik Buterin (@vbuterin)
-
-Se você deseja se tornar um editor de EIP, confira [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069).
-
-Os editores de EIP decidem quando uma proposta está pronta para se tornar uma EIP e ajudam os autores da EIP a avançar com suas propostas. O grupo [Ethereum Cat Herders](https://www.ethereumcatherders.com/) ajuda a organizar reuniões entre os editores de EIP e a comunidade (consulte [EIPIP](https://github.com/ethereum-cat-herders/EIPIP)).
-
-O processo completo de padronização, juntamente com o gráfico, é descrito em [EIP-1](https://eips.ethereum.org/EIPS/eip-1)
-
-## Saiba mais {#learn-more}
-
-Se você estiver interessado em ler mais sobre EIPs, confira o [site sobre EIPs](https://eips.ethereum.org/) e [EIP-1](https://eips.ethereum.org/EIPS/eip-1). Aqui estão alguns links úteis:
-
-- [Uma lista de todas as propostas de melhoria do Ethereum](https://eips.ethereum.org/all)
-- [Uma descrição de todos os tipos de EIP](https://eips.ethereum.org/EIPS/eip-1#eip-types)
-- [Uma descrição de todos os status de EIP](https://eips.ethereum.org/EIPS/eip-1#eip-process)
-
-### Projetos de educação comunitária {#community-projects}
-
-- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — *PEEPanEIP é uma série de vídeos educacionais que discute a Proposta de Melhoria do Ethereum (EIPs) e os principais recursos das próximas melhorias.*
-- [EIPs For Nerds](https://ethereum2077.substack.com/t/eip-research) — *EIPs For Nerds fornece visões gerais abrangentes no estilo ELI5 de várias Propostas de Melhoria do Ethereum (EIPs), incluindo EIPs principais e EIPs de camada de aplicativo/infraestrutura (ERCs), para educar os leitores e formar um consenso em torno das mudanças propostas no protocolo Ethereum.*
-- [EIPs.wtf](https://www.eips.wtf/) — *EIPs.wtf fornece informações extras para Propostas de Melhoria do Ethereum (EIPs), incluindo status, detalhes de implementação, solicitações de pull relacionadas e feedback da comunidade.*
-- [EIP.Fun](https://eipfun.substack.com/) — *EIP.Fun fornece as últimas notícias sobre Propostas de Melhoria do Ethereum (EIPs), atualizações sobre reuniões do EIP e muito mais.*
-- [EIPs Insight](https://eipsinsight.com/) — *EIPs Insight é uma representação do estado do processo e estatísticas das Propostas de Melhoria do Ethereum (EIPs) de acordo com informações coletadas de diferentes recursos.*
-
-## Participar {#participate}
-
-Qualquer pessoa pode criar uma EIP. Antes de enviar uma proposta, é necessário ler a [EIP-1](https://eips.ethereum.org/EIPS/eip-1), que descreve o processo de EIP, como escrever uma EIP e solicitar feedback sobre no fórum [Ethereum Magicians](https://ethereum-magicians.org/), no qual as propostas são discutidas primeiro com a comunidade antes de um plano ser enviado.
-
-## Referências {#references}
-
-
-
-Conteúdo da página retirado parcialmente do artigo [Coordenação do upgrade da rede e governança do desenvolvimento do protocolo Ethereum (em inglês)](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-network-upgrade-coordination/) por Hudson Jameson
-
-
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/beacon-chain/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/beacon-chain/index.md
deleted file mode 100644
index 35ac892bc0c..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/beacon-chain/index.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: A Beacon Chain
-description: Saiba mais sobre a Beacon Chain — a melhoria que introduziu a prova de participação no Ethereum.
-lang: pt-br
-template: upgrade
-image: /images/upgrades/core.png
-alt:
-summaryPoint1: A Beacon Chain introduziu a prova de participação no ecossistema Ethereum.
-summaryPoint2: Ela foi integrada à cadeia de prova de trabalho do Ethereum original em setembro de 2022.
-summaryPoint3: A Beacon Chain introduziu a lógica de consenso e o protocolo de propagação de blocos que agora protege o Ethereum.
----
-
-
- A Beacon Chain foi lançada em 1º de Dezembro de 2020 e formalizou a prova de participação como mecanismo de consenso da Ethereum, com a atualização da Fusão em 15 de setembro de 2022.
-
-
-## O que é a Beacon Chain? {#what-is-the-beacon-chain}
-
-Beacon Chain é o nome do blockchain de prova de participação original que foi lançado em 2020. Ela foi criada para garantir que a lógica de consenso de prova de participação era sólida e sustentável antes de implementá-la na rede principal do Ethereum. Portanto, ela existia paralelamente à prova de trabalho do Ethereum. Beacon Chain era uma cadeia de blocos '"vazios", mas para desativar a prova de trabalho e ativar a prova de participação no Ethereum era necessário instruir a Beacon Chain a aceitar dados de transação de clientes de execução, agrupá-los em blocos e depois organizá-los em um blockchain usando um mecanismo de consenso com base em prova de participação. Ao mesmo tempo, os nós da rede original do Ethereum desligaram sua lógica de consenso, propagação de blocos e mineração, passando essas funções para a Beacon Chain. Este evento ficou conhecido como [The Merge](/roadmap/merge/). Após a Fusão, não havia mais dois blockchains. Em vez disso, havia apenas um Ethereum de prova de participação, que agora exige dois clientes diferentes por nó. Agora, a Beacon Chain é a camada de consenso, uma rede ponto a ponto de clientes de consenso que processa a lógica de consenso e transmissão de blocos, enquanto os clientes originais formam a camada de execução, responsável pela transmissão e execução de transações e pelo gerenciamento do estado do Ethereum. As duas camadas podem se comunicar mutuamente por meio da Engine API.
-
-## O que a Beacon Chain faz? {#what-does-the-beacon-chain-do}
-
-Beacon Chain é o nome dado a um registro de contas que orientava e coordenava a rede de [stakers](/participantes/) do Ethereum antes que começassem a validar blocos reais do Ethereum. Entretanto, não processa transações nem interações de contratos inteligentes, pois isso é feito na camada de execução. A Beacon Chain é responsável por atividades como processamento de blocos e atestações, executação do algoritmo de escolha de bifurcação e gerenciamento de recompensas e penalidades. Leia mais em nossa [página de arquitetura de nós](/developers/docs/nodes-and-clients/node-architecture/#node-comparison).
-
-## O impacto da Beacon Chain {#beacon-chain-features}
-
-### Participação (staking) {#introducing-staking}
-
-A Beacon Chain introduziu a [prova de participação](/developers/docs/consensus-mechanisms/pos/) no Ethereum. Isso mantém o Ethereum protegido e os validadores recebem mais ETH no processo. Na prática, você precisará participar com os seus ETH para ativar o software de validador. Como participante, você executa o software que cria e valida novos blocos na cadeia.
-
-O processo de participação tem um objetivo semelhante ao da [mineração](/developers/docs/consensus-mechanisms/pow/mining/), mas tem muitas diferenças. A mineração exigia grandes investimentos iniciais na forma de um hardware potente e consumo de energia, o que resultava em economias de escala e promovia a centralização. A mineração também não tem como garantia uma exigência de bloqueio de ativos, o que limita a capacidade do protocolo de punir os malfeitores após um ataque.
-
-A transição para a prova de participação tornou o Ethereum consideravelmente mais seguro e descentralizado, em comparação com a prova de trabalho. Quanto mais pessoas participarem da rede, mais descentralizada e segura contra ataques ela será.
-
-E utilizar a prova de participação como mecanismo de consenso é um componente fundamental para [o Ethereum seguro, ecológico e dimensionável que temos agora](/roadmap/vision/).
-
-
- Se você estiver interessado em se tornar um validador e ajudar a manter o Ethereum seguro, saiba mais sobre o conceito de participação.
-
-
-### Preparação para a fragmentação {#setting-up-for-sharding}
-
-Desde que a Beacon Chain se fundiu à rede principal original do Ethereum, a comunidade Ethereum começou tentar dimensionar a rede.
-
-A prova de participação tem a vantagem de manter um registro de todos os produtores de blocos aprovados a qualquer momento, cada um com ETH participado. Esse registro prepara o cenário para a capacidade de dividir e conquistar, mas dividir de forma confiável as responsabilidades específicas da rede.
-
-Essa responsabilidade contrasta com a prova de trabalho, em que os mineradores não têm nenhuma obrigação com a rede e podem interromper a mineração e desligar o software do nó permanentemente, em um instante, sem repercussão. Também não há registro de proponentes de blocos conhecidos e nenhuma maneira confiável de dividir as responsabilidades da rede com segurança.
-
-[Mais sobre fragmentação](/roadmap/danksharding/)
-
-## Relação entre as melhorias {#relationship-between-upgrades}
-
-As melhorias do Ethereum estão, de certa forma, relacionadas. Vamos recapitular como a Beacon Chain afeta as outras melhorias.
-
-### Beacon Chain e A Fusão {#merge-and-beacon-chain}
-
-No começo, a Beacon Chain existia separadamente da rede principal do Ethereum, mas ocorreu uma fusão em 2022.
-
-
- A integração
-
-
-### Fragmentos e a Beacon Chain {#shards-and-beacon-chain}
-
-As cadeias de fragmentação apenas podem ser introduzidas no ecossistema Ethereum por meio do estabelecimento de um mecanismo de consenso de prova de participação. A Beacon Chain introduziu a participação, que se "fundiu" com a rede principal, abrindo caminho para a fragmentação, de forma a ajudar a dimensionar ainda mais o Ethereum.
-
-
- Cadeias de fragmentos
-
-
-## Leituras adicionais
-
-- [Mais informações sobre as futuras atualizações do Ethereum](/roadmap/vision)
-- [Mais sobre arquitetura de nós](/developers/docs/nodes-and-clients/node-architecture)
-- [Mais sobre prova de participação](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/future-proofing/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/future-proofing/index.md
deleted file mode 100644
index 3b55e25385b..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/future-proofing/index.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Preparação do Ethereum para o futuro
-description: Essas melhorias consolidam o Ethereum como a camada de base resiliente e descentralizada para o futuro, seja ele qual for.
-lang: pt-br
-image: /images/roadmap/roadmap-future.png
-alt: "Planejamento Ethereum"
-template: roadmap
----
-
-Algumas partes do planejamento não são necessariamente obrigatórias para dimensionar ou proteger o Ethereum no curto prazo, mas preparam o Ethereum para a estabilidade e a confiabilidade no futuro.
-
-## Resistência quântica {#quantum-resistance}
-
-Parte da [criptografia](/glossary/#cryptography) que protege o Ethereum atual será comprometida quando a computação quântica se tornar uma realidade. Embora os computadores quânticos estejam provavelmente a décadas de se tornarem uma ameaça genuína à criptografia moderna, o Ethereum tem sido desenvolvido para ser seguro nos próximos séculos. Isso significa tornar o [Ethereum resistente ao quântico](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) o mais rápido possível.
-
-O desafio enfrentado pelos desenvolvedores Ethereum é que o protocolo atual de [prova de participação](/glossary/#pos) depende de um esquema de assinatura muito eficiente conhecido como BLS para agregar votos em [blocos](/glossary/#block)válidos. Esse esquema de assinatura é quebrado por computadores quânticos, mas as alternativas quânticas resistentes não são tão eficientes.
-
-Os [esquemas de compromisso "KZG"](/roadmap/danksharding/#what-is-kzg) utilizados em diversos lugares no Ethereum para gerar segredos criptográficos são conhecidos por serem vulneráveis ao quântico. Atualmente, isso é contornado por meio da utilização de "configurações confiáveis", em que muitos usuários geram uma aleatoriedade que não pode ser revertida por um computador quântico. Entretanto, a solução ideal seria simplesmente incorporar a criptografia quântica segura. Há duas abordagens principais que poderiam se tornar substitutos eficientes para o esquema BLS: assinatura [com base em STARK](https://hackmd.io/@vbuterin/stark_aggregation) e [em malha](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **Essas abordagens ainda estão sendo pesquisadas e desenvolvidas.**.
-
- Leia sobre o KZG e as configurações confiáveis
-
-## Ethereum mais simples e mais eficiente {#simpler-more-efficient-ethereum}
-
-A complexidade cria oportunidades para bugs ou vulnerabilidades que podem ser explorados por invasores. Portanto, parte do planejamento é simplificar o Ethereum e remover códigos que permaneceram ao longo de diversas melhorias, mas que não são mais necessários ou podem ser aprimorados. Os desenvolvedores conseguem manter e aplicar lógica de uma maneira mais fácil com uma base de código mais enxuta e simples.
-
-Diversas atualizações serão feitas na [Máquina Virtual do Ethereum (EVM)](/developers/docs/evm) para torná-la mais simples e eficiente. Isso inclui a [remoção do código de operação SELFDESTRUCT](https://hackmd.io/@vbuterin/selfdestruct), um comando raramente utilizado que não é mais necessário e, em algumas circunstâncias, pode ser perigoso de usar, especialmente quando combinado com outras melhorias futuras do modelo de armazenamento do Ethereum. Os [clientes Ethereum](/glossary/#consensus-client) também ainda suportam alguns tipos de transação antigos que agora podem ser completamente removidos. A maneira como [gás](/glossary/#gas) é calculado também pode ser melhorada e podem ser introduzidos métodos mais eficientes para a aritmética que sustenta algumas operações criptográficas.
-
-Da mesma forma, há atualizações que podem ser feitas em outras partes dos clientes atuais do Ethereum. Um exemplo é que os clientes atuais de execução e consenso utilizam um tipo diferente de compactação de dados. Quando o esquema de compactação for unificado em toda a rede, será muito mais fácil e intuitivo compartilhar dados entre clientes.
-
-## Progresso atual {#current-progress}
-
-A maioria das melhorias necessárias para preparação do Ethereum para o futuro ainda** está em fase de pesquisa em poderá demorar diversos anos** para implementação. Melhorias como a remoção do SELFDESTRUCT e a harmonização do esquema de compactação usado na execução e nos clientes de consenso provavelmente virão antes da criptografia quântica resistente.
-
-**Leitura adicional**
-
-- [Gás](/developers/docs/gas)
-- [EVM](/developers/docs/evm)
-- [Estruturas de dados](/developers/docs/data-structures-and-encoding)
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/index.md
deleted file mode 100644
index 849d7a125b8..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/index.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: Planejamento Ethereum
-description: O caminho para mais escalabilidade, segurança e sustentabilidade no Ethereum.
-lang: pt-br
-template: roadmap
-image: /images/heroes/roadmap-hub-hero.jpg
-alt: "Planejamento Ethereum"
-summaryPoints:
-buttons:
- -
- label: Melhorias adicionais
- toId: próximas-alterações
- -
- label: Melhorias anteriores
- href: /history/
- variant: descrição
----
-
-O Ethereum já é uma plataforma poderosa para a coordenação global, mas ainda está sendo aprimorado. Um conjunto ambicioso de melhorias atualizará o Ethereum da forma atual em uma plataforma totalmente dimensionada e com a máxima resiliência. Essas melhorias estão definidas no planejamento do Ethereum.
-
-**Para saber mais sobre as melhorias anteriores do Ethereum, acesse a nossa página [Histórico](/history/)**
-
-## Quais serão as próximas alterações no Ethereum? {#what-changes-are-coming}
-
-O planejamento do Ethereum descreve as melhorias específicas que serão feitas no protocolo no futuro. Em geral, o planejamento oferecerá os benefícios descritos a seguir aos usuários do Ethereum:
-
-
-
-
-
-
-
-
-## Por que o Ethereum precisa de um planejamento? {#why-does-ethereum-need-a-roadmap}
-
-O Ethereum recebe melhorias regulares que aprimoram a escalabilidade, a segurança ou a sustentabilidade. Um dos principais pontos fortes do Ethereum é a adaptação à medida que novas ideias surgem a partir de pesquisa e desenvolvimento. A adaptabilidade confere ao Ethereum a flexibilidade para enfrentar os desafios emergentes e acompanhar os avanços tecnológicos mais revolucionários.
-
-
-
-O planejamento é, em grande parte, o resultado de anos de trabalho de pesquisadores e desenvolvedores, pois o protocolo é muito técnico, mas qualquer pessoa motivada pode participar. As ideias geralmente começam como discussões em um fórum, como [ethresear.ch](https://ethresear.ch/), [Ethereum Magicians](https://ethereum-magicians.org/) ou no servidor Eth R&D no Discord. Elas podem ser respostas a novas vulnerabilidades descobertas, sugestões de organizações que trabalham na camada de aplicativos (como [dapps](/glossary/#dapp) e exchanges) ou temas polêmicos conhecidos pelos usuários finais (como custos ou velocidades de transação). Quando essas ideias amadurecem, elas podem ser apresentadas como [Propostas de melhorias do Ethereum] (https://eips.ethereum.org/). Tudo isso é feito abertamente, e qualquer pessoa da comunidade pode dar sua opinião, a qualquer momento.
-
-[Mais sobre a governança do Ethereum](/governance/)
-
-
-
-
-
O que era ETH2?
-
-
O termo 'Eth2' era comumente usado para descrever o futuro do Ethereum antes da mudança para prova de participação, mas foi eliminado em favor de uma terminologia mais precisa. Originalmente, era usado para diferenciar a rede Ethereum antes da mudança para prova de participação e a rede depois, ou às vezes para se referir aos diferentes clientes Ethereum (os clientes de execução e os clientes de consenso eram respectivamente chamados de clientes ETH1 e ETH2).
-
-
-
-## O planejamento do Ethereum mudará ao longo do tempo? {#will-ethereums-roadmap-change-over-time}
-
-**Sim, quase sem dúvida**. O planejamento é o plano atual de atualização do Ethereum, abrangendo planos futuros e de curto prazo. Esperamos que o planejamento mude à medida que novas informações e tecnologias sejam disponibilizadas.
-
-Pense no roadmap do Ethereum como um conjunto de intenções para aprimorar o Ethereum; é a melhor hipótese dos pesquisadores e desenvolvedores do núcleo sobre o melhor caminho a seguir no Ethereum.
-
-## Quando o planejamento será finalizado? {#when-will-the-roadmap-be-finished}
-
-Algumas melhorias são de prioridade mais baixa e provavelmente não serão implementadas nos próximos 5 a 10 anos (por exemplo, resistência quântica). **É difícil prever o momento exato de cada melhoria**, pois muitos itens do roadmap são trabalhados em paralelo e desenvolvidos em velocidades diferentes. A urgência de uma melhoria também pode mudar ao longo do tempo, dependendo de fatores externos (por exemplo, um avanço repentino no desempenho e na disponibilidade de computadores quânticos pode tornar a criptografia resistente a quânticos mais urgente).
-
-Uma maneira de pensar sobre o desenvolvimento do Ethereum é por analogia à evolução biológica. É mais provável que uma rede capaz de se adaptar a novos desafios e manter a adequação seja bem-sucedida do que uma resistente a mudanças, embora, à medida que a rede se torne cada vez mais eficiente, dimensionável e segura, sejam necessárias menos alterações no protocolo.
-
-## Preciso fazer algo quando uma melhoria é implementada? {#do-i-have-to-do-anything-when-there-is-an-upgrade}
-
-As melhorias normalmente não afetam os usuários finais, exceto ao proporcionar melhores experiências de usuário e um protocolo mais seguro e talvez mais opções de como interagir com o Ethereum. **Os usuários comuns não precisam participar ativamente de uma melhoria, nem precisam fazer nada** para proteger seus ativos. Os operadores de [nós](/glossary/#node) precisarão atualizar seus clientes para se prepararem para uma melhoria. Algumas melhorias podem gerar mudanças para os desenvolvedores de aplicativos. Por exemplo, as melhorias de expiração do histórico podem fazer com que os desenvolvedores de aplicativos obtenham dados históricos de novas fontes.
-
-## E quanto ao Verge, Splurge etc? {#what-about-the-verge-splurge-etc}
-
-[Vitalik Buterin propôs uma visão para o planejamento do Ethereum](https://twitter.com/VitalikButerin/status/1741190491578810445) que foi organizada em diversas categorias vinculadas pelos efeitos na arquitetura do Ethereum. Ela inclui:
-
-- <**A Fusão**: melhorias relacionadas à mudança de [prova de trabalho](/glossary/#pow) para [prova de participação](/glossary/#pos)
-- **The Surge**: melhorias relacionadas ao dimensionamento por meio de [rollups](/glossary/#rollups) e fragmentação de dados
-- **The Scourge**: melhorias relacionadas à resistência à censura, à descentralização e a riscos de protocolo do [MEV](/glossary/#mev)
-- **The Verge**: melhorias relacionadas à verificação de [blocos](/glossary/#block) com mais facilidade
-- **The Purge**: melhorias relacionadas à redução dos custos computacionais dos nós em execução e à simplificação do protocolo
-- **The Splurge**: outras melhorias que não se encaixam bem nas categorias anteriores.
-
-Decidimos não usar essa terminologia porque queríamos usar um modelo mais simples e mais centrado no usuário. Embora usemos uma linguagem centrada no usuário, a visão permanece idêntica à proposta por Vitalik.
-
-## E quanto à fragmentação? {#what-about-sharding}
-
-A fragmentação divide a blockchain do Ethereum de modo que subconjuntos de [validadores](/glossary/#validator) sejam responsáveis apenas por uma fração do total de dados. Originalmente, essa era a forma de escalabilidade do Ethereum. No entanto, os rollups da [camada 2](/glossary/#layer-2) se desenvolveram muito mais rápido do que o esperado e já proporcionaram um grande aumento de escala, e proporcionarão muito mais depois que o Proto-Danksharding for implementado. Isso significa que as "cadeias de fragmentos" não são mais necessárias e foram retiradas do planejamento.
-
-## Procurando por melhorias técnicas específicas? {#looking-for-specific-technical-upgrades}
-
-- [Danksharding](/roadmap/danksharding) - o Danksharding torna os rollups da camada 2 muito mais baratos para os usuários ao adicionar "blobs" de dados aos blocos Ethereum.
-- [Saques de participação](/staking/withdrawals) - a melhoria Shanghai/Capella habilitou saques de participação no Ethereum, permitindo que as pessoas desbloqueassem seus ETHs participados.
-- [Finalidade de um único espaço](/roadmap/single-slot-finality) - em vez de esperar quinze minutos, os blocos poderiam ser propostos e finalizados no mesmo espaço. Isso é mais conveniente para os aplicativos e muito mais difícil de atacar.
-- [Separação entre proponente e construtor](/roadmap/pbs) - a divisão das tarefas de construção e proposta de blocos em validadores separados cria uma maneira mais justa, mais resistente à censura e mais eficiente para que o Ethereum chegue a um consenso.
-- [Eleição de líder secreto](/roadmap/secret-leader-election) - a criptografia inteligente pode ser utilizada para garantir que a identidade do proponente do bloco atual não seja tornada pública, protegendo-o de determinados tipos de ataque.
-- [Abstração da conta](/roadmap/account-abstraction) - a abstração da conta é uma classe de melhorias que oferece suporte a carteiras de contratos inteligentes nativamente no Ethereum, em vez de precisar usar um middleware complexo.
-- [Verkle Trees](/roadmap/verkle-trees) - As Verkle Trees são uma estrutura de dados que pode ser utilizada para habilitar clientes sem estado no Ethereum. Esses clientes "sem estado" exigirão uma quantidade mínima de espaço de armazenamento, mas ainda poderão verificar novos blocos.
-- [Sem estado](/roadmap/statelessness) - os clientes sem estado poderão verificar novos blocos sem precisar armazenar grandes quantidades de dados. Isso proporcionará todos os benefícios da execução de um nó a apenas uma pequena fração dos custos atuais.
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/merge/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/merge/index.md
deleted file mode 100644
index b0a6d443e3b..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/merge/index.md
+++ /dev/null
@@ -1,229 +0,0 @@
----
-title: A Fusão
-description: Aprenda sobre A Fusão — quando a Rede principal do Ethereum adotou a prova de participação.
-lang: pt-br
-template: upgrade
-image: /images/upgrades/merge.png
-alt:
-summaryPoint1: A rede principal do Ethereum usa prova de participação, mas esse nem sempre foi o caso.
-summaryPoint2: A melhoria do mecanismo original de prova de trabalho para prova de participação foi chamada de The Merge, ou seja, A Fusão.
-summaryPoint3: A Fusão se refere à fusão original da Rede principal do Ethereum com uma blockchain de prova de participação separada chamada Beacon Chain, agora existente como uma cadeia.
-summaryPoint4: A Fusão reduziu o consumo de energia do Ethereum em cerca de 99,95%.
----
-
-
- A Fusão foi executada em 15 de setembro de 2022. Isto completou a transição do Ethereum para o consenso de prova de participação, depreciando oficialmente a prova de trabalho, e reduzindo o consumo de energia em ~99,95%.
-
-
-## O que foi A Fusão? {#what-is-the-merge}
-
-A Fusão foi a junção da camada de execução original do Ethereum (a Rede principal que existe desde a [origem](/history/#frontier)) com a sua nova camada de consenso de prova de participação, a Beacon Chain. Ele eliminou a necessidade de mineração que faz uso intensivo de energia e, em vez disso, permitiu que a rede fosse protegida usando participação de ETH. Foi uma etapa realmente emocionante para a realização da visão do Ethereum — mais escalabilidade, segurança e sustentabilidade.
-
-
-
-Inicialmente, a [Beacon Chain](/roadmap/beacon-chain/) foi enviada separadamente da [Mainnet](/glossary/#mainnet). A rede principal da Ethereum - com todas as suas contas, saldos, contratos inteligentes e estado da cadeia de blocos - continuou a ser protegida pela [prova de trabalho](/developers/docs/consensus-mechanisms/pow/), mesmo enquanto a Beacon Chain funcionava em paralelo usando a [prova de participação](/developers/docs/consensus-mechanisms/pos/). A Fusão foi quando esses dois sistemas finalmente se uniram, e a prova de trabalho foi permanentemente substituída pela prova de participação.
-
-Imagine que o Ethereum é uma espaçonave que foi lançada antes que estivesse pronta para uma viagem interestelar. Com a Beacon Chain, a comunidade construiu um novo motor e um casco reforçado. Após muitos testes, chegou a hora de trocar o novo motor a quente pelo antigo em pleno voo. Isso integrou o novo e mais eficiente motor à nave existente, o que lhe permitiu cruzar anos-luz e conquistar o universo.
-
-## Fusão com a Rede principal {#merging-with-mainnet}
-
-A prova de trabalho protegeu a rede principal do Ethereum desde sua origem até A Fusão. Isso permitiu que a cadeia de blocos do Ethereum com a qual todos estamos acostumados surgisse em julho de 2015 com todos os seus recursos familiares — transações, contratos inteligentes, contas, etc.
-
-Ao longo da história do Ethereum, os desenvolvedores se prepararam para uma eventual transição da prova de trabalho para a prova de participação. Em 1 de dezembro de 2020, a Beacon Chain foi criada como uma cadeia de blocos separada da Rede principal, rodando em paralelo.
-
-A Beacon Chain não estava processando originalmente as transações da Rede principal. Em vez disso, ela estava chegando ao consenso sobre seu próprio estado ao concordar com validadores ativos e seus saldos de conta. Após extensos testes, chegou a hora da Beacon Chain chegar a um consenso sobre os dados do mundo real. Após A Fusão, a Beacon Chain tornou-se o mecanismo de consenso para todos os dados da rede, incluindo transações da camada de execução e saldos de contas.
-
-A integração representou a mudança oficial para o uso da Beacon Chain como o motor de produção de blocos. A mineração não é mais o meio de produzir blocos válidos. Em vez disso, os validadores da prova de participação adotaram esse papel e agora são responsáveis por processar a validade de todas as transações e propor blocos.
-
-Nenhuma história foi perdida na Fusão. À medida que a Rede principal se uniu com a Beacon Chain, ela também integrou todo o histórico transacional do Ethereum.
-
-
-Essa transição para a prova de participação mudou o modo como o ether é emitido. Saiba mais sobre Emissão de ether antes de depois do The Merge.
-
-
-### Usuários e titulares {#users-holders}
-
-**A Fusão não mudou nada para titulares/usuários.**
-
-_Vale a pena repetir_: como usuário ou titular de ETH, ou qualquer outro ativo digital no Ethereum, bem como participantes não operantes dos nós, **você não precisa fazer nada com seus fundos ou carteira para dar conta da Fusão.** ETH é apenas ETH. Não existe algo como "ETH antigo"/"ETH novo" ou "ETH1"/"ETH2" e as carteiras funcionam exatamente da mesma forma após A Fusão como antes — pessoas dizendo a você o contrário provavelmente são golpistas.
-
-Apesar de trocar a prova de trabalho, toda a história do Ethereum desde a origem permaneceu intacta e inalterada com a transição para a prova de participação. Quaisquer fundos mantidos em sua carteira antes da Fusão ainda estarão acessíveis após A Fusão. **Nenhuma ação é necessária da sua parte para fazer parte dessa atualização revolucionária.**
-
-[Mais sobre segurança no Ethereum](/security/#eth2-token-scam)
-
-### Operadores de nós e desenvolvedores de dapps {#node-operators-dapp-developers}
-
-
-
-As principais ações incluem:
-
-1. Execute ao mesmo tempo um cliente de consenso e um cliente de execução; pontos de extremidade de terceiros para obter dados de execução não funcionam mais desde A Fusão.
-2. Autentique os clientes de execução e de consenso com um segredo JWT compartilhado para que eles possam se comunicar com segurança.
-3. Defina um endereço de "destinatário das taxas" para receber dicas sobre suas taxas de transação ganhas / MEV.
-
-Não completar os dois primeiros itens acima fará com que seu nó seja visto como "offline" até que ambas as camadas sejam sincronizadas e autenticadas.
-
-Não definir um "destinatário de taxa" ainda permitirá que seu validador se comporte como de costume, mas você perderá comissões de taxas não queimadas e qualquer MEV que você teria ganhado em blocos que seu validador propõe.
-
-
-
-
-Até a integração, um cliente de execução (como Geth, Erigon, Besu ou Nethermind) era suficiente para receber, validar devidamente e propagar blocos sendo transmitidos pela rede. _Após A Fusão_, a validade das transações contidas em uma carga de execução agora também depende da validade do "bloco de consenso" que ele contém.
-
-Como resultado, um nó completo do Ethereum agora requer um cliente de execução e um cliente de consenso. Esses dois clientes trabalham juntos usando uma nova API do mecanismo. A API do mecanismo requer autenticação usando um segredo JTW, que é fornecido a ambos os clientes, permitindo uma comunicação segura.
-
-Os principais itens de ação incluem:
-
-- Instalar um cliente de consenso além de um cliente de execução
-- Autenticar clientes de execução e de consenso com um segredo JWT compartilhado para que eles possam se comunicar com segurança uns com os outros.
-
-Não completar os itens acima resultará com que seu nó pareça estar "offline" até que ambas as camadas sejam sincronizadas e autenticadas.
-
-
-
-
-
-A Fusão veio com alterações no consenso, que também inclui alterações relacionadas a:<
-
-
-
estrutura de bloco
-
timing de espaço/bloco
-
alterações de opcode
-
fontes de aleatoriedade em cadeia
-
conceito de cabeçalho seguro e blocos finalizados
-
-
-Para obter mais informações, leia esta publicação de Tim Beiko sobre How The Merge Impacts Ethereum’s Application Layer (Como a Fusão afeta a camada de aplicação do Ethereum).
-
-
-
-## A Fusão e o consumo de energia {#merge-and-energy}
-
-A Fusão marcou o fim da prova de trabalho para o Ethereum e deu início à era de um Ethereum mais sustentável e ecológico. O consumo de energia do Ethereum reduziu cerca de 99,95%, tornando o Ethereum uma blockchain verde. Descubra mais sobre [Consumo de energia na rede Ethereum](/energy-consumption/).
-
-## A Fusão e a escalabilidade {#merge-and-scaling}
-
-The Merge também preparou o terreno para futuras atualizações de escalabilidade que não eram possíveis na prova de trabalho, deixando o Ethereum mais próximo de alcançar a escalabilidade, segurança e sustentabilidade descritas na [Visão do Ethereum](/roadmap/vision/).
-
-## Concepções erradas sobre A Fusão {#misconceptions}
-
-
-
-Existem dois tipos de nós no Ethereum: nós que podem propor blocos e nós que não podem.
-
-Os nós que propõem blocos são apenas um pequeno número dos nós totais no Ethereum. Esta categoria inclui nós de mineração sob a prova de trabalho (PoW) e nós validadores sobre a prova de participação (PoS). Esta categoria requer comprometer recursos econômicos (como o poder de hash da GPU em prova de trabalho ou ETH em prova de participação) em troca da capacidade de propor, ocasionalmente, o próximo bloco e ganhar recompensas de protocolo.
-
-Os outros nós na rede (por exemplo, a maioria) não é obrigada a comprometer quaisquer recursos econômicos para além de um computador com 1 a 2 TB de armazenamento disponível e uma conexão com a internet. Esses nós não propõem blocos, mas eles ainda desempenham um papel crítico na segurança da rede, mantendo todos os proponentes de bloco responsáveis, ouvindo novos blocos e verificando sua validade na chegada de acordo com as regras de consenso da rede. Se o bloco for válido, o nó continua a propagá-lo pela rede. Se o bloco é inválido por qualquer motivo, o software do nó irá ignorá-lo como inválido e irá parar sua propagação.
-
-Qualquer pessoa pode executar um nó que não produz blocos, em qualquer mecanismo de consenso (prova de trabalho ou prova de participação); isso é amplamente incentivado para todos os usuários, se tiverem os meios. A execução de um nó é imensamente valiosa para o Ethereum e oferece benefícios adicionais a qualquer indivíduo executando um, como maior segurança, privacidade e resistência à censura.
-
-A capacidade de qualquer pessoa de executar seu próprio nó é absolutamente essencial para manter a descentralização da rede Ethereum.
-
-Mais detalhes sobre como executar seu próprio nó
-
-
-
-
-
-Taxas de gás são um produto da demanda de rede relativa à capacidade da rede. A Fusão depreciou o uso da prova de trabalho, passando para a prova de participação por consenso, mas não alterou significativamente nenhum parâmetro que influencie diretamente a capacidade da rede ou a taxa de transferência.
-
-Com um planejamento centrado em rollup, os esforços se concentram em dimensionar a atividade do usuário na camada 2 ao habilitar a rede principal da camada 1 como uma camada de estabelecimento descentralizada e segura, otimizada para o armazenamento de dados de rollup para ajudar a fazer com que as transações de rollup sejam exponencialmente mais acessíveis. A transição para a prova de participação é um precursor crítico para a realização desse objetivo. Mais informações sobre gás e taxas.
-
-
-
-
-A "velocidade" da transação pode ser medida de poucas maneiras, incluindo o tempo para ser incluída em um bloco e o tempo para finalização. Esses dois fatores mudam ligeiramente, mas não de uma forma que os usuários perceberão.
-
-Historicamente, na prova de trabalho, o objetivo era ter um bloco novo a cada ~13,3 segundos. Já na prova de participação, os espaços ocorrem precisamente a cada 12 segundos, e cada um deles é uma oportunidade para um validador publicar um bloco. A maioria dos espaços tem blocos, mas não necessariamente todos (isto é, um validador está offline). Na prova de participação, os blocos são produzidos ~10% mais frequentemente do que na prova de trabalho. Essa foi uma mudança bastante insignificante e é pouco provável que seja notada pelos usuários.
-
-A prova de participação introduziu o conceito de finalidade da transação que não existia anteriormente. Na prova de trabalho, a capacidade de reverter um bloco fica exponencialmente mais difícil com cada bloco de passagem minerado em cima de uma transação, mas nunca chega a zero. Sob a prova de participação, os blocos são agrupados em épocas (períodos de tempo de 6,4 minutos contendo 32 chances de blocos) que os validadores votam. Quando uma época termina, os validadores votam se devem considerar a época "justificada". Se os validadores concordarem em justificar a época, ela será finalizada na próxima época. Desfazer transações finalizadas é economicamente inviável, pois exigiria obter e queimar mais de um terço do total de ETH colocado.
-
-
-
-
-
-Inicialmente, após a Fusão, os participantes podiam acessar apenas as comissões de taxas e o MEV obtidos como resultado de propostas de bloco. Essas recompensas são creditadas em uma conta de não participação controlada pelo validador (conhecido como destinatário da taxa), e ficam disponíveis imediatamente. Essas recompensas são separadas das recompensas do protocolo pela execução das obrigações do validador.
-
-Desde a melhoria da rede Shanghai/Capella, os participantes agora podem designar um endereço de saque para começar a receber pagamentos automáticos de qualquer saldo de participação excedente (ETH superior a 32 de recompensas do protocolo). Essa melhoria também permitiu que um validador desbloqueasse e recuperasse todo o saldo ao sair da rede.
-
-Mais sobre saques de participação
-
-
-
-
-Como a melhoria do Shanghai/Capella permitiu saques, os validadores são incentivados a sacar o saldo de participação superior a 32 ETH, já que esses fundos não aumentam o rendimento e são bloqueados. Dependendo da APR (determinada pelo total de ETH participado), eles podem ser incentivados a sair de seus validadores para recuperar todo o saldo ou potencialmente participar ainda mais utilizando as recompensas, de forma a obter mais rendimento.
-
-Uma advertência importante aqui é que as saídas completas do validador são limitadas pelo protocolo, e apenas um número específico de validadores pode sair por época (a cada 6,4 minutos). Esse limite varia de acordo com o número de validadores ativos, mas chega a aproximadamente 0,33% do total de ETH participado que pode ser sacado da rede em um único dia.
-
-Isso evita um êxodo em massa dos fundos participados. Além disso, impede que um possível invasor com acesso a uma grande parte do total de ETH participado cometa uma ofensa passível de corte e saia/saque todos os saldos do validador infrator na mesma época, antes que o protocolo possa aplicar a penalidade de corte.
-
-A APR também é intencionalmente dinâmica, o que permite que um mercado de participantes equilibre o quanto estão dispostos a receber para ajudar a proteger a rede. Se a taxa for muito baixa, os validadores sairão a uma taxa limitada pelo protocolo. Gradualmente, isso aumentará a APR para todos os que permanecerem, atraindo participantes novos ou antigos novamente.
-
-
-## O que aconteceu com o "Eth2"? {#eth2}
-
-O termo "Eth2" foi descontinuado. Após unir "Eth1" e "Eth2" em uma única cadeia, não há mais necessidade de distinguir entre duas redes Ethereum; agora existe apenas o Ethereum.
-
-Para diminuir a confusão, a comunidade atualizou estes termos:
-
-- O "Eth1" agora é a "camada de execução", que lida com transações e execução.
-- O "Eth2" é agora a "camada de consenso", que lida com o consenso da prova de participação.
-
-Estas atualizações de terminologia apenas alteram as convenções de nomenclatura; isso não altera os objetivos ou o roteiro do Ethereum.
-
-[Saiba mais sobre a renomeação "Eth2"](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/)
-
-## Relação entre as melhorias {#relationship-between-upgrades}
-
-Todas as melhorias do Ethereum estão, de alguma forma, interrelacionadas. Vamos então recapitular como a fusão se relaciona com as outras melhorias.
-
-### A Fusão e a Beacon Chain {#merge-and-beacon-chain}
-
-A Fusão representa a adoção formal do Beacon Chain como a nova camada de consenso para a camada de execução da Rede principal original. Desde A Fusão, os validadores são designados a proteger a Rede principal do Ethereum, e a mineração na [prova de trabalho](/developers/docs/consensus-mechanisms/pow/) não é mais um meio válido de produção em bloco.
-
-Em vez disso, os blocos são propostos validando nós que colocaram o ETH em troca do direito de participar do consenso. Essas atualizações preparam o cenário para futuras atualizações de escalabilidade, incluindo fragmentação.
-
-
- A Beacon Chain
-
-
-### A Fusão e a atualização do Shanghai {#merge-and-shanghai}
-
-Para simplificar e maximizar o foco em uma transição bem-sucedida para a prova de participação, a atualização da Fusão não incluiu certos recursos previstos, como a possibilidade de retirar o ETH colocado. Essa funcionalidade foi habilitada separadamente com a melhoria Shanghai/Capella.
-
-Se tiver curiosidade, assista ao vídeo [What Happens After The Merge](https://youtu.be/7ggwLccuN5s?t=101) (O que ocorre após a Fusão), apresentado por Vitalik no evento ETHGlobal de abril de 2021.
-
-### A Fusão e a fragmentação {#merge-and-data-sharding}
-
-Originalmente, o plano era trabalhar na fragmentação antes da Fusão para atender a escalabilidade. No entanto, com a expansão das [soluções de escalabilidade da camada 2](/layer-2/), a prioridade passou a ser a troca da prova de trabalho pela prova de participação.
-
-Os planos para fragmentação estão evoluindo rapidamente, mas dado o surgimento e o sucesso das tecnologias de camada 2 para escalar a execução de transação, os planos de fragmentação mudaram para encontrar a maneira mais otimizada de distribuir a carga de armazenamento dos dados de chamadas compactadas em contratos rollup, permitindo um crescimento exponencial da capacidade da rede. Isso não seria possível sem uma primeira transição para a prova de participação.
-
-
- Fragmentação
-
-
-## Leitura adicional {#further-reading}
-
-
-
-
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/merge/issuance/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/merge/issuance/index.md
deleted file mode 100644
index 35ba71d46ac..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/merge/issuance/index.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: Como a Fusão afetou o fornecimento de ETH
-description: Detalhamento de como a Fusão afetou o fornecimento de ETH
-lang: pt-br
----
-
-# Como A Fusão afetou o fornecimento de ETH {#how-the-merge-impacts-ETH-supply}
-
-A Fusão representou a transição das redes Ethereum da prova de trabalho para a prova de participação, que ocorreu em setembro de 2022. A forma como o ETH foi emitido passou por mudanças no momento dessa transição. Anteriormente, novas moedas de ETH eram emitidas por duas fontes: a camada de execução (ou seja, Mainnet) e a camada de consenso (ou seja, Beacon Chain). Desde o The Merge, a emissão na camada de execução não acontece mais. Vamos explicar isso melhor.
-
-## Componentes da emissão de ETH {#components-of-eth-issuance}
-
-Podemos dividir o fornecimento de ETH em duas forças principais: emissão e queima.
-
-A **emissão** de ETH é o processo de criação de ETH que não existia anteriormente. A **queima** de ETH é quando o ETH existente é destruído, removendo-o de circulação. A taxa de emissão e de queima é calculada com base em vários parâmetros, e o saldo entre eles determina a taxa de inflação / deflação resultante de ether.
-
-
-
-— Antes da transição para prova de participação, os mineradores estavam emitindo aproximadamente 13.000 ETH/dia
-— Os participantes emitem aproximadamente 1.700 ETH/dia, com base em cerca de 14 milhões de ETH total em participação
-— A emissão exata de staking flutua com base na quantidade total de ETH em participação
-— **Desde o The Merge, restam apenas ~1.700 ETH/dia, reduzindo a emissão total de novos ETH em ~88%**
-— A queima: varia de acordo com a demanda da rede. _Se_ um preço médio do gás de pelo menos 16 gwei for observado para um determinado dia, isso compensa efetivamente os ~1.700 ETH que são emitidos para os validadores e leva a inflação líquida do ETH para zero ou menos para esse dia.
-
-
-
-## Pré-fusão (histórico) {#pre-merge}
-
-### Emissão da camada de execução {#el-issuance-pre-merge}
-
-Na prova de trabalho, os mineradores só interagiam com a camada de execução e recebiam recompensas de bloco se fossem os primeiros mineradores a resolver o bloco seguinte. Desde a [atualização Constantinople](/history/#constantinople) em 2019, essa recompensa era de 2 ETH por bloco. Os mineradores também foram recompensados por publicar blocos [ommer](/glossary/#ommer), que eram blocos válidos que não terminavam na cadeia mais longa/canônica. Essas recompensas foram de no máximo 1,75 ETH por ommer e foram _além da_ recompensa emitida pelo bloco canônico. O processo de mineração era uma atividade economicamente intensiva, que historicamente exigia altos níveis de emissão de ETH para sustentar.
-
-### Emissão da camada de consenso {#cl-issuance-pre-merge}
-
-A [Beacon Chain](/history/#beacon-chain-genesis) foi lançada em 2020. Em vez de mineradores, ela é protegida por validadores usando a prova de participação. Essa cadeia foi iniciada por usuários do Ethereum depositando ETH, de uma forma em um contrato inteligente na Mainnet (a camada de execução), que a Beacon Chain escuta, creditando ao usuário com uma quantidade igual de ETH na nova cadeia. Até a Fusão ter acontecido, os validadores da Beacon Chain não estavam processando transações e essencialmente estavam chegando a um consenso sobre o estado do próprio pool de validadores.
-
-Os validadores da Beacon Chain são recompensados com ETH, por atestar o estado da cadeia e propor blocos. As recompensas (ou penalidades) são calculadas e distribuídas a cada época (a cada 6,4 minutos) com base no desempenho do validador. As recompensas do validador são **significativamente** menores do que as recompensas de mineração, que foram emitidas anteriormente na prova de trabalho (2 ETH a cada ~13,5 segundos), pois operar um nó de validação não é tão intenso economicamente e, portanto, não requer ou garante uma recompensa tão alta.
-
-### Análise da emissão pré-fusão {#pre-merge-issuance-breakdown}
-
-Fornecimento total de ETH: **~120.520.000 ETH** (até o momento do The Merge, em setembro de 2022)
-
-**Emissão da camada de execução:**
-
-- Foi estimada em 2,08 ETH a cada 13,3 segundos\*: **~4.930.000** ETH emitidos em um ano
-- Resultou em uma taxa de inflação de **aproximadamente 4,09%** (4,93 milhões por ano / 120,5 milhões no total)
-- \*Isso inclui os 2 ETH por bloco canônico, mais uma média de 0,08 ETH ao longo do tempo dos blocos ommer. Também usa 13,3 segundos, o tempo base alvo do bloco sem qualquer influência de uma [bomba de dificuldade](/glossary/#difficulty-bomb). ([Ver a fonte](https://bitinfocharts.com/ethereum/))
-
-**Emissão da camada de consenso:**
-
-- Usando um total de 14.000.000 ETH em stake, a taxa de emissão de ETH é de aproximadamente 1.700 ETH/dia ([Ver a fonte](https://ultrasound.money/))
-- Resultados em **~620.500** ETH emitidos em um ano
-- Resultou em uma taxa de inflação de **aproximadamente 0,52%** (620,5 mil por ano / 119,3 milhões no total)
-
-
-Taxa total de emissão anual (pré-fusão): ~4,61% (4,09% + 0,52%)
-~88,7% da emissão estava indo para mineradores na camada de execução (4,09 / 4,61 * 100)
-~11,3% estava sendo emitido para participantes na camada de consenso (0,52 / 4,61 * 100)
-
-
-## Pós-fusão (atualmente) {#post-merge}
-
-### Emissão da camada de execução {#el-issuance-post-merge}
-
-A emissão da camada de execução desde o The Merge é zero. A prova de trabalho já não é mais um meio válido de produção de blocos sob as regras atualizadas de consenso. Toda a atividade da camada de execução é empacotada em “blocos beacon”, que são publicados e atestados por validadores de prova de participação. As recompensas por atestar e publicar blocos beacon são contabilizadas separadamente na camada de consenso.
-
-### Emissão da camada de consenso {#cl-issuance-post-merge}
-
-A emissão da camada de consenso continua hoje, como antes do The Merge, com pequenas recompensas para os validadores que atestam e propõem blocos. As recompensas do validador continuam a acumular para _saldos do validador_ que são gerenciados na camada de consenso. Diferentemente das contas atuais (contas de "execução"), que podem fazer transações na rede principal, essas são contas Ethereum separadas que não podem realizar transações livremente com outras contas Ethereum. Os fundos nessas contas podem ser retirados apenas para um único endereço de execução especificado.
-
-Desde a melhoria Shanghai/Capella que ocorreu em abril de 2023, esses saques foram habilitados para os participantes (stakers). Os participantes são incentivados a remover seus _ganhos/recompensas (saldo superior a 32 ETH)_, pois esses fundos não contribuem para o peso da participação (que é de no máximo 32).
-
-Os participantes também podem optar por sair e sacar todo o saldo do validador. Para garantir que o Ethereum esteja estável, o número de validadores saindo simultaneamente é limitado.
-
-Aproximadamente 0,33% da contagem total de validadores pode sair em um dia específico. Por padrão, quatro (4) validadores podem sair por época (a cada 6,4 minutos ou 900 por dia). Um (1) validador adicional tem permissão para sair a cada 65.536 (216) validadores adicionais acima de 262.144 (218). Por exemplo, com mais de 327.680 validadores, cinco (5) podem sair por época (1.125 por dia). Com uma contagem total de validadores ativos acima de 393.216, sies (6) poderão sair, e assim por diante.
-
-À medida que mais validadores sacam, o número máximo de validadores que saem reduz gradualmente para um mínimo de quatro, para evitar intencionalmente que grandes quantidades desestabilizadoras de ETH participado sejam sacadas simultaneamente.
-
-### Detalhamento da inflação pós-fusão {#post-merge-inflation-breakdown}
-
-- Fornecimento total de ETH: **~120.520.000 ETH** (no momento do The Merge, em setembro de 2022)
-- Emissão da camada de execução: **0**
-- Emissão da camada de consenso: o mesmo que acima, **~0.52%** taxa de emissão anualizada (com 14 milhões de ETH totais em stake)
-
-
-Taxa total de emissão anualizada: ~0.52%
-Redução líquida na emissão anual de ETH: ~88,7% (4,61% - 0,52%) / 4,61% * 100)
-
-
-## A queima {#the-burn}
-
-A força oposta à emissão de ETH é a taxa em que o ETH é queimado. Para uma transação executar no Ethereum, a taxa mínima (conhecida como “taxa base”) deve ser paga, a qual flutua continuamente (bloco a bloco) dependendo da atividade da rede. A taxa é paga no ETH e é _necessária_ para que a transação seja considerada válida. Essa taxa é _queimada_ durante o processo de transação, removendo-a de circulação.
-
-
-A queima de taxas foi lançada com a atualização London em agosto de 2021 e permanece inalterada desde o The Merge.
-
-
-Além da queima de taxas implementada pela atualização London, os validadores também podem incorrer em penalidades por estarem offline ou, pior ainda, eles podem ser removidos por quebrar regras específicas que ameaçam a segurança da rede. Essas penalidades resultam na redução de ETH do saldo do validador, que não é recompensado diretamente para nenhuma outra conta, efetivamente queimando/retirando-o de circulação.
-
-### Calculando o preço médio do gás para deflação {#calculating-average-gas-price-for-deflation}
-
-Conforme discutido acima, a quantidade de ETH emitido em um determinado dia depende do total de ETH em stake. No momento da produção deste texto, isso equivale a aproximadamente 1.700 ETH/dia.
-
-Para determinar o preço médio do gás necessário para compensar completamente essa emissão, em um determinado período de 24 horas, começaremos calculando o número total de blocos em um dia, dado um tempo de bloco de 12 segundos:
-
-- `(1 bloco/12 segundos) * (60 segundos/minuto) = 5 blocos/minuto`
-- `(5 blocos/minuto) * (60 minutos/hora) = 300 blocos/hora`
-- `(300 blocos/hora) * (24 horas/dia) = 7.200 blocos/dia`
-
-Cada bloco tem como alvo `15x10^6 gás/bloco` ([mais sobre gás](/developers/docs/gas/)). Usando isso, podemos calcular o preço médio do gás (em unidades de gwei/gás), necessário para compensar a emissão, dada uma emissão diária total de ETH de 1.700 ETH:
-
-- `7.200 blocos/dia * 15x10^6 gás/bloco *`**`Y gwei/gás`**`* 1 ETH/ 10^9 gwei = 1.700 ETH/dia`
-
-Resolvendo para `Y`:
-
-- `Y = (1.700(10^9))/(7.200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (arredondamento para apenas dois dígitos significativos)
-
-Outra maneira de reorganizar esta última etapa seria substituir `1.700` por uma variável `X` que represente a emissão diária de ETH e simplificar o restante para:
-
-- `Y = (X(10^3)/(7.200 * 15)) = X/108`
-
-Podemos simplificar e escrever isso como uma função de `X`:
-
-- `f(X) = X/108` em que `X` é a emissão diária de ETH e `f(X)` representa o preço de gwei/gás necessário para compensar todos os ETH recém-emitidos.
-
-Assim, por exemplo, se `X` (emissão diária de ETH) aumentar para 1.800 com base no total de ETH em stake, `f(X)` (gwei necessário para compensar toda a emissão), então seria `17 gwei` (usando 2 dígitos significativos)
-
-## Leia mais {#further-reading}
-
-- [The Merge (A Fusão)](/roadmap/merge/)
-- [Ultrasound.money](https://ultrasound.money/) — _Painéis disponíveis para visualizar a emissão e queima de ETH em tempo real_
-- [Charting Ethereum Issuance](https://www.attestant.io/posts/charting-ethereum-issuance/) — _Jim McDonald 2020_
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/scaling/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/scaling/index.md
deleted file mode 100644
index 2b1bd543fc1..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/scaling/index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Escalar o Ethereum
-description: Rollups agrupam transações fora da cadeia, o que reduz os custos para o usuário. No entanto, a forma como os rollups usam recursos de dados atualmente é muito cara, o que limita o baixo custo das transações. Proto-Danksharding corrige isso.
-lang: pt-br
-image: /images/roadmap/roadmap-transactions.png
-alt: "Planejamento Ethereum"
-template: roadmap
----
-
-A escalabilidade do Ethereum é feita por meio de [camadas 2s](/layer-2/#rollups) (também conhecidas como rollups), que agrupam transações em lote e enviam o resultado para o Ethereum. Embora os rollups sejam até oito vezes mais baratos do que a rede principal do Ethereum, é possível otimizar ainda mais os rollups de forma a reduzir os custos para os usuários finais. Os rollups também dependem de alguns componentes centralizados que os desenvolvedores podem remover à medida que os rollups se desenvolvem.
-
-
-
-
Os rollups de hoje são cerca de5 a 20 vezes mais baratos do que a camada 1 do Ethereum
-
ZK-rollups em breve reduzirão as taxas em ~40-100x
-
As próximas alterações no Ethereum oferecerão ~100-1000x a mais de escalabilidade
-
Os usuários devem se beneficiar com transações que custam menos do que $0,001
-
-
-
-## Tornar os dados mais baratos {#making-data-cheaper}
-
-Os rollups coletam um grande número de transações, executam elas e enviam os resultados ao Ethereum. Isso gera muitos dados que precisam estar disponíveis abertamente para que qualquer pessoa possa executar as transações por conta própria e verificar se o operador de rollup foi honesto. Se alguém encontrar uma discrepância, pode abrir uma contestação.
-
-### Proto-Danksharding {#proto-danksharding}
-
-Historicamente, os dados de rollup têm sido armazenados de forma permanente no Ethereum, o que é caro. Mais de 90% do custo de transação que os usuários pagam em rollups se deve a esse armazenamento de dados. Para reduzir os custos de transação, podemos mover os dados para um novo armazenamento "blob" temporário. Os blobs são mais baratos porque não são permanentes; eles são excluídos do Ethereum assim que não são mais necessários. O armazenamento de dados de rollup a longo prazo passa a ser responsabilidade das pessoas que precisam deles, como operadores de rollup, exchanges, serviços de indexação, etc. A adição de transações de blob ao Ethereum faz parte de uma melhoria conhecida como "Proto-Danksharding".
-
-Com o Proto-Danksharding, é possível adicionar muitos blobs aos blocos de Ethereum. Isso permite outro aumento substancial (>100x) na taxa de transferência do Ethereum e uma redução nos custos de transação.
-
-### Danksharding {#danksharding}
-
-O segundo estágio da expansão dos dados de blob é complicado porque requer novos métodos para verificar se os dados de rollup estão disponíveis na rede e depende de [validadores](/glossary/#validator) que separam suas responsabilidades de [construção de blocos](/glossary/#block) e de proposta de blocos. Isso também exige uma maneira de provar criptograficamente que os validadores verificaram pequenos subconjuntos dos dados do blob.
-
-Essa segunda etapa é conhecida como [“Danksharding”](/roadmap/danksharding/). **É provável que ainda faltem vários anos** para que isso seja totalmente implementado. O Danksharding depende de outros desenvolvimentos, como a [separação da construção e da proposta de bloco](/roadmap/pbs), e novos designs de rede que permitem que a rede confirme, de maneira eficaz, que os dados estão disponíveis por meio de uma amostragem aleatória de alguns kilobytes por vez, conhecida como [amostragem de disponibilidade de dados (DAS)](/developers/docs/data-availability).
-
-Mais sobre Danksharding
-
-## Descentralização de rollups {#decentralizing-rollups}
-
-[Os rollups](/layer-2) já estão dimensionando o Ethereum. Um [ecossistema sofisticado de projetos de rollup](https://l2beat.com/scaling/tvl) está permitindo que os usuários façam transações de forma rápida e barata, com diversas garantias de segurança. Entretanto, os rollups foram inicializados usando sequenciadores centralizados (computadores que fazem todo o processamento e a agregação das transações antes de enviá-las ao Ethereum). Isso é vulnerável à censura, pois os operadores do sequenciador podem ser sancionados, subornados ou comprometidos de qualquer outra forma. Ao mesmo tempo, os [rollups variam](https://l2beat.com) na maneira como validam os dados recebidos. A melhor maneira é que os "provadores" enviem [provas de fraude](/glossary/#fraud-proof) ou provas de validade, mas nem todos os rollups já chegaram a esse nível. Mesmo os rollups que usam provas de validação/fraude utilizam um pequeno grupo de provadores conhecidos. Portanto, a próxima etapa essencial na escalabilidade do Ethereum é distribuir a responsabilidade pela execução de sequenciadores e provadores entre mais pessoas.
-
-Mais sobre rollups
-
-## Progresso atual {#current-progress}
-
-O Proto-Danksharding é o primeiro desses itens do roteiro a ser implementado como parte da melhoria da rede Cancun-Deneb ("Dencun"), em março de 2024. **É provavél que ainda faltem vários anos para o Danksharding completo**, já que isso depende de vários outros itens do roteiro serem concluídos primeiro. É provável que a descentralização da infraestrutura de rollup seja um processo gradual. Há muitos rollups diferentes que estão criando sistemas ligeiramente diferentes e que se descentralizarão totalmente a velocidades diferentes.
-
-[Mais informações sobre a melhoria da rede Dencun](/roadmap/dencun/)
-
-
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/security/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/security/index.md
deleted file mode 100644
index 15c0c8499f6..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/security/index.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Um Ethereum mais seguro
-description: O Ethereum é a plataforma de contrato inteligente mais segura e descentralizada que existe. Entretanto, ainda existem melhorias que podem ser feitas para que o Ethereum permaneça resiliente a qualquer nível de ataque no futuro.
-lang: pt-br
-image: /images/roadmap/roadmap-security.png
-alt: "Planejamento Ethereum"
-template: roadmap
----
-
-O**Ethereum já é uma plataforma muito segura** e descentralizada de [contrato inteligente](/glossary/#smart-contract). Entretanto, ainda há melhorias que podem ser feitas para que o Ethereum permaneça resiliente a todos os tipos de ataque no futuro. Isso inclui mudanças sutis na forma como os [clientes Ethereum](/glossary/#consensus-client) lidam com [blocos concorrentes](/glossary/#block), além de aumentar a velocidade com que a rede considera os blocos como ["finalizados"](/developers/docs/consensus-mechanisms/pos/#finality) (o que significa que eles não podem ser alterados sem perdas econômicas extremas para um invasor).
-
-Há também melhorias que tornam as transações de censura muito mais difíceis, fazendo com que os proponentes de blocos não consigam ver o conteúdo real de seus blocos e novas maneiras de identificar quando um cliente está censurando. Juntos, esses aperfeiçoamentos vão melhorar o protocolo de [prova de participação](/glossary/#pos) para que os usuários – de indivíduos a corporações – tenham confiança imediata em seus aplicativos, dados e ativos no Ethereum.
-
-## Saque de staking {#staking-withdrawals}
-
-A melhoria da [prova de trabalho](/glossary/#pow) para a prova de participação começou com os pioneiros do Ethereum fazendo "staking" de ETHs em um contrato de depósito. Esse ETH é utilizado para proteger a rede. Houve uma segunda atualização em 12 de abril de 2023 para permitir a retirada do ETH apostado. Desde então, os validadores podem apostar ou retirar ETH livremente.
-
-Leia sobre saques
-
-## Defesa contra ataques {#defending-against-attacks}
-
-Há aperfeiçoamentos que podem ser feitos no protocolo de prova de participação do Ethereum. Um deles é conhecido como [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), um algoritmo mais seguro de [fork](/glossary/#fork)-choice que dificulta certos tipos sofisticados de ataque.
-
-Reduzir o tempo que o Ethereum leva para [finalizar](/glossary/#finality) blocos proporcionaria uma melhor experiência ao usuário e evitaria ataques sofisticados de "reorganização", em que os invasores tentam reorganizar blocos muito recentes para obter lucro ou censurar determinadas transações. [**Finalidade de slot único (SSF)**](/roadmap/single-slot-finality/) é uma **maneira de minimizar o atraso na finalização**. No momento, há 15 minutos de blocos que um invasor poderia, teoricamente, convencer outros validadores a reconfigurar. Com a SSF, há 0. Os usuários, de indivíduos a aplicativos e corretoras, beneficiam-se da garantia rápida de que as transações não serão revertidas, e a rede se beneficia ao desativar toda uma classe de ataques.
-
-Leia sobre a finalidade de espaço único
-
-## Defesa contra a censura {#defending-against-censorship}
-
-A descentralização evita que indivíduos ou pequenos grupos de [validadores](/glossary/#validator) se tornem muito influentes. Novas tecnologias de participação podem ajudar a garantir que os validadores do Ethereum permaneçam o mais descentralizados possível e, ao mesmo tempo, defendê-los contra falhas de hardware, software e rede. Isso inclui software que compartilha as responsabilidades do validador em vários [nós](/glossary/#node). Isso é conhecido como **tecnologia de validador distribuído (DVT)**. Os[pools de staking](/glossary/#staking-pool) são incentivados a usar o DVT porque ele permite que vários computadores participem coletivamente da validação, acrescentando redundância e tolerância a falhas. Ela também divide as chaves do validador entre diversos sistemas, em vez de ter um único operador executando vários validadores. Isso torna mais difícil para os operadores desonestos coordenarem ataques ao Ethereum. Em geral, a ideia é obter benefícios de segurança ao executar validadores como _comunidades_, em vez de indivíduos.
-
-Leia sobre a tecnologia de validador distribuído
-
-A implementação da **separação entre proponente e construtor (PBS)** melhorará drasticamente as defesas internas do Ethereum contra a censura. A PBS permite que um validador crie um bloco e outro o transmita pela rede Ethereum. Isso garante que os ganhos dos algoritmos profissionais de construção de blocos que maximizam o lucro sejam compartilhados de forma mais justa em toda a rede, **impedindo que a participação se concentre** nos participantes institucionais de melhor desempenho ao longo do tempo. O proponente do bloco pode selecionar o bloco mais lucrativo oferecido por um mercado de construtores de blocos. Para censurar, um proponente de bloco geralmente teria que escolher um bloco menos lucrativo, o que seria **economicamente irracional e também óbvio para o restante dos validadores** na rede.
-
-Há potenciais complementos para a PBS, como transações criptografadas e listas de inclusão, que poderiam melhorar ainda mais a resistência do Ethereum à censura. Isso faz com que o construtor e o proponente do bloco não saibam quais são as transações reais incluídas nos respectivos blocos.
-
-Leia sobre a separação entre proponente e construtor
-
-## Proteção dos validadores {#protecting-validators}
-
-É possível que um invasor experiente identifique os próximos validadores e envie spam para impedi-los de propor blocos. Isso é conhecido como um ataque de **negação de serviço (DoS)**. A implementação da [**eleição de líder secreto (SLE)**](/roadmap/secret-leader-election) protegerá contra esse tipo de ataque ao impedir que os proponentes de blocos possam ser conhecidos antecipadamente. Isso funciona ao embaralhar continuamente um conjunto de compromissos criptográficos que representam os proponentes de blocos candidatos e utilizar a ordem deles para determinar qual validador é selecionado, de forma que apenas os validadores saibam a ordem com antecedência.
-
-Leia sobre a eleição do líder secreto
-
-## Progresso atual {#current-progress}
-
-As**melhorias de segurança no planejamento estão em etapas avançadas de pesquisa**, mas a implementação delas ainda deve demorar. As próximas etapas para view-merge, PBS, SSF e SLE são finalizar uma especificação e começar a criação de protótipos.
diff --git a/public/content/translations/pt-br/11) Roadmap/roadmap/user-experience/index.md b/public/content/translations/pt-br/11) Roadmap/roadmap/user-experience/index.md
deleted file mode 100644
index e2e7c342a4a..00000000000
--- a/public/content/translations/pt-br/11) Roadmap/roadmap/user-experience/index.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Melhoria da experiência do usuário
-description: Para a maioria das pessoas, ainda é complicado usar o Ethereum. Para incentivar a adoção em massa, o Ethereum precisa reduzir drasticamente as barreiras de entrada. Os usuários devem obter os benefícios do acesso descentralizado, sem permissão e resistente à censura ao Ethereum, mas isso precisa ser tão simples quanto usar um aplicativo web2 tradicional.
-lang: pt-br
-image: /images/roadmap/roadmap-ux.png
-alt: "Planejamento Ethereum"
-template: roadmap
----
-
-**O uso do Ethereum precisa ser simplificado**; desde o gerenciamento de [chaves](/glossary/#key) e [carteiras](/glossary/#wallet) até o início das transações. Para facilitar a adoção em massa, o Ethereum deve aumentar consideravelmente a facilidade de uso, permitindo que os usuários tenham acesso ao Ethereum sem que haja necessidade de permissão e resistência à censura, com a melhor experiência de uso de aplicativos [Web2](/glossary/#web2).
-
-## Além das frases sementes {#no-more-seed-phrases}
-
-As contas Ethereum são protegidas por um par de chaves utilizadas para identificar contas (chave pública) e assinar mensagens (chave privada). Uma chave privada é como uma senha mestra, ela permite acesso completo a uma conta Ethereum. Essa é uma maneira diferente de operar para pessoas que têm mais experiência com bancos e aplicativos Web2 e que gerenciam contas em nome de um usuário. Para que o Ethereum alcance a adoção em massa sem depender de terceiros centralizados, deve haver uma maneira direta e sem atritos para que um usuário assuma a custódia de seus ativos e mantenha o controle dos dados sem precisar compreender criptografia de chave pública-privada e gerenciamento de chaves.
-
-A solução para isso é usar carteiras de [contrato inteligente](/glossary/#smart-contract) para interagir com o Ethereum. As carteiras de contratos inteligentes criam maneiras de proteger as contas em caso de perda ou roubo de chaves oportunidades para uma melhor detecção e defesa contra fraudes e permitem que as carteiras obtenham novas funcionalidades. Embora existam carteiras de contratos inteligentes atualmente, elas são difíceis de desenvolver porque o protocolo Ethereum precisa oferecer um melhor suporte. Esse suporte adicional é conhecido como abstração de conta.
-
-Mais sobre abstração de contas
-
-## Nós para todos
-
-Os usuários que executam [nós](/glossary/#node) não precisam confiar em terceiros para o fornecimento de dados, e podem interagir de forma rápida, privada e sem necessidade de permissão com a [blockchain](/glossary/#blockchain) do Ethereum. Entretanto, a execução de um nó atualmente exige conhecimento técnico e espaço considerável em disco, o que significa que muitas pessoas precisam confiar em intermediários.
-
-Há várias melhorias que tornarão a execução dos nós muito mais fácil e sem a necessidade de muitos recursos. A forma como os dados são armazenados será alterada para usar uma estrutura mais eficiente em termos de espaço, conhecida como **Verkle Tree**. Além disso, com [statelessness](/roadmap/statelessness) (sem estado) ou [expiração de dados](/roadmap/statelessness/#data-expiry), os nós do Ethereum não precisarão armazenar uma cópia de todos os dados de estado do Ethereum, o que reduz drasticamente os requisitos de espaço em disco rígido. [Os nós leves](/developers/docs/nodes-and-clients/light-clients/) oferecerão muitos benefícios da execução de um nó completo, mas podem ser executados facilmente em celulares ou em aplicativos simples de navegador.
-
-Leia sobre Verkle Trees
-
-Com essas melhorias, as barreiras à execução de um nó são erradicadas de maneira eficaz. Os usuários se beneficiarão do acesso seguro e sem permissão ao Ethereum sem precisar sacrificar espaço perceptível em disco ou CPU no computador ou celular e, ao usarem aplicativos, não precisarão depender de terceiros para obter acesso a dados ou à rede.
-
-## Progresso atual {#current-progress}
-
-As carteiras de contratos inteligentes já estão disponíveis, mas são necessárias mais melhorias para torná-las o mais descentralizadas e sem permissão possível. A EIP-4337 é uma proposta desenvolvida, que não exige alteração no protocolo do Ethereum. O principal contrato inteligente necessário para o EIP-4337 foi **implantado em março de 2023**.
-
-**O princípio de não verificação de estado ainda está em fase de pesquisa** e é provável que ainda faltem vários anos para ser implementado. Há vários marcos no caminho para uma condição total sem estado, incluindo a expiração de dados, que podem ser implementados mais cedo. Outros itens do planejamento, como [Verkle Trees](/roadmap/verkle-trees/) e a [separação entre proponente e construtor](/roadmap/pbs/), precisam ser concluídas primeiro.
-
-As redes de testes de Verkle Trees já estão em funcionamento, e a próxima fase é a execução de clientes habilitados para Verkle Trees em redes de testes privadas e, em seguida, públicas. Você pode ajudar a acelerar o progresso por meio da implantação de contratos nas redes de testes ou da execução de clientes de rede de testes.
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/account-abstraction/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/account-abstraction/index.md
deleted file mode 100644
index 0b1c9c3962e..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/account-abstraction/index.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: Abstração de conta
-description: Uma visão geral dos planos do Ethereum para tornar as contas de usuário mais simples e seguras
-lang: pt-br
-summaryPoints:
- - A abstração da conta facilita muito a criação de carteiras de contratos inteligentes
- - As carteiras de contratos inteligentes facilitam muito o gerenciamento do acesso às contas do Ethereum
- - Chaves perdidas e expostas podem ser recuperadas usando vários backups
----
-
-# Abstração de conta {#account-abstraction}
-
-Os usuários interagem com o Ethereum por meio de **[contas de propriedade externa (EOAs)](/glossary/#eoa)**. Essa é a única maneira de iniciar uma transação ou executar um contrato inteligente. Isso limita a maneira como os usuários podem interagir com o Ethereum. Por exemplo, dificulta a realização de lotes de transações e exige que os usuários sempre mantenham um saldo de ETH para cobertura do gás.
-
-A abstração de contas é uma maneira de resolver esses problemas, permitindo que os usuários programem com flexibilidade mais segurança e melhores experiências de usuário nas respectivas contas. Isso pode ocorrer por meio da [melhoria de EOAs](https://eips.ethereum.org/EIPS/eip-3074) para que possam ser controladas por contratos inteligentes ou pela [melhoria de contratos inteligentes](https://eips.ethereum.org/EIPS/eip-2938) para que possam iniciar transações. Ambas as opções exigem alterações no protocolo Ethereum. Há também um terceiro caminho que envolve a adição de um [segundo sistema de transações separado](https://eips.ethereum.org/EIPS/eip-4337) para ser executado em paralelo ao protocolo existente. Independentemente da rota, o resultado é o acesso ao Ethereum por meio de carteiras de contratos inteligentes, seja com suporte nativo como parte do protocolo existente ou por meio de uma rede de transações complementar.
-
-As carteiras de contratos inteligentes oferecem muitos benefícios ao usuário, incluindo:
-
-- definição das próprias regras de segurança flexíveis
-- recuperação da conta, se o usuário perder as chaves
-- compartilhamento da segurança da conta entre dispositivos ou indivíduos confiáveis
-- pagamento do gás de outra pessoa ou solicitar o pagamento do respectivo gás a um terceiro
-- transações em lote juntas (por exemplo, aprovar e executar uma troca de uma só vez)
-- mais oportunidades para que os desenvolvedores de dApps e carteiras inovem as experiências do usuário
-
-Atualmente, esses benefícios não têm compatibilidade nativa porque apenas contas de propriedade externa ([EOAs](/glossary/#eoa)) podem iniciar transações. As EOAs são simplesmente pares de chaves públicas-privadas. Elas funcionam assim:
-
-- se você tiver a chave privada, poderá fazer _qualquer coisa_ de acordo com as regras da Máquina Virtual do Ethereum (EVM)
-- se você não tiver a chave privada, não poderá fazer _nada_.
-
-Se você perder as suas chaves, elas não poderão ser recuperadas, e as chaves roubadas dão aos ladrões acesso imediato a todos os fundos de uma conta.
-
-As carteiras de contratos inteligentes são a solução para esses problemas, mas atualmente são difíceis de programar porque, no final, qualquer lógica que elas implementem precisa ser traduzida em um conjunto de transações EOA antes que possam ser processadas pelo Ethereum. A abstração de conta permite que contratos inteligentes iniciem as próprias transações. Dessa forma, qualquer lógica que o usuário queira implementar poderá ser codificada na própria carteira de contrato inteligente e executada no Ethereum.
-
-Na realidade, é a abstração de contas que melhora o suporte a carteiras de contratos inteligentes, tornando-as mais fáceis de criar e mais seguras de usar. No final, com a abstração de conta, os usuários podem aproveitar todos os benefícios do Ethereum sem precisar conhecer ou se preocupar com a tecnologia subjacente.
-
-## Além das frases sementes {#beyond-seed-phrases}
-
-As contas de hoje são protegidas por meio de chaves privadas que são calculadas a partir de frases sementes. Qualquer pessoa que tenha acesso a uma frase semente pode descobrir facilmente a chave privada que protege uma conta e obter acesso a todos os ativos que ela protege. Se uma chave privada e uma frase semente forem perdidas, elas nunca poderão ser recuperadas e os ativos que elas controlam ficarão congelados para sempre. Proteger essas frases semente é difícil, mesmo para usuários experientes, e o phishing de frases semente é uma das maneiras mais comuns de enganar os usuários.
-
-A abstração de conta resolverá esse problema ao utilizar um contrato inteligente para manter ativos e autorizar transações. Esses contratos inteligentes podem ser decorados com lógica personalizada para torná-los tão seguros e adaptados ao usuário quanto possível. Em última análise, você ainda usa chaves privadas para controlar o acesso à sua conta, mas com redes de segurança que as tornam mais fáceis e seguras de gerenciar.
-
-Por exemplo, as chaves de backup podem ser adicionadas a uma carteira para que, se você perder ou expor acidentalmente a sua chave principal, ela possa ser substituída por uma nova e segura, com a permissão das chaves de backup. Você pode proteger cada uma dessas chaves de uma maneira diferente ou dividi-las entre guardiões confiáveis. Isso faz com que seja muito mais difícil para um ladrão obter controle total dos seus fundos. Da mesma forma, você pode adicionar regras à carteira para reduzir o impacto se sua chave principal for comprometida; por exemplo, você pode permitir que transações de baixo valor sejam verificadas por uma única assinatura, enquanto as transações de valor mais alto exigem a aprovação de vários signatários autenticados. Também existem outras formas em que carteiras de contratos inteligentes podem te ajudar a impedir a ação de ladrões, por exemplo, uma lista de permissões pode ser usada para bloquear todas as transações, a menos que sejam para um endereço confiável ou verificadas por várias de suas chaves pré-aprovadas.
-
-### Exemplos de lógica de segurança que podem ser incorporados em uma carteira de contrato inteligente:
-
-- **Autorização multisig**: você pode compartilhar credenciais de autorização entre várias pessoas ou dispositivos confiáveis. Em seguida, o contrato pode ser configurado de modo que as transações superiores a um valor predefinido exijam autorização de uma proporção específica (por exemplo, 3/5) das partes confiáveis. Por exemplo, transações de alto valor podem exigir a aprovação de um dispositivo móvel e de uma carteira de hardware, ou assinaturas de contas distribuídas a familiares confiáveis.
-- **Congelamento de conta**: se um dispositivo for perdido ou comprometido, a conta pode ser bloqueada a partir de outro dispositivo autorizado, protegendo os ativos do usuário.
-- **Recuperação de conta**: perdeu um dispositivo ou esqueceu uma senha? No paradigma atual, isso significa que os seus ativos podem ser congelados para sempre. Com uma carteira de contrato inteligente, você pode configurar uma lista de permissões de contas que podem autorizar novos dispositivos e redefinir o acesso.
-- **Definição de limites de transações**: especifique limites diários de transferência de valores da conta em um dia/semana/mês. Isso significa que, se um invasor obtiver acesso à sua conta, ele não poderá ficar com tudo de uma vez e você terá oportunidades de congelar e redefinir o acesso.
-- **Criar listas de permissões**: apenas permitir transações para determinados endereços que você sabe que são seguros. Isso significa que _mesmo que_ sua chave privada fosse roubada, o invasor só poderia enviar fundos para contas de destino que estão em sua lista. Essas listas de permissões exigiriam várias assinaturas para alterá-las, de modo que um invasor não pudesse adicionar seu próprio endereço à lista, a menos que tivesse acesso a várias de suas chaves de backup.
-
-## Melhor experiência do usuário {#better-user-experience}
-
-A abstração de conta permite uma **melhor experiência geral do usuário**, bem como uma **segurança reforçada**, porque adiciona suporte para carteiras de contratos inteligentes no nível do protocolo. O motivo mais importante para isso é que isso proporcionará aos desenvolvedores de contratos inteligentes, carteiras e aplicativos muito mais liberdade para inovar a experiência do usuário de maneiras que talvez ainda não possamos prever. Alguns aprimoramentos óbvios que ocorrerão com a abstração de contas incluem o agrupamento de transações para aumentar a velocidade e a eficiência. Por exemplo, uma simples troca deveria ser uma operação de um clique, mas atualmente é necessário assinar várias transações para aprovar o gasto de tokens individuais antes que a troca seja executada. A abstração da conta remove esse atrito ao permitir o agrupamento de transações. Além disso, a transação agrupada poderia aprovar exatamente o valor correto dos tokens exigidos para cada transação e, em seguida, revogar as aprovações após a conclusão da transação, o que oferece uma segurança adicional.
-
-O gerenciamento de gás também é muito aprimorado com a abstração de conta. Não só os aplicativos podem se oferecer para pagar as taxas de gás de seus usuários, mas as taxas de gás podem ser pagas em tokens além de ETH, o que libera os usuários da necessidade de manter um saldo de ETH para financiar as transações. Isso funcionaria por meio da troca de tokens do usuário por ETH no contrato e, em seguida, usar o ETH para pagar o gás.
-
-
-
-O gerenciamento de gás é um dos principais atritos para os usuários do Ethereum, principalmente porque o ETH é o único ativo que pode ser usado para pagar as transações. Imagine que você tem uma carteira com saldo USDC, mas sem ETH. Você não pode mover ou trocar esses tokens USDC porque não pode pagar o gás. Você também não pode trocar o USDC por ETH, porque isso custa gás. Para resolver o problema, você teria de enviar mais ETH para a sua conta a partir de uma corretora ou outro endereço. Com carteiras de contrato inteligentes, você pode simplesmente pagar o gás em USDC e liberar a conta. Você não precisa mais que manter um saldo de ETH em todas as suas contas.
-
-A abstração de conta também permite que desenvolvedores de dApps sejam criativos com o gerenciamento de gás. Por exemplo, você pode começar a pagar ao seu DEX favorito uma taxa fixa por mês para transações ilimitadas. As dApps podem se oferecer para pagar todas as suas taxas de gás em seu nome, como recompensa, pelo uso da plataforma ou como uma oferta de boas-vindas. Será muito mais fácil para os desenvolvedores realizarem inovações com relação ao gás quando houver compatibilidade com as carteiras de contratos inteligentes no nível do protocolo.
-
-
-
-As sessões confiáveis também são potencialmente transformadoras para experiências do usuário, especialmente para aplicativos como jogos, em que um grande número de pequenas transações pode precisar de aprovação em um curto espaço de tempo. Aprovar individualmente cada transação prejudicaria a experiência do jogo, mas uma aprovação permanente é insegura. Uma carteira de contrato inteligente pode aprovar transações específicas por um período fixo, até um valor específico ou apenas para endereços específicos.
-
-Também é interessante considerar como as compras poderiam mudar com a abstração da conta. Hoje, cada transação precisa ser aprovada e executada a partir de uma carteira pré-financiada com uma quantidade suficiente do token correto. Com a abstração da conta, a experiência poderia ser mais parecida com uma compra online conhecida, em que um usuário poderia colocar itens no "carrinho" e clicar uma vez para comprar tudo junto, e o contrato processaria toda a lógica exigida, não o usuário.
-
-Esses são apenas alguns exemplos de como as experiências do usuário podem ser aprimoradas pela abstração de contas, mas haverá muitos outros que ainda nem imaginamos. A abstração de contas libera os desenvolvedores das restrições dos EOAs atuais, permite que tragam os aspectos positivos da web2 para a web3 sem sacrificar a autocustódia e criar novas experiências de usuário inovadoras.
-
-## Como a abstração da conta será implementada? {#how-will-aa-be-implemented}
-
-Atualmente, existem carteiras de contratos inteligentes, mas a implementação é difícil porque a EVM não tem compatibilidade com as carteiras. Em vez disso, elas dependem do agrupamento ("enrolamento") de códigos relativamente complexos em torno de transações padrão da Ethereum. O Ethereum pode mudar isso ao permitir que contratos inteligentes iniciem transações, processando a lógica necessária em contratos inteligentes Ethereum em vez de fora da cadeia. Colocar lógica em contratos inteligentes também aumenta a descentralização do Ethereum, pois elimina a necessidade de "retransmissores" executados por desenvolvedores de carteiras para traduzir mensagens assinadas pelo usuário em transações regulares do Ethereum.
-
-
-
-O EIP-2771 introduz o conceito de meta-transações que permitem que terceiros paguem o custo do gás do usuário sem fazer alterações no protocolo Ethereum. A ideia é que as transações assinadas por um usuário sejam enviadas para um contrato "Encaminhador" (Forwarder). O encaminhador é uma entidade confiável que verifica se as transações são válidas antes de enviá-las a um retransmissor de gás. Isso é feito fora da cadeia, evitando a necessidade de pagar gás. O retransmissor de gás envia a transação para um contrato "Destinatário" (Recipient), pagando o gás necessário para tornar a transação executável no Ethereum. A transação é executada se o "Destinatário" conhecer e confiar no "Encaminhador". Esse modelo torna mais fácil para os desenvolvedores implementarem transações sem gás para os usuários.
-
-
-
-
-
-O EIP-4337 é o primeiro passo em direção ao suporte nativo à carteira de contrato inteligente de forma descentralizada, sem exigir alterações no protocolo Ethereum. Em vez de modificar a camada de consenso para oferecer suporte a carteiras de contrato inteligente, um novo sistema é adicionado em separado ao protocolo normal de transmissão de transações. Esse sistema de nível mais alto é construído em torno de um novo objeto chamado UserOperation, que empacota as ações de um usuário juntamente com as assinaturas relevantes. Esses objetos UserOperation são então transmitidos para um mempool dedicado, em que os validadores podem coletá-los em uma "transação de pacote". A transação de pacote representa uma sequência de muitas UserOperations individuais e pode ser incluída em blocos Ethereum, como uma transação normal, e seria coletada por validadores usando um modelo de seleção de maximização de taxas semelhante.
-
-A maneira como as carteiras funcionariam também mudaria no EIP-4337. Em vez de cada carteira reimplementar a lógica de segurança comum, mas complexa, essas funções seriam terceirizadas para um contrato de carteira global conhecido como "ponto de entrada". Isso processaria operações como pagamento de taxas e execução do código EVM para que os desenvolvedores de carteiras possam se concentrar em oferecer excelentes experiências ao usuário.
-
-Obs.: o contrato do ponto de entrada EIP 4337 foi implantado na rede principal do Ethereum em 1º de março de 2023. O contrato está disponível no Etherscan.
-
-
-
-
-
-O EIP-2938 visa atualizar o protocolo Ethereum introduzindo um novo tipo de transação, AA_TX_TYPE, que inclui três campos: nonce, target e data, em que nonce é um contador de transações, target é o endereço do contrato do ponto de entrada e data é o bytecode da EVM. Para executar essas transações, duas novas instruções (conhecidas como opcodes) precisam ser agregadas à EVM: NONCE e PAYGAS. O opcode NONCE rastreia a sequência da transação e o PAYGAS calcula e saca do saldo do contrato o gás necessário para executar a transação. Essas novas funcionalidades permitem que o Ethereum ofereça suporte a carteiras de contratos inteligentes de forma nativa, pois a infraestrutura necessária é incorporada ao protocolo do Ethereum.
-
-Observe que o protocolo EIP-2938 não está ativo no momento. A comunidade atualmente está a favor do EIP-4337, porque não exige alterações no protocolo.
-
-
-
-
-
-O EIP-3074 visa atualizar as contas de propriedade externa do Ethereum, permitindo a delegação do controle a um contrato inteligente. Isso significa que a lógica do contrato inteligente poderia aprovar transações originadas de um EOA. Isso permitiria recursos como o patrocínio de gás e transações em lote. Para isso funcionar, dois novos opcodes precisam ser agregados à EVM: AUTH e AUTHCALL. Com o EIP-3074, os benefícios de uma carteira de contrato inteligente são disponibilizados sem a necessidade de um contrato. Em vez disso, um tipo específico de contrato sem estado, sem confiança e não atualizável, conhecido como "invocador" (invoker), processa as transações.
-
-Observe que o protocolo EIP-3074 não está ativo no momento. A comunidade atualmente está a favor do EIP-4337, porque não exige alterações no protocolo.
-
-
-
-## Progresso atual {#current-progress}
-
-As carteiras de contratos inteligentes já estão disponíveis, mas são necessárias mais melhorias para torná-las o mais descentralizadas e sem permissão possível. O EIP-4337 é uma proposta desenvolvida que não exige nenhuma alteração no protocolo Ethereum, portanto, é possível que isso seja implementado rapidamente. Entretanto, as melhorias que alteram o protocolo Ethereum não estão em desenvolvimento ativo no momento. Portanto, ainda pode demorar muito para a implementação dessas alterações. Também é possível que EIP-4337 alcance a abstração da conta de uma maneira suficientemente adequada, e nenhuma alteração de protocolo será necessária.
-
-## Leitura adicional {#further-reading}
-
-- [erc4337.io](https://www.erc4337.io/)
-- [Discussão do painel sobre abstração de conta da Devcon Bogota](https://www.youtube.com/watch?app=desktop&v=WsZBymiyT-8)
-- ["Por que a abstração de contas é um agente de mudança para dApps", Devcon Bogota](https://www.youtube.com/watch?v=OwppworJGzs)
-- ["Abstração de conta ELI5", Devcon Bogota](https://www.youtube.com/watch?v=QuYZWJj65AY)
-- [Notas sobre o "Caminho para abstração de contas", Vitalik](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists)
-- [Publicação do blog de Vitalik sobre carteiras de recuperação social](https://vitalik.eth.limo/general/2021/01/11/recovery.html)
-- [Notas EIP-2938](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938)
-- [Documentação EIP-2938](https://eips.ethereum.org/EIPS/eip-2938)
-- [Notas EIP-4337](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a)
-- [Documentação EIP-4337](https://eips.ethereum.org/EIPS/eip-4337)
-- [Documentação EIP-2771](https://eips.ethereum.org/EIPS/eip-2771)
-- ["Fundamentos sobre abstração de contas" -- O que é abstração de contas, Parte I](https://www.alchemy.com/blog/account-abstraction)
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/danksharding/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/danksharding/index.md
deleted file mode 100644
index aa8ed3bb1f1..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/danksharding/index.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Danksharding
-description: Saiba mais sobre Proto-Danksharding e Danksharding, duas melhorias sequenciais para a escalabilidade do Ethereum.
-lang: pt-br
-summaryPoints:
- - Danksharding é uma melhoria em diversas fases para melhorar a escalabilidade e a capacidade do Ethereum.
- - A primeira fase, Proto-Danksharding, adiciona blobs de dados aos blocos
- - Os blods de dados oferecem uma maneira mais barata para os rollups publicarem dados no Ethereum e esses custos podem ser repassados aos usuários na forma de taxas de transação mais baixas.
- - Posteriormente, o Danksharding completo distribuirá a responsabilidade pela verificação dos blobs de dados em subconjuntos de nós, o que dimensionará ainda mais o Ethereum para mais de 100.000 transações por segundo.
----
-
-# Danksharding {#danksharding}
-
-**Danksharding** é como o Ethereum torna um blockchain verdadeiramente dimensionável, mas são necessárias diversas melhorias de protocolo para chegar a isso. **Proto-Danksharding** é uma etapa intermediária ao longo do caminho. Ambos têm como objetivo tornar as transações na Camada 2 o mais baratas possível para os usuários e devem dimensionar o Ethereum para >100.000 transações por segundo.
-
-## O que é Proto-Danksharding? {#what-is-protodanksharding}
-
-Proto-Danksharding, também conhecido como [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), é uma maneira para os [rollups](/layer-2/#rollups) adicionarem dados mais baratos aos blocos. O nome vem dos dois pesquisadores que propuseram a ideia: Dankrad Feist e Protolambda. Historicamente, rollups foram limitados em quão barato eles podem tornar as transações dos usuários pelo motivo de postarem suas transações em `CALLDATA`.
-
-Isso é caro porque é processado por todos os nós da Ethereum e permanece na cadeia para sempre, embora os rollups só precisem dos dados por um curto período. Proto-Danksharding introduz blobs de dados que podem ser enviados e anexados aos blocos. Os dados nessa bolhas não são acessíveis para a EVN e são automaticamente deletados depois de um período fixo (configurado para 4096 épocas, no tempo em que esse artigo foi escrito, ou cerca de 18 dias). Isso significa que os rollups podem enviar os dados de uma maneira muito mais barata e repassar a economia aos usuários finais na forma de transações mais baratas.
-
-
-
-Os rollups são uma forma de dimensionar o Ethereum por meio de transações em lote fora da cadeia e, em seguida, publicar os resultados no Ethereum. Um rollup é composto essencialmente de duas partes: dados e verificação de execução. Os dados são a sequência completa de transações que está sendo processada por um rollup para gerar a alteração de estado que está sendo publicada no Ethereum. A verificação da execução é a reexecução dessas transações por um participante honesto (um "provador") para garantir que a alteração de estado proposta está correta. Para realizar a verificação de execução, os dados da transação precisam estar disponíveis por tempo suficiente para que qualquer pessoa possa fazer o download e verificar. Isso significa que qualquer comportamento desonesto do sequenciador de rollup pode ser identificado e contestado pelo provador. Entretanto, os dados não precisam ficar disponíveis para sempre.
-
-
-
-
-
-Os rollups publicam compromissos com seus dados de transação na cadeia e também disponibilizam os dados reais em blobs de dados. Isso significa que os provadores podem verificar se os compromissos são válidos ou contestar os dados que acham que estão errados. No nível do nó, os blobs de dados são mantidos no cliente de consenso. Os clientes de consenso atestam que viram os dados e que eles foram propagados pela rede. Se os dados fossem mantidos para sempre, o volume desses clientes alcançaria um tamanho excessivo e seriam necessários grandes requisitos de hardware para a execução dos nós. Ao invés disso, os dados são automaticamente apagados do nó a cada 18 dias. As atestações de clientes de consenso demonstram que houve oportunidade suficiente para que os provadores verificassem os dados. Os dados reais podem ser armazenados fora da cadeia por operadores de rollup, usuários ou outros.
-
-
-
-### Como os dados do blob são verificados? {#how-are-blobs-verified}
-
-Os rollups publicam as transações que executam em blobs de dados. Também publicam um "compromisso" com os dados. Isso é feito por meio do ajuste de uma função polinomial aos dados. Em seguida, essa função pode ser avaliada em diversos pontos. Por exemplo, se definirmos uma função extremamente simples `f(x) = 2x-1`, poderemos avaliar essa função para `x = 1`, `x = 2`, `x = 3` com os resultados `1, 3, 5`. Um provador aplica a mesma função aos dados e a avalia nos mesmos pontos. Se os dados originais forem alterados, a função não será idêntica e, portanto, os valores avaliados em cada ponto também não serão. Na realidade, o compromisso e a prova são mais complicados porque estão "envolvidos" em funções criptográficas.
-
-### O que é KZG? {#what-is-kzg}
-
-KZG significa Kate-Zaverucha-Goldberg, os nomes dos três [autores originais](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) de um esquema que reduz um blob de dados a um pequeno ["compromisso" criptográfico](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html). O blob de dados enviado por um rollup precisa ser verificado para garantir que o comportamento do rollup seja correto. Isso envolve um provador que reexecuta as transações no blob para verificar se o compromisso foi válido. Isso é conceitualmente o mesmo que a maneira como os clientes de execução verificam a validade das transações do Ethereum na camada 1 por meio de provas de Merkle. KZG é uma prova alternativa que ajusta uma equação polinomial aos dados. O compromisso avalia equação polinomial em alguns pontos de dados secretos. Um provador ajustaria a mesma equação polinomial nos dados e a avaliaria com os mesmos valores, verificando se o resultado é o mesmo. Essa é uma maneira de verificar os dados que é compatível com as técnicas de conhecimento zero utilizadas por alguns rollups e, eventualmente, outras partes do protocolo Ethereum.
-
-### O que foi a cerimônia KZG? {#what-is-a-kzg-ceremony}
-
-A cerimônia KZG foi uma forma de muitas pessoas da comunidade Ethereum de gerar coletivamente uma sequência secreta de números aleatórios que poderia ser usada para verificar alguns dados. É muito importante que essa sequência de números não seja conhecida e não possa ser recriada por ninguém. Para garantir isso, cada pessoa que participou da cerimônia recebeu uma sequência do participante anterior. Essas pessoas então criaram alguns valores aleatórios novos (por exemplo, permitindo o navegador Web medir o movimento do mouse) e misturando esses valores novos ao valor anterior. O valor então era enviado ao próximo participante e destruído na máquina local. Enquanto cada pessoa na cerimônia fizesse isso honestamente, o valor final ficaria desconhecido por um atacante.
-
-A cerimônia do EIP-4844 KZG foi aberta ao público e dezenas de milhares de pessoas participaram para adicionar sua própria entropia (aleatoriedade). No total foram mais de 140.000 contribuições, fazendo dela a maior cerimônia desse tipo. Para que a cerimônia fosse prejudicada, 100% dos participantes teriam que ser ativamente desonestos. Do ponto de vista dos participantes, se eles sabem que foram honestos, não há necessidade de confiar em mais ninguém, pois eles sabem que protegeram a cerimônia (eles atenderam individualmente ao requisito de 1 de N participantes honestos).
-
-
-
-Quando um rollup posta um dado em uma bolha, eles fornecem uma "garantia" de que foi postado na blockchain. Esse compromisso é o resultado da avaliação de um ajuste polinomial aos dados em pontos específicos. Esses pontos são definidos pelos números aleatórios gerados na cerimônia KZG. Em seguida, os provadores podem avaliar o polinomial nos mesmos pontos para verificar os dados e, se chegarem aos mesmos valores, os dados estão corretos.
-
-
-
-
-
-Se alguém souber os locais aleatórios utilizados no compromisso, será fácil gerar um novo polinômio que se encaixe nesses pontos específicos (ou seja, uma "colisão"). Isso significa que podem adicionar ou remover dados do blob e ainda assim oferecer uma prova válida. Para evitar isso, em vez de indicar aos provedores os locais secretos reais, na verdade recebem os locais "embrulhados" em uma "caixa preta" criptográfica usando curvas elípticas. Os valores são realmente embaralhados de tal forma que os valores originais não podem passar por engenharia reversa, mas com alguns provadores e verificadores de álgebra inteligentes ainda é possível avaliar os polinômios nos pontos que representam.
-
-
-
-
- Nem o Danksharding, nem o Proto-Danksharding seguem o modelo tradicional de "sharding", que visa dividir a blockchain em várias partes. As cadeias de fragmentos não fazem mais parte do planejamento. Em vez disso, o Danksharding utiliza amostragem de dados distribuídos em blobs para dimensionar o Ethereum. Isso é muito mais simples de implementar. Às vezes, esse modelo é chamado de "fragmentação de dados".
-
-
-## O que é Danksharding? {#what-is-danksharding}
-
-O Danksharding é a realização completa da escalabilidade do rollup que começou com o Proto-Danksharding. O Danksharding oferecerá enormes quantidades de espaço ao Ethereum para que os rollups "entreguem" os dados de transação compactados. Isso significa que o Ethereum poderá suportar centenas de rollups individuais com facilidade e permitir a realização de milhões de transações por segundo.
-
-A maneira como isso funciona é expandindo os blobs anexados aos blocos de seis (6) no Proto-Danksharding para 64 no Danksharding completo. As demais alterações necessárias são melhorias na maneira como os clientes de consenso operam para que possam processar os novos blobs grandes. Diversas dessas alterações já estão no planejamento para outros fins, independentemente do Danksharding. Por exemplo, o Danksharding exige que a separação entre proponente e construtor tenha sido implementada. Essa é uma melhoria que separa as tarefas de construção e de proposição de blocos entre diferentes validadores. Da mesma forma, a amostragem de disponibilidade de dados é necessária para o Danksharding, mas também para o desenvolvimento de clientes muito leves que não armazenam muitos dados históricos ("clientes sem estado").
-
-
-
-A separação entre proponente e construtor é necessária para evitar que validadores individuais tenham que gerar compromissos e provas caras para 32 MB de dados de blob. Isso pressionaria muito os participantes internos e exigiria que eles investissem em hardware mais potente, o que prejudicaria a descentralização. Em vez disso, os construtores de blocos especializados assumem a responsabilidade por esse trabalho caro de computação. Em seguida, eles disponibilizam os blocos aos proponentes de blocos, para transmissão. O proponente do bloco simplesmente escolhe o bloco que é mais lucrativo. Qualquer pessoa pode verificar os blobs de uma maneira barata e rápida, o que significa que qualquer validador normal pode verificar se o comportamento dos construtores de blocos é honesto. Isso permite o processamento de blobs grandes sem sacrificar a descentralização. Os construtores de blocos com um comportamento indevido podem simplesmente ser expulsos da rede e removidos. Outros entrarão no lugar deles, porque a construção de blocos é uma atividade lucrativa.
-
-
-
-
-
-A amostragem de disponibilidade de dados é necessária para que os validadores verifiquem os dados de blob de uma maneira rápida e eficiente. Ao utilizar a amostragem de disponibilidade de dados, os validadores podem ter certeza de que os dados do blob estavam disponíveis e que houve um compromisso correto. Cada validador pode fazer uma amostragem aleatória de apenas alguns pontos de dados e criar uma prova, o que significa que nenhum validador precisa verificar todo o blob. Se algum dado estiver ausente, ele será identificado rapidamente e o blob será rejeitado.
-
-
-
-### Progresso atual {#current-progress}
-
-Ainda demora muitos anos para alcançar o Danksharding completo. Nesse meio tempo, a cerimônia KZG foi concluída com mais de 140.000 contribuições e o [EIP](https://eips.ethereum.org/EIPS/eip-4844) para Proto-Danksharding tinha amadurecido. Essa proposta tem sido implementada em todas as redes teste e foi posta em funcionamento na Mainnet através da atualização de rede Cancun-Deneb ("Dencun") em março de 2024.
-
-### Leitura adicional {#further-reading}
-
-- [Observações sobre o Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_
-- [Observações sobre Danksharding de Dankrad](https://notes.ethereum.org/@dankrad/new_sharding)
-- [Dankrad, Proto e Vitalik discutem sobre Danksharding](https://www.youtube.com/watch?v=N5p0TB77flM)
-- [A cerimônia KZG](https://ceremony.ethereum.org/)
-- [Palestra de Carl Beekhuizen na Devcon sobre configurações confiáveis](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube)
-- [Mais informações sobre a amostragem de disponibilidade de dados para blobs](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
-- [Dankrad Feist fala sobre compromissos e provas de KZG](https://youtu.be/8L2C6RDMV9Q)
-- [Compromissos polinomiais KZG](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/dencun/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/dencun/index.md
deleted file mode 100644
index 283bc974c66..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/dencun/index.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Cancun-Deneb (Dencun) FAQ
-description: Questões mais frequentes sobre a atualização de rede Cancun-Deneb (Dencun)
-lang: pt-br
----
-
-# Cancun-Deneb (Dencun) {#dencun}
-
-Cancun-Deneb (Dencun) é uma atualização na rede Ethereum, que ativa o **Proto-Danksharding (EIP-4844)**, introduzindo blobs de dados temporários para armazenamento mais barato em rollups de [camada 2 (L2)](/glossary/#layer-2).
-
-Um novo tipo de transação que permite fornecedores de rollup armazenarem dados de uma maneira mais eficiente em relação ao custo, o que é conhecido como "bolhas." As bolhas ficam disponíveis para a rede em torno de 18 dias (mais precisamente, 4096 [épocas](/glossary/#epoch)). Depois desse período as bolhas são removidas da rede, mas as aplicações ainda podem verificar a validade dos dados delas usando provas.
-
-Isso reduz significativamente o custo dos rollups, limita o crescimento da cadeia e ajuda a aguentar mais usuários enquanto mantém a segurança e um conjunto descentralizado de nós operadores.
-
-## Quando nós esperamos que rollups tenham taxas menores devido ao Proto-Danksharding? {#when}
-
-- Essa atualização foi ativada na época 269568, em **13-Mar-24 às 13:55PM (UTC)**
-- Todos os provedores de rollup mais conhecidos, como Arbitrum ou Optimism, sinalizaram que bolhas serão suportadas imediatamente após a atualização
-- O prazo para suporte ao rollup individual pode variar, pois cada provedor atualiza seus sistemas para tirar vantagem do novo espaço de bolha
-
-## Como ETH pode ser convertido depois do hard fork? {#scam-alert}
-
-- **Nenhuma ação será necessária para seu ETH**: Depois da atualização Dencun na Ethereum não há necessidade de converter or atualizar seu ETH. Seu saldo de conta irá permanecer o mesmo e o ETH que você tem atualmente continuará acessível na sua forma existente depois do hard fork.
-- **Atenção aos Golpes!** **qualquer pessoa que te instrua a "atualizar" seu ETH está tentando aplicar um golpe em você.** Você não precisa fazer nada em relação a essa atualização. Seus ativos não serão afetados de forma nenhuma. Lembre, estar informado(a) é a melhor defesa contra golpes.
-
-[Mais sobre como reconhecer e evitar golpes](/segurança/)
-
-## Qual problema a atualização de rede Dencun está resolvendo? {#network-impact}
-
-Dencun primeiro soluciona a questão da **escalabilidade** (lidar com mais usuários e mais transações) com **taxas acessíveis** enquanto **mantém a descentralização** da rede.
-
-A comunidade Ethereum está optando por uma abordagem "centrada em rollup" para o seu crescimento, essa abordagem coloca rollups de camada 2 como a principal forma de lidar com mais usuários de forma segura.
-
-Redes rollup gerenciam o _processamento_ (ou "execução") das transações separadamente da Mainnet e então publicam uma prova criptográfica e/ou os dados comprimidos dos resultados das transações de volta para a Mainnet para que sejam gravados. Armazenar essas provas tem um custo (na forma de [gas](/glossary/#gas)), o qual, antes do Proto-Danksharding, tinha de ser armazenado de forma permanente por todos os operadores de nós da rede, sendo essa uma tarefa de custo elevado.
-
-A introdução do Proto-Danksharding na atualização Dencun adiciona um armazenamento de dados mais barato para essas provas por somente requisitar aos operadores de nó que armazenem esses dados por aproximadamente 18 dias, depois dos quais esses dados podem ser removidos de forma segura para prevenir o aumento dos requisitos de hardware. Como os rollups têm tipicamente um período para saque de 7 dias, seus modelos de segurança continuam sem modificações enquanto as bolhas estiverem disponíveis na L1 durante esse período. A janela de remoção de 18 dias cria um divisor importante para esse período.
-
-[Mais sobre escalonando a Ethereum](/roadmap/scaling/)
-
-## Como os dados antigos da bolha são acessados? {#historical-access}
-
-Enquanto os nós regulares da Ethereum sempre irão armazenar o _estado atual_ da rede, dados históricos da bolha podem ser descartados em aproximadamente 18 dias após sua introdução. Antes de descartar esses dados a Ethereum assegura que eles estejam disponíveis para todos os participantes da rede, permitindo tempo para:
-
-- As partes interessadas possam fazer o download e armazenar os dados.
-- Conclusão de todos os períodos de desafio do rollup.
-- Finalização das transações do rollup.
-
-Dados _históricos_ da bolha podem ser desejados por diversos motivos e podem ser armazenados e acessados usando vários protocolos descentralizados:
-
-- **Protocolos de indexação de terceiros**, como o The Graph, armazenam esses dados através de uma rede descentralizada de operadores de nó incentivada por mecanismos criptoeconômicos.
-- **BitTorrent** é um protocolo descentralizado onde voluntários(as) podem armazenar e distribuir esses dados para outras pessoas.
-- **[Rede portal da Ethereum](/developers/docs/networking-layer/portal-network/)** tem o objetivo de prover acesso a todos os dados da Ethereum através de uma rede descentralizada de operadores de nó distribuindo dados entre os(as) participantes de forma semelhante ao BitTorrent.
-- **Usuários individuais** sempre são livres para armazenar suas próprias cópias de quaisquer dados que desejarem para referência histórica.
-- **Provedores de rollup** são incentivados a armazenar esses dados para trazer melhorias para a experiência do usuário do rollup.
-- **Exploradores de bloco** tipicamente executam nós de arquivo que indexam e armazenam toda essa informação para facilitar a referência histórica, acessível para usuários via uma interface Web.
-
-É importante lembrar que a recuperação de estados do passado opera em um \***modelo de confiança 1-de-N**. Isso significa que você precisa somente de _uma única fonte confiável_ para verificar a validade desses dados usando o estado atual da rede.
-
-## Como essa atualização contribui para o plano de ação mais amplo da Ethereum? {#roadmap-impact}
-
-O Proto-Danksharding prepara o caminho para a total implementação do [Danksharding](/roadmap/danksharding/). O Danksharding é feito para distribuir o armazenamento dos dados de rollup através dos operadores de nó, para que cada operador gerencie somente uma pequena parte do total desses dados. Essa distribuição aumentará o número de bolhas de dados por bloco, o que é essencial no escalonamento da Ethereum para gerenciar mais usuários e transações.
-
-Essa escalonabilidade é crucial para [suportar bilhões de usuários na Ethereum](/roadmap/scaling/) com taxas acessíveis e aplicações mais avançadas, enquanto se mantém uma rede descentralizada. Sem essas mudanças, as demandas de hardware para os operadores de nó iriam se agravar, levando à necessidade de uso de um equipamento cada vez mais caro. Isso poderia excluir pequenos operadores pelo fator preço, resultando em uma concentração do controle de rede entre alguns grandes operadores, o que iria contra o princípio da descentralização.
-
-## Essa atualização atinge todos os clientes nos mecanismos de consenso e clientes validadores da Ethereum? {#client-impact}
-
-Sim, o Proto-Danksharding (EIP-4844) requer atualizações tanto para os clientes de execução quanto para os clientes de consenso. Todos os clientes da Ethereum têm versões lançadas que são comportam a atualização. Para manter a sincronização com a rede Ethereum após a atualização, os operadores de nó precisam assegurar que eles estão executando uma versão habilitada do cliente. Perceba que a informação sobre os lançamentos de clientes é sensível no tempo, e os usuários deveriam usar como referência as últimas atualizações para os detalhes mais atuais. [Veja detalhes sobre lançamentos de clientes habilitados](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases).
-
-Os clientes de consenso gerenciam o software _validador_, o qual teve tudo atualizado para acomodar a atualização.
-
-## Como a Cancun-Deneb (Dencun) afeta a Goerli ou outras redes de teste da Ethereum? {#testnet-impact}
-
-- Devnets, Goerli, Sepolia e Holesky, todas passaram pela atualização Dencun e têm o Proto-Danksharding em funcionamento total
-- Desenvolvedores(as) de rollup podem usar essas redes para testar o EIP-4844
-- A maioria dos usuários irá continuar sem ser afetada por essa mudança em cada rede de teste
-
-## Todas as transações nas camadas L2 agora irão utilizar o espaço bolha temporário ou você poderá escolher? {#calldata-vs-blobs}
-
-Transações rollup na Camada 2 (L2) da Ethereum têm a opção de usar dois tipos de armazenamento de dados: espaço bolha temporário ou calldata permanente para contratos inteligentes. O espaço bolha é uma escolha econômica, fornecendo um armazenamento temporário com um custo menor. Ele garante a disponibilidade dos dados para todos os períodos de desafio necessários. Por sua vez, o calldata do contrato inteligente oferece um armazenamento permanente, mas tem um custo maior.
-
-A decisão de utilizar o espaço bolha ou calldata é feita principalmente pelos provedores de rollup. Eles baseiam essa decisão pela demanda atual por espaço bolha. Se o espaço bolha está com alta demanda, rollups podem optar por calldata para assegurar que os dados são publicados de maneira oportuna.
-
-Enquanto é teoricamente possível para os usuários escolherem seu tipo de armazenamento preferido, geralmente são os provedores de rollup que gerenciam essa escolha. Oferecer essa opção para os usuários iria adicionar complexidade, particularmente em transações envolvendo rentabilidade. Para detalhes específicos sobre essa escolha, usuários devem se referir a documentação fornecida por cada provedor de rollup.
-
-## O 4844 irá reduzir o gas na L1? {#l1-fee-impact}
-
-Não muito. Um novo mercado de gas foi introduzido exclusivamente para o espaço bolha, para uso pelos provedores de rollup. _Apesar das taxas na L1 poderem ser reduzidas pela redução da carga dos dados do rollup para as bolhas, essa atualização foca na redução das taxas na L2. Redução das taxas na L1 (Mainnet) podem ocorrer como um efeito de segunda ordem com menor alcance._
-
-- A redução do gas na L1 será proporcional à adoção/uso dos dados de bolha pelos provedores de rollup
-- O gas na L1 provavelmente irá se manter competitivo para atividades não relacionadas a rollup
-- Rollups que adotarem o uso do espaço bolha utilizarão menos gas na L1, ajudando a abaixar as taxas de gas para baixo em um curto período
-- O espaço bolha ainda é limitado, então se as bolhas contidas em um bloco estiverem saturadas/cheias os rollups podem solicitar a publicação dos seus dados como dados permanentes durante esse período, o que iria aumentar os preços de gas na L1 e L2
-
-## Isso irá reduzir as taxas em outras blockchains da camada 1 da EVM? {#alt-l1-fee-impact}
-
-Não. Os benefícios do Proto-Danksharding são específicos para os rollups da camada 2 da Ethereum que armazenem suas provas na camada 1 (Mainnet).
-
-Ser compatível com a Máquina Virtual Ethereum (EVM) não significa que uma rede terá qualquer benefício dessa atualização. Redes que operam de forma independente da Ethereum (sejam ou não compatíveis com a EVM) não armazenam seus dados na Ethereum e não terão nenhum benefício dessa atualização.
-
-[Mais sobre rollups da camada 2](/layer-2/)
-
-## Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner}
-
-
-
-_Desvendando o Escalonamento da Ethereum, EIP-4844 -- Finematics _
-
-
-
-_Espaço bolha 101 com Domothy -- Bankless_
-
-## Leitura adicional {#further-reading}
-
-- [EIP4844.com](https://www.eip4844.com/)
-- [EIP-4844: Transações bolha fragmentadas (Proto-Danksharding)](https://eips.ethereum.org/EIPS/eip-4844)
-- [Anúncio da Mainnet Dencun](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _Blog da Fundação Ethereum_
-- [O guia Hitchhiker's para a Ethereum: Proto-Danksharding](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _Jon Charbonneau_
-- [Proto-Danksharding FAQ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_
-- [Uma explicação em profundidade do EIP-4844: O núcleo da atualização Cancun](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c) - _Ebunker_
-- [AllCoreDevs Atualização 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _Tim Beiko_
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/pbs/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/pbs/index.md
deleted file mode 100644
index f349fe81709..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/pbs/index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Separação de Proponente-Construtor
-description: Saiba como e por que os validadores do Ethereum dividirão suas responsabilidades de construção e transmissão de blocos.
-lang: pt-br
----
-
-# Separação de Proponente-Construtor {#proposer-builder-separation}
-
-Os validadores atuais do Ethereum criam _e_ transmitem blocos. Eles agrupam as transações de que tomaram conhecimento por meio da rede de transmissão e as empacotam em um bloco que é enviado a pares na rede Ethereum. A **separação entre proponente e construtor (PBS)** divide essas tarefas entre diversos validadores. Os construtores de blocos se tornam responsáveis por criar blocos e oferecê-los ao proponente de blocos em cada espaço. O proponente de blocos não pode ver o conteúdo do bloco, ele simplesmente escolhe o mais lucrativo e paga uma taxa ao construtor do bloco antes de enviar o bloco aos seus pares.
-
-Essa é uma importante melhoria por diversos motivos. Primeiro, cria oportunidades para evitar a censura das transações no nível do protocolo. Em segundo lugar, evita que validadores amadores sejam superados por participantes institucionais que podem otimizar melhor a lucratividade da construção de blocos. Em terceiro lugar, ajuda na escalabilidade do Ethereum, permitindo melhorias do Danksharding.
-
-## PBS e resistência à censura {#pbs-and-censorship-resistance}
-
-A separação entre os construtores e os proponentes de blocos faz com que seja muito mais difícil para os construtores de blocos censurar as transações. Isso ocorre porque é possível adicionar critérios de inclusão relativamente complexos que garantem que não houve censura antes da proposição do bloco. Como o proponente do bloco é uma entidade separada do construtor do bloco, ele pode assumir o papel de protetor contra censurar construtores de blocos.
-
-Por exemplo, podem ser introduzidas listas de inclusão para que, quando os validadores souberem das transações, mas não as virem incluídas nos blocos, possam impô-las como obrigatórias no próximo bloco. A lista de inclusão é gerada a partir do mempool local (a lista de transações conhecidas) dos proponentes do bloco e enviada aos pares imediatamente antes da proposição de um bloco. Se alguma das transações da lista de inclusão estiver faltando, o proponente poderá rejeitar o bloco, adicionar as transações faltantes antes de propô-lo, ou propô-lo e permitir que ele seja rejeitado por outros validadores assim que o receberem. Há também uma versão potencialmente mais eficiente dessa ideia que afirma que os construtores devem utilizar totalmente o espaço de bloco disponível e, se não o fizerem, as transações serão adicionadas a partir da lista de inclusão do proponente. Essa ainda é uma área de pesquisa ativa e a configuração ideal das listas de inclusão ainda não foi determinada.
-
-[Mempools criptografados](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) também pode impossibilitar que os criadores e proponentes saibam quais transações estão sendo incluídas em um bloco até que o bloco já tenha sido transmitido.
-
-
-
-Organizações poderosas podem pressionar os validadores a censurar transações de ou para determinados endereços. Os validadores cumprem essa pressão detectando endereços na lista negra em seu pool de transações e omitindo-os dos blocos que propõem. Depois da PBS, isso não será mais possível, porque os proponentes de blocos não saberão quais transações estão transmitindo em seus blocos. Pode ser importante que indivíduos ou aplicativos específicos estejam em conformidade com as regras de censura, por exemplo, quando isso se torna uma lei na respectiva região. Nesses casos, a conformidade ocorre no nível do aplicativo, enquanto o protocolo permanece sem permissão e sem censura.
-
-
-
-## PBS e MEV {#pbs-and-mev}
-
-**Valor máximo extraível (MEV)** se refere a validadores que maximizam a lucratividade ao ordenar transações favoravelmente. Exemplos comuns incluem trocas de arbitragem de swaps em corretoras descentralizadas (por exemplo, antecipação de uma grande venda ou compra) ou a identificação de oportunidades para liquidar posições de DeFi. Maximizar o MEV exige conhecimento técnico sofisticado e software personalizado anexado a validadores comuns, o que faz com que seja muito mais provável que os operadores institucionais superem os validadores e amadores individuais na extração do MEV. Isso significa que os retornos das participações provavelmente serão maiores com operadores centralizados, criando uma força centralizadora que desincentiva a participação interna.
-
-O PBS resolve esse problema ao reconfigurar a economia do MEV. Em vez de o proponente do bloco fazer sua própria pesquisa de MEV, ele simplesmente escolhe um bloco dentre os muitos oferecidos pelos construtores de blocos. Os construtores de blocos podem ter feito uma extração sofisticada do MEV, mas a recompensa vai para o proponente de bloco. Isso significa que, mesmo que um pequeno grupo de construtores de blocos especializados domine a extração do MEV, a recompensa pode ir para qualquer validador na rede, incluindo participantes internos individuais.
-
-
-
-Os indivíduos poderiam ser incentivados a realizar participações com pools em vez de por conta própria devido às recompensas maiores oferecidas por estratégias sofisticadas de MEV. Separar a construção do bloco da proposta do bloco significa que o MEV extraído será distribuído entre mais validadores, em vez de ser centralizado no pesquisador de MEV mais eficiente. Ao mesmo tempo, permitir a existência de construtores de blocos especializados retira o ônus da construção de blocos dos indivíduos e também evita que roubem o MEV, o que maximiza o número de validadores individuais e independentes que podem verificar se os blocos são honestos. O conceito importante é a "assimetria entre provador e verificador", que se refere à ideia de que a produção centralizada de blocos é aceitável, desde que haja uma rede eficiente e descentralizada ao máximo de validadores capazes de provar que os blocos são honestos. A descentralização é um meio, não um objetivo fina. O que queremos são blocos honestos.
-
-
-## PBS e Danksharding {#pbs-and-danksharding}
-
-Danksharding é a maneira pela qual o Ethereum será dimensionado para >100.000 transações por segundo e minimizará as taxas para usuários de rollup. Ele depende da PBS porque aumenta a carga de trabalho dos construtores de blocos, que precisarão calcular provas de até 64 MB de dados de rollup em menos de 1 segundo. Isso provavelmente exigirá construtores especializados que possam dedicar um hardware bastante considerável à tarefa. Entretanto, na situação atual, o desenvolvimento de blocos pode se tornar cada vez mais centralizado em torno de operadores mais sofisticados e poderosos, devido à extração de MEV. A separação entre proponente e construtor é uma forma de aceitar essa realidade e evitar que exerça uma força centralizadora na validação do bloco (a parte importante) ou na distribuição das recompensas de participação. Um grande benefício adicional é que os construtores de blocos especializados também estão dispostos e têm a capacidade de calcular as provas de dados necessárias para o Danksharding.
-
-## Progresso atual {#current-progress}
-
-A PBS está em uma etapa avançada de pesquisa, mas ainda há algumas questões importantes de design que precisam ser resolvidas antes da abordagem poder ser prototipada em clientes Ethereum. Ainda não há uma especificação finalizada. Isso significa que a PBS está provavelmente a um ano de distância ou mais. Confira o [estado da pesquisa](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) mais recente.
-
-## Leitura adicional {#further-reading}
-
-- [Estado da pesquisa: resistência à censura na PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
-- [Designs de mercado de taxas compatíveis com a PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
-- [PBS e resistência à censura](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions)
-- [Listas de inclusão](https://notes.ethereum.org/@fradamt/H1ZqdtrBF)
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/secret-leader-election/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/secret-leader-election/index.md
deleted file mode 100644
index 08c043a4484..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/secret-leader-election/index.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Eleição de líder secreto
-description: Explicação de como a eleição de líder secreto pode ajudar a proteger os validadores contra ataques
-lang: pt-br
-summaryPoints:
- - O endereço IP dos proponentes de blocos pode ser conhecido antecipadamente, o que os torna vulneráveis a ataques
- - A eleição de líder secreto oculta a identidade dos validadores para que eles não possam ser conhecidos antecipadamente
- - Uma extensão dessa ideia é tornar a seleção do validador aleatória em cada espaço.
----
-
-# Eleição de líder secreto {#single-secret-leader-election}
-
-No mecanismo atual de consenso baseado em [prova de participação](/developers/docs/consensus-mechanisms/pos), a lista de proponentes de blocos futuros é pública e é possível mapear os endereços IP. Isso significa que os invasores podem identificar quais validadores devem propor um bloco e atacá-los com um ataque de negação de serviço (DOS) que os impeça de propor o bloco a tempo.
-
-Isso pode criar oportunidades de lucro para um invasor. Por exemplo, um proponente de bloco selecionado para o espaço `n+1` poderia aplicar um ataque de DoS contra o proponente no espaço `n` para que perca a oportunidade de propor um bloco. Isso permitiria que o proponente do bloco atacante extraísse o MEV de ambos os espaços ou pegasse todas as transações que deveriam ter sido divididas em dois blocos e, em vez disso, as incluísse em um só, ganhando todas as taxas associadas. É provável que isso afete mais os validadores internos do que os validadores institucionais experientes, que podem usar métodos mais avançados para se proteger de ataques de DOS e, portanto, podem ser uma força centralizadora.
-
-Há várias soluções para esse problema. Uma delas é a [tecnologia de validador distribuído](https://github.com/ethereum/distributed-validator-specs), que visa distribuir as várias tarefas relacionadas à execução de um validador entre várias máquinas, com redundância, de modo que seja muito mais difícil para um invasor impedir que um bloco seja proposto em um espaço específico. Entretanto, a solução mais eficiente é a **eleição de um único líder secreto (Single Secret Leader Election, SSLE)**.
-
-## Eleição secreta de um único líder {#secret-leader-election}
-
-Na SSLE, uma criptografia inteligente é usada para garantir que apenas o validador selecionado saiba que foi selecionado. Isso funciona fazendo com que cada validador envie um compromisso com um segredo que todos compartilham. Os compromissos são embaralhados e reconfigurados para que ninguém possa mapear compromissos a validadores, mas cada validador sabe qual compromisso pertence a ele. Em seguida, um compromisso é escolhido aleatoriamente. Se um validador detectar que o compromisso dele foi escolhido, ele saberá que é a vez dele de propor um bloco.
-
-A principal implementação dessa ideia é chamada [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Funciona da seguinte forma:
-
-1. Os validadores se comprometem com um segredo compartilhado. O esquema de compromisso é projetado de forma que possa ser vinculado a uma identidade de validador, mas também randomizado para que nenhum terceiro possa fazer engenharia reversa do vínculo e associar um compromisso específico a um validador específico.
-2. No início de uma época, o RANDAO é utilizado para escolher um conjunto aleatório de 16.384 validadores para uma amostra de compromissos.
-3. Para os próximos 8182 espaços (1 dia), os proponentes do bloco embaralham e randomizam um subconjunto dos compromissos usando a respectiva entropia privada.
-4. Após o término do embaralhamento, o RANDAO é usado para criar uma lista ordenada dos compromissos. Essa lista é mapeada para espaços Ethereum.
-5. Os validadores observam que o compromisso está vinculado a um espaço específico e, quando esse espaço chega, eles propõem um bloco.
-6. Repita essas etapas para que a atribuição de compromissos aos espaços esteja sempre muito à frente do espaço atual.
-
-Isso impede que os invasores saibam com antecedência qual validador específico proporá o próximo bloco, evitando a possibilidade de ataques DoS.
-
-## Eleição de líder secreto não único (SnSLE) {#secret-non-single-leader-election}
-
-Há também uma proposta separada que visa criar um cenário em que os validadores têm uma chance aleatória de propor um bloco em cada espaço, de forma semelhante à maneira como a proposta de bloco foi decidida na prova de trabalho, conhecida como **eleição de líder secreto não único (secret non-single leader election, SnSLE)**. Uma maneira simples de fazer isso é utilizar a função RANDAO usada para selecionar validadores aleatoriamente no protocolo atual. A ideia do RANDAO é que um número suficientemente aleatório seja gerado pela combinação de hashes enviados por diversos validadores independentes. Na SnSLE, esses hashes poderiam ser utilizados para escolher o próximo proponente de bloco, por exemplo, ao escolher o hash de menor valor. O intervalo de hashes válidos pode ser restringido para ajustar a probabilidade de validadores individuais serem selecionados em cada espaço. Ao declarar que o hash deve ser inferior a `2^256 * 5 / N`, em que `N` é o número de validadores ativos, a possibilidade de qualquer validador individual ser selecionado em cada espaço seria de `5/N`. Nesse exemplo, haveria uma chance de 99,3% de pelo menos um proponente gerar um hash válido em cada espaço.
-
-## Progresso atual {#current-progress}
-
-SSLE e SnSLE estão ambas em fase de pesquisa. Ainda não há especificações finalizadas para nenhuma das ideias. A SSLE e a SnSLE são propostas concorrentes que não podem ser implementadas conjuntamente. Antes da implementação, elas precisam de mais pesquisa e desenvolvimento, criação de protótipos e implementação em redes de testes públicas.
-
-## Leitura adicional {#further-reading}
-
-- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/single-slot-finality/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/single-slot-finality/index.md
deleted file mode 100644
index ff826aae6d8..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/single-slot-finality/index.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Finalidade de espaço único
-description: Explicação da finalidade de espaço único
-lang: pt-br
----
-
-# Finalidade de espaço único {#single-slot-finality}
-
-Demora aproximadamente 15 minutos para finalizar um bloco do Ethereum. Entretanto, podemos fazer com que o mecanismo de consenso do Ethereum valide blocos de forma mais eficiente, o que reduzirá drasticamente o tempo de finalização. Em vez de esperar 15 minutos, os blocos podem ser propostos e finalizados em um mesmo espaço. Esse conceito é conhecido como **finalidade de espaço único (single slot finality, SSF)**.
-
-## O que é a finalidade? {#what-is-finality}
-
-No mecanismo de consenso de prova de participação (proof-of-stake, PoS) do Ethereum, finalizar se refere à garantia de que o bloco não pode ser alterado ou removido do blockchain sem queimar pelo menos 33% do total de ETH em participação na rede. Essa é uma segurança "criptoeconômica", pois a confiança vem do custo extremamente alto associado à alteração da ordem ou do conteúdo da cadeia, o que impediria qualquer agente econômico racional de tentar fazê-lo.
-
-## Por que ter como objetivo uma finalidade mais rápida? {#why-aim-for-quicker-finality}
-
-O tempo atual da finalidade (finalização) é muito longo. A maioria dos usuários não quer esperar 15 minutos pela finalidade, e é inconveniente para os aplicativos e corretoeas que podem querer uma alta taxa de transferência de transações ter que esperar tanto tempo para garantir que as transações são permanentes. O atraso entre a proposta e a finalização de um bloco também cria uma oportunidade para pequenas reformulações que um invasor poderia usar para censurar blocos específicos ou extrair MEV. O mecanismo que processa a atualização dos blocos em fases é bem complexo e foi corrigido diversas vezes para fechar as vulnerabilidades de segurança, tornando-o uma das partes da base de código do Ethereum em que há maior probabilidade de surgir falhas sutis. Todas essas questões poderiam ser eliminadas ao reduzir o tempo de finalidade em um único espaço.
-
-## A compensação entre descentralização/tempo/sobrecarga {#the-decentralization-time-overhead-tradeoff}
-
-A garantia de finalidade não é uma propriedade imediata de um novo bloco. A finalização de um bloco demora. O motivo disso é que os validadores que representam pelo menos 2/3 do total de ETH em participação na rede precisam votar no bloco ("atestar") para que ele seja considerado finalizado. Cada nó de validação na rede precisa processar as atestações de outros nós para saber se um bloco atingiu ou não o limite de 2/3.
-
-Quanto menor for o tempo permitido para a finalização, maior será a capacidade de computação necessária em cada nó, pois o processamento da atestação precisa ser feito mais rapidamente. Além disso, quanto mais nós de validação existirem na rede, mais atestações precisarão ser processadas para cada bloco, o que também aumenta a capacidade de processamento necessária. Quanto mais poder de processamento for necessário, menos pessoas poderão participar devido o alto custo de hardware necessário para executar um nó de validação. Aumentar o tempo entre os blocos reduz a capacidade de computação necessária em cada nó, mas também aumenta o tempo até a finalização, pois as atestações são processadas mais lentamente.
-
-Portanto, há uma compensação entre a sobrecarga (poder de computação), a descentralização (número de nós que podem participar da validação da cadeia) e o tempo até a finalização. O sistema ideal balanceia o mínimo poder de computação, a máxima descentralização e o tempo mínimo para a finalização.
-
-O mecanismo atual de consenso do Ethereum balanceou esses três parâmetros da seguinte forma:
-
-- **Definição da participação mínima para 32 ETH**. Isso define um limite superior para o número de atestações de validadores que precisam ser processadas por nós individuais e, portanto, um limite superior de requisitos computacionais para cada nó.
-- **Definição do tempo de finalização em ~15 minutos**. Isso dá tempo suficiente para que os validadores que executam em computadores domésticos normais processem com segurança as atestações de cada bloco.
-
-Com o design do mecanismo atual, para reduzir o tempo de finalização, é necessário reduzir o número de validadores na rede ou aumentar os requisitos de hardware para cada nó. Entretanto, há aprimoramentos que podem ser feitos na forma como as atestações são processadas, que podem permitir que mais atestações sejam contadas sem aumentar a sobrecarga em cada nó. O processamento mais eficiente permitirá que a finalidade seja determinada em um único espaço, em vez de em duas épocas.
-
-## Rotas para SSF {#routes-to-ssf}
-
-
-
-O mecanismo de consenso atual combina atestações de diversos validadores, conhecidos como "comitês", para reduzir o número de mensagens que cada validador precisa processar para validar um bloco. Cada validador tem a oportunidade de atestar em cada época (32 espaços), mas em cada espaço, apenas um subconjunto de validadores, conhecido como uma atestação de "comitê". Eles fazem isso ao se dividir em sub-redes, nas quais alguns validadores são selecionados para serem "agregadores". Esses agregadores combinam, em uma única assinatura agregada, todas as assinaturas que observam de outros validadores na respectiva sub-rede. O agregador que inclui o maior número de contribuições individuais passa a assinatura agregada ao proponente do bloco, que a inclui no bloco juntamente com a assinatura agregada dos demais comitês.
-
-Esse processo oferece capacidade suficiente para cada validador votar em cada época, porque "32 espaços * 64 comitês * 256 validadores por comitê = 524.288 validadores por época". No momento da redação deste artigo (fevereiro de 2023), há aproximadamente 513.000 validadores ativos.
-
-Nesse esquema, só é possível que cada validador vote em um bloco se distribuir as respectivas atestações por toda a época. Entretanto, há potencialmente maneiras de aprimorar o mecanismo para que _cada validador tenha a chance de atestar em cada espaço_.
-
-
-Desde que o mecanismo de consenso do Ethereum foi projetado, o esquema de agregação de assinaturas (BLS) foi considerado muito mais dimensionável do que se pensava inicialmente, enquanto a capacidade dos clientes de processar e verificar assinaturas também melhorou. Foi constatado que o processamento de atestações de um grande número de validadores é realmente possível em um único espaço. Por exemplo, com um milhão de validadores, cada um votando duas vezes em cada espaço, e os tempos de espaço ajustados para 16 segundos, os nós precisariam verificar as assinaturas a uma taxa mínima de 125.000 agregações por segundo para processar o um milhão de atestações no espaço. Na realidade, um computador comum demora aproximadamente 500 nanossegundos para fazer uma verificação de assinatura, o que significa que 125.000 podem ser feitas em ~62,5 ms, muito abaixo do limite de um segundo.
-
-Outros ganhos de eficiência poderiam ser obtidos com a criação de supercomitês de, por exemplo, 125.000 validadores selecionados aleatoriamente por espaço. Apenas esses validadores podem votar em um bloco e, portanto, apenas esse subconjunto de validadores decide se um bloco é finalizado. Se essa é ou não uma boa ideia, depende do quanto que a comunidade prefere que custe um ataque bem-sucedido à Ethereum. Isso porque, em vez de exigir 2/3 do total de ether em participação, o invasor poderia finalizar um bloco desonesto com 2/3 do ether em participação, _no supercomitê_. Essa ainda é uma área de pesquisa ativa, mas parece plausível que, para que um conjunto de validadores suficientemente grande possa exigir supercomitês, o custo de atacar um desses subcomitês será extremamente alto (por exemplo, o custo de ataque denominado ETH seria `2/3 * 125.000 * 32 = ~2,6 milhões de ETH`). O custo do ataque pode ser ajustado ao aumentar o tamanho do conjunto de validadores (por exemplo, ajustar o tamanho do validador para que o custo do ataque seja igual a 1 milhão de ether, 4 milhões de ether, 10 milhões de ether etc.). [Pesquisas preliminares](https://youtu.be/ojBgyFl6-v4?t=755) da comunidade parecem sugerir que 1-2 milhões de ether é um custo aceitável de ataque, o que implica ~65.536 - 97.152 validadores por supercomitê.
-
-Entretanto, a verificação não é o verdadeiro obstáculo, mas sim a agregação de assinaturas que realmente apresenta um desafio aos nós validadores. Para dimensionar a agregação de assinaturas, provavelmente será necessário aumentar o número de validadores em cada sub-rede, aumentar o número de sub-redes ou adicionar outras camadas de agregação (ou seja, implementar comitês de comitês). Parte da solução pode ser permitir agregadores especializados, semelhante à maneira como a construção de blocos e a geração de compromissos para dados de rollup serão terceirizados para construtores de blocos especializados na proposta de separação entre proponente e construtor (PBS) e no Danksharding.
-
-## Qual é o papel da regra de escolha de bifurcação na SSF? {#role-of-the-fork-choice-rule}
-
-O mecanismo de consenso atual se baseia em um forte acoplamento entre o dispositivo de finalidade (o algoritmo que determina se 2/3 dos validadores atestaram uma cadeia específica) e a regra de escolha de bifurcação (o algoritmo que decide qual cadeia é a correta quando há várias opções). O algoritmo de escolha da bifurcação apenas considera os blocos _desde_ o último bloco finalizado. Na SSF, não haveria nenhum bloco a ser considerado pela regra de escolha de bifurcação, pois a finalização ocorre no mesmo espaço em que o bloco é proposto. Isso significa que, na SSF, _ou_ o algoritmo de escolha de bifurcação _ou_ o mecanismo de finalidade estaria ativo a qualquer momento. O mecanismo de finalidade finalizaria os blocos em que 2/3 dos validadores estivessem online e atestando honestamente. Se um bloco não conseguir ultrapassar o limite de 2/3, a regra de escolha de bifurcação entrará em ação para determinar qual cadeia seguir. Isso também cria uma oportunidade de manter o mecanismo de vazamento de inatividade que recupera uma cadeia em que >1/3 dos validadores ficam offline, embora com algumas nuances adicionais.
-
-## Problemas pendentes {#outstanding-issues}
-
-O problema da escalabilidade da agregação por meio do aumento do número de validadores por sub-rede é que isso aplica uma carga maior na rede ponto a ponto. O problema ao adicionar camadas de agregações é que é bastante complexo de projetar e adiciona latência (ou seja, poderia levar mais tempo para o proponente do bloco 'ouvir' todos os agregadores da sub-rede). Também não está claro como lidar com o cenário em que há mais validadores ativos na rede do que é possível processar em cada espaço, mesmo com a agregação de assinaturas BLS. Uma possível solução é que, como todos os validadores atestam em todos os espaços e não há comitês na SSF, o limite de 32 ETH no saldo poderia ser totalmente removido, o que significa que os operadores que gerenciam vários validadores poderiam consolidar a participação e executar menos, o que reduziria o número de mensagens que os nós de validação precisam processar para contabilizar todo o conjunto de validadores. Isso depende de os grandes participantes concordarem com a consolidação dos respectivos validadores. Também é possível impor um limite fixo ao número de validadores ou à quantidade de ETH em participação a qualquer momento. Entretanto, isso exige um mecanismo para decidir quais validadores podem participar e quais não podem, o que pode criar efeitos secundários indesejados.
-
-## Progresso atual {#current-progress}
-
-A SSF está em fase de pesquisa. A implementação não deverá ocorrer por vários anos, provavelmente apenas após outras melhorias consideráveis, como [Verkle Trees](/roadmap/verkle-trees/) e [Danksharding](/roadmap/danksharding/).
-
-## Leitura adicional {#further-reading}
-
-- [Vitalik sobre SSF na EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI)
-- [Notas de Vitalik: caminhos para a finalidade de espaço único](https://notes.ethereum.org/@vbuterin/single_slot_finality)
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/statelessness/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/statelessness/index.md
deleted file mode 100644
index 9b00312dda9..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/statelessness/index.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Sem estado, expiração do estado e expiração do histórico
-description: Explicação sobre a expiração do histórico e o Ethereum sem estado
-lang: pt-br
----
-
-# Sem estado, expiração do estado e expiração do histórico {#statelessness}
-
-A capacidade de executar nós Ethereum em hardware modesto é fundamental para uma verdadeira descentralização. Isso porque a execução de um nó permite que os usuários verifiquem as informações por meio da execução de verificações criptográficas de forma independente, em vez de confiar em terceiros para fornecer os dados. A execução de um nó permite que os usuários enviem transações diretamente para a rede ponto a ponto do Ethereum, em vez de precisarem confiar em um intermediário. A descentralização não será possível se esses benefícios estiverem disponíveis apenas para usuários com hardware caro. Em vez disso, os nós devem ser capazes de funcionar com requisitos de processamento e memória extremamente modestos, para que possam ser executados em celulares, microcomputadores ou de forma imperceptível em um computador doméstico.
-
-Atualmente, os altos requisitos de espaço em disco são a principal barreira que impede o acesso universal aos nós. Isso se deve principalmente à necessidade de armazenar grandes partes dos dados de estado do Ethereum. Esses dados de estado contêm informações essenciais necessárias para processar corretamente novos blocos e transações. No momento da redação deste artigo, recomenda-se um SSD rápido de 2 TB para executar um nó Ethereum completo. Para um nó que não remove os dados mais antigos, o requisito de armazenamento aumenta em cerca de 14 GB/semana, e os nós de arquivamento que armazenam todos os dados desde o início estão se aproximando de 12 TB (no momento da redação deste artigo, em fevereiro de 2023).
-
-Discos rígidos mais baratos podem ser utilizados para armazenar dados mais antigos, mas eles são muito lentos para acompanhar os blocos recebidos. Manter os modelos de armazenamento atuais para os clientes e, ao mesmo tempo, tornar os dados mais baratos e mais fáceis de armazenar é apenas uma solução temporária e parcial para o problema, porque o crescimento do estado do Ethereum é "ilimitado", o que significa que os requisitos de armazenamento só podem aumentar, e as melhorias tecnológicas sempre precisarão acompanhar o ritmo do crescimento contínuo do estado. Em vez disso, os clientes precisam encontrar novas maneiras de verificar blocos e transações que não dependam da busca de dados em bancos de dados locais.
-
-## Redução do armazenamento para os nós {#reducing-storage-for-nodes}
-
-Há várias maneiras de reduzir a quantidade de dados que cada nó precisa armazenar, e cada uma exige que o protocolo principal do Ethereum seja atualizado em uma extensão diferente:
-
-- **Expiração do histórico**: habilita os nós para descartar dados de estado mais antigos que X blocos, mas não muda a maneira como o cliente Ethereum processa os dados de estado
-- **Expiração do estado**: permite que os dados de estado que não são usados com frequência se tornem inativos. Os clientes podem ignorar os dados inativos até que sejam "ressuscitados".
-- **Sem estado fraco**: apenas os produtores de blocos precisam acessar os dados de estado completos, outros nós podem verificar blocos sem um banco de dados de estado local.
-- **Sem estado forte**: nenhum nó precisa de acesso aos dados de estado completos.
-
-## Expiração de dados {#data-expiry}
-
-### Expiração do histórico {#history-expiry}
-
-A expiração do histórico se refere à eliminação, pelos clientes, de dados mais antigos que provavelmente não serão necessários, de forma a armazenarem apenas uma pequena quantidade de dados históricos, descartando os dados mais antigos quando chegam dados novos. Há dois motivos pelos quais os clientes precisam de dados históricos: sincronização e atendimento de solicitações de dados. Originalmente, os clientes tinham que sincronizar a partir do bloco de início, verificando se cada bloco sucessivo estava correto até o início da cadeia. Atualmente, os clientes usam "pontos de verificação de subjetividade fraca" para chegar ao início da cadeia. Esses pontos de verificação são pontos de partida confiáveis, como ter um bloco de início perto do momento presente em vez de no início do Ethereum. Isso significa que os clientes podem "descartar" todas as informações anteriores ao ponto de verificação de subjetividade fraca mais recente sem perder a capacidade de sincronizar com o início da cadeia. Atualmente, os clientes atendem a solicitações (que chegam por meio de JSON-RPC) de dados históricos, obtendo-os junto aos respectivos bancos de dados locais. Entretanto, com a expiração do histórico, isso não será possível se os dados solicitados tiverem sido eliminados. Para atender a esses dados históricos, são necessárias algumas soluções inovadoras.
-
-Uma opção é os clientes solicitarem dados históricos de pares usando uma solução como o Portal Network. O Portal Network é uma rede ponto a ponto em desenvolvimento para o atendimento a dados históricos, em que cada nó armazena uma pequena parte do histórico do Ethereum, de modo que todo o histórico seja distribuído pela rede. As solicitações são atendidas por meio da busca de pares que armazenam os dados relevantes e enviando uma solicitação a eles. Alternativamente, como geralmente são os aplicativos que exigem acesso a dados históricos, pode ser responsabilidade deles armazená-los. Também pode haver participantes suficientemente altruístas no espaço Ethereum que estariam dispostos a manter arquivos históricos. Pode ser uma DAO que se desenvolve para gerenciar o armazenamento de dados históricos ou, idealmente, será uma combinação de todas essas opções. Esses provedores poderiam fornecer os dados de muitas maneiras, como por meio de um torrent, FTP, Filecoin ou IPFS.
-
-A expiração do histórico é um tanto controversa porque até agora o Ethereum sempre garantiu implicitamente a disponibilidade de quaisquer dados históricos. Uma sincronização completa a partir do início sempre foi possível como padrão, mesmo que dependa da reconstrução de alguns dados mais antigos a partir de snapshots. A expiração do histórico transfere a responsabilidade de fornecer essa garantia para fora do protocolo principal do Ethereum. Se as organizações centralizadas acabarem entrando em cena para fornecer dados históricos, isso pode introduzir novos riscos de censura.
-
-O EIP-4444 ainda não está pronto para implementação, mas está sendo discutido ativamente. É interessante notar que os desafios do EIP-4444 não são muito técnicos, mas principalmente de gerenciamento da comunidade. Para que isso seja implementado, é necessário que a comunidade se comprometa não apenas com a concordância, mas também com o armazenamento e o fornecimento de dados históricos a partir de entidades confiáveis.
-
-Essa melhoria não altera fundamentalmente como os nós Ethereum processam os dados de estado, apenas muda como os dados históricos são acessados.
-
-### Expiração do estado {#state-expiry}
-
-A expiração do estado se refere à remoção do estado dos nós individuais, se o nó não tiver sido acessado recentemente. Há várias maneiras de implementar isso, incluindo:
-
-- **Expiração por locação**: cobrar "aluguel" das contas e expirar o estado assim que o valor da locação chegar a zero
-- **Expiração por tempo**: desativar as contas se não houver leitura/escrita na conta por algum período específico
-
-A expiração por locação poderia ser um aluguel direto cobrado das contas para mantê-las no banco de dados de estado ativo. A expiração por tempo poderia ser por meio de uma contagem regressiva a partir da interação mais recente com a conta, ou poderia ser uma expiração periódica de todas as contas. Também pode haver mecanismos que combinem elementos dos modelos baseados em tempo e em aluguel, por exemplo, contas individuais continuam no estado ativo se pagarem uma pequena taxa antes da expiração com base em tempo. Com a expiração do estado, é importante observar que o estado inativo **não é excluído**, ele é apenas armazenado em separado do estado ativo. O estado inativo pode ser "ressuscitado" para estado ativo.
-
-A maneira como isso funcionaria provavelmente seria ter uma árvore de estado para períodos específicos (talvez cerca de 1 ano). Sempre que um novo período começa, também começa uma árvore de estado completamente nova. Apenas a árvore de estado atual pode ser alterada, todas as outras permanecem inalteráveis. Espera-se que os nós Ethereum mantenham apenas a árvore do estado atual e o próximo mais recente. Isso exige uma maneira de aplicar o carimbo de data/hora de um endereço com o período em que se encontra. Existem [várias maneiras possíveis](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) de fazer isso, mas a principal opção exige que [os endereços sejam ampliados](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) para acomodar as informações adicionais, com o benefício adicional de que endereços mais longos são muito mais seguros. O item do planejamento que faz isso é chamado [extensão do espaço do endereço](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485).
-
-Da mesma forma que a expiração do histórico, na expiração do estado a responsabilidade pelo armazenamento de dados do estado antigo é removida dos usuários individuais e transferida para outras entidades, como provedores centralizados, membros altruístas da comunidade ou soluções descentralizadas mais futuristas, como a Portal Network.
-
-A expiração de estado ainda está em fase de pesquisa e ainda não está pronta para implementação. A expiração do estado pode ocorrer mais tarde do que a dos clientes sem estado e a expiração do histórico, porque essas melhorias fazem com que a maioria dos validadores possam gerenciar facilmente grandes tamanhos de estado.
-
-## Sem estado {#statelessness}
-
-O termo "sem estado" é um tanto equivocado, pois não significa que o conceito de "estado" seja eliminado, mas envolve alterações na maneira como os nós Ethereum processam os dados de estado. O conceito de "sem estado" ocorre em duas formas: sem estado fraco e sem estado forte. Sem estado fraco permite que a maioria dos nós se torne sem estado e coloca a responsabilidade pelo armazenamento do estado em alguns poucos nós. Sem estado forte remove completamente a necessidade de qualquer nó armazenar os dados de estado completos. Ambos os conceitos, sem estado fraco e forte, oferecem os seguintes benefícios aos validadores normais:
-
-- sincronização quase instantânea
-- capacidade de validar blocos fora de ordem
-- os nós podem ser executados com requisitos de hardware muito baixos (por exemplo, no celular)
-- os nós podem ser executados em discos rígidos baratos, porque não há necessidade de leitura/escrita de disco
-- compatível com melhorias futuras da criptografia do Ethereum
-
-### Sem estado fraco {#weak-statelessness}
-
-Sem estado fraco envolve alterações na maneira como os nós Ethereum verificam as alterações do estado, mas não elimina completamente a necessidade de armazenamento do estado em todos os nós da rede. Em vez disso, sem estado fraco coloca a responsabilidade pelo armazenamento do estado nos proponentes de bloco, enquanto todos os outros nós da rede verificam os blocos sem armazenar os dados do estado completos.
-
-**Em sem estado fraco, propor blocos exige acesso a dados de estado completos, mas verificar blocos não exige dados do estado**
-
-Para que isso aconteça, [Verkle Trees](/roadmap/verkle-trees/) já devem ter sido implementadas nos clientes Ethereum. As Verkle Trees são uma estrutura de dados de substituição para armazenar dados de estado do Ethereum que permitem que "testemunhas" pequenas e de tamanho fixo dos dados sejam transmitidas entre pares e utilizadas para verificar blocos, em vez de verificar blocos com relação aos bancos de dados locais. A [separação entre proponente e construtor](/roadmap/pbs/) também é necessária, porque isso permite que os construtores de blocos sejam nós especializados com hardware mais poderoso, e esses são os que exigem acesso aos dados de estado completos.
-
-
-
-O conceito sem estado depende de os construtores de blocos manterem uma cópia dos dados do estado completos para que possam gerar testemunhas que possam ser utilizadas para verificar o bloco. Outros nós não precisam de acesso aos dados do estado. Todas as informações necessárias para verificar o bloco estão disponíveis na testemunha. Isso cria uma situação em que propor um bloco é caro, mas a verificação do bloco é barata, o que implica que menos operadores executarão um nó de proposta de bloco. Entretanto, a descentralização dos proponentes de blocos não é essencial, desde que o maior número possível de participantes possa verificar, de maneira independente, se os blocos propostos são válidos.
-
-Leia mais sobre as observações de Dankrad
-
-
-Os proponentes de blocos usam os dados de estado para criar "testemunhas", o conjunto mínimo de dados que provam os valores do estado que estão sendo alterados pelas transações em um bloco. Outros validadores não mantêm o estado, eles apenas armazenam a raiz do estado (um hash do estado inteiro). Eles recebem um bloco e uma testemunha, e utilizam esses elementos para atualizar a raiz do estado. Isso faz com que um nó de validação fique extremamente leve.
-
-O conceito "sem estado fraco" está em um estado avançado de pesquisa, mas depende da implementação da separação entre proponente e construtor e das Verkle Trees para que as pequenas testemunhas possam ser transferidas entre os pares. Isso significa que provavelmente ainda vai demorar alguns anos para a implementação do conceito "sem estado fraco" na rede principal do Ethereum.
-
-### Sem estado forte {#strong-statelessness}
-
-A forte ausência de estado elimina a necessidade de qualquer nó armazenar dados de estado. Em vez disso, as transações são enviadas com testemunhas que podem ser agregadas pelos produtores de blocos. Portanto, os produtores de blocos serão responsáveis por armazenar apenas o estado necessário para gerar testemunhas para as contas relevantes. A responsabilidade pelo estado é quase totalmente transferida para os usuários, pois eles enviam testemunhas e "listas de acesso" para declarar com quais contas e chaves de armazenamento estão interagindo. Embora isso permitiria nódulos altamente leves, seria mais difícil realizar trtansações conm contratos inteligentes.
-
-O conceito "sem estado forte" foi investigado por pesquisadores, mas atualmente não se espera que faça parte do planejamento do Ethereum. É mais provável que o sem estado fraco seja suficiente para as necessidades de escalabilidade do Ethereum.
-
-## Progresso atual {#current-progress}
-
-Sem estado fraco, expiração do histórico e expiração do estado estão em fase de pesquisa e devem ser implementados daqui a vários anos. Não há garantia de que todas essas propostas serão implementadas. Por exemplo, se a expiração do estado for implementada primeiro, talvez não seja necessário implementar também a expiração do histórico. Há também outros itens do planejamento, como [Verkle Trees](/roadmap/verkle-trees) e [separação entre proponente e construtor](/roadmap/pbs), que precisam ser concluídos primeiro.
-
-## Leitura adicional {#further-reading}
-
-- [AMA sem estado, Vitalik](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/)
-- [Uma teoria de gerenciamento do tamanho do estado](https://hackmd.io/@vbuterin/state_size_management)
-- [Limitação do estado minimizado por conflito de "ressurreição"](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739)
-- [Caminhos para "sem estado" e expiração do estado](https://hackmd.io/@vbuterin/state_expiry_paths)
-- [Especificação EIP-4444](https://eips.ethereum.org/EIPS/eip-4444)
-- [Alex Stokes sobre EIP-4444](https://youtu.be/SfDC_qUZaos)
-- [Por que é tão importante implementar o conceito "sem estado"](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html)
-- [Observações sobre o conceito do cliente sem estado original](https://ethresear.ch/t/the-stateless-client-concept/172)
-- [Mais sobre expiração do estado](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry)
-- [Ainda mais sobre expiração do estado](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry)
diff --git a/public/content/translations/pt-br/12) Roadmap 2/roadmap/verkle-trees/index.md b/public/content/translations/pt-br/12) Roadmap 2/roadmap/verkle-trees/index.md
deleted file mode 100644
index 024bc522a4b..00000000000
--- a/public/content/translations/pt-br/12) Roadmap 2/roadmap/verkle-trees/index.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Árvores de Verkle
-description: Uma descrição detalhada de Verkle Trees e como elas serão utilizadas na melhoria do Ethereum
-lang: pt-br
-summaryPoints:
- - Saiba o que são Verkle Trees
- - Leia por que Verkle Trees são uma melhoria útil para o Ethereum
----
-
-# Árvores de Verkle {#verkle-trees}
-
-As Verkle Trees (um composto de "Vector commitment" e "Merkle Trees") são uma estrutura de dados que pode ser usada para melhorar os nós do Ethereum para que possam parar de armazenar grandes quantidades de dados de estado sem perder a capacidade de validar blocos.
-
-## Sem estado {#statelessness}
-
-As Verkle Trees são uma etapa essencial no caminho para clientes Ethereum sem estado. Os clientes sem estado são aqueles que não precisam armazenar todo o banco de dados de estado para validar os blocos recebidos. Em vez de usar a própria cópia local do estado do Ethereum para verificar os blocos, os clientes sem estado usam uma "testemunha" dos dados de estado que chegam com o bloco. Uma testemunha é uma coleção de partes individuais dos dados de estado necessários para executar um conjunto específico de transações e uma prova criptográfica de que a testemunha é realmente parte dos dados completos. A testemunha é usada _em vez_ do banco de dados do estado. Para que isso funcione, as testemunhas precisam ser muito pequenas, de modo que possam ser transmitidas com segurança pela rede a tempo de serem processadas pelos validadores em um espaço de 12 segundos. A estrutura de dados de estado atual não é adequada, porque as testemunhas são muito grandes. As Verkle Trees resolvem esse problema ao permitir testemunhas pequenas, removendo uma das principais barreiras aos clientes sem estado.
-
-
-
-Atualmente, os clientes Ethereum usam uma estrutura de dados conhecida como Patricia Merkle Trie para armazenar os dados de estado. As informações sobre contas individuais são armazenadas como folhas na "trie", e os pares de folhas são transformados em hash repetidamente até que fique apenas um único hash. Esse hash final é conhecido como "root" (raiz). Para verificar os blocos, os clientes Ethereum executam todas as transações em um bloco e atualizam a "trie" de estado local. O bloco é considerado válido se a raiz da árvore local for idêntica à fornecida pelo proponente do bloco, pois qualquer diferença no cálculo feito pelo proponente do bloco e pelo nó de validação faria com que o hash da raiz fosse completamente diferente. O problema com isso é que a verificação da cadeia de blocos exige que cada cliente armazene toda a "trie" de estado do bloco principal e em diversos blocos históricos (o padrão no Geth é manter os dados de estado de 128 blocos atrás do principal). Isso exige que os clientes tenham acesso a uma grande quantidade de espaço em disco, o que é uma barreira para a execução de nós completos em hardware barato e de baixo consumo de energia. Uma solução para isso é atualizar a "trie" de estado para uma estrutura mais eficiente (Verkle Tree) que pode ser resumida usando uma pequena "testemunha" dos dados que podem ser compartilhados, em vez dos dados de estado completos. A reformatação dos dados de estado em uma Verkle Tree é uma porta de entrada para a mudança para clientes sem estado.
-
-
-
-## O que é uma testemunha e por que precisamos dela? {#what-is-a-witness}
-
-A verificação de um bloco significa reexecutar as transações contidas no bloco, aplicar as alterações na trie de estado do Ethereum e calcular o novo hash raiz. Um bloco verificado é aquele cujo hash raiz de estado calculado é idêntico ao fornecido com o bloco (porque isso significa que o proponente do bloco realmente fez o cálculo que diz ter feito). Nos clientes Ethereum atuais, a atualização do estado exige acesso a toda a trie do estado, que é uma estrutura de dados grande que precisa ser armazenada localmente. Uma testemunha contém apenas os fragmentos dos dados de estado necessários para executar as transações no bloco. Um validador pode usar apenas esses fragmentos para verificar se o proponente do bloco executou as transações do bloco e atualizou o estado corretamente. Entretanto, isso significa que a testemunha precisa ser transferida entre pares na rede Ethereum com rapidez suficiente para ser recebida e processada por cada nó com segurança, em um espaço de 12 segundos. Se a testemunha for muito grande, alguns nós poderão levar muito tempo para fazer o download e acompanhar a cadeia. Essa é uma força centralizadora, pois significa que apenas nós com conexões rápidas à Internet podem participar da validação de blocos. Com as Verkle Trees, não há necessidade de ter o estado armazenado no disco rígido local; _tudo_ que você precisa para verificar um bloco está no próprio bloco. Infelizmente, as testemunhas que podem ser produzidas a partir de Merkle tries são muito grandes para suportar clientes sem estado.
-
-## Por que as Verkle Trees permitem testemunhas menores? {#why-do-verkle-trees-enable-smaller-witnesses}
-
-A estrutura de uma Merkle Trie faz com que as testemunhas sejam muito grandes, grandes demais para serem transmitidas com segurança entre pares em um espaço de 12 segundos. Isso ocorre porque a testemunha é um caminho que conecta os dados, que são mantidos nas folhas, ao hash raiz. Para verificar os dados, é necessário ter não apenas todos os hashes intermediários que conectam cada folha à raiz, mas também todos os nós "irmãos". Cada nó na prova tem um irmão com o qual é feito o hash para criar o próximo hash na trie. São muitos dados. As Verkle Trees reduzem o tamanho da testemunha ao reduzir a distância entre as folhas da árvore e sua raiz, bem como ao eliminar a necessidade de fornecer nós irmãos para verificar o hash raiz. Será possível obter ainda mais eficiência de espaço usando um esquema eficiente de compromisso polinomial em vez do compromisso vetorial no estilo hash. O compromisso polinomial permite que a testemunha tenha um tamanho fixo, independentemente do número de folhas que ela comprove.
-
-No esquema de compromisso polinomial, as testemunhas têm tamanhos gerenciáveis que podem ser facilmente transferidos na rede ponto a ponto. Isso permite que os clientes verifiquem as alterações de estado em cada bloco com uma quantidade mínima de dados.
-
-
-
-O tamanho da testemunha varia de acordo com o respectivo número de folhas. Se a testemunha tiver mil folhas, uma testemunha de uma Merkle Trie terá aproximadamente 3,5 MB (supondo 7 níveis para a trie). Uma testemunha dos mesmos dados em uma Verkle Tree (supondo 4 níveis para a árvore) teria cerca de 150 kB, **aproximadamente 23 vezes menor**. Essa redução no tamanho da testemunha permitirá que as testemunhas de clientes sem estado sejam aceitavelmente pequenas. As testemunhas polinomiais são de 0,128 -1 kB, dependendo do compromisso polinomial específico usado.
-
-
-
-## Qual é a estrutura de uma Verkle Tree? {#what-is-the-structure-of-a-verkle-tree}
-
-As Verkle Trees são pares `(chave, valor)` em que as chaves são elementos de 32 bytes compostos por uma _stem_ (haste) de 31 bytes e um _sufixo_ de um byte. Essas chaves são organizadas em nós de _extensão_ e nós _internos_. Os nós de extensão representam uma única haste para 256 filhos com sufixos diferentes. Os nós internos também têm 256 filhos, mas eles podem ser outros nós de extensão. A principal diferença entre a Verkle Tress e a estrutura da Merkle Tree é que a de Verkle é muito mais plana, o que significa que há menos nós intermediários ligando uma folha à raiz e, portanto, menos dados necessários para gerar uma prova.
-
-
-
-[Leia mais sobre a estrutura das Verkle Trees](https://blog.ethereum.org/2021/12/02/verkle-tree-structure)
-
-## Progresso atual {#current-progress}
-
-As redes de testes de Verkle Trees já estão em execução, mas ainda há atualizações pendentes consideráveis em clientes que são necessárias para oferecer suporte às Verkle Trees. Você pode ajudar a acelerar o progresso por meio da implantação de contratos nas redes de testes ou da execução de clientes de rede de testes.
-
-[Explore a rede de teste Verkle Gen Devnet 2](https://verkle-gen-devnet-2.ethpandaops.io/)
-
-[Assista Guillaume Ballet explicar a rede de teste Condrieu Verkle](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (observe que a rede de teste Condrieu era uma prova de trabalho e agora foi substituída pela rede de teste Verkle Gen Devnet 2).
-
-## Leitura adicional {#further-reading}
-
-- [Árvores Verkle para falta de Estado](https://verkle.info/)
-- [Dankrad Feist explica as Verkle Trees no PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ)
-- [Guillaume Ballet explica as Verkle Trees na ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o)
-- ["Como as Verkle Trees tornam o Ethereum simples e eficiente", por Guillaume Ballet na Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs)
-- [Piper Merriam sobre clientes sem estado da ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4)
-- [Dankrad Fiest explica as árvores Verkle e a falta de Estado no podcast da Zero Knowledge](https://zeroknowledge.fm/episode-202-stateless-ethereum-verkle-tries-with-dankrad-feist/)
-- [Vitalik Buterin sobre Verkle Trees](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
-- [Dankrad Feist sobre Verkle Trees](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)
-- [Documentação de EIO da Verkle Tree](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/accounts/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/accounts/index.md
deleted file mode 100644
index 1456285c484..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/accounts/index.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Contas Ethereum
-description: Uma explicação das contas Ethereum – suas estruturas de dados e sua relação com a criptografia de pares de chaves.
-lang: pt-br
----
-
-Uma conta Ethereum é uma entidade com um saldo de ether (ETH) que pode enviar transações no Ethereum. As contas podem ser controladas pelo usuário ou implementadas como contratos inteligentes.
-
-## Pré-requisitos {#prerequisites}
-
-Para ajudá-lo a entender melhor esta página, recomendamos que você primeiro leia nossa [introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-## Tipos de conta {#types-of-account}
-
-Ethereum tem dois tipos de contas:
-
-- Conta de propriedade externa (EOA) — controlada por qualquer pessoa com as chaves privadas
-- Conta de contrato — um contrato inteligente implantado na rede, controlado por código. Saiba mais sobre [contratos inteligentes](/developers/docs/smart-contracts/)
-
-Ambos os tipos de conta têm capacidade para:
-
-- Receber, guardar e enviar ETH e tokens
-- Interagir com contratos inteligentes implementados
-
-### Principais diferenças {#key-differences}
-
-**Propriedade externa**
-
-- Não há custo para criar uma conta
-- Pode iniciar transações
-- Transações entre contas de propriedade externa só podem ser transferências de ETH/token
-- Composto por um par de chaves criptográficas: chaves públicas e privadas que controlam as atividades da conta
-
-**Contrato**
-
-- Criar um contrato tem um custo porque você está usando o armazenamento de rede
-- Só pode enviar transações em resposta ao recebimento de transação
-- Transações de uma conta externa para uma conta contrato podem acionar um código que pode executar muitas ações diferentes, como transferir tokens ou até mesmo criar um contrato
-- As contas de contrato não têm chaves privadas. Em vez disso, eles são controlados pela lógica do código do contrato inteligente
-
-## Uma conta analisada {#an-account-examined}
-
-As contas Ethereum têm quatro campos:
-
-- `nonce` – Um contador que indica o número de transações enviadas de uma conta de propriedade externa ou o número de contratos criados por uma conta de contrato. Apenas uma transação com um dado nonce pode ser executada para cada conta, protegendo contra ataques de repetição em que as transações assinadas são repetidamente transmitidas e reexecutadas.
-- `balance` – o número de Wei pertencentes a este endereço. Wei é uma denominação de ETH e existem 1e + 18 Wei por ETH.
-- `codeHash` - este hash se refere ao _código_ de uma conta na máquina virtual Ethereum (EVM). Contas contratuais têm fragmentos de código programados que podem executar diferentes operações. Este código EVM é executado se a conta receber uma chamada de mensagem. Diferentemente dos outros campos da conta, ele não pode ser alterado. Todos esses fragmentos de código estão contidos na base de dados de estados sob suas hashes correspondentes para recuperação posterior. Este valor de hash é conhecido como codeHash. Para contas de propriedade externa, o campo codeHash é o hash de uma “string” vazia.
-- `storageRoot` – Às vezes conhecido como um hash de armazenamento. Um hash de 256 bits do nó raiz de uma árvore de Merkle que codifica o conteúdo de armazenamento da conta (um mapeamento entre valores inteiros de 256 bits), codificado para o mapeamento a partir do hash Keccak de 256 bits das chaves inteiras de 256 bits para os valores inteiros codificados no RLP-256 bits. Esta árvore codifica o hash do conteúdo de armazenamento desta conta e está vazia por padrão.
-
- _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## Contas de propriedade externa e pares de chaves {#externally-owned-accounts-and-key-pairs}
-
-Uma conta é composta de um par de chaves criptográficas: pública e privada. Eles ajudam a provar que uma transação foi realmente assinada pelo remetente e evitam falsificações. Sua chave privada é o que você usa para assinar transações, portanto, concede a você a custódia dos fundos associados à sua conta. Você nunca tem criptomoeda, você tem chaves privadas - os fundos estão sempre no livro-razão do Ethereum.
-
-Isso evita que agentes mal-intencionados transmitam transações falsas, porque você sempre pode verificar o remetente de uma transação.
-
-Se Alice quer enviar ether da sua própria conta para a conta do Bob, Alice precisa criar um pedido de transação e enviá-lo para a rede para verificação. O uso da criptografia de chave pública na Ethereum, garante que a Alice possa provar que foi ela quem iniciou originalmente o pedido de transação. Sem mecanismos criptográficos, um adversário malicioso "Eve" poderia simplesmente transmitir publicamente uma solicitação como “enviar 5 ETH da conta de Alice para a conta de Eve", e ninguém poderia verificar que a transmissão não veio da Alice.
-
-## Criação de conta {#account-creation}
-
-Quando você quiser criar uma conta, a maioria das bibliotecas vai gerar uma chave privada aleatória.
-
-Uma chave privada é composta por 64 caracteres hexadecimais e pode ser criptografada com uma senha.
-
-Exemplo:
-
-`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f`
-
-A chave pública é gerada a partir da chave privada usando o [Algoritmo de assinatura digital da curva elíptica](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm). Você recebe um endereço público para sua conta a partir dos últimos 20 “bytes” do hash Keccak-256 da chave pública e adiciona `0x` no início.
-
-Isso significa que uma Conta de Propriedade Externa (EOA) possui um endereço de 42 caracteres (um segmento de 20 bytes, que corresponde a 40 caracteres hexadecimais mais o prefixo `0x`).
-
-Exemplo:
-
-`0x5e97870f263700f46aa00d967821199b9bc5a120`
-
-O exemplo a seguir mostra como usar uma ferramenta de assinatura chamada [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) para gerar uma nova conta. Clef é uma ferramenta de assinatura e gerenciamento de contas que vem com o cliente Ethereum, [Geth](https://geth.ethereum.org). O comando `clef newaccount` cria um novo par de chaves e os salva em um repositório de chaves criptografado.
-
-```
-> clef newaccount --keystore
-
-Please enter a password for the new account to be created:
->
-
-------------
-INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please remember your password!
-Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
-```
-
-[Documentação do Geth](https://geth.ethereum.org/docs)
-
-É possível obter novas chaves públicas de sua chave privada, mas você não pode obter uma chave privada de chaves públicas. É fundamental manter suas chaves privadas seguras e, como o nome sugere, **PRIVADAS**.
-
-Você precisa de uma chave privada para assinar mensagens e transações que resultam em uma assinatura. Outros podem então pegar a assinatura derivada da sua chave pública, provando a autoria da mensagem. Em seu aplicativo, é possível usar uma biblioteca JavaScript para enviar transações para a rede.
-
-## Contas de contrato {#contract-accounts}
-
-As contas contratuais também têm um endereço hexadecimal de 42 caracteres:
-
-Exemplo:
-
-`0x06012c8cf97bead5deae237070f9587f8e7a266d`
-
-O endereço do contrato é geralmente dado quando um contrato é implantado na Blockchain do Ethereum. O endereço vem do endereço do criador e do número de transações enviadas desse endereço (o “nonce”).
-
-## Chaves de validação {#validators-keys}
-
-Há também outro tipo de chave no Ethereum, introduzida quando o Ethereum mudou de prova de trabalho para prova de participação baseado no consenso. Essas chaves são "BLS" e são usadas para identificar validadores. Essas chaves podem ser agregadas de forma eficiente para reduzir a largura de banda necessária para que a rede chegue a um consenso. Sem essa agregação de chaves, a participação mínima para um validador seria muito maior.
-
-[Mais sobre chaves de validação](/developers/docs/consensus-mechanisms/pos/keys/).
-
-## Observação sobre carteiras {#a-note-on-wallets}
-
-Uma conta não é uma carteira. Uma carteira é uma interface ou aplicativo que permite interagir com sua conta Ethereum, seja uma conta de propriedade externa ou uma conta de contrato.
-
-## Uma demonstração visual {#a-visual-demo}
-
-Assista a Austin mostrando passo a passo as funções de hash e os pares de chaves.
-
-
-
-
-
-## Leitura adicional {#further-reading}
-
-- [Entendendo Contas Ethereum](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan
-
-_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione-a!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Contratos inteligentes](/developers/docs/smart-contracts/)
-- [Transações](/developers/docs/transactions/)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/blocks/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/blocks/index.md
deleted file mode 100644
index 8dc7e5a1f46..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/blocks/index.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-title: Blocos
-description: Uma visão geral dos blocos na blockchain do Ethereum — sua estrutura de dados, por que são necessários e como são feitos.
-lang: pt-br
----
-
-Blocos são lotes de transações com um hash do bloco anterior na cadeia. Isso une os blocos (em uma cadeia) porque os hashes são criptograficamente derivados dos dados do bloco. Isso previne fraudes, porque uma mudança em qualquer bloco no histórico invalidaria todos os blocos subsequentes, alteraria todos os hashes subsequentes e todos que estivessem executando o blockchain notariam.
-
-## Pré-requisitos {#prerequisites}
-
-Os blocos são um tópico muito amigável para iniciantes. Mas para ajudá-lo a entender melhor esta página, recomendamos que você primeiro leia [Contas](/developers/docs/accounts/), [Transações](/developers/docs/transactions/)e nossa [introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-## Por que blocos? {#why-blocks}
-
-Para garantir que todos os participantes da rede Ethereum mantenham um estado sincronizado e concordem com o histórico preciso de transações, nós processamos lotes de transações em blocos. Isso significa que dezenas (ou centenas) de transações são confirmadas, acordadas e sincronizadas de uma só vez.
-
- _Diagrama adaptado de [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-Ao espaçar as confirmações, damos a todos os participantes da rede tempo suficiente para chegar a um consenso: mesmo que as solicitações de transação ocorram dezenas de vezes por segundo, os blocos só são criados e confirmados na Ethereum uma vez a cada doze segundos.
-
-## Como os blocos funcionam {#how-blocks-work}
-
-Para preservar o histórico de transação, os blocos são estritamente ordenados (cada novo bloco criado contém uma referência ao seu bloco de origem), e as transações dentro dos blocos também são ordenadas estritamente. Exceto em casos raros, a qualquer momento, todos os participantes da rede concordam com o número exato e o histórico de blocos, e estão trabalhando para processar em lote as solicitações atuais de transações para o bloco seguinte.
-
-Uma vez que um bloco é agregado por um validador selecionado aleatoriamente na rede, ele é propagado pelo resto da rede. Em seguida, todos os nós adicionam esse bloco ao final de sua blockchain e um novo validador é selecionado para criar o próximo bloco. O processo exato de montagem de blocos e o processo de compromisso/consenso são atualmente especificados pelo protocolo de “prova de participação” da Ethereum.
-
-## Protocolo de prova de participação {#proof-of-work-protocol}
-
-Prova de participação significa o seguinte:
-
-- Os nós de validação precisam colocar 32 ETH em um contrato de depósito como garantia contra mau comportamento. Isso ajuda a proteger a rede porque atividades comprovadamente desonestas fazem com que parte de ou toda essa participação seja destruída.
-- Em cada espaço (espaçados de doze segundos), um validador é selecionado aleatoriamente para ser o proponente do bloco. Eles agrupam transações, as executam e determinam um novo "estado". Eles agrupam essas informações em um bloco e as passam para outros validadores.
-- Outros validadores que ouvem sobre um novo bloco reexecutam as transações para garantir que concordam com a mudança proposta para o estado global. Assumindo que o bloco é válido, eles o adicionam ao seu próprio banco de dados.
-- Se um validador ouvir sobre dois blocos conflitantes para o mesmo espaço, eles usam seu algoritmo de escolha de fork para escolher aquele suportado pelo ETH que teve mais participação.
-
-[Mais sobre prova de participação](/developers/docs/consensus-mechanisms/pos)
-
-## O que há em um bloco? {#block-anatomy}
-
-Há muitas informações contidas em um bloco. No nível mais alto, um bloco contém os seguintes campos:
-
-| Campo | Descrição |
-|:---------------- |:---------------------------------------------------------- |
-| `slot` | o slot ao qual o bloco pertence |
-| `proposer_index` | a ID do validador que propõe o bloco |
-| `parent_root` | o hash do bloco anterior |
-| `state_root` | o hash raiz do estado do objeto |
-| `body` | um objeto contendo vários campos, conforme definido abaixo |
-
-O bloco `body` contém vários campos próprios:
-
-| Campo | Descrição |
-|:-------------------- |:------------------------------------------------------------- |
-| `randao_reveal` | um valor usado para selecionar o proponente do próximo bloco |
-| `eth1_data` | informações sobre o contrato de depósito |
-| `graffiti` | dados arbitrários usados para marcar blocos |
-| `proposer_slashings` | lista de validadores a serem removidos |
-| `attester_slashings` | lista de validadores a serem removidos |
-| `attestations` | lista de validadores a serem removidos |
-| `deposits` | lista de novos depósitos para o contrato de depósito |
-| `voluntary_exits` | lista de validadores saindo da rede |
-| `sync_aggregate` | subconjunto de validadores usados para atender clientes leves |
-| `execution_payload` | transações transmitidas do cliente de execução |
-
-O campo `attestations` contém uma lista de todas as atestações no bloco. As atestações têm seu próprio tipo de dados que contém vários dados. Cada atestação contém:
-
-| Campo | Descrição |
-|:------------------ |:----------------------------------------------------------- |
-| `aggregation_bits` | uma lista de quais validadores participaram desta atestação |
-| `data` | um contêiner com vários subcampos |
-| `signature` | assinatura agregada com todos os validadores de atestação |
-
-O campo `data` no `attestation` contém o seguinte:
-
-| Campo | Descrição |
-|:------------------- |:------------------------------------------------ |
-| `slot` | o local ao qual a atestação se refere |
-| `index` | índices para as atestações dos validadores |
-| `beacon_block_root` | o hash raiz do bloco Beacon contendo este objeto |
-| `source` | o último ponto de verificação justificado |
-| `target` | o último bloco de limite de época |
-
-A execução das transações no `execution_payload` atualiza o estado global. Todos os clientes reexecutam as transações no `execution_payload` para garantir que o novo estado corresponda ao novo bloco do campo `state_root`. É assim que os clientes podem dizer que um novo bloco é válido e seguro para adicionar à cadeia de blocos deles. O próprio `execution payload` é um objeto com vários campos. Há também um `execution_payload_header` que contém informações importantes de resumo sobre os dados de execução. Essas estruturas de dados são organizadas da seguinte forma:
-
-O `execution_payload_header` contém os seguintes campos:
-
-| Campo | Descrição |
-|:------------------- |:------------------------------------------------------------------ |
-| `parent_hash` | hash do bloco pai |
-| `fee_recipient` | endereço da conta para pagar taxas de transação para |
-| `state_root` | hash raiz para o estado global após aplicar alterações neste bloco |
-| `receipts_root` | hash dos recibos da transação trie |
-| `logs_bloom` | estrutura de dados contendo logs de eventos |
-| `prev_randao` | valor usado na seleção do validador aleatório |
-| `block_number` | o número do bloco atual |
-| `gas_limit` | gás máximo permitido neste bloco |
-| `gas_used` | a quantidade real de gás usado neste bloco |
-| `timestamp` | o tempo do bloco |
-| `extra_data` | dados adicionais arbitrários como bytes brutos |
-| `base_fee_per_gas` | o valor da taxa base |
-| `block_hash` | hash do bloco de execução |
-| `transactions_root` | hash raiz das transações na carga |
-| `withdrawal_root` | hash raiz das retiradas no payload |
-
-O próprio `execution_payload` contém o seguinte (note que é idêntico ao cabeçalho, exceto que, em vez do hash raiz das transações, ele inclui a lista real de transações e informações de retirada):
-
-| Campo | Descrição |
-|:------------------ |:------------------------------------------------------------------ |
-| `parent_hash` | hash do bloco pai |
-| `fee_recipient` | endereço da conta para pagar taxas de transação para |
-| `state_root` | hash raiz para o estado global após aplicar alterações neste bloco |
-| `receipts_root` | hash dos recibos da transação trie |
-| `logs_bloom` | estrutura de dados contendo logs de eventos |
-| `prev_randao` | valor usado na seleção do validador aleatório |
-| `block_number` | o número do bloco atual |
-| `gas_limit` | gás máximo permitido neste bloco |
-| `gas_used` | a quantidade real de gás usado neste bloco |
-| `timestamp` | o tempo do bloco |
-| `extra_data` | dados adicionais arbitrários como bytes brutos |
-| `base_fee_per_gas` | o valor da taxa base |
-| `block_hash` | hash do bloco de execução |
-| `transações` | lista de transações a serem executadas |
-| `saques` | lista de objetos de retirada |
-
-A lista `withdrawals` contém objetos `withdrawal` estruturados da seguinte forma:
-
-| Campo | Descrição |
-|:---------------- |:----------------------------- |
-| `endereço` | endereço da conta que retirou |
-| `quantidade` | quantidade retirada |
-| `index` | valor do índice da retirada |
-| `validatorIndex` | valor do índice do validador |
-
-## Tempo de bloco {#block-time}
-
-O tempo do bloco refere-se ao tempo de separação dos blocos. No Ethereum, o tempo é dividido em doze unidades de segundos chamadas de "espaços". Em cada espaço, um único validador é selecionado para propor um bloco. Supondo que todos os validadores estejam online e totalmente funcionais, haverá um bloco em cada espaço, o que significa que o tempo de um bloco é de 12s. No entanto, ocasionalmente, os validadores podem estar offline quando chamados para propor um bloco, o que significa que os espaços podem às vezes ficar vazios.
-
-Essa implementação difere dos sistemas baseados em prova de trabalho, na qual os tempos de bloco são probabilísticos e ajustados de acordo com a dificuldade da meta de mineração do protocolo. O [tempo médio do bloco](https://etherscan.io/chart/blocktime) do Ethereum é um exemplo perfeito disso, no qual a transição de prova de trabalho para prova de participação pode ser claramente inferida com base na consistência do novo tempo do bloco de 12s.
-
-## Tamanho do bloco {#block-size}
-
-Uma observação final importante é que os blocos em si são delimitados por tamanho. Cada bloco tem um tamanho alvo de 15 milhões de gás, mas o tamanho dos blocos aumentar ou diminui de acordo com as demandas da rede, até o limite do bloco de 30 milhões de gás (2 vezes o tamanho do bloco de destino). O limite de gás do bloco pode ser ajustado para mais ou para menos em um fator de 1/1.024 em relação ao limite de gás do bloco anterior. Como resultado, os validadores podem alterar o limite de gás do bloco por meio de um consenso. A quantidade total de gás gasto por todas as transações no bloco deve ser inferior ao limite de gás do bloco. Isso é importante porque garante que os blocos não possam ser arbitrariamente grandes. Se os blocos pudessem ser arbitrariamente grandes, os nós completos com menos desempenho iriam gradualmente deixar de conseguir acompanhar a rede devido aos requisitos de espaço e velocidade. Quanto maior o bloco, maior o poder de computação necessário para processá-los a tempo para o próximo espaço. Essa força centralizadora é impedida com a limitação do tamanho dos blocos.
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Transações](/developers/docs/transactions/)
-- [Gás](/developers/docs/gas/)
-- [Prova de participação](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/dapps/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/dapps/index.md
deleted file mode 100644
index 7f028162580..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/dapps/index.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Introdução à aplicativos descentralizados (dapps)
-description:
-lang: pt-br
----
-
-Um aplicativo descentralizado (dapp) é um aplicativo construído em uma rede descentralizada que combina um [contrato inteligente](/developers/docs/smart-contracts/) e uma interface de usuário de front-end. Observe que no Ethereum os contratos inteligentes são acessíveis e transparentes – como APIs abertas — então, seu dapp pode até incluir um contrato inteligente que outra pessoa escreveu.
-
-## Pré-requisitos {#prerequisites}
-
-Antes de aprender sobre dapps, você deve entender sobre os [fundamentos da blockchain](/developers/docs/intro-to-ethereum/), ler sobre a rede Ethereum e como ela é descentralizada.
-
-## Definição de dapp {#definition-of-a-dapp}
-
-Um dapp tem seu código de back-end em execução em uma rede peer-to-peer descentralizada. Contraste isso com um aplicativo no qual o código de back-end está sendo executado em servidores centralizados.
-
-Um dapp pode ter código front-end e interfaces de usuário escritas em qualquer linguagem (como um aplicativo) que podem fazer chamadas para seu back-end. Além disso, o front-end dele pode ser hospedado em um sistema de armazenamento descentralizado, como [IPFS](https://ipfs.io/).
-
-- **Descentralizado**: os dapps operam no Ethereum, uma plataforma descentralizada pública aberta onde ninguém ou grupo tem controle
-- **Determinista** ou seja, eles desempenham a mesma função independentemente do ambiente em que são executados.
-- **Turing completo**: os dapps podem executar qualquer ação, dados os recursos necessários
-- **Isolado**: significa que eles são executados em um ambiente virtual conhecido como Ethereum Virtual Machine para que, se o contrato inteligente tiver um bug, não dificultará o funcionamento normal da rede blockchain
-
-### Sobre contratos inteligentes {#on-smart-contracts}
-
-Para introduzir dapps, precisamos introduzir contratos inteligentes (que são dapps de back-end, para assim dizer). Para obter uma visão geral detalhada, vá para a nossa seção sobre [ contratos inteligentes](/developers/docs/smart-contracts/).
-
-Um contrato inteligente é um código presente na blockchain Ethereum e funciona exatamente como programado. Uma vez que eles são implantados na rede, você não pode alterá-los. Os dapps podem ser descentralizados porque são controlados pela lógica escrita no contrato, não por um indivíduo ou empresa. Isso também significa que você precisa projetar seus contratos com muito cuidado e testá-los cuidadosamente.
-
-## Benefícios do desenvolvimento de dapps {#benefits-of-dapp-development}
-
-- **Zero tempo de inatividade**: uma vez que o contrato inteligente é implementado na base de um aplicativo e na blockchain, a rede como um todo sempre será capaz de atender clientes que procuram interagir com o contrato. Os atores mal-intencionados, portanto, não podem lançar ataques de negação de serviço direcionados a dapps individuais.
-- **Privacidade**: você não precisa fornecer identidade real para implantar ou interagir com um dapp.
-- **Resistância à censura**: nenhuma entidade na rede pode impedir que os usuários enviem transações, implantem dapps ou leiam dados da blockchain.
-- **Completar a integridade dos dados**: os dados armazenados na blockchain são imutáveis e indiscutíveis, graças aos primitivos criptográficos. Atores mal-intencionados não podem forjar transações ou outros dados que já foram tornados públicos.
-- **Computação sem confiança/comportamento verificável** – Contratos inteligentes podem ser analisados e têm garantia de execução de maneiras previsíveis, sem a necessidade de confiar em uma autoridade central. Isso não é verdade nos modelos tradicionais; por exemplo, quando usamos sistemas bancários on-line, temos que confiar que as instituições financeiras não usarão indevidamente nossos dados financeiros, adulterarão registros ou serão hackeadas.
-
-## Benefícios do desenvolvimento de dapps {#drawbacks-of-dapp-development}
-
-- **Manutenção**: os dapps podem ser mais difíceis de manter, porque o código e os dados publicados na blockchain são mais difíceis de modificar. É difícil para os desenvolvedores fazerem atualizações em seus dapps (ou nos dados armazenados sob um dapp) uma vez que eles foram implantados, mesmo se bugs ou riscos de segurança forem identificados em uma versão antiga.
-- **Impactos no desempenho**: há um grande impacto no desempenho, e o dimensionamento é realmente difícil. Para alcançar o nível de segurança, integridade, transparência e confiabilidade que o Ethereum aspira, cada nó executa e armazena cada transação. Além disso, o consenso de prova de participação também leva tempo.
-- **Congestionamento da rede **: pelo menos no modelo atual, se um dapp estiver usando muitos recursos computacionais, toda a rede é apoiada. Atualmente, a rede só é capaz de processar cerca de 10 transações por segundo; se as transações estiverem sendo enviadas mais rápido do que isso, o pool de transações não confirmadas poderá aumentar rapidamente.
-- **Experiência do usuário**: pode ser mais difícil projetar experiências amigáveis ao usuário porque o usuário final pode achar muito difícil configurar uma pilha de ferramentas necessária para interagir com a blockchain de uma forma verdadeiramente segura.
-- **Centralização**: soluções amigáveis para o usuário e amigáveis ao desenvolvedor construídas sobre a camada base do Ethereum podem acabar parecendo serviços centralizados. Por exemplo, tais serviços podem armazenar chaves ou outros pontos sensíveis do servidor de informações, servir um front-end usando um servidor centralizado ou executar uma lógica de negócios importante em um servidor centralizado antes de escrever na blockchain. A centralização elimina muitas (se não todas) das vantagens da blockchain sobre o modelo tradicional.
-
-## Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner}
-
-
-
-## Ferramentas para criar dapps {#dapp-tools}
-
-**Scaffold-ETH _: experimente rápido com Solidity usando um front-end que se adapta ao seu contrato inteligente._**
-
-- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
-- [Exemplo de dapp](https://punkwallet.io/)
-
-**Crie um aplicativo Eth_: crie aplicativos com a tecnologia Ethereum apenas com um comando._**
-
-- [GitHub](https://github.com/paulrberg/create-eth-app)
-
-**One Click Dapp _: ferramenta FOSS para gerar front-end de dapp de um [ABI](/glossary/#abi)._**
-
-- [oneclickdapp.com](https://oneclickdapp.com)
-- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1)
-
-**Etherflow _: ferramenta FOSS para desenvolvedores de Ethereum testar seus nós e compor e depurar chamadas RPC do navegador._**
-
-- [etherflow.quiknode.io](https://etherflow.quiknode.io/)
-- [GitHub](https://github.com/abunsen/etherflow)
-
-**thirdweb _- SDKs em todos os idiomas, contratos inteligentes, ferramentas e infraestrutura para o desenvolvimento da web3._**
-
-- [Página inicial](https://thirdweb.com/)
-- [Documentação](https://portal.thirdweb.com/)
-- [GitHub](https://github.com/thirdweb-dev/)
-
-**Crossmint - _Plataforma de desenvolvimento web3 de nível empresarial para implantar contratos inteligentes, habilitar pagamentos com cartão de crédito e entre cadeias, e usar APIs para criar, distribuir, vender, armazenar e editar NFTs._**
-
-- [crossmint.com](https://www.crossmint.com)
-- [Documentação](https://docs.crossmint.com)
-- [Discord](https://discord.com/invite/crossmint)
-
-## Leitura adicional {#further-reading}
-
-- [Ver dapps](/dapps)
-- [A arquitetura de um aplicativo Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-- [Um guia de 2021 para aplicativos descentralizados](https://limechain. tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_
-- [O que são aplicativos descentralizados?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_
-- [Dapps populares](https://www.alchemy.com/dapps) - _Alchemy_
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Introdução à pilha de Ethereum](/developers/docs/ethereum-stack/)
-- [Estruturas de desenvolvimento](/developers/docs/frameworks/)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/evm/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/evm/index.md
deleted file mode 100644
index a85c2a3f341..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/evm/index.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Máquina virtual do Ethereum (EVM)
-description: Uma introdução à máquina virtual do Ethereum e como ela se relaciona com o estado, as transações e os contratos inteligentes.
-lang: pt-br
----
-
-A Máquina Virtual Ethereum (EVM, em inglês) é um ambiente virtual descentralizado que executa códigos de forma consistente e segura em todos os nós do Ethereum. Os "nós" executam a EVM para executar contratos inteligentes, usando "[gas](/gas/)" para medir o esforço computacional necessário para [operações](/developers/docs/evm/opcodes/), garantindo a alocação eficiente de recursos e a segurança da rede.
-
-## Pré-requisitos {#prerequisites}
-
-Alguma familiaridade básica com a terminologia comum em ciência da computação, como [bytes](https://wikipedia.org/wiki/Byte), [memória](https://wikipedia.org/wiki/Computer_memory) e [pilha](https://wikipedia.org/wiki/Stack_(abstract_data_type)) é necessária para entender a EVM. Também recomendamos se familiarizar com conceitos de criptografia/cadeia de blocos, como [funções hash](https://wikipedia.org/wiki/Cryptographic_hash_function) e a [árvore Merkle](https://wikipedia.org/wiki/Merkle_tree).
-
-## Do livro-razão para a máquina de estado {#from-ledger-to-state-machine}
-
-A analogia de um 'livro-razão distribuído' é muitas vezes usada para descrever blockchains como o Bitcoin, que permite uma moeda descentralizada usando ferramentas fundamentais de criptografia. O livro-razão mantém um registro de atividades que deve aderir a um conjunto de regras que regem o que alguém pode e não pode fazer para modificar o livro-razão. Por exemplo, um endereço de Bitcoin não pode gastar mais Bitcoin do que o recebido previamente. Essas regras sustentam todas as transações em Bitcoin e em muitas outras blockchains.
-
-Embora Ethereum tenha sua própria criptomoeda nativa (Ether), que segue quase exatamente as mesmas regras intuitivas, ele também permite dispor de uma função muito mais poderosa: [os contratos inteligentes](/developers/docs/smart-contracts/). Para este recurso mais complexo, uma analogia mais sofisticada é necessária. Em vez de um livro-razão distribuído, Ethereum é uma [máquina de estado distribuída](https://wikipedia.org/wiki/Finite-state_machine). O estado do Ethereum é uma grande estrutura de dados que contém não apenas todas as contas e saldos, mas também um _estado da máquina_, que pode mudar de bloco para bloco de acordo com um conjunto predefinido de regras, as quais podem executar código de máquina arbitrário. As regras específicas para mudar o estado de bloco em bloco são definidas pela EVM.
-
- _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## A função de transição do estado Ethereum {#the-ethereum-state-transition-function}
-
-A EVM se comporta como uma função matemática seria: de acordo com a entrada, ele produz uma saída determinística. Portanto, é bastante útil descrever mais formalmente o Ethereum como tendo uma **função de transição de estado**:
-
-```
-Y(S, T)= S'
-```
-
-Dado um antigo estado `(S)` e um novo conjunto de transações válidas `(T)`, a função de transição de estado de Ethereum `Y(S, T)` produz um novo estado de saída válido `S'`
-
-### Estado {#state}
-
-No contexto do Ethereum, o estado é uma enorme estrutura de dados chamada [árvore de Merkle Patricia modificada](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), que mantém todas as [contas](/developers/docs/accounts/) vinculadas por hashes e redutíveis a um único hash raiz armazenado na cadeia de blocos.
-
-### Transações {#transactions}
-
-Transações são instruções assinadas criptograficamente de contas. Existem dois tipos de transações: as que resultam em chamadas de mensagem e as que resultam na criação de contratos.
-
-A criação do contrato resulta na criação de uma nova conta de contrato que contém o bytecode compilado do [contrato inteligente](/developers/docs/smart-contracts/anatomy/). Sempre que outra conta faz uma mensagem de chamada a esse contrato, ele executa seu bytecode.
-
-## Instruções da EVM {#evm-instructions}
-
-A EVM é executada como uma [máquina de pilha](https://wikipedia.org/wiki/Stack_machine) com uma profundidade de 1.024 itens. Cada item é uma palavra de 256 bits, que foi escolhida para facilitar o uso com criptografia de 256 bits (como hashes Keccak-256 ou assinaturas secp256k1).
-
-Durante a execução, a EVM mantém uma _memória transiente_ (como um array de bytes direcionado por palavra) que não persiste entre as transações.
-
-Os contratos, no entanto, contêm uma árvore Merkle Patricia de _armazenamento_ (como um array direcionado por palavras) associada com a conta em questão e parte do estado global.
-
-O bytecode compilado do contrato inteligente executa como um número de [opcodes de EVM](/developers/docs/evm/opcodes), que realizam operações padrão de stake como `XOR`, `AND`, `ADD`, `SUB` etc. A EVM também implementa um número de operações de stake específicas da blockchain, como `ADDRESS`, `BALANCE`, `BLOCKHASH` etc.
-
- _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## Implementações da EVM {#evm-implementations}
-
-Todas as implementações da EVM devem aderir à especificação descrita no Ethereum Yellowpaper.
-
-Durante o histórico de 9 anos do Ethereum, a EVM passou por várias revisões e existem várias implementações da EVM em várias linguagens de programação.
-
-Os [clientes de execução Ethereum](/developers/docs/nodes-and-clients/#execution-clients) incluem uma implementação EVM. Além disso, existem várias implementações independentes, incluindo:
-
-- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_
-- [evmone](https://github.com/ethereum/evmone) - _C++_
-- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_
-- [revm](https://github.com/bluealloy/revm) - _Rust_
-
-## Leitura adicional {#further-reading}
-
-- [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [Jellopaper também conhecido como KEVM: semânticos de EVM em K](https://jellopaper.org/)
-- [O Beigepaper](https://github.com/chronaeon/beigepaper)
-- [Códigos de operação da EVM](https://www.ethervm.io/)
-- [Referência interativa dos códigos de operação da máquina virtual Ethereum](https://www.evm.codes/)
-- [Uma breve introdução à documentação do Solidy](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
-- [Dominando Ethereum - A Máquina Virtual Ethereum](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc)
-
-## Tópicos relacionados {#related-topics}
-
-- [Gás](/developers/docs/gas/)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/evm/opcodes/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/evm/opcodes/index.md
deleted file mode 100644
index 9f31f9c451c..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/evm/opcodes/index.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-title: Opcodes para o EVM
-description: Uma lista de todos os opcodes disponíveis para a máquina virtual do Ethereum.
-lang: pt-br
----
-
-## Visão geral {#overview}
-
-Essa é uma versão atualizada da página de referência EVM em [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). Também extraído do [Papel Amarelo](https://ethereum.github.io/yellowpaper/paper.pdf), do [Jello Paper](https://jellopaper.org/evm/) e da implementação [geth](https://github.com/ethereum/go-ethereum). Este artigo tem o intuito de ser uma referência acessível, mas não é particularmente rigorosa. Se quiser se certificar da exatidão e consciência de todos os casos extremos, é aconselhável usar o Jello Paper ou uma implementação do cliente.
-
-Procurando uma referência interativa? Confira [evm.codes](https://www.evm.codes/).
-
-Para operações com custos de gás dinâmico, consulte [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md).
-
-💡 Dica rápida: Para ver linhas inteiras, use `[shift] + scroll` para rolar horizontalmente na área de trabalho.
-
-| Pilha | Nome | Gás | Pilha inicial | Pilha resultante | Memória / Armazenamento | Observações |
-|:-----:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 00 | STOP | 0 | | | | halt execution |
-| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 |
-| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 |
-| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 |
-| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division |
-| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division |
-| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus |
-| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus |
-| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N |
-| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N |
-| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 |
-| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes |
-| 0C-0F | _invalid_ | | | | | |
-| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than |
-| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than |
-| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than |
-| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than |
-| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality |
-| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero |
-| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND |
-| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR |
-| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR |
-| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT |
-| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left |
-| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left |
-| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right |
-| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right |
-| 1E-1F | _invalid_ | | | | | |
-| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
-| 21-2F | _invalid_ | | | | | |
-| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract |
-| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei |
-| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx |
-| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender |
-| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei |
-| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` |
-| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes |
-| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data |
-| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes |
-| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode |
-| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
-| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes |
-| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` |
-| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes |
-| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
-| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 |
-| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `.` | `block.coinbase` | | endereço do proponente do bloco atual |
-| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block |
-| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block |
-| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon |
-| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block |
-| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
-| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei |
-| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block |
-| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
-| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
-| 4B-4F | _invalid_ | | | | | |
-| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it |
-| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
-| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory |
-| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory |
-| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage |
-| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage |
-| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest |
-| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` |
-| 58 | PC | 2 | `.` | `$pc` | | program counter |
-| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes |
-| 5A | GAS | 2 | `.` | `gasRemaining` | | |
-| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | write word to transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copy memory from one area to another ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
-| 5F | PUSH0 | 2 | `.` | `uint8` | | empurra o valor constante 0 para a pilha |
-| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack |
-| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack |
-| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack |
-| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack |
-| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack |
-| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack |
-| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack |
-| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack |
-| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack |
-| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack |
-| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack |
-| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack |
-| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack |
-| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack |
-| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack |
-| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack |
-| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack |
-| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack |
-| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack |
-| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack |
-| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack |
-| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack |
-| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack |
-| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack |
-| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack |
-| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack |
-| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack |
-| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack |
-| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack |
-| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack |
-| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack |
-| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack |
-| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack |
-| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack |
-| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack |
-| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack |
-| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack |
-| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack |
-| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack |
-| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack |
-| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack |
-| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack |
-| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack |
-| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack |
-| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack |
-| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack |
-| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack |
-| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack |
-| 90 | SWAP1 | 3 | `a, b` | `b, a` | | |
-| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | |
-| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | |
-| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | |
-| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
-| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) |
-| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
-| A5-EF | _invalid_ | | | | | |
-| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
-| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
-| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] |
-| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
-| F6-F9 | _invalid_ | | | | | |
-| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| FB-FC | _invalid_ | | | | | |
-| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
-| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract |
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/gas/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/gas/index.md
deleted file mode 100644
index 17050fe7020..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/gas/index.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: Gás e taxas
-description:
-lang: pt-br
----
-
-O gás é essencial para a rede Ethereum. É o combustível que permite que ele funcione, da mesma forma que um carro precisa de gasolina para funcionar.
-
-## Pré-requisitos {#prerequisites}
-
-Para entender melhor esta página, recomendamos que você leia primeiro sobre [transações](/developers/docs/transactions/) e [EVM](/developers/docs/evm/).
-
-## O que é gás? {#what-is-gas}
-
-Gás refere-se à unidade que mede a quantidade de esforço computacional necessário para executar operações específicas na rede Ethereum.
-
-Como cada transação Ethereum requer recursos computacionais para executar, estes recursos têm de ser pagos para garantir que o Ethereum não seja vulnerável a spam e não possa ficar preso em loops computacionais infinitos. Pagamentos por computação são feitos na forma de uma taxa de gas.
-
-A taxa de gas é **a quantia de gas usada para fazer alguma operação, multiplicada pelo custo da unidade de gas**. A taxa é paga independentemente da transação ter sucesso ou falhar.
-
- _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-Taxas de gas tem que ser pagas na moeda nativa do Ethereum, ether (ETH). Preços de gas são geralmente cotados em gwei, que é uma denominação do ETH. Cada gwei é igual a um bilionésimo de um ETH (0,000000001 ETH ou 10-9 ETH).
-
-Por exemplo, em vez de dizer que seu gás custa 0.000000001 Ether, pode-se dizer que ele custa 1 Gwei.
-
-A palavra 'gwei' é uma contração de 'giga-wei', significando 'bilhão de wei'. Um gwei é igual a um bilhão de wei. O próprio Wei (nomeado em homenagem a [Wei Dai](https://wikipedia.org/wiki/Wei Dai), criador do [B-Money](https://www.investopedia.com/terms/b/bmoney.asp)) é a menor unidade de ETH.
-
-## Como são calculadas as taxas de gás? {#how-are-gas-fees-calculated}
-
-Você pode definir a quantidade de gás que está disposto a pagar ao enviar uma transação. Ao oferecer uma certa quantidade de gás, você está fazendo um lance para que sua transação seja incluída no próximo bloco. Se você oferecer muito pouco, é menos provável que os validadores escolham sua transação para inclusão, o que significa que sua transação pode ser executada com atraso ou simplesmente não. Se você oferecer muito, pode desperdiçar algum ETH. Então, como você pode saber quanto deve pagar?
-
-O total de gás que você paga é dividido em dois componentes: a `base_fee` e a `priority fee` (gorjeta).
-
-A `base_fee` é definida pelo protocolo - você tem que pagar pelo menos este valor para que sua transação seja considerada válida. A `priority fee` é uma gorjeta que você adiciona à taxa base (base fee) para tornar sua transação atrativa para os validadores, para que eles a escolham para inclusão no próximo bloco.
-
-Uma transação que paga apenas a `base_fee` é tecnicamente válida, mas é improvável que seja incluída, porque não oferece incentivo aos validadores para a escolhê-la em detrimento de qualquer outra transação. A taxa de `priority` 'correta' é determinada pelo uso da rede no momento em que você envia sua transação - se houver muita demanda, então você pode ter que definir sua taxa de `priority` maior, mas quando há menos demanda você pode pagar menos.
-
-Por exemplo, digamos que Jordan tem que pagar a Taylor 1 ETH. Uma transferência de ETH requer 21.000 unidades de gás e a taxa básica é de 10 gwei. João inclui uma gorjeta de 2 gwei.
-
-A taxa total agora seria igual a:
-
-`unidades de gás usadas * (taxa de base + taxa de prioridade)`
-
-onde a `base_fee` é um valor definido pelo protocolo e a `priority fee` é um valor definido pelo usuário como gorjeta ao validador.
-
-ou seja, `21.000 * (10 + 2) = 252.000 gwei` (0.000252 ETH).
-
-Quando João enviar o dinheiro, 1,000252 ETH serão deduzidos da conta de João. Tomé receberá 1,0000 ETH. O validador recebe a gorjeta de 0,000042 ETH. A `taxa base` de 0,00021 ETH foi queimada.
-
-### Taxa base {#base-fee}
-
-Cada bloco tem uma taxa base que funciona como um preço de reserva. Para ser elegível para inclusão em um bloco, o preço oferecido por gás deve ser pelo menos igual à taxa base. A taxa base é calculada independentemente do bloco atual e, em vez disso, é determinada pelos blocos anteriores, tornando as taxas de transação mais previsíveis para os usuários. Quando o bloco é criado, esta **taxa base é "queimada"**, removendo-a de circulação.
-
-A taxa base é calculada por uma fórmula que compara o tamanho do bloco anterior (a quantidade de gás utilizada para todas as transações) com o tamanho do alvo. A taxa base aumentará em um máximo de 12,5% por bloco se o tamanho do bloco de destino for excedido. Esse crescimento exponencial torna economicamente inviável que o tamanho do bloco permaneça elevado indefinidamente.
-
-| Número do bloco | Gás incluído | Aumento de taxa | Taxa base atual |
-| --------------- | ------------:| ---------------:| ---------------:|
-| 1 | 15M | 0% | 100 gwei |
-| 2 | 30M | 0% | 100 gwei |
-| 3 | 30M | 12,5% | 112,5 gwei |
-| 4 | 30M | 12,5% | 126,6 gwei |
-| 5 | 30M | 12,5% | 142,4 gwei |
-| 6 | 30M | 12,5% | 160,2 gwei |
-| 7 | 30M | 12,5% | 180,2 gwei |
-| 8 | 30M | 12,5% | 202,7 gwei |
-
-Conforme a tabela acima, para criar uma transação no bloco número 9, uma carteira informará o usuário que a **taxa base máxima** a ser adicionada ao próximo bloco é a `taxa base atual * 112,5%` ou `202,7 gwei * 112,5% = 228,1 gwei`.
-
-Também é importante notar que, é improvável que veremos picos prolongados de blocos completos, devido à velocidade com que a taxa base aumenta antes de um bloco completo.
-
-| Número do bloco | Gás incluído | Aumento da taxa | Taxa base atual |
-| --------------- | ------------:| ---------------:| ---------------:|
-| 30 | 30M | 12,5% | 2705,6 gwei |
-| ... | ... | 12,5% | ... |
-| 50 | 30M | 12,5% | 28531,3 gwei |
-| ... | ... | 12,5% | ... |
-| 100 | 30M | 12,5% | 10302608,6 gwei |
-
-### Taxa de prioridade (gorjetas) {#priority-fee}
-
-A taxa de prioridade (gorjeta) incentiva os validadores a incluir uma transação no bloco. Sem gorjetas, os validadores achariam economicamente viável minerar blocos vazios, pois receberiam a mesma recompensa pelo bloco. Pequenas gorjetas dão aos validadores um incentivo mínimo para incluir uma transação. Para que as transações sejam executadas preferencialmente antes de outras transações no mesmo bloco, uma gorjeta maior pode ser adicionada para tentar ultrapassar as transações concorrentes.
-
-### Taxa máxima {#maxfee}
-
-Para executar uma transação na rede, os usuários podem especificar um limite máximo que estão dispostos a pagar para que a sua transação seja executada. Este parâmetro opcional é conhecido como `maxFeePerGas`. Para que uma transação seja executada, a taxa máxima deve exceder a soma da taxa base e da gorjeta. O remetente da transação é reembolsado pela diferença entre a taxa máxima e a soma da taxa base e da gorjeta.
-
-### Tamanho do bloco {#block-size}
-
-Cada bloco tem um tamanho alvo de 15 milhões de gás, mas o tamanho dos blocos aumentará ou diminuirá de acordo com a demanda da rede, até o limite do bloco de 30 milhões de gás (2x o tamanho do bloco alvo). O protocolo atinge um tamanho de bloco de equilíbrio de 15 milhões em média através do processo de _tentativa e erro_. Isso significa que se o tamanho do bloco for maior que o tamanho do bloco alvo, o protocolo aumentará a taxa base para o bloco a seguir. Da mesma forma, o protocolo diminuirá a taxa base se o tamanho do bloco for menor que o tamanho do bloco de destino. A quantidade pela qual a taxa base é ajustada é proporcional ao quão longe o tamanho do bloco atual está do alvo. [Mais sobre blocos](/developers/docs/blocks/).
-
-### Calculando taxas de gás na prática {#calculating-fees-in-practice}
-
-Você pode explicitamente declarar o quanto está disposto a pagar para que sua transação seja executada. No entanto, a maioria dos provedores de carteira definirá automaticamente uma taxa de transação recomendada (taxa base + taxa prioritária recomendada) para reduzir a quantidade de complexidade que pesa sobre seus usuários.
-
-## Porque as taxas de gás existem? {#why-do-gas-fees-exist}
-
-Em resumo, as taxas de gás ajudam a manter a rede Ethereum segura. Ao exigir uma taxa para cada cálculo executado na rede, evitamos que os maus atores enviem spam para a rede. Para evitar loops infinitos acidentais ou hostis ou outro desperdício de cálculo no código, cada transação deve definir um limite para quantas etapas de cálculo de execução de código ela pode usar. A unidade fundamental de cálculo é "gás".
-
-Embora uma transação inclua um limite, qualquer gás não usado em uma transação é devolvido ao usuário (ou seja, `taxa máxima - (taxa base + gorjeta)` é retornada).
-
- _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## Qual é o limite de gás? {#what-is-gas-limit}
-
-O limite de gás se refere à quantidade máxima de gás que você está disposto a consumir em uma transação. Transações mais complicadas envolvendo [contratos inteligentes](/developers/docs/smart-contracts/) exigem mais trabalho de cálculo, portanto, exigem um limite de gás mais alto do que um simples pagamento. Uma transferência ETH padrão requer um limite de gás de 21.000 unidades de gás.
-
-Por exemplo, se você colocar um limite de gás de 50.000 para uma simples transferência de ETH, a EVM consumirá 21.000 e você receberá de volta os 29.000 restantes. No entanto, se você especificar muito pouco gás, por exemplo, um limite de gás de 20.000 para uma simples transferência de ETH, a EVM consumirá suas 20.000 unidades de gás tentando cumprir a transação, mas não será concluída. A EVM então reverte quaisquer alterações, mas como o validador já fez 20 mil unidades de gás de trabalho, esse gás é consumido.
-
-## Por que as taxas de gás são tão altas? {#why-can-gas-fees-get-so-high}
-
-As altas taxas de gás são devidas à popularidade do Ethereum. Se houver muita demanda, os usuários devem oferecer valores mais altos de gorjeta e tentar superar as transações de outros usuários. Uma gorjeta mais alta pode aumentar a probabilidade de sua transação entrar no próximo bloco. Além disso, aplicativos de contratos inteligentes mais complexos podem estar realizando muitas operações para dar suporte a suas funções, fazendo com que consumam muito combustível.
-
-## Iniciativas para reduzir os custos do gás {#initiatives-to-reduce-gas-costs}
-
-As [atualizações de escalabilidade](/roadmap/) do Ethereum deverão em última análise resolver algumas das questões de taxas de gás que, por sua vez, permitirá que a plataforma processe milhares de transações por segundo e escale globalmente.
-
-A escalabilidade da camada 2 é uma iniciativa primária para melhorar significativamente os custos do gás, a experiência do usuário e a escalabilidade. [Mais sobre a escalabilidade de camada 2](/developers/docs/scaling/#layer-2-scaling).
-
-## Monitoramento de taxas de gás {#monitoring-gas-fees}
-
-Se você deseja monitorar os preços do gás, para poder enviar seu ETH por menos, pode usar muitas ferramentas diferentes, como:
-
-- [Etherscan Gas Tracker](https://etherscan.io/gastracker): _calculadora do preço do gas de uma transação_
-- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm): _uma extensão do Chrome para estimar o preço do gás e que suporta transações do tipo 0 e do tipo 2 EIP-1559._
-- [Calculadora de taxas de gás Cryptoneur](https://www.cryptoneur.xyz/gas-fees-calculator) _Calcule as taxas de gás em sua moeda local para diferentes tipos de transação na Rede principal, no Arbitrum e Polygon._
-
-## Ferramentas relacionadas {#related-tools}
-
-- [Gas Platform da Blocknative](https://www.blocknative.com/gas): _API para estimativas do gás desenvolvida pela plataforma global de dados mempool da Blocknative_
-
-## Leitura adicional {#further-reading}
-
-- [Explicação sobre o gás de Ethereum](https://defiprime.com/gas)
-- [Reduzindo o consumo de gás de seus Contratos Inteligentes](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
-- [Prova de participação em comparação à Prova de trabalho](https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/)
-- [Estratégias de otimização de gás para desenvolvedores](https://www.alchemy.com/overviews/solidity-gas-optimization)
-- [Documentos EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
-- [Recursos EIP-1559 de Tim Beiko](https://hackmd.io/@timbeiko/1559-resources).
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/index.md
deleted file mode 100644
index f2a2066354c..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/index.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Documentação sobre o desenvolvimento do Ethereum
-description: Introduzindo a documentação sobre o desenvolvimento da rede Ethereum.
-lang: pt-br
----
-
-O objetivo dessa documentação é ajudar você a criar utilizando o Ethereum. Ela cobre o Ethereum como um conceito, explica a tecnologia de pilha do Ethereum e documenta tópicos avançados para aplicativos e casos de uso mais complexos.
-
-Este é um esforço da comunidade de código aberto, então, não hesite em sugerir novos tópicos, adicionar novo conteúdo e fornecer exemplos sempre que você julgar ser útil. Toda a documentação é editável através do GitHub. Se não souber como, [siga estas instruções](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
-
-## Módulos de desenvolvimento {#development-modules}
-
-Se esta é sua primeira tentativa de desenvolvimento com o Ethereum, recomendamos começar do início e ir avançando como se fosse um livro.
-
-### Tópicos fundamentais {#foundational-topics}
-
-
-
-### Pilha Ethereum {#ethereum-stack}
-
-
-
-### Avançado {#advanced}
-
-
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/intro-to-ether/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/intro-to-ether/index.md
deleted file mode 100644
index 9342b086cff..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/intro-to-ether/index.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Introdução ao Ether
-description: Introdução de um desenvolvedor à criptomoeda ETHER.
-lang: pt-br
----
-
-## Pré-requisitos {#prerequisites}
-
-Para ajudá-lo a entender melhor esta página, recomendamos que você leia primeiro [Introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-## O que é criptomoeda? {#what-is-a-cryptocurrency}
-
-Uma criptomoeda é um meio de troca garantido por um livro-razão baseado em blockchain.
-
-Um meio de troca é qualquer coisa amplamente aceita como pagamento de bens e serviços, e um livro-razão é um armazenamento de dados que mantém o controle das transações. A tecnologia Blockchain permite que os usuários façam transações no livro-razão sem depender de terceiros de confiança para manter o livro-razão.
-
-A primeira criptomoeda foi o Bitcoin, criado por Satoshi Nakamoto. Desde o lançamento do Bitcoin em 2009, as pessoas fizeram milhares de criptomoedas em muitos blockchains diferentes.
-
-## O que é ether? {#what-is-ether}
-
-**Ether (ETH)** é a criptomoeda usada para muitas coisas na rede Ethereum. Fundamentalmente, essa é a única forma de pagamento aceitável para taxas de transação e, após [A Fusão](/roadmap/merge) (The Merge), é necessário ether para validar e propor blocos na Rede principal (Mainnet). O ether também é usado como uma forma primária de garantia nos mercados de crédito de [DeFi](/defi) como unidade de conta nos mercados NFT, como o pagamento ganho pela realização de serviços ou a venda de produtos do mundo real, entre outros.
-
-Ethereum permite que os desenvolvedores criem [**aplicativos descentralizados (dapps)**](/developers/docs/dapps), que compartilham um conjunto de capacidades de computação. Este pool compartilhado é finito, portanto Ethereum precisa de um mecanismo para determinar quem vai usá-lo. Caso contrário, um dapp poderia acidental ou maliciosamente consumir todos os recursos de rede, o que bloquearia o acesso de outros.
-
-A criptomoeda oferece suporte a um mecanismo de preços para o poder de computação do Ethereum. Quando os usuários querem fazer uma transação, devem pagar uma certa quantia em Ether para que sua transação seja reconhecida na blockchain. Estes custos de uso são conhecidos como [taxas de gás](/developers/docs/gas/), e a taxa de gás depende da quantidade de poder de computação necessária para executar a transação e a demanda em toda a rede por poder de computação no momento.
-
-Portanto, mesmo que um aplicativo malicioso tenha enviado um ciclo infinito, a transação acabaria sem ether e terminaria, permitindo que a rede voltasse ao normal.
-
-É [comum](https://www.reuters.com/article/us-crypto-currencies-lending-insight-idUSKBN25M0GP#:~:text=price%20of%20ethereum) [confundir](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845#:~:text=cryptocurrencies%20including%20ethereum) [](https://www.cnn.com/2021/03/14/tech/nft-art-buying/index.html#:~:text=price%20of%20ethereum) Ethereum e ether — quando as pessoas se referem ao "preço do Ethereum", estão descrevendo o preço do ether.
-
-## Como cunhar ether {#minting-ether}
-
-A cunhagem é o processo no qual o novo ether é criado no livro-razão do Ethereum. O protocolo Ethereum subjacente cria o novo ether. Não é possível que um usuário crie ether.
-
-O Ether é cunhado como recompensa para cada bloco proposto e em cada ponto de verificação da época para outras atividades de validação relacionadas à obtenção de consenso. O valor total emitido depende do número de validadores e do quanto de ether eles têm colocado. Essa emissão total é dividida igualmente entre os validadores no caso ideal de que todos os validadores são honestos e estão online, mas, na realidade, ele varia com base no desempenho do validador. Cerca de 1/8 da emissão total vai para o proponente do bloco; o restante é distribuído entre os outros validadores. Os proponentes do bloco também recebem gorjetas das taxas de transação e receitas relacionadas ao MEV, mas estas vêm de ether reciclado, não de novas emissões.
-
-## Como "queimar" ether {#burning-ether}
-
-Além de criar ether por meio de recompensas de bloco, o ether pode ser destruído por um processo chamado "burning". Quando o ether é queimado, ele é removido de circulação permanentemente.
-
-A queima de ether ocorre em todas as transações no Ethereum. Quando os usuários pagam por suas transações, uma taxa base de gás, definida pela rede de acordo com a demanda transacional, é destruída. Isso, juntamente com tamanhos de blocos variáveis e uma taxa máxima de gás, simplifica a estimativa da taxa de transação no Ethereum. Quando a demanda da rede é alta, os [blocos](https://etherscan.io/block/12965263) podem queimar mais ether do que gerar, compensando efetivamente a emissão de ether.
-
-Queimar a taxa base dificulta a capacidade de os produtores de blocos de manipular transações. Por exemplo, se os produtores de blocos recebessem a taxa base, eles poderiam incluir suas próprias transações gratuitamente e aumentar a taxa base para todos os demais. Como alternativa, eles poderiam reembolsar a taxa base para alguns usuários fora da cadeia, gerando um mercado de taxas de transação mais opaco e complexo.
-
-## Denominações do ether {#denominations}
-
-Uma vez que muitas transações no Ethereum são pequenas, o ether tem várias denominações que podem ser referenciadas por unidades menores de conta. Dessas denominações, Wei e gwei são particularmente importantes.
-
-Wei é a menor quantidade possível de ether, e, como resultado, muitas implementações técnicas, como o [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf), irão basear todos os cálculos em Wei.
-
-Gwei, abreviado de giga-wei, é frequentemente usado para descrever os custos de gás no Ethereum.
-
-| Denominação | Valor em ether | Uso comum |
-| ----------- | ---------------- | --------------------------------- |
-| Wei | 10-18 | Implementações técnicas |
-| Gwei | 10-9 | Taxas de gás legíveis por humanos |
-
-## Como transferir ether {#transferring-ether}
-
-Cada transação no Ethereum contém um campo `valor` que especifica a quantidade de ether a ser transferido, denominado em wei, para enviar do endereço do remetente para o endereço do destinatário.
-
-Quando o endereço do destinatário é um [contrato inteligente](/developers/docs/smart-contracts/), o ether transferido pode ser usado para pagar gás quando o contrato inteligente executa seu código.
-
-[Mais sobre transações](/developers/docs/transactions/)
-
-## Como consultar saldos de ether {#querying-ether}
-
-Os usuários podem consultar o saldo de ether de qualquer conta [](/developers/docs/accounts/) inspecionando o campo `saldo` da conta que mostra participações de ether denominadas em wei.
-
-[Etherscan](https://etherscan.io) é uma ferramenta popular para consultar saldos de endereços através de um aplicativo baseado na Web. Por exemplo, [esta página Etherscan](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae) mostra o saldo da Fundação Ethereum. Os saldos das contas também podem ser consultados usando carteiras ou diretamente fazendo solicitações aos nós.
-
-## Leitura adicional {#further-reading}
-
-- [Definindo Ether e Ethereum](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html): _CME Group_
-- [Ethereum Whitepaper](/whitepaper/): a proposta original para o Ethereum. Este documento inclui uma descrição do ether e os motivos subjacentes à sua criação.
-- [Calculadora Gwei](https://www.alchemy.com/gwei-calculator): use esta calculadora gwei para converter facilmente wei, gwei e ether. Basta conectar qualquer quantidade de wei, gwei ou ETH e calcular automaticamente a conversão.
-
-_Conhece algum recurso da comunidade que o ajudou? Edite esta página e adicione-o!_
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md
deleted file mode 100644
index bdabc90c531..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: Introdução à Ethereum
-description: Uma introdução do desenvolvedor de dapps aos conceitos principais do Ethereum.
-lang: pt-br
----
-
-## O que é uma blockchain? {#what-is-a-blockchain}
-
-Uma blockchain é melhor descrita como um banco de dados público atualizado e compartilhado entre muitos computadores em uma rede.
-
-"Block" refere-se ao fato de que os dados e o estado são armazenados em lotes sequenciais ou "blocos". Se você envia ETH para outra pessoa, os dados da transação precisam ser adicionados a um bloco para que ela seja bem-sucedida.
-
-"Chain" refere-se ao fato de cada bloco referenciar, criptograficamente, seu bloco-pai. Em outras palavras, os blocos são encadeados juntos. Os dados de um bloco não podem ser alterados sem mudar todos os blocos subsequentes, o que exigiria o consenso de toda a rede.
-
-Todos os computadores da rede têm de chegar a um acordo sobre cada novo bloco e sobre a cadeia como um todo. Estes computadores são conhecidos como "nós". Os nós garantem que todos interagindo com a blockchain tenham os mesmos dados. Para cumprir este acordo distribuído, as blockchains precisam de um mecanismo de consenso.
-
-O Ethereum utiliza um mecanismo de consenso baseado em [prova de participação](/developers/docs/consensus-mechanisms/pos/). Qualquer um que queira adicionar novos blocos à cadeia deve colocar ETH – a moeda nativa no Ethereum – como garantia e executar um software validador. Esses “validadores” podem então ser selecionados aleatoriamente para propor blocos que outros validadores verificam e adicionam à blockchain. Há um sistema de recompensas e penalidades que fortemente incentiva os participantes a serem honestos e estarem disponíveis online o máximo possível.
-
-Se você quiser ver como a cadeia de blocos faz hash dos dados e, subsequentemente, ao histórico de referência aos blocos, confira [esta demonstração](https://andersbrownworth. com/blockchain/blockchain) de Anders Brownworth e assista ao vídeo abaixo.
-
-Assista a Anders explicando hashes em cadeias de blocos:
-
-
-
-## O que é o Ethereum? {#what-is-ethereum}
-
-O Ethereum é uma cadeia de blocos com um computador embutido nela. Ele é a base para criar aplicativos e organizações de maneira descentralizada, sem permissão e resistente à censura.
-
-No universo Ethereum, existe um único computador canônico (chamado de Máquina virtual Ethereum, ou EVM) cujo estado todos na rede Ethereum concordam. Todos os que participam da rede Ethereum (todos os nós do Ethereum) mantêm uma cópia do estado deste computador. Além disso, qualquer participante pode transmitir uma solicitação para que esse computador execute um cálculo arbitrário. Sempre que tal solicitação é transmitida, outros participantes da rede verificam, validam e realizam ("executam") o cálculo. Isso provoca uma mudança de estado na EVM, que é incorporada e propagada em toda a rede.
-
-Os pedidos de cálculo são chamados de solicitações de transação; o registro de todas as transações, bem como o estado atual da EVM, é armazenado na cadeia de blocos que, por sua vez, é armazenada e aceita por todos os nós.
-
-Os mecanismos criptográficos garantem que, uma vez que as transações são verificadas como válidas e adicionadas à cadeia de blocos, elas não podem ser manipuladas mais tarde. Os mesmos mecanismos também garantem que todas as transações sejam assinadas e executadas com "permissões" apropriadas (ninguém mais além de Alice pode enviar ativos digitais da conta dela).
-
-## O que é ether? {#what-is-ether}
-
-**Ether (ETH)** é a criptomoeda nativa do Ethereum. O objetivo do ETH é possibilitar um mercado para cálculo. Tal mercado fornece um incentivo econômico para os participantes verificarem ou executarem solicitações de transação e fornecerem recursos computacionais para a rede.
-
-Qualquer participante que transmita uma solicitação de transação também deve oferecer alguma quantidade de ETH à rede como recompensa. A rede queimará parte da recompensa e concederá o restante a quem eventualmente fizer o trabalho de verificar a transação, executá-la, confirmá-la na blockchain e transmiti-la para a rede.
-
-O valor de ETH pago corresponde aos recursos necessários para fazer o cálculo. Essas recompensas também impedem que participantes mal-intencionados entupam intencionalmente a rede, ao solicitar a execução de computação infinita ou outros scripts com uso intensivo de recursos, pois esses participantes devem pagar pelos recursos de cálculo.
-
-O ETH também é usado para fornecer segurança criptoeconômica à rede de três maneiras principais: 1) é usado como meio de recompensar validadores que propõem bloqueios ou denunciam comportamento desonesto de outros validadores; 2) é envolvido pelos validadores, atuando como garantia contra comportamento desonesto – se os validadores tentarem se comportar mal, seu ETH pode ser destruído; 3) é usado para ponderar o peso dos "votos" para novos blocos propostos, alimentando a parte de escolha da bifurcação do mecanismo de consenso.
-
-## O que são contratos inteligentes? {#what-are-smart-contracts}
-
-Na prática, os participantes não escrevem um novo código toda vez que querem solicitar um cálculo da EVM. Em vez disso, os desenvolvedores de aplicativos carregam os programas (trechos de código reutilizáveis) para serem armazenados na EVM, para que os usuários solicitem a execução desses trechos de código com parâmetros variáveis. Precisamente, chamamos de contratos inteligentes a todos esses programas que são enviados e executados na rede.
-
-Em um nível muito básico, você pode pensar em um contrato inteligente como uma espécie de máquina de venda automática: um script que, quando chamado com determinados parâmetros, executa algumas ações ou cálculos se certas condições forem satisfeitas. Por exemplo, um simples contrato inteligente do fornecedor poderia criar e atribuir a propriedade de um ativo digital se o chamador enviar ETH para um destinatário específico.
-
-Qualquer desenvolvedor pode criar um contrato inteligente e torná-lo público na rede, usando a cadeia de blocos como sua camada de dados, por uma taxa paga à rede. Qualquer usuário pode chamar um contrato inteligente para executar seu código, sendo necessário pagar uma nova taxa à rede.
-
-Assim, com contratos inteligentes, os desenvolvedores podem criar e implantar arbitrariamente aplicativos e serviços voltados para usuários: mercados, instrumentos financeiros, jogos, etc.
-
-## Terminologia {#terminology}
-
-### Blockchain {#blockchain}
-
-A sequência de todos os blocos que foram registrados na rede Ethereum no histórico da rede. Assim chamado porque cada bloco contém uma referência ao bloco anterior, o que nos ajuda a manter uma ordenação sobre todos os blocos (e, portanto, sobre o histórico preciso).
-
-### ETH {#eth}
-
-**Ether (ETH)** é a criptomoeda nativa do Ethereum. Os usuários pagam ETH a outros usuários para que suas solicitações de execução de código sejam atendidas.
-
-[Mais sobre ETH](/developers/docs/intro-to-ether/)
-
-### EVM {#evm}
-
-A Máquina Virtual Ethereum é o computador virtual global em que o estado de cada participante da rede Ethereum é armazenado e aceito. Qualquer participante pode solicitar a execução do código arbitrário na EVM; a execução do código altera o estado da EVM.
-
-[Mais sobre a EVM](/developers/docs/evm/)
-
-### Nós {#nodes}
-
-Máquinas da vida real que estão armazenando o estado da EVM. Os nós se comunicam entre eles para propagar informações sobre o estado da EVM e novas mudanças de estado. Qualquer usuário também pode solicitar execução do código através da solicitação de execução do código de um nó. A própria rede Ethereum é a agregação de todos os nós do Ethereum e suas comunicações.
-
-[Mais sobre nós](/developers/docs/nodes-and-clients/)
-
-### Contas {#accounts}
-
-Onde o ETH é armazenado. Os usuários podem inicializar contas, depositar ETH nas contas e transferir ETH de suas contas para outros usuários. Contas e saldos de conta são armazenados em uma tabela grande na EVM, fazendo parte do estado geral da EVM.
-
-[Mais sobre contas](/developers/docs/accounts/)
-
-### Transações {#transactions}
-
-Um "pedido de transação" é o termo formal para um pedido de execução de código na EVM, e uma "transação" é uma solicitação de transação cumprida e a mudança associada no estado da EVM. Qualquer usuário pode transmitir um pedido de transação para a rede a partir de um nó. Para que a solicitação de transação afete realmente o estado da EVM acordado, ela deve ser validada, executada e "comprometida com a rede" por algum outro nó. A execução de qualquer código causa uma mudança de estado na EVM; após a aprovação, essa alteração de estado é transmitida para todos os nós da rede. Alguns exemplos de transações:
-
-- Envie X ETH da minha conta para a conta da Alice.
-- Publicar algum código de contrato inteligente no estado da EVM.
-- Executar o código do contrato inteligente no endereço X da EVM, com argumentos Y.
-
-[Mais sobre transações](/developers/docs/transactions/)
-
-### Blocos {#blocks}
-
-O volume de transações é muito alto, portanto, as transações são "autorizadas" em lotes ou blocos. Os blocos geralmente contêm dezenas de centenas de transações.
-
-[Mais sobre blocos](/developers/docs/blocks/)
-
-### Smart Contracts {#smart-contracts}
-
-Um trecho de código reutilizável (um programa) que um desenvolvedor publica no estado da EVM. Qualquer um pode solicitar que o código de contrato inteligente seja executado fazendo uma solicitação de transação. Como desenvolvedores podem escrever aplicativos executáveis arbitrários na EVM (jogos, mercados, instrumentos financeiros, etc.) ao publicar contratos inteligentes, esses geralmente também são chamados de [dapps, ou apps descentralizados](/developers/docs/dapps/).
-
-[Mais sobre contratos inteligentes](/developers/docs/smart-contracts/)
-
-## Leitura adicional {#further-reading}
-
-- [Whitepaper do Ethereum](/whitepaper/)
-- [Afinal, como funciona o Ethereum?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**NB** este recurso ainda é valioso, mas esteja ciente de que é anterior à [Fusão](/roadmap/merge) (The Merge) e, portanto, ainda se refere ao mecanismo de prova de trabalho do Ethereum, que agora é protegido pelo uso da [prova de participação](/developers/docs/consensus-mechanisms/pos))
-
-_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione-o!_
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Um guia do desenvolvedor para Ethereum, parte 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– uma exploração muito simples para iniciantes do Ethereum usando Python e web3.py_
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/networks/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/networks/index.md
deleted file mode 100644
index 7a90684867e..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/networks/index.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: Redes
-description: Uma visão geral das redes Ethereum e onde obter ether (ETH) da rede de testes para testar seu aplicativo.
-lang: pt-br
----
-
-Redes Ethereum são grupos de computadores conectados que se comunicam usando o protocolo Ethereum. Só há uma Ethereum Mainnet, mas redes independentes seguindo as mesmas regras de protocolo podem ser criadas para finalidade de testes e desenvolvimento. Há várias "redes" independentes que seguem o protocolo sem interagir uma com a outra. Você pode até iniciar uma localmente no seu próprio computador para testar seus contratos inteligentes e apps web3.
-
-Sua conta Ethereum funcionará nas diferentes redes, mas o saldo da sua conta e o histórico de transações não serão transferidos da rede Ethereum principal. Para fins de teste, é útil saber quais redes estão disponíveis e como obter a rede de testes ETH para brincar. Em geral, por razões de segurança, não é recomendado reutilizar contas da rede principal em redes de testes ou vice-versa.
-
-## Pré-requisitos {#prerequisites}
-
-Você deveria entender as [noções básicas do Ethereum](/developers/docs/intro-to-ethereum/) antes de ler sobre as diferentes redes, pois as redes de teste lhe darão uma versão barata e segura do Ethereum para brincar.
-
-## Redes públicas {#public-networks}
-
-As redes públicas são acessíveis a qualquer pessoa no mundo com uma conexão à Internet. Qualquer um pode ler ou criar transações em uma blockchain pública e validar as transações que estão sendo executadas. O consenso entre os pares decide sobre a inclusão de transações e o estado da rede.
-
-### Rede Principal Ethereum {#ethereum-mainnet}
-
-A rede principal é a blockchain de produção Ethereum pública primária, onde as transações de valor real ocorrem no livro-razão distribuído.
-
-Quando as pessoas e as exchanges discutem os preços do ETH, eles estão falando sobre a rede principal ETH.
-
-### Redes de Testes Ethereum {#ethereum-testnets}
-
-Além da rede principal, existem redes de teste públicas. Essas são redes usadas por desenvolvedores de protocolo ou desenvolvedores de contrato inteligente para testar as atualizações de protocolo e também os contratos inteligentes em potencial em um ambiente de produção antes da implantação na rede principal. Pense nisso como um análogo a servidores de produção versus servidores de teste.
-
-Você deve testar qualquer código de contrato que você escrever em uma rede de testes antes de publicar na Rede principal. Entre os dapps que se integram com contratos inteligentes existentes, a maioria dos projetos tem cópias publicadas em redes de teste.
-
-A maioria das redes de teste começou usando um mecanismo de consenso de prova de autoridade permitido. Isso significa que um pequeno número de nós é escolhido para validar as transações e criar novos blocos, incluindo sua identidade no processo. Como alternativa, algumas redes de testes apresentam um mecanismo de consenso de prova de participação aberto, no qual todos podem testar a execução de um validador, assim como a Rede principal do Ethereum.
-
-ETH em redes de teste (testnets) supostamente não tem valor real; entretanto, tem sido criados mercados para certos tipos de ETH de testnet que têm se tornado escassos ou difíceis de se obter. Como você precisa do ETH para realmente interagir com o Ethereum (mesmo em redes de teste), a maioria das pessoas obtém ETH em redes de teste gratuitamente em torneiras (faucets). A maioria das torneiras são aplicativos Web em que você pode inserir um endereço para o qual deseja que o ETH seja enviado.
-
-#### Qual rede de testes devo usar?
-
-As duas redes de testes públicas que os desenvolvedores dos clientes estão atualmente mantendo são Sepolia e Goerli. Sepolia é uma rede para desenvolvedores de contrato e aplicativos para testar seus aplicativos. A rede Goerli permite que os desenvolvedores de protocolo testem atualizações de rede e permite que os participantes façam testes usando validadores.
-
-#### Sepolia {#sepolia}
-
-****Sepolia é a rede de teste padrão recomendada para desenvolvimento de aplicativos. A rede Sepolia usa um conjunto de validadores autorizados. É bastante novo, o que significa que seu estado e história são bastante pequenos. Isso significa que a rede é rápida para sincronizar e que a execução de um nó requer menos armazenamento. Isso é útil para usuários que desejam ativar rapidamente um nó e interagir diretamente com a rede.
-
-- Conjunto de validadores fechado, controlado pelo cliente & equipes de teste
-- Nova rede de teste, menos aplicativos implantados que outras redes de teste
-- A sincronização rápida e a execução de um nó exigem um espaço de disco mínimo
-
-##### Recursos
-
-- [Website](https://sepolia.dev/)
-- [GitHub](https://github.com/eth-clients/sepolia)
-- [Otterscan](https://sepolia.otterscan.io/)
-- [Etherscan](https://sepolia.etherscan.io)
-- [Blockscout](https://eth-sepolia.blockscout.com/)
-
-##### Faucets
-
-- [Faucet do QuickNode Sepolia](https://faucet.quicknode.com/drip)
-- [Grabteeth](https://grabteeth.xyz/)
-- [Faucet de PoW](https://sepolia-faucet.pk910.de/)
-- [Faucet da Carteira Coinbase | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet)
-- [Faucet do Alchemy Sepolia](https://sepoliafaucet.com/)
-- [Faucet do Infura Sepolia](https://www.infura.io/faucet)
-- [Faucet da Chainstack Sepolia](https://faucet.chainstack.com/sepolia-faucet)
-- [Faucet do ecossistema Ethereum](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia)
-
-#### Goerli _(suporte a longo prazo)_ {#goerli}
-
-_Nota: [a rede de testes Goerli está obsoleta](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) e será substituída por [Holesovice](https://github.com/eth-clients/holesovice) em 2023. Considere migrar seus aplicativos para a Sepolia._
-
-Goerli é a rede de testes usada para testar a validação e staking. A rede Goerli está aberta para usuários que queiram executar um validador na rede de testes. Os participantes que desejam testar atualizações de protocolo antes de serem implantados na rede principal devem, portanto, usar a Goerli.
-
-- Conjunto de validadores abertos, com o qual os participantes podem testar atualizações de rede
-- Estado grande, útil para testar interações complexas de contratos inteligentes
-- Mais longo para sincronizar e requer mais armazenamento para executar um nó
-
-##### Recursos
-
-- [Site](https://goerli.net/)
-- [GitHub](https://github.com/eth-clients/goerli)
-- [Etherscan](https://goerli.etherscan.io)
-- [Blockscout](https://eth-goerli.blockscout.com/)
-
-##### Faucets
-
-- [Faucet Goerli do QuickNode](https://faucet.quicknode.com/drip)
-- [Grabteeth](https://grabteeth.xyz/)
-- [Faucet de PoW](https://goerli-faucet.pk910.de/)
-- [Faucet Paradigm](https://faucet.paradigm.xyz/)
-- [Faucet Alchemy Goerli](https://goerlifaucet.com/)
-- [Todas as faucets do nó Goerli](https://www.allthatnode.com/faucet/ethereum.dsrv)
-- [Coinbase Wallet Faucet | Goerli](https://coinbase.com/faucets/ethereum-goerli-faucet)
-- [Faucet Chainstack Goerli](https://faucet.chainstack.com/goerli-faucet)
-
-Para iniciar um Validador na rede de testes Goerli, use a barra de inicialização ["validador goerli barato"](https://goerli.launchpad.ethstaker.cc/en/) do ethstaker.
-
-### Redes de testes de camada 2 {#layer-2-testnets}
-
-[Camada 2 (L2)](/layer-2/) é um termo coletivo para descrever um conjunto específico de soluções de escalabilidade do Ethereum. Uma camada 2 é uma cadeia de blocos separada que estende o Ethereum e herda as garantias de segurança do Ethereum. Normalmente, as redes de teste de camada 2 estão fortemente associadas às redes de testes públicas do Ethereum.
-
-#### Arbitrum Goerli {#arbitrum-goerli}
-
-Uma rede de testes para [Arbitrum](https://arbitrum.io/).
-
-##### Faucets
-
-- [Faucet do Chainlink](https://faucets.chain.link/)
-
-#### Optimistic Goerli {#optimistic-goerli}
-
-Uma rede de testes para [Optimism](https://www.optimism.io/).
-
-##### Faucets
-
-- [Faucet Paradigm](https://faucet.paradigm.xyz/)
-- [Coinbase Wallet Faucet | Optimism Goerli](https://coinbase.com/faucets/optimism-goerli-faucet)
-
-#### Starknet Goerli {#starknet-goerli}
-
-Uma rede de teste para [Starknet](https://www.starknet.io).
-
-##### Faucets
-
-- [Faucet da Starknet](https://faucet.goerli.starknet.io)
-
-## Redes privadas {#private-networks}
-
-Uma rede Ethereum é uma rede privada se seus nódulos não estiverem conectados a uma rede pública (ex: Rede principal e rede de testes). Neste contexto, privado significa apenas reservado ou isolado, em vez de protegido ou seguro.
-
-### Redes de desenvolvimento {#development-networks}
-
-Para desenvolver um aplicativo Ethereum, você deve executá-lo em uma rede privada para ver como funciona antes de implantá-lo. Tal como você pode criar um servidor local em seu computador para desenvolvimento Web, você pode criar uma instância local de blockchain para testar seu dapp. Isso permite uma iteração muito mais rápida do que uma rede de testes pública.
-
-Existem projetos e ferramentas dedicadas a ajudá-lo com isso. Saiba mais sobre [redes de desenvolvimento](/developers/docs/development-networks/).
-
-### Redes de consórcio {#consortium-networks}
-
-O processo de consenso é controlado por um conjunto predefinido de nódulos confiáveis. Por exemplo, uma rede privada de instituições acadêmicas conhecidas, cada uma administrando um único nódulo, e os blocos são validados por um limite de signatários na rede.
-
-Se uma rede pública Ethereum é como a internet pública, uma rede de consórcio é como uma intranet privada.
-
-## Ferramentas relacionadas {#related-tools}
-
-- [Chainlist](https://chainlist.org/) _Lista de redes EVM para conectar carteiras e fornecedores aos identificadores de cadeia e rede apropriados_
-- [/Cadeias baseadas em EVM](https://github.com/ethereum-lists/chains) _Repositório do GitHub com metadados de cadeias que alimenta a Chainlist_
-
-## Leitura adicional {#further-reading}
-
-- [Proposta: Ciclo de vida previsível da rede de testes do Ethereum](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17)
-- [A evolução das redes de testes do Ethereum](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/transactions/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/transactions/index.md
deleted file mode 100644
index 47070a5580d..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/transactions/index.md
+++ /dev/null
@@ -1,221 +0,0 @@
----
-title: Transações
-description: 'Uma visão geral das transações no Ethereum: como elas funcionam, sua estrutura de dados e como enviá-las através de um aplicativo.'
-lang: pt-br
----
-
-Transações são instruções assinadas criptograficamente de contas. Uma conta iniciará uma transação para atualizar o estado da rede Ethereum. A transação mais simples é transferir ETH de uma conta para outra.
-
-## Pré-Requisitos {#prerequisites}
-
-Mas para ajudá-lo a entender melhor esta página, recomendamos que você primeiro leia [Contas](/developers/docs/accounts/), [Transações](/en/developers/docs/transactions/)e nossa [introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-## O que é uma transação? {#whats-a-transaction}
-
-Uma transação Ethereum refere-se a uma ação iniciada por uma conta de propriedade externa, ou seja, uma conta gerenciada por um ser humano, não um contrato. Por exemplo, se Bob enviar a Alice 1 ETH, a conta de Bob deverá ser debitada e a de Alice deverá ser creditada. Esta ação de mudança de estado ocorre no âmbito de uma transação.
-
- _Diagrama adaptado de [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-Transações que alteram o estado da EVM precisam ser transmitidas para toda a rede. Qualquer nó pode transmitir uma solicitação para que uma transação seja executada na EVM; depois que isso acontecer, um validador executará a transação e propagará a mudança de estado resultante para o restante da rede.
-
-As transações exigem uma taxa e devem ser incluídas em um bloco validado. Para tornar esta visão geral mais simples, cobriremos as taxas de gás e validação em outro lugar.
-
-Uma transação enviada inclui as seguintes informações:
-
-- `from`: o endereço do remetente que assinará a transação. Ela será uma conta de propriedade externa, pois as contas de contrato não podem enviar transações.
-- `para`: o endereço de recebimento (se for uma conta de propriedade externa, a transação transferirá o valor. Se for uma conta de contrato, a transação executará o código do contrato)
-- `signature`: o identificador do remetente. Ele é gerado quando a chave privada do remetente assina a transação e confirma que o remetente autorizou essa transação.
-- `nonce`: um contador de incremento sequencial que indica o número da transação a partir da conta.
-- `value`: a quantidade de ETH a transferir do remetente para o destinatário (denominado em WEI, onde 1ETH equivale a 1e+18wei).
-- `input data` – campo opcional para incluir um dado arbitrário
-- `gasLimit`: a quantidade máxima de gás que pode ser consumida pela transação. A [EVM](/developers/docs/evm/opcodes) especifica as unidades de gás necessárias para cada etapa computacional
-- `maxPriorityFeePerGas`: o preço máximo do gás consumido a ser incluído como gorjeta para o validador.
-- `maxFeePerGas`: a taxa máxima por unidade de gás disposta a ser paga pela transação (inclusive de `baseFeePerGas` e `maxPriorityFeePerGas`)
-
-Gás é uma referência ao cálculo necessário para processar a transação por um validador. Os usuários têm que pagar uma taxa por este cálculo. O `gasLimit` e o `maxPriorityFeePerGas` determinam a taxa máxima de transação paga ao validador. [Mais sobre gás](/developers/docs/gas/).
-
-O objeto da transação ficará um pouco assim:
-
-```js
-{
- from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
- to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
- gasLimit: "21000",
- maxFeePerGas: "300",
- maxPriorityFeePerGas: "10",
- nonce: "0",
- value: "10000000000"
-}
-```
-
-Mas um objeto de transação deve ser assinado usando a chave privada do remetente. Isso prova que a transação só poderia ter vindo do remetente e não foi enviada fraudulentamente.
-
-Um cliente Ethereum como o Geth irá lidar com este processo de assinatura.
-
-Exemplo de chamada [JSON-RPC](/developers/docs/apis/json-rpc):
-
-```json
-{
- "id": 2,
- "jsonrpc": "2.0",
- "method": "account_signTransaction",
- "params": [
- {
- "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
- "gas": "0x55555",
- "maxFeePerGas": "0x1234",
- "maxPriorityFeePerGas": "0x1234",
- "input": "0xabcd",
- "nonce": "0x0",
- "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
- "value": "0x1234"
- }
- ]
-}
-```
-
-Exemplo de resposta:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 2,
- "result": {
- "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
- "tx": {
- "nonce": "0x0",
- "maxFeePerGas": "0x1234",
- "maxPriorityFeePerGas": "0x1234",
- "gas": "0x55555",
- "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
- "value": "0x1234",
- "input": "0xabcd",
- "v": "0x26",
- "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
- "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
- "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
- }
- }
-}
-```
-
-- o `raw` é a transação assinada no [Prefixo de Tamanho Recursivo (RLP)](/developers/docs/data-structures-and-encoding/rlp) na forma codificada
-- `tx` é a transação assinada no formato JSON
-
-Com o hash da assinatura, a transação pode ser provada criptograficamente de que veio do remetente e enviada para a rede.
-
-### O campo de dados {#the-data-field}
-
-A grande maioria das transações acessa um contrato de uma conta de propriedade externa. A maioria dos contratos é escrita em Solidity e interpreta seus campos de dados de acordo com a [interface binária do aplicativo (ABI)](/glossary/#abi).
-
-Os primeiros quatro bytes especificam qual função chamar, usando o hash do nome e dos argumentos da função. Às vezes, você pode identificar a função do seletor usando [este banco de dados](https://www.4byte.directory/signatures/).
-
-O restante dos dados da chamada são os argumentos, [codificado conforme especificado nas especificações ABI](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding).
-
-Por exemplo, vejamos [esta transação](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1). Use **Clique para ver mais** para conferir os dados de chamada.
-
-O seletor de função é `0xa9059cbb`. Existem várias [funções conhecidas com esta assinatura](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). Nesse caso, [o código-fonte do contrato](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) foi carregado para o Etherscan, então sabemos que a função é `transfer(address, uint256)`.
-
-O resto dos dados é:
-
-```
-0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
-000000000000000000000000000000000000000000000000000000003b0559f4
-```
-
-De acordo com as especificações da ABI, valores inteiros (como endereços, que são inteiros de 20 bytes) aparecem na ABI como palavras de 32 bytes, preenchidos com zeros na frente. Portanto, sabemos que o endereço `para` é [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279). O `valor` é 0x3b0559f4 = 990206452.
-
-## Tipos de transações {#types-of-transactions}
-
-No Ethereum existem alguns tipos diferentes de transações:
-
-- Transações regulares: uma transação de uma conta para outra.
-- Transações de implantação do contrato: uma transação sem um endereço 'para', onde o campo de dados é usado para o código do contrato.
-- Execução de um contrato: uma transação que interage com um contrato inteligente implantado. Nesse caso, o endereço "para" é o endereço do contrato inteligente.
-
-### Sobre gás {#on-gas}
-
-Como mencionado, as transações custam [gás](/developers/docs/gas/) para serem executadas. Transações de transferência simples requerem 21.000 unidades de gás.
-
-Então para Bob enviar a Alice 1 ETH para `baseFeePerGas` de 190 gwei e `maxPriorityFeePerGas` de 10 gwei, Bob precisará pagar a seguinte taxa:
-
-```
-(190 + 10) * 21000 = 4.200.000 gwei
---ou--
-0,0042 ETH
-```
-
-A conta de Bob será debitada **-1,0042 ETH** (1 ETH para Alice + 0,0042 ETH em taxas de gás)
-
-A conta de Alice será creditada **+1,0 ETH**
-
-A taxa base queimará **-0,00399 ETH**
-
-O validador mantém a gorjeta de **+0,000210 ETH**
-
-
- _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-Qualquer gás não usado em uma transação é reembolsado para a conta do usuário.
-
-### Interações de contratos inteligentes {#smart-contract-interactions}
-
-Gás é necessário para qualquer transação que envolva um contrato inteligente.
-
-Contratos inteligentes também podem conter funções conhecidas como [`visões`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) ou [`puras`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), as quais não alteram o estado do contrato. Dessa maneira, nenhum gás é necessário ao chamar essas funções de um EOA. A chamada RPC subjacente para esse cenário é [`eth_call`](/developers/docs/apis/json-rpc#eth_call)
-
-Diferentemente de quando acessadas usando `eth_call`, essas funções ` de visualização` ou `puras "` também são comumente chamadas internamente (ou seja, a partir do próprio contrato ou de outro contrato), o que custa gás.
-
-## Ciclo de vida de transação {#transaction-lifecycle}
-
-Quando uma transação é enviada, acontece o seguinte:
-
-1. Um hash de transação é gerado criptograficamente: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
-2. A transação é então transmitida para a rede e adicionada a um pool de transações que compreende todas as outras transações de rede pendentes.
-3. Um validador deve escolher sua transação e incluí-la em um bloco para verificar a transação e considerá-la "bem-sucedida".
-4. Com o passar do tempo, o bloco que contém sua transação será atualizado para "justificado" e depois "finalizado". Essas atualizações tornam muito mais certo de que sua transação foi bem-sucedida e nunca será alterada. Uma vez que um bloco é “finalizado”, ele só poderá ser alterado por um ataque na rede que custe muitos bilhões de dólares.
-
-## Uma demonstração visual {#a-visual-demo}
-
-Assista Austin mostrar as transações, gás e mineração.
-
-
-
-## Envelope de transação digitado {#typed-transaction-envelope}
-
-O Ethereum originalmente tinha um formato para transações. Cada transação possuía um emissor, custo de "queima", parâmetro de "queima", endereçamentos, valores, dados, v, r, e s. Esses campos são [codificados por RLP](/developers/docs/data-structures-and-encoding/rlp/), podendo se parecer com isto:
-
-`RLP ([emissor, taxa de "queima", parâmetros de "queima", destino, valor, dados, v, r, s])`
-
-O Ethereum evoluiu para apoiar vários tipos de transações, permitindo que novos recursos, como listas de acesso e [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) sejam implementados sem que isso afete os formatos de transação herdados.
-
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) é o que permite esse comportamento. Transações são interpretadas como:
-
-`TransactionType || TransactionPayload`
-
-Onde os campos são definidos como:
-
-- `TransactionType`: um número entre 0 e 0x7f, para um total de 128 tipos de transações possíveis.
-- `TransactionPayload`: um array de bytes arbitrário definido pelo tipo de transação.
-
-Baseado no valor do `TransactionType` , a transação pode ser classificada como
-
-1. **Transações do tipo 0 (legado):** O formato de transação original usado desde o lançamento do Ethereum. Eles não incluem recursos do [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), como cálculos dinâmicos de taxas de gás ou listas de acesso para contratos inteligentes. As transações legadas não têm um prefixo específico que indique seu tipo em sua forma serializada, começando com o byte `0xf8` ao usar a codificação [Prefixo de comprimento recursivo (RLP, na sigla em inglês)](/developers/docs/data-structures-and-encoding/rlp). O valor TransactionType para essas transações é `0x0`.
-
-2. **Transações do tipo 1:** Introduzidas na [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) como parte da [Melhoria de Berlim](/history/#berlin) do Ethereum, essas transações incluem um parâmetro `accessList`. Essa lista especifica endereços e chaves de armazenamento que a transação espera acessar, ajudando a reduzir potencialmente os custos de [gás](/developers/docs/gas/) para transações complexas que envolvem contratos inteligentes. As alterações de mercado da taxa EIP-1559 não estão incluídas nas transações do Tipo 1. As transações do tipo 1 também incluem um parâmetro `yParity`, que pode ser `0x0` ou `0x1`, indicando a paridade do valor y da assinatura secp256k1. Elas começam com o byte `0x01`, e seu valor TransactionType é `0x1`.
-
-3. **Transações do Tipo 2**, comumente conhecidas como transações EIP-1559, são transações introduzidas no [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), na [Melhoria Londres](/history/#london) do Ethereum. Elas se tornaram o tipo de transação padrão na rede Ethereum. Essas transações introduzem um novo mecanismo de mercado de taxas que melhora a previsibilidade ao separar a taxa de transação em uma taxa base e uma taxa de prioridade. Elas começam com o byte `0x02` e incluem campos como `maxPriorityFeePerGas` e `maxFeePerGas`. As transações do Tipo 2 agora são o padrão devido à sua flexibilidade e eficiência, especialmente preferidas durante períodos de alta congestão na rede por sua capacidade de ajudar os usuários a gerenciar as taxas de transação de forma mais previsível. O valor TransactionType para essas transações é `0x2`.
-
-
-
-## Leitura adicional {#further-reading}
-
-- [EIP-2718: Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718)
-
-_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Contas](/developers/docs/accounts/)
-- [Máquina virtual de Ethereum (EVM)](/developers/docs/evm/)
-- [Gás](/developers/docs/gas/)
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/web2-vs-web3/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
deleted file mode 100644
index 15e5e20e0d5..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Web2 vs Web3
-description:
-lang: pt-br
----
-
-Web2 refere-se à versão da internet que a maioria de nós conhecemos hoje. Uma internet dominada por empresas que prestam serviços em troca de seus dados pessoais. Web3, no contexto da Ethereum, refere-se a aplicativos descentralizados que são executados na cadeia de blocos. Estes são aplicativos que permitem a qualquer pessoa participar sem monetizar seus dados pessoais.
-
-Procurando por uma explicação mais adaptada para iniciantes? Veja nossa [introdução ao Web3](/web3/).
-
-## Benefícios da Web3 {#web3-benefits}
-
-Muitos desenvolvedores Web3 optaram por criar dapps devido à descentralização inerente à Ethereum:
-
-- Qualquer pessoa que esteja em rede tem permissão para usar o serviço – ou em outras palavras, a permissão não é necessária.
-- Ninguém pode bloquear você ou recusar o acesso ao serviço.
-- Pagamentos são feitos através do token nativo, ether (ETH).
-- Ethereum é "turing-completo", o que significa que você pode programar praticamente qualquer coisa.
-
-## Comparações práticas {#practical-comparisons}
-
-| Web2 | Web3 |
-| -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
-| O Twitter pode censurar qualquer conta ou tweet | Tweets da Web3 seriam incensuráveis porque o controle é descentralizado |
-| O serviço de pagamento pode decidir não permitir pagamentos para certos tipos de trabalho | Os aplicativos de pagamento Web3 não requerem dados pessoais e não podem impedir pagamentos |
-| Os servidores para aplicativos gig-economy poderiam ficar inoperantes e afetar a renda dos trabalhadores | Os servidores Web3 não podem ficar inoperantes – eles usam a Ethereum, uma rede descentralizada de 1000s de computadores como seu backend |
-
-Isto não significa que todos os serviços precisam ser transformados em um dapp. Estes exemplos são ilustrativos das principais diferenças entre os serviços Web 2 e Web3.
-
-## Limitações da Web3 {#web3-limitations}
-
-O Web3 tem alguns limites neste momento:
-
-- Escalabilidade - as transações são mais lentas na web3 porque são descentralizadas. Mudanças de estado, como um pagamento, precisam ser processadas por um nó e propagadas por toda a rede.
-- UX – interagir com ações do aplicativo web 3 pode exigir etapas, software e educação extras. Isto pode ser um obstáculo à adopção.
-- Acessibilidade – A falta de integração em navegadores de internet modernos torna a web3 menos acessível à maioria dos usuários.
-- Custo – os dapps mais bem sucedidos colocam pequenas partes do seu código na blockchain, pois é caro.
-
-## Centralização vs descentralização {#centralization-vs-decentralization}
-
-Na tabela abaixo, listamos algumas das vantagens e desvantagens das redes digitais centralizadas e descentralizadas.
-
-| Sistemas centralizados | Sistemas Descentralizados |
-| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Diâmetro da rede baixo (todos os participantes estão conectados a uma autoridade central); a informação propaga-se rapidamente, já que a propagação é tratada por uma autoridade central com muitos recursos computacionais. | Os demais participantes da rede podem estar muito distantes uns dos outros. A transmissão de informações de um lado da rede pode levar muito tempo para chegar à outra parte. |
-| Geralmente maior desempenho (maior taxa de transferência, menos recursos computacionais totais gastos) e mais fácil de implementar. | Geralmente maior desempenho (maior taxa de transferência, menos recursos computacionais totais gastos) e mais fácil de implementar. |
-| Em caso de conflito de dados, a resolução é clara e fácil: a fonte final da verdade é a autoridade central. | Para a resolução de litígios, é necessário um protocolo (frequentemente complexo) se os pares fizerem afirmações conflitantes sobre o estado dos dados em que os participantes devem ser sincronizados. |
-| Um ponto único do fracasso: os agentes maliciosos poderão conseguir derrubar a rede dirigindo-se à autoridade central. | Nenhum ponto de falha: a rede pode ainda funcionar mesmo que uma grande percentagem de participantes seja atacada/eliminada. |
-| A coordenação entre os participantes na rede é muito mais fácil e é gerida por uma autoridade central. A autoridade central pode obrigar os participantes da rede a adotarem melhorias, melhorias de protocolo, etc., com muito pouca fricção. | A coordenação é muitas vezes difícil, já que nenhum agente tem a última palavra sobre decisões a nível de rede, melhorias de protocolo, etc. No pior dos casos, a rede está propensa a fracturar quando há desacordos sobre alterações de protocolo. |
-| A autoridade central pode censurar dados, impedindo potencialmente partes da rede de interagir com o resto da rede. | A censura é muito mais difícil, pois a informação tem muitas maneiras de se propagar através da rede. |
-| A participação na rede é controlada pela autoridade central. | Qualquer um pode participar da rede; não há “guardiões”. O ideal é que o custo da participação seja muito baixo. |
-
-Observe que estes são padrões gerais que podem não se aplicar em todas as redes. Além disso, na realidade, o grau em que uma rede é centralizada/descentralizada reside em um espectro; nenhuma rede é inteiramente centralizada ou inteiramente descentralizada.
-
-## Leia mais {#further-reading}
-
-- [O que é Web3?](/web3/) - _ethereum.org_
-- [A Arquitetura de um aplicativo Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-- [O Significado da Descentralização](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _6 de fevereiro de 2017 – Vitalik Buterin_
-- [Por que a descentralização é importante](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) _18 de fevereiro de 2018 – Chris Dixon_
-- [O que é o Web 3.0 e por que ele é importante](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _31 de dezembro de 2019 – Max Mersch e Richard Muirhead_
-- [Por que precisamos do Web 3.0](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _12 de setembro de 2018 - Gavin Wood_
diff --git a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/wrapped-eth/index.md b/public/content/translations/pt-br/13) Foundational Docs/developers/docs/wrapped-eth/index.md
deleted file mode 100644
index a8b7225af4b..00000000000
--- a/public/content/translations/pt-br/13) Foundational Docs/developers/docs/wrapped-eth/index.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: O que é Wrapped Ether (WETH)
-description: Uma introdução ao Wrapped ether (WETH), um wrapper compatível com ERC20 para ether (ETH).
-lang: pt-br
----
-
-# Wrapped ether (WETH) {#intro-to-weth}
-
-Ether (ETH) é a principal moeda do Ethereum. É usado para várias finalidades, como staking, como moeda e pagamento de taxas de gás para computação. O **WETH é efetivamente uma forma atualizada do ETH com algumas funcionalidades adicionais exigidas por muitos aplicativos e [tokens ERC-20](/glossary/#erc-20)**, que são outros tipos de ativos digitais no Ethereum. Para trabalhar com esses tokens, o ETH deve seguir as mesmas regras que eles, conhecidas como padrão ERC-20.
-
-Para preencher essa lacuna, foi criado o wrapped ETH (WETH). O **Wrapped ETH é um contrato inteligente que permite que você deposite qualquer quantia de ETH no contrato e receba a mesma quantia em WETH cunhado**, em conformidade com o padrão de token ERC-20. O WETH é uma representação do ETH que permite que você interaja com ele como um token ERC-20, e não como o ativo nativo ETH. Você ainda precisará de ETH nativo para pagar as taxas de gás, portanto, certifique-se de guardar um pouco ao depositar.
-
-Você pode trocar WETH por ETH usando o contrato inteligente WETH. Você pode resgatar qualquer quantia de WETH com o contrato inteligente WETH, e receberá a mesma quantia em ETH. O WETH depositado é então queimado e retirado do suprimento circulante de WETH.
-
-**Cerca de 3% do suprimento de ETH em circulação está bloqueado no contrato do token WETH**, o que o torna um dos [contratos inteligentes] mais usados (/glossary/#smart-contract). O WETH é especialmente importante para usuários que interagem com aplicativos em finanças descentralizadas (DeFi).
-
-## Por que precisamos empacotar o ETH como um ERC-20? {#why-do-we-need-to-wrap-eth}
-
-O [ERC-20](/developers/docs/standards/tokens/erc-20/) define uma interface padrão para tokens transferíveis, de modo que qualquer pessoa pode criar tokens que interajam perfeitamente com aplicativos e tokens que usam esse padrão no ecossistema do Ethereum. Como o **ETH é anterior ao padrão ERC-20**, o ETH não está em conformidade com essa especificação. Isso significa que **você não pode trocar facilmente** ETH por outros tokens ERC-20 ou **usar ETH em aplicativos que usam o padrão ERC-20**. O empacotamento de ETH dá a você oportunidade de fazer o seguinte:
-
-- **Trocar ETH por tokens ERC-20**: você não pode trocar ETH diretamente por outros tokens ERC-20. O WETH é uma representação do ether que está em conformidade com o padrão de token fungível ERC-20 e pode ser trocado por outros tokens ERC-20.
-
-- **Usar ETH em dapps**: como o ETH não é compatível com o ERC20, os desenvolvedores precisariam criar interfaces separadas (uma para ETH e outra para tokens ERC-20) nos dapps. O empacotamento de ETH elimina esse obstáculo e permite que os desenvolvedores lidem com ETH e outros tokens no mesmo dapp. Muitos aplicativos financeiros descentralizados usam esse padrão e criam mercados para a troca desses tokens.
-
-## Wrapped ether (WETH) vs. ether (ETH): qual é a diferença? {#weth-vs-eth-differences}
-
-| | **Ether (ETH)** | **Wrapped Ether (WETH)** |
-| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Abastecimento | O abastecimento de ETH é gerenciado pelo protocolo Ethereum. A [emissão](/roadmap/merge/issuance) de ETH é tratada pelos validadores do Ethereum ao processar transações e criar blocos. | O WETH é um token ERC-20 cujo abastecimento é gerenciado por um contrato inteligente. Novas unidades de WETH são emitidas pelo contrato depois que ele recebe depósitos de ETH dos usuários, ou unidades de WETH são queimadas quando um usuário deseja resgatar WETH por ETH. |
-| Propriedade | A propriedade é gerenciada pelo protocolo Ethereum por meio do saldo de sua conta. | A propriedade do WETH é gerenciada pelo contrato inteligente do token WETH, protegido pelo protocolo Ethereum. |
-| Gás | Ether (ETH) é a unidade de pagamento aceita para computação na rede Ethereum. As tarifas de gás são denominadas em gwei (uma unidade de ether). | O pagamento de gás com tokens WETH não é suportado nativamente. |
-
-## Perguntas mais frequentes {#faq}
-
-
-
-Você paga taxas de gás para empacotar ou desempacotar ETH usando o contrato WETH.
-
-
-
-
-
-O WETH é geralmente considerado seguro porque é baseado em um contrato inteligente simples e de eficiência comprovada. O contrato WETH também foi formalmente verificado, que é o mais alto padrão de segurança para contratos inteligentes no Ethereum.
-
-
-
-
-
-Além da [implementação canônica do WETH] (https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) descrita nesta página, há outras variantes disponíveis. Eles podem ser tokens personalizados criados por desenvolvedores de aplicativos ou versões emitidas em outras blockchains e podem se comportar de forma diferente ou ter propriedades de segurança diferentes. \*\*Sempre verifique novamente as informações do token para saber com qual implementação do WETH você está interagindo
-
-
-
-
-
-- [Rede principal do Ethereum](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
-- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
-- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
-
-
-
-## Leitura adicional {#further-reading}
-
-- [O que é WETH?](https://weth.tkn.eth.limo/)
-- [Informações sobre o token WETH no Etherscan](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
-- [Verificação formal do WETH](https://zellic.io/blog/formal-verification-weth)
diff --git a/public/content/translations/pt-br/14) Community Pages/community/code-of-conduct/index.md b/public/content/translations/pt-br/14) Community Pages/community/code-of-conduct/index.md
deleted file mode 100644
index b67e442c36e..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/code-of-conduct/index.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Código de Conduta
-description: As normas básicas que buscamos nos espaços do ethereum.org.
-lang: pt-br
----
-
-# Código de Conduta {#code-of-conduct}
-
-## Missão {#mission}
-
-Desenvolver e manter o centro de conhecimento mais abrangente e acessível para o Ethereum.
-
-## Valores {#values}
-
-A comunidade ethereum.org trabalha para ser:
-
-- educativa, com o objetivo de ajudar todos a compreender o Ethereum
-- inclusiva
-- acessível
-- voltada à comunidade
-- centrada nos casos de uso e na tecnologia subjacente do Ethereum
-- centrada nos conceitos e princípios de design do Ethereum
-
-## O que não somos {#what-we-are-not}
-
-- O site Ethereum Foundation
-- Uma plataforma para promover investimentos ou gerar lucros de qualquer tipo
-- Uma plataforma para elevar ou endossar projetos ou organizações individuais
-- Uma DEX, CEX, ou qualquer outra forma de plataforma financeira
-- Uma plataforma que oferece recomendações financeiras ou jurídicas de qualquer tipo
-
-## Código de Conduta {#code-of-conduct}
-
-### Compromisso {#pledge}
-
-A participação aberta é fundamental para o ethos do ethereum.org. Somos um site e uma comunidade mantidos por milhares de colaboradores, e isso só é possível se mantivermos um ambiente acolhedor e participativo. Com esse objetivo, os colaboradores do site se comprometem a manter um ambiente sem assédio para todos os participantes em todas as plataformas e espaços comunitários do ethereum.org. A comunidade ethereum.org dá as boas-vindas e valoriza qualquer pessoa que queira participar de uma maneira construtiva e amigável, independentemente de idade, deficiência, etnia, características sexuais, identidade de gênero, nível de experiência, área de especialização, educação, situação socioeconômica, nacionalidade, aparência pessoal, raça, religião ou qualquer outra dimensão da diversidade.
-
-### Escopo {#scope}
-
-Este Código de Conduta se aplica a todos os espaços do ethereum.org (como GitHub, Discord, Figma Crowdin, Twitter e outras plataformas online) e também se aplica quando a comunidade é representada em espaços públicos reais, como em encontros, conferências e eventos.
-
-### As nossas normas {#our-standards}
-
-Exemplos de comportamentos que colaboram para criar um ambiente positivo incluem:
-
-- Usar uma linguagem acolhedora e inclusiva
-- Respeitar os diferentes pontos de vista e experiências
-- Aceitar e/ou oferecer educadamente críticas construtivas, com empatia
-- Agir com calma e profissionalismo ao resolver conflitos ou desentendimentos
-- Demonstrar empatia e tolerância a outros membros da comunidade
-- Incentivar e ampliar novas opiniões na comunidade
-
-Exemplos de comportamento inaceitável por parte dos participantes incluem:
-
-- Violência física, ameaça de violência física ou incentivo à violência física de qualquer tipo
-- Usar linguagem ou imagens sexualizadas ou impor atenção sexual indesejada
-- Fazer-se passar por outra pessoa ou reivindicar, de forma desonesta, afiliação a alguma pessoa ou organização
-- Brincadeiras de mau gosto, comentários ofensivos/pejorativos e ataques pessoais ou políticos
-- Assediar outros membros da comunidade em canais públicos ou privados
-- Publicar informações privadas de outras pessoas, como endereço físico ou eletrônico, sem permissão explícita
-- Engenharia social, fraude ou manipulação de outros membros da comunidade
-- Promover investimentos, tokens, projetos ou qualquer outro item para benefício próprio, monetário ou não
-- Fazer spam nos servidores com conteúdo não relacionado
-- Ignorar solicitações ou avisos dos moderadores da comunidade
-- Envolvimento em qualquer outra conduta que possa ser razoavelmente considerada inadequada em um ambiente profissional
-
-### Denúncia {#reporting}
-
-As violações do código de conduta normalmente ficarão visíveis à comunidade, pois tentamos fazer tudo em canais abertos e públicos, de forma a permitir que os membros da comunidade se autopoliciem.
-
-Entretanto, se ocorrer algo que você acha que precisa de atenção, pode falar com uma pessoa na função de moderação (por exemplo, guia do Discord) para que a pessoa possa ajudar a investigar e aplicar a resposta apropriada.
-
-Ao fazer uma denúncia, inclua todos os detalhes possíveis, inclusive exemplos específicos e carimbos de data e hora. Isso ajudará a garantir um resultado justo.
-
-### Aplicação {#enforcement}
-
-Dependendo da gravidade, as pessoas que violarem o código de conduta podem receber avisos, banimento temporário ou banimento permanente das comunidades do ethereum.org.
diff --git a/public/content/translations/pt-br/14) Community Pages/community/events/index.md b/public/content/translations/pt-br/14) Community Pages/community/events/index.md
deleted file mode 100644
index 3c9525a51ed..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/events/index.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Eventos Ethereum
-description: Como fazer parte da comunidade Ethereum.
-lang: pt-br
-hideEditButton: true
----
-
-# Próximos eventos {#events}
-
-**Todos os meses há grandes eventos da Ethereum ao redor do mundo.** Considere participar de um perto de você para conhecer pessoas que fazem parte da comunidade, aprender sobre oportunidades de emprego e desenvolver novas habilidades.
-
-
-
-Essa é uma lista não exaustiva mantida pela nossa comunidade. Conhece um evento por vir da Ethereum? [Vá em frente e o adicione a lista](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-events.json)!
-
-## Encontros da Ethereum {#meetups}
-
-Nenhum dos eventos serve para você? Tente ir a um encontro. Os encontros são eventos menores realizados por grupos de entusiastas da Ethereum. e uma oportunidade para pessoas com um interesse em comum em Ethereum se reunirem, conversarem sobre o projeto e conhecer mais sobre os desenvolvimentos recentes.
-
-
-
-Interessado em organizar o seu próprio encontro? Confira a [BUIDL Network](https://consensys.net/developers/buidlnetwork/), uma iniciativa da ConsenSys para oferecer suporte às comunidades de encontros da Ethereum.
-
-Essa é uma lista não exaustiva mantida pela nossa comunidade. Você pode [ver mais encontros da Ethereum aqui](https://www.meetup.com/topics/ethereum/). Conhece algum grupo ativo de encontros? [Adicione-o a lista](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-meetups.json)!
diff --git a/public/content/translations/pt-br/14) Community Pages/community/get-involved/index.md b/public/content/translations/pt-br/14) Community Pages/community/get-involved/index.md
deleted file mode 100644
index fe51c8a6e9d..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/get-involved/index.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Como posso participar?
-description: Como fazer parte da comunidade Ethereum.
-lang: pt-br
----
-
-# Como posso participar? {#get-involved}
-
-A comunidade Ethereum inclui pessoas de diferentes contextos e habilidades. Seja você um desenvolvedor, artista ou contador, há diversas maneiras de participar. Aqui temos uma lista de sugestões que podem ajudar você a começar.
-
-Comece lendo sobre a missão e os valores da ethereum.org no nosso [código de conduta](/community/code-of-conduct).
-
-## Desenvolvedores {#developers}
-
-- Conheça e experimente o Ethereum em [ethereum.org/developers/](/developers/)
-- Participe de uma hackathon [ETHGlobal](http://ethglobal.co/) perto de você!
-- Dê uma olhada nos [projetos relacionados à sua área de conhecimento ou linguagem de programação favorito](/developers/docs/programming-languages/)
-- Assista ou participe das [chamadas de Consenso e Camada de Execução](https://www.youtube.com/@EthereumProtocol/streams)
-- [Lista de desejos do Programa de apoio ao ecossistema](https://esp.ethereum.foundation/wishlist/): ferramentas, documentação e áreas de infraestrutura onde o Programa de suporte ao ecossistema do Ethereum está ativamente buscando aplicativos
-- [Web3Bridge](https://www.web3bridge.com/): participe da promissora comunidade da web3 em sua iniciativa de identificar, treinar e oferecer suporte a centenas de desenvolvedores e membros da comunidade em toda a África
-- Junte-se ao [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)
-- Junte-se ao [Discord Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu)
-
-## Pesquisadores e acadêmicos {#researchers-and-academics}
-
-Você tem formação em matemática, criptografia ou economia? Talvez tenha interesse em alguns dos trabalhos revolucionários que estão sendo realizados no ecossistema Ethereum:
-
-- Junte-se ao [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)
-- Escreva ou avalie uma proposta de melhoria do Ethereum (EIP)
- - Escreva uma EIP
- 1. Envie a sua ideia em [Ethereum Magicians](https://ethereum-magicians.org)
- 2. Leia a [EIP-1](https://eips.ethereum.org/EIPS/eip-1) - **Sim, esse é o documento _na íntegra_.**
- 3. Siga as orientações estabelecidas na EIP-1. Consulte-a ao redigir a sua versão preliminar.
- - Saiba como se tornar um [editor de EIP](https://eips.ethereum.org/EIPS/eip-5069)
- - Você pode fazer a revisão por pares de EIPs agora mesmo! Consulte os [PRs abertos com a tag `e-review`](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review). Envie feedback técnico por meio do link `discussion-to`.
- - Participe da [governança de EIP](https://github.com/ethereum-cat-herders/EIPIP)
- - Junte-se ao [Discord Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu)
- - [Mais sobre EIPs](/eips/)
-- [Challenges.ethereum.org](https://challenges.ethereum.org/): uma série de pesquisas com recompensas de alto valor. Você pode ganhar >US$ 100.000
-- [Ethresear.ch](https://ethresear.ch): fórum principal de pesquisa do Ethereum e o fórum mais influente do mundo sobre criptoeconomia
-- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022): uma série contínua de perguntas e respostas com pesquisadores. À medida que cada parte seguinte é aberta, qualquer pessoa poderá publicar perguntas.
-- [Lista de desejos do programa de apoio ao ecossistema](https://esp.ethereum.foundation/wishlist/): áreas de pesquisa em que o programa de apoio ao ecossistema Ethereum busca ativamente pedidos de subsídios
-- [AllWalletDevs](https://allwallet.dev) - um fórum para desenvolvedores, designers e usuários interessados em Ethereum se reunirem regularmente e discutirem carteiras
-
-[Conheça as áreas de pesquisa mais ativas](/community/research/).
-
-## Habilidades que não necessitam de conhecimento técnico {#non-technical}
-
-Se você não é um desenvolvedor, pode ser difícil saber por onde começar no Ethereum. Apresentamos algumas sugestões, juntamente com recursos para históricos profissionais específicos.
-
-### Organize um encontro na sua cidade {#meetups}
-
-- Não sabe como começar? A [rede BUIDL](https://consensys.net/developers/buidlnetwork/) pode ajudar.
-
-### Escreva sobre Ethereum {#write-content}
-
-- Ethereum precisa de bons escritores que sejam capazes de explicar o seu valor em uma linguagem simples de entender
-- Não está preparado para publicar seu próprio artigo? Considere contribuir para o conteúdo já existente nos recursos da comunidade, ou [proponha novos conteúdos para o ethereum.org](/contributing/)!
-
-### Tome notas durante as reuniões da comunidade {#take-notes}
-
-- Existem várias chamadas open-source da comunidade, e ter pessoas tomando notas é uma grande ajuda. Se você está interessado, una-se ao servidor [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) no Discord e se apresente!
-
-### Traduza conteúdo do Ethereum para a sua língua materna {#translate-ethereum}
-
-- ethereum.org mantém um projeto de tradução d site, e outros recursos, para vários idiomas diferentes
-- Saiba como participar [aqui](/contributing/translation-program)
-
-### Execute um nó {#run-a-node}
-
-Junte-se a milhares de operadores de nós e ajude na descentralização do Ethereum.
-
-- [Mais informações sobre como executar um nó](/developers/docs/nodes-and-clients/run-a-node/)
-
-### Faça staking de seu ETH {#staking}
-
-Ao utilizar seu ETH em uma participação, você pode ganhar recompensas e, ao mesmo tempo, ajudar a proteger a rede Ethereum.
-
-- [Mais sobre participação](/staking/)
-
-### Apoie projetos {#support-projects}
-
-O objetivo do ecossistema Ethereum é financiar bens públicos e projetos com impacto. Por meio de pequenas doações você pode demonstrar o seu apoio e permitir a realização de um trabalho importante.
-
-- [Gitcoin](https://gitcoin.co/fund)
-- [clr.fund](https://clr.fund/#/about)
-
-## Profissionais de finanças e contadores {#financial-professionals}
-
-- Ethereum é o centro do ecossistema de "Finanças descentralizadas" – uma rede de protocolos e aplicativos que oferece um sistema financeiro alternativo. Se você é um profissional de finanças, confira alguns aplicativos de DeFi em [DeFi Llama](https://defillama.com/) ou [DeFiPrime](https://defiprime.com)
-- É um contador? Ativos no Ethereum — ETH, tokens, DeFi etc – criam novas dúvidas contábeis. Você pode começar conferindo alguns projetos que tem como objetivo ajudar usuários de criptomoedas a resolver seus desafios de contabilidade, como o [Rotki](https://rotki.com/)
-
-## Gerentes de produto {#product-managers}
-
-- O ecossistema do Ethereum precisa de suas habilidades! Muitas empresas estão contratando para as funções de gerente de produtos. Se você quiser começar contribuindo para um projeto de código aberto, entre em contato com [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) ou [RaidGuild](https://www.raidguild.org/)
-
-## Marketing {#marketing}
-
-- Existem muitas posições de marketing e comunicação no ecossistema Ethereum!
-
-## Trabalhe para a Ethereum {#ethereum-jobs}
-
-**Quer trabalhar na Ethereum?**
-
-- [Empregos em ethereum.org](/about/#open-jobs)
-- [Ofertas de empregos da Ethereum Foundation (Lever)](https://jobs.lever.co/ethereumfoundation)
-- [Oferstas de emprego da Ethereum Foundation (BambooHR)](https://ethereum.bamboohr.com/jobs/)
-- [JobStash](https://jobstash.xyz)
-- [Empregos relacionados a criptomoedas](https://cryptocurrencyjobs.co/ethereum/)
-- [Carreiras na ConsenSys](https://consensys.net/careers/)
-- [Lista de empregos relacionados a criptomoedas](https://cryptojobslist.com/ethereum-jobs)
-- [Ofertas de emprego na Bankless](https://pallet.xyz/list/bankless/jobs)
-- [Empregos na Web3](https://web3.career)
-- [Web3 Army](https://web3army.xyz/)
-- [Empregos na Crypto Valley](https://cryptovalley.jobs/)
-- [Trabalhe para a Ethereum](https://startup.jobs/ethereum-jobs)
-- [CriptoJobster](https://cryptojobster.com/tag/ethereum/)
-
-## Participe de uma DAO {#decentralized-autonomous-organizations-daos}
-
-"DAOs" são organizações autônomas descentralizadas. Esses grupos utilizam a tecnologia do Ethereum para facilitar a organização e a colaboração. Por exemplo, para controlar a associação, votar em propostas ou gerenciar ativos agrupados. Embora as DAOs ainda sejam experimentais, elas oferecem oportunidades para encontrar grupos com os quais você se identifique, encontrar colaboradores e aumentar o seu impacto na comunidade Ethereum. [Mais sobre DAOs](/dao/)
-
-- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) – _Promova o conceito de DAO no campo não técnico e ajude as pessoas a criar valor através do DAO_
-- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) – _Comunidade de construtores que acreditam na propriedade coletiva da Internet_
-- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) – _Grupo de freelancers de desenvolvimento Web3 trabalhando como DAO_
-- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) – _Governaça comunitária da DAOhaus_
-- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) – _Engenharia jurídica_
-- [Machi X](https://machix.com) [@MachiXOficial](https://twitter.com/MachiXOfficial) – _Comunidade artística_
-- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) – _Venture para projetos cripto pré-seed_
-- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) – _Mecânica de jogos para a vida real MMORPG_
-- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) – _Marcas de vestuário Digiphysical_
-- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) – _Comunidade focada em financiar o desenvolvimento do Ethereum_
-- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild)– _Grupo de construtores da Web3_
-
-Lembre-se de sempre respeitar o [código de conduta](/community/code-of-conduct) do ethereum.org, independentemente de como contribuir para o ethereum.org!
diff --git a/public/content/translations/pt-br/14) Community Pages/community/grants/index.md b/public/content/translations/pt-br/14) Community Pages/community/grants/index.md
deleted file mode 100644
index 81f8dc6f860..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/grants/index.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Fundação Ethereum & Programa de Recompensas da Comunidade
-description: Uma listagem dos programas de recompensas por meio do ecossistema Ethereum.
-lang: pt-br
----
-
-# Recompensas Ethereum {#ethereum-grants}
-
-Os programas listados abaixo oferecem uma variedade de subsídios de financiamento para projetos que trabalham promovendo o sucesso e o crescimento do ecossistema Ethereum. Use isso como um guia para encontrar e solicitar fundos para ajudar a tornar seu próximo projeto Ethereum um sucesso.
-
-Esta página é administrada por nossa comunidade. Se houver algo faltando ou errado, por favor edite esta página!
-
-## Macro ecossistema Ethereum {#broad-ethereum-ecosystem}
-
-Esses programas abrangem um amplo ecossistema Ethereum ao oferecer recompensas a um grande escopo de projetos. Eles incluem soluções de dimensionamento, formação de comunidades, segurança, privacidade e muito mais. Essas recompensas não são específicas de nenhuma plataforma Ethereum e são um bom lugar para começar se você não tiver certeza.
-
-- [ Programa de suporte ao ecossistema EF](https://esp.ethereum.foundation)-_ Financiar projetos de código aberto que beneficiam o Ethereum, com foco particular em ferramentas universais, infraestrutura, pesquisa e bens públicos _
-- [Moloch DAO](https://www.molochdao.com/) – _Privacidade, dimensionamento da camada 2, segurança do cliente e mais_
-- [Concessões DAO](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) – _Planilha Google de organizações que oferecem concessões_
-- [Bolsas acadêmicas](https://esp.ethereum.foundation/academic-grants) – _Bolsas para apoiar o trabalho acadêmico relacionado com o Ethereum_
-- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _A Blockworks compilou um diretório abrangente de todas as recompensas, RFPs e programas de caça a bugs._
-
-## Especificidades do projeto {#project-specific}
-
-Estes projetos criaram seus próprios programas de recompensas destinados a desenvolvimento e experimentação de suas tecnologias.
-
-- [Programa de concessões Aave](https://aavegrants.org/) – _[Aave](https://aave.com/) concede DAO_
-- [Balancer](https://grants.balancer.community/) – _Fundo do ecossistema [Balancer](https://balancer.fi/)_
-- [Programa de concessões da Chainlink](https://chain.link/community/grants) – _Concessões da comunidade da [Chainlink](https://chain.link/)_
-- [Programa de recompensas Decentraland](https://governance.decentraland.org/grants/) – _[Decentraland](https://decentraland.org/)Metaverso DAO_
-- [Lido Ecosystem Grants Organisation (LEGO)](https://lido.fi/lego) – _Ecossistema financeiro [Lido](https://lido.fi/)_
-- [Programa MetaMask](https://metamaskgrants.org/) - _[MetaMask](https://metamask.io/) bolsas lideradas por funcionários DAO_
-- [Programa de bolsas da SKALE Network](https://skale.space/developers#grants) - _[Ecossistema da SKALE Network](https://skale.space/)_
-- [Programa de Subsídios da Fundação Swarm](https://my.ethswarm.org/grants) - _[Ecossistema da Fundação Swarm](https://www.ethswarm.org/)
-- [The Graph](https://thegraph.com/ecosystem/grants/) – _Ecossistema [The Graph](https://thegraph.com/)_
-- [Programa de bolsas da Uniswap](https://www.uniswapfoundation.org/approach) – _Comunidade [Uniswap](https://uniswap.org/)_
-
-## Financiamento quadrático {#quadratic-funding}
-
-As raízes do código aberto do Ethereum levaram ao maior interessante em um modelo de captação de recursos: financiamento quadrático. Isto tem o potencial de melhorar a forma como financiamos todos os tipos de bens públicos no futuro. Financiamento quadrático assegura que projetos que recebem mais recursos sejam aqueles com a maior procura. Em outras palavras, projetos que contribuem para melhorar a vida da maioria das pessoas. [Mais sobre financiamento quadrático.](/defi/#quadratic-funding)
-
-- [Gitcoin](https://gitcoin.co/grants)
-- [clr.fund](https://clr.fund/)
-
-## Trabalhar em Ethereum {#work-in-ethereum}
-
-Não está pronto para iniciar seu próprio projeto? Existem centenas de companhias que estão procurando ativamente indivíduos apaixonados para trabalharem e contribuírem com o ecossistema Ethereum. Buscando mais informações? [Confira empregos relacionados a Ethereum](/community/get-involved/#ethereum-jobs)
diff --git a/public/content/translations/pt-br/14) Community Pages/community/language-resources/index.md b/public/content/translations/pt-br/14) Community Pages/community/language-resources/index.md
deleted file mode 100644
index 5c9d8353c4f..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/language-resources/index.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: Recursos de idiomas
-description: Recursos para aprender sobre Ethereum em outros idiomas
-lang: pt-br
----
-
-# Recursos de idiomas {#language-resources}
-
-Ethereum é uma comunidade global composta por milhões de não falantes da língua inglesa.
-
-Nosso objetivo é fornecer conteúdo educacional em todas as línguas e ajudar a superar as barreiras linguísticas que tornam um desafio a integração de pessoas do mundo todo com Ethereum.
-
-Caso prefira ler em seu idioma nativo ou conheça alguém que não fale inglês, você pode encontrar uma lista de recursos úteis em outros idiomas abaixo. Centenas de milhares de entusiastas do Ethereum se reúnem nestes fóruns na Internet para compartilhar notícias, falar sobre avanços recentes, debater problemas técnicos e imaginar o futuro.
-
-Conhece algum recurso educacional em sua língua? [Abra uma solicitação](https://github.com/ethereum/ethereum-org-website/issues/new/choose) para adicioná-lo à lista!
-
-## Recursos em Ethereum.org {#ethereum-org}
-
-O Ethereum.org é traduzido nativamente para mais de 40 idiomas, que você pode encontrar usando nosso menu de seleção de idiomas, localizado na parte superior de cada página.
-
-
-
-Se você for bilíngue e deseja nos ajudar a alcançar mais pessoas, também pode fazer parte do [Programa de tradução da ethereum.org](/contributing/translation-program/#translation-program) e nos ajudar a traduzir o site.
-
-## Recursos para a comunidade {#community}
-
-### Português do Brasil {#br-pt}
-
-**Notícias**
-
-- [BeInCrypto](http://www.beincrypto.com.br): notícias e artigos sobre criptomoedas, incluindo uma lista das exchanges disponíveis no Brasil
-- [Cointelegraph](http://cointelegraph.com.br/category/analysis): versão brasileira do Cointelegraph, um das maiores mídias digitais sobre criptomoedas
-- [Livecoins](http://www.livecoins.com.br/ethereum) - notícias e materiais informativos sobre criptomoedas
-- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/): notícias e relatórios sobre criptomoedas
-- [Modular Crypto](https://modularcrypto.xyz/) - notícias sobre criptomoedas e artigos educacionais
-
-**Educação**
-
-- [web3dev](https://www.web3dev.com.br/) - Centro de conteúdo e comunidade Discord para desenvolvedores de web 3.
-- [Web3Brasil](https://github.com/web3brasil/web3brasil): recursos para aprender Web3 e DeFi
-- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/): notícias e educação sobre criptomoedas, incluindo Ethereum para principiantes e DeFi para iniciantes
-- [CriptoAtivos](http://www.criptoativos.wiki.br/): informações sobre criptomoedas, materiais educativos e blog
-- [Cointimes](http://www.cointimes.com.br/): notícias e materiais informativos sobre criptomoedas
-- [Pacote inicial da Web3](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/): um guia que responde às perguntas mais frequentes e fundamentais sobre criptomoedas
-
-### Chinês {#zh}
-
-**Recursos gerais**
-
-- [Ethereum.cn](https://www.ethereum.cn/): conteúdo mantido pela comunidade, cobrindo assuntos como as melhorias na camada de consenso, as conclusões dos encontros dos desenvolvedores, a segunda camada etc.
-- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) — aprenda tudo, de noções básicas a tópicos avançados do Ethereum
-- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA): conteúdo mantido pela comunidade sobre Ethereum, DeFi, NFT ou conhecimento relacionado à Web3
-- [123ETH](https://123eth.org/): um portal para o ecossistema Ethereum
-- [Zhen Xiao](http://zhenxiao.com/blockchain/): cursos on-line gratuitos sobre criptomoedas e suas aplicações
-- [Ethereum Whitepaper](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6): versão chinesa do Ethereum Whitepaper
-
-**Ecossistema Ethereum**
-
-- [ETHPlanet](https://www.ethplanet.org/): hackathons on-line e presenciais que oferecem treinamento para estudantes universitários
-- [PrimitivesLane](https://www.primitiveslane.org/) - Um grupo de pesquisa sem fins lucrativos dedicado à tecnologia blockchain
-- [Comunidade de tradução da Ethereum CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171): uma comunidade dedicada à tradução de conteúdo educativo da Ethereum
-
-**Para desenvolvedores**
-
-- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) – um grupo de aprendizado para estudar projetos Dapp convencionais e compartilhar pensamentos e comentários toda semana
-- [LearnBlockchain](https://learnblockchain.cn/): uma comunidade para desenvolvedores. Compartilha informações sobre a tecnologia blockchain
-
-**Para pesquisadores de criptografia**
-
-- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - uma conta WeChat, explicando a criptografia, segurança, etc.
-- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - uma conta no WeChat sobre a tecnologia ZK
-
-### Tcheco {#cs}
-
-- [Gwei.cz](https://gwei.cz) – Comunidade local em torno da Web3, que cria conteúdo educacional, organiza eventos online e presenciais
-- [Gwei.cz Příručka](https://prirucka.gwei.cz/) – Guia Ethereum para iniciantes
-- [DAO Příručka](https://dao.gwei.cz/) – Guia do iniciante para DAOs
-- [ Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) – Dominando o Ethereum em Tcheco
-
-### Francês {#fr}
-
-- [Ethereum France](https://www.ethereum-france.com/) – O Ethereum France organiza eventos, cria conteúdo e incentiva discussões em torno do Ethereum
-- [Ethereum.fr](https://ethereum.fr/) – Educação e notícias sobre o Ethereum
-- [BanklessFR](https://banklessfr.substack.com/) – Boletim informativo em francês sobre finanças descentralizadas
-- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) – Fórum de criptomoedas com uma subpágina sobre o Ethereum
-
-### Alemão {#de}
-
-- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) – Usando o Solidity
-- [Microsoft Learn (contratos inteligentes)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) – escrevendo contratos inteligentes do Ethereum com Solidity
-- [Microsoft Learn (redes Ethereum)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) – Conectar e implementar redes Ethereum
-- [Microsoft Learn (cadeias de blocos)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) – Ponto de entrada para o desenvolvimento da cadeia de blocos
-
-### Hebraico {#he}
-
-- [Udi Wertheimer - O que os usuários de bitcoin podem aprender com a Ethereum](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/)
-- [Omer Greismen (OpenZeppelin) - Como prevenimos um hack de contrato inteligente de 15 bilhões de dólares](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/)
-- [Shy Datika (INX) - Tokenização e o futuro dos títulos, incluindo o Ethereum como um título](https://www.cryptojungle.co.il/shy-datika-tokenization/)
-- [Roy Confino (Lemonade) - Seguros @ Ethereum](https://www.cryptojungle.co.il/roy-confino-insurance/)
-- [Idan Ofrat (Fireblocks) - Adoção Institucional](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/)
-- [Gal Weizman (MetaMask) - O que é MetaMask](https://www.cryptojungle.co.il/gal-weizman-metamask/)
-- [Dror Aviely (Consensys) - O centro do Ethereum](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/)
-- [Nir Rozin - Ser um criptopunk](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/)
-- [Adan Kedem - Jogos & Metaverso](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/)
-- [Uri Kolodny (Starkware) - Camadas do Ethereum e blockchain](https://www.cryptojungle.co.il/uri-kolodny-starkware/)
-- [Udi Wertheimer - Ethereum 2.0 vs concorrência](https://www.cryptojungle.co.il/udi-on-eth2/)
-- [Ben Samocha (eu) - Ethereum 2.0 - uma oportunidade?](https://www.cryptojungle.co.il/etherurm2-week-summary/)
-- [Alon Muroch (Bloxstaking) - O que é Ethereum 2.0?](https://www.cryptojungle.co.il/alon-moroch-eth2/)
-- [Eilon Aviv (Collider Ventures) - O que pode dar errado com o Ethereum 2.0](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/)
-- [Eilon Aviv (Collider Ventures) - Por que precisamos do Ethereum 2.0](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/)
-
-### Italiano {#it}
-
-- [Ethereum Italia](https://www.ethereum-italia.it/) – Educação, eventos e notícias sobre o Ethereum com foco nos contratos inteligentes e na tecnologia blockchain
-- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) – podcast sobre o Ethereum em italiano
-- [Aprendizagem em Microsoft (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) – usando Solidity
-- [Microsoft Learn (conratos inteligentes)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) – Escrevendo contratos inteligentes com Solidity
-- [Microsoft Learn (dapps)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) – crie uma interface de usuário com aplicativos descentralizados
-
-### Japonês {#ja}
-
-- [Associação japonesa de corretoras de ativos virtuais e de criptomoedas](https://jvcea.or.jp/)
-- [Associação japonesa de empresas de criptoativos](https://cryptocurrency-association.org/)
-- [Comece com o desenvolvimento de cadeia de blocos – Learn | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) – Este caminho de aprendizagem apresenta a blockchain e o desenvolvimento na plataforma do Ethereum
-- [ Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) – Dominando o Ethereum em Japonês
-- [Desenvolvimento de contratos inteligentes com Solidity e Ethereum](https://www.oreilly.co.jp/books/9784873119342/) – Desenvolvimento de contratos inteligentes com Solidity e Ethereum em Japonês
-
-### Russo {#ru}
-
-- [Cyber Academy](https://cyberacademy.dev) – espaço educacional para criadores web3
-- [Forklog](https://forklog.com) - notícias e artigos educacionais sobre criptografia em geral, tecnologias existentes e futuras atualizações de diferentes blockchains
-- [BeInCrypto](https://ru.beincrypto.com) - notícias, análise de preços de criptografia e artigos não técnicos com explicações simples sobre tudo em criptografia
-
-### Espanhol {#es}
-
-- [Ethereum Madrid](https://ethereummadrid.com/) – blockchain, DeFi e cursos, eventos e blog sobre governança
-- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) – guia sobre o Ethereum em espanhol para iniciantes
-- [Tutoriais online](https://tutoriales.online/curso/solidity) – aprenda Solidity e programação em Ethereum
-- [Curso de introdução ao desenvolvimento do Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) – noções básicas, testes e implantação em Solidity do seu primeiro contrato inteligente
-- [Curso de introdução à segurança e hacking no Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) – entendendo as vulnerabilidades comuns e os problemas de segurança em contratos inteligentes reais
-- [Curso de introdução ao desenvolvimento em DeFi](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) – aprendendo como funcionam os contratos inteligentes de DeFi em Solidity e criando seu próprio Automated Market Maker
-- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) – Educação não técnica sobre blockchain do iniciante ao avançado. Aprenda tudo sobre criptomoedas e Ethereum.
-
-### Turco {#tr}
-
-- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) – curso com foco em blockchain e criptomoedas
-- [A grande mudança de nome – o que aconteceu com Eth2?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) – tradução em turco da excelente publicação de blog sobre a mudança de nome, explicando a mudança da terminologia "Eth2"
-
-### Vietnamita {#vi}
-
-- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) – visão geral do Ethereum, dapps, carteiras e perguntas frequentes
-- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) – plataforma Web com subpáginas de notícias e informações educativas sobre o Ethereum
-- [Coin68](https://coin68.com/ethereum-tieu-diem/) – portal de criptomoedas com notícias e conteúdo educacional sobre o Ethereum
diff --git a/public/content/translations/pt-br/14) Community Pages/community/online/index.md b/public/content/translations/pt-br/14) Community Pages/community/online/index.md
deleted file mode 100644
index 9fb9a83b4e1..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/online/index.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Comunidades online
-description: Uma listagem dos programas de recompensas por meio do ecossistema Ethereum.
-lang: pt-br
----
-
-# Comunidades online {#online-communities}
-
-Centenas de milhares de entusiastas do Ethereum se reúnem nestes fóruns na Internet para compartilhar notícias, falar sobre avanços recentes, debater problemas técnicos e imaginar o futuro.
-
-## Fóruns {#forums}
-
-r/ethereum – tudo sobre o Ethereum
-r/ethfinance – o lado financeiro do Ethereum, incluindo DeFi
-r/ethdev – focado no desenvolvimento do Ethereum
-r/ethtrader – tendências e análise de mercado
-r/ethstaker – bem-vindos a todos os interessados em apostar no Ethereum
-Fellowship of Ethereum Magicians – comunidade orientada em torno de padrões técnicos no Ethereum
-Ethereum Stackexchange – discussão e ajuda para desenvolvedores Ethereum
-Pesquisa Ethereum – o painel de mensagens mais influente para pesquisa criptoeconômica
-
-## Salas de bate-papo {#chat-rooms}
-
-Ethereum Cat Herders –Comunidade orientada em torno da oferta de apoio à gestão de projetos para o desenvolvimento do Ethereum
-Ethereum Hackers – Chat no Discord administrado pela ETHGlobal: uma comunidade online para hackers Ethereum em todo o mundo
-CryptoDevs – Comunidade Discord focada no desenvolvimento do Ethereum
-EthStaker Discord - orientação, educação, apoio e recursos geridos pela comunidade para stakers existentes e potenciais
-Equipe do site Ethereum.org – pare e converse sobre desenvolvimento e design do site ethereum.org com a equipe e pessoas da comunidade
-Matos Discord – comunidade de criadores da Web3 na qual construtores, líderes do setor e entusiastas do Ethereum se encontram. Somos apaixonados pelo desenvolvimento, design e cultura Web3. Venha criar conosco.
-Solidity Gitter — chat para desenvolvimento do solidity (Gitter)
-Solidity Matrix — chat para desenvolvimento do solidity (Matrix)
-Ethereum Stack Exchange * — fórum de perguntas e respostas*
-Peeranha * — fórum descentralizado de perguntas e respostas*
-
-## YouTube e Twitter {#youtube-and-twitter}
-
-Ethereum Foundation – Mantenha-se atualizado com as últimas novidades da Ethereum Foundation
-@ethereum – Conta oficial da Fundação Ethereum
-@ethdotorg – O portal para o Ethereum, construído para a nossa comunidade global em crescimento
-Lista de contas influentes sobre o Ethereum no Twitter
-
-
-
-
-
-
- Saiba mais sobre DAOs
-
-
-
diff --git a/public/content/translations/pt-br/14) Community Pages/community/research/index.md b/public/content/translations/pt-br/14) Community Pages/community/research/index.md
deleted file mode 100644
index ec3d8781a1d..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/research/index.md
+++ /dev/null
@@ -1,399 +0,0 @@
----
-title: Áreas ativas de pesquisa do Ethereum
-description: Acesse diferentes áreas de pesquisa aberta e saiba como participar.
-lang: pt-br
----
-
-# Áreas ativas de pesquisa da Ethereum {#active-areas-of-ethereum-research}
-
-Um dos principais pontos fortes do Ethereum é ele está sendo constantemente aprimorado por meio de uma comunidade ativa de pesquisa e engenharia. Muitas pessoas entusiasmadas e capacitadas ao redor do mundo gostariam de se dedicar a questões pendentes no Ethereum, mas nem sempre é fácil descobrir quais são essas questões. Esta página descreve as principais áreas de pesquisa ativas como um guia aproximado da tecnologia de ponta do Ethereum.
-
-## Como funciona da pesquisa do Ethereum {#how-ethereum-research-works}
-
-A pesquisa do Ethereum é aberta e transparente, incorporando os princípios da [Ciência Descentralizada (DeSci)](https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science). A cultura é tornar as ferramentas e os resultados de pesquisa tão abertos e interativos quanto possível, por exemplo, por meio de notebooks executáveis. A pesquisa sobre o Ethereum avança rapidamente, com novas descobertas publicadas e discutidas abertamente em fóruns como o [ethresear.ch] (https://ethresear.ch/), em vez de chegar à comunidade por meio de publicações tradicionais após rodadas de revisão por pares.
-
-## Recursos para pesquisa comum {#general-research-resources}
-
-Independentemente do tópico específico, há uma grande quantidade de informações sobre a pesquisa da Ethereum que podem ser encontradas em [ethresear.ch](https://ethresear.ch) e no [Eth R&D Discord channel](https://discord.gg/qGpsxSA). Esses são os principais locais onde os pesquisadores do Ethereum discutem as ideias e oportunidades mais recentes de desenvolvimento.
-
-Esse relatório que foi publicado em maio de 2022 pela [DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) fornece uma boa visão geral sobre o plano de ação da Ethereum.
-
-## Fontes de financiamento {#sources-of-funding}
-
-Você pode participar da pesquisa do Ethereum e ser pago por isso! Por exemplo, a [Fundação Ethereum](/foundation/) realizou recentemente uma rodada de financiamento [Academic Grants](https://esp.ethereum.foundation/academic-grants). Você pode encontrar informações sobre oportunidades de financiamento ativas e futuras na [página de concessões da Ethereum] (/community/grants/).
-
-## Pesquisa de protocolo {#protocol-research}
-
-A pesquisa de protocolo está relacionada à camada de base da Ethereum, o conjunto de regras que define como os nós se conectam, se comunicam, trocam e armazenam dados do Ethereum e chegam a um consenso sobre o estado do blockchain. A pesquisa de protocolos é dividida em duas categorias de nível superior: consenso e execução.
-
-### Consenso {#consensus}
-
-A pesquisa sobre consenso se preocupa com o [mecanismo de prova de participação da Ethereum](/developers/docs/consensus-mechanisms/pos/). Alguns exemplos de tópicos de pesquisa de consenso são:
-
-- identificar e resolver vulnerabilidades;
-- quantificar a segurança criptoeconômica;
-- aumentar a segurança ou desempenho de implementações do cliente;
-- e desenvolver clientes leves.
-
-Além da pesquisa voltada para o futuro, algumas reformulações fundamentais do protocolo, como a finalidade de espaço único, estão sendo pesquisadas para permitir melhorias significativas no Ethereum. Além disso, a eficiência, a segurança e o monitoramento da rede ponto a ponto entre clientes de consenso também são importantes tópicos de pesquisa.
-
-#### Leitura de apoio {#background-reading}
-
-- [Introdução à prova de participação](/developers/docs/consensus-mechanisms/pos/)
-- [Artigo Casper-FFG](https://arxiv.org/abs/1710.09437)
-- [Explicando o Casper-FFG](https://arxiv.org/abs/1710.09437)
-- [Artigo Gasper](https://arxiv.org/abs/2003.03052)
-
-#### Pesquisa recente {#recent-research}
-
-- [Ethresear.ch Consenso](https://ethresear.ch/c/consensus/29)
-- [Dilema disponibilidade/finalidade](https://arxiv.org/abs/2009.04987)
-- [Finalidade de posição única](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259)
-- [Separação sugestor-construtor](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
-
-### Execução {#execution}
-
-A camada de execução é responsável pelas transações em execução, o funcionamento da [máquina virtual Ethereum (EVM)](/developers/docs/evm/) e a geração de cargas de execução para serem transferidas para a camada de consenso. Há muitas áreas ativas de pesquisa, incluindo:
-
-- desenvolvimento de suporte a cliente leve;
-- pesquisa de limites de gás;
-- e incorporar novas estruturas de dados (por exemplo, Verkle Trees).
-
-#### Leitura de apoio {#background-reading-1}
-
-- [Introdução à EVM](/developers/docs/evm)
-- [Ethresear.ch camada de execução](https://ethresear.ch/c/execution-layer-research/37)
-
-#### Pesquisa recente {#recent-research-1}
-
-- [Otimizações da base de dados](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md)
-- [Término de estado](https://notes.ethereum.org/@vbuterin/state_expiry_eip)
-- [Caminhos para o término de estado](https://hackmd.io/@vbuterin/state_expiry_paths)
-- [Verkle e a proposta do término de estado](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal)
-- [Gerenciamento de histórico](https://eips.ethereum.org/EIPS/eip-4444)
-- [Árvores Verkle](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
-- [Amostragem de disponibilidade de dados](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)
-
-## Desenvolvimento de cliente {#client-development}
-
-Os clientes Ethereum são implementações do protocolo Ethereum. O desenvolvimento do cliente transforma os resultados da pesquisa de protocolo em realidade ao incorporá-los nesses clientes. O desenvolvimento do cliente inclui a atualização das especificações do cliente, bem como a criação de implementações específicas.
-
-Um nó Ethereum é necessário para executar dois softwares:
-
-1. um cliente de consenso para manter o controle da cabeça do blockchain, blocos de transmissão e para processar a lógica de consenso
-2. um cliente de execução para oferecer suporte à Máquina Virtual do Ethereum e executar transações e contratos inteligentes
-
-Consulte a página [nós e clientes] (/developers/docs/nodes-and-clients/) para obter mais detalhes sobre nós e clientes e para obter uma lista de todas as implementações atuais de clientes. Você também pode encontrar um histórico de todas as atualizações do Ethereum na página [historia page](/history/).
-
-### Clientes de execução {#execution-clients}
-
-- [Especificação do cliente de execução] (https://github.com/ethereum/execution-specs)
-- [Especificação da API de execução] (https://github.com/ethereum/execution-apis)
-
-### Clientes de consenso {#consensus-clients}
-
-- Clientes de consenso {#consensus-clients}
-- [Especificação da API do Beacon] (https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot)
-
-## Escalabilidade e desempenho {#escalonamento-e-desempenho}
-
-A escalabilidade do Ethereum é uma importnate área de foco dos pesquisadores Ethereum. As abordagens atuais incluem descarregar transações em rollups e torná-las o mais financeiramente acessíveis possível usando blobs de dados. Informações introdutórias sobre a escalabilidade da Ethereum estão disponíveis em nossa [página de escala] (/developers/docs/scaling).
-
-### Camada 2 {#layer-2}
-
-Atualmente, há vários protocolos de camada 2 que dimensionam o Ethereum por meio de diferentes técnicas para agrupar transações e protegê-las na camada 1 do Ethereum. Esse é um tópico de crescimento muito rápido, com muito potencial de pesquisa e desenvolvimento.
-
-#### Leitura de apoio {#background-reading-2}
-
-- [Introdução à camada 2](/layer-2/)
-- [Polynya: Rollups, DA e cadeias modulares](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d)
-
-#### Pesquisa recente {#recent-research-2}
-
-- [Ordenação justa do Arbitrum para sequenciadores](https://eprint.iacr.org/2021/1465)
-- [ethresear.ch Camada 2](https://ethresear.ch/c/layer-2/32)
-- [Roteiro centrado em rollup](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)
-- [L2Beat](https://l2beat.com/)
-
-### Pontes {#bridges}
-
-Uma área específica da camada 2 que exige mais pesquisa e desenvolvimento são as pontes seguras e de bom desempenho. Isso inclui pontes entre várias Camadas 2 e entre a Camada 1 e a Camada 2. Essa é uma área de pesquisa particularmente importante porque os hackers normalmente visam as pontes (bridges).
-
-#### Leitura de apoio {#background-reading-3}
-
-- [Introdução às pontes de blockchain](/bridges/)
-- [Vitalik abordando as pontes](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/)
-- [Artigo das pontes do Blockchain](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8)
-- [Valor bloqueado em pontes](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\))
-
-#### Pesquisa recente {#recent-research-3}
-
-- [Validação de pontes](https://stonecoldpat.github.io/images/validatingbridges.pdf)
-
-### Sharding {#sharding}
-
-A fragmentação do blockchain do Ethereum faz parte do roadmap de desenvolvimento há muito tempo. Entretanto, novas soluções de escalabilidade, como "Danksharding", atualmente ocupam o centro das atenções.
-
-O precursor do Danksharding completo, conhecido como Proto-Danksharding, entrou em operação com a atualização da rede Cancun-Deneb ("Dencun").
-
-[Mais informações sobre a atualização do Dencun](/roadmap/dencun/)
-
-#### Leitura de apoio {#background-reading-4}
-
-- [Notas sobre o Proto-Danksharding] (https://notes.ethereum.org/@vbuterin/proto_danksharding_faq)
-- [Vídeo de Danksharding sem banco](https://www.youtube.com/watch?v=N5p0TB77flM)
-- [Compêndio de pesquisa sobre fragmentação da Ethereum](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view)
-- [Danksharding (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe)
-
-#### Pesquisa recente {#recent-research-4}
-
-- [EIP-4844: Proto-Danksharding](https://eips.ethereum.org/EIPS/eip-4844)
-- [Vitalik sobre sharding e amostragem de disponibilidade de dados] (https://hackmd.io/@vbuterin/sharding_proposal)
-
-### Hardware {#hardware}
-
-[A execução de nós](/developers/docs/nodes-and-clients/run-a-node/) em hardware modesto é fundamental para manter a descentralização da Ethereum. Portanto, a pesquisa ativa para minimizar os requisitos de hardware para executar os nós é uma importante área de pesquisa.
-
-#### Leitura de apoio {#background-reading-5}
-
-- [Ethereum em ARM] (https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)
-
-#### Pesquisa recente {#recent-research-5}
-
-- [ecdsa sobre FPGAs](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738)
-
-## Segurança {#security}
-
-Segurança é um tópico amplo que pode incluir prevenção de spam/scam, segurança de carteira, segurança de hardware, segurança criptoeconômica, caça a bugs e testes de aplicativos e software cliente, bem como gerenciamento de chaves. Contribuir para o conhecimento nessas áreas ajudará a incentivar a adoção generalizada.
-
-### Criptografia e ZKP {#cryptography--zkp}
-
-As provas de conhecimento zero (ZKP) e criptografia são essenciais para o desenvolvimento de privacidade e segurança no Ethereum e em seus aplicativos. O conhecimento zero é um espaço relativamente novo, mas em rápida evolução, com muitas oportunidades abertas de pesquisa e desenvolvimento. Algumas possibilidades incluem o desenvolvimento de implementações mais eficientes do [algoritmo de hashing Keccak] (https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview), a descoberta de compromissos polinomiais melhores do que os existentes atualmente ou a redução do custo dos circuitos de geração de chaves públicas e de verificação de assinaturas da ecdsa.
-
-#### Leitura de apoio {#background-reading-6}
-
-- [Blog do 0xparc](https://0xparc.org/blog)
-- [zkp.science](https://zkp.science/)
-- [Podcast do Zero Knowledge](https://zeroknowledge.fm/)
-
-#### Pesquisa recente {#recent-research-6}
-
-- [Avanços recentes na criptografia de curva elíptica](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346)
-- [Ethresear.ch ZK](https://ethresear.ch/c/zk-s-nt-arks/13)
-
-### Carteiras {#wallets}
-
-As carteiras Ethereum podem ser extensões de navegador, aplicativos móveis e de desktop ou contratos inteligentes no Ethereum. Há uma pesquisa ativa sobre carteiras de recuperação social que reduzem parte do risco associado ao gerenciamento de chaves de usuários individuais. Associada ao desenvolvimento de carteiras está a pesquisa de formas alternativas de abstração de contas, que é uma área importante de pesquisa emergente.
-
-#### Leitura de apoio {#background-reading-7}
-
-- [Introdução às carteiras](/wallets/)
-- [Introdução à segurança da carteira](/security/)
-- [Segurança em ethresear.ch](https://ethresear.ch/tag/security)
-- [EIP-2938 Abstração de contas](https://eips.ethereum.org/EIPS/eip-2938)
-- [EIP-4337 Abstração de contas](https://eips.ethereum.org/EIPS/eip-4337)
-
-#### Pesquisa recente {#recent-research-7}
-
-- [Carteiras de contratos inteligentes com foco em validação] (https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603)
-- [O futuro das contas] (https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603)
-- [EIP-3074 AUTH e os AUTHCALL Opcodes] (https://eips.ethereum.org/EIPS/eip-3074)
-- [Código de publicação em um endereço EOA] (https://eips.ethereum.org/EIPS/eip-5003)
-
-## Comunidade, educação e alcance {#community-education-and-outreach}
-
-A integração de novos usuários ao Ethereum exige novos recursos educacionais e abordagens de divulgação. Isso pode incluir postagens e artigos de blog, livros, podcasts, memes, recursos de aprendizagem, eventos e qualquer outra coisa que crie comunidades, dê as boas-vindas a novos iniciantes e instrua as pessoas sobre a Ethereum.
-
-### UX/UI {#uxui}
-
-Para atrair mais pessoas para o Ethereum, o ecossistema precisa melhorar a UX/UI. Isso exigirá que designers e especialistas de produtos reexaminem o design de carteiras e aplicativos.
-
-#### Leitura de apoio {#background-reading-8}
-
-- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24)
-
-#### Pesquisa recente {#recent-research-8}
-
-- [Web3 design no Discord](https://discord.gg/FsCFPMTSm9)
-- [Princípios de design da Web3 no Discord](https://www.web3designprinciples.com/)
-- [Discussão sobre o UX do Ethereum Magicians] (https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3)
-
-### Economia {#economics}
-
-De modo geral, a pesquisa de economia no Ethereum segue duas abordagens: validar a segurança dos mecanismos que dependem de incentivos econômicos ("microeconomia") e analisar os fluxos de valor entre protocolos, aplicativos e usuários ("macroeconomia"). Há fatores criptoeconômicos complexos relacionados ao ativo nativo do Ethereum (ether) e aos tokens criados com base nele (por exemplo, NFTs e tokens ERC20).
-
-#### Leitura de apoio {#background-reading-9}
-
-- [Grupo de Incentivos Robustos](https://ethereum.github.io/rig/)
-- [Workshop de ETHconomics na Devconnect](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm)
-
-#### Pesquisa recente {#recent-research-9}
-
-- [Análise empírica do EIP1559] (https://arxiv.org/abs/2201.05574)
-- [Equilíbrio de abastecimento circulante](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954)
-- [Quantificando o MEV: quão escura é a floresta?] (https://arxiv.org/abs/2101.05511)
-
-### Espaço de blocos e mercados de taxas {#blockspace-fee-markets}
-
-Os mercados de espaço de bloco regem a inclusão de transações de usuários finais, seja diretamente na Ethereum (Camada 1) ou em redes em ponte, por exemplo, rollups (Camada 2). No Ethereum, as transações são enviadas ao mercado de taxas implantado no protocolo como EIP-1559, protegendo a cadeia contra spam e congestionamento de preços. Em ambas as camadas, as transações podem produzir externalidades, conhecidas como Valor Máximo Extraível (MEV), que induzem novas estruturas de mercado para capturar ou gerenciar essas externalidades.
-
-#### Leitura de apoio {#background-reading-10}
-
-- [Design do mecanismo da taxa de transação para Blockchain Ethereum: uma análise econômica do EIP-1559 (Tim Roughgarden, 2020](https://timroughgarden.org/papers/eip1559.pdf)
-- [Simulações da EIP-1559 (Grupo de Incentivos Robustos)] (https://ethereum.github.io/abm1559)
-- [Economia de rollup a partir dos primeiros princípios](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url)
-- [Flash Boys 2.0: Frontrunning, Reordenação de Transações e Instabilidade de Consenso em Exchanges Descentralizadas](https://arxiv.org/abs/1904.05234)
-
-#### Pesquisa recente {#recent-research-10}
-
-- [Apresentação em vídeo do EIP-1559 multidimensional] (https://youtu.be/QbR4MTgnCko)
-- [MEV de domínio cruzado] (http://arxiv.org/abs/2112.01472)
-- [Leilões MEV](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788)
-
-### Incentivos de prova de participação {#proof-of-stake-incentives}
-
-Os validadores usam o ativo nativo do Ethereum (ether) como garantia contra comportamento desonesto. As criptoeconomias disso determinam a segurança da rede. Validadores sofisticados podem ser capazes de explorar as nuances da camada de incentivo para lançar ataques explícitos.
-
-#### Leitura de apoio {#background-reading-11}
-
-- [Aula magna de economia do Ethereum e modelo econômico] (https://github.com/CADLabs/ethereum-economic-model)
-- [Simulações de incentivos de PoS (Grupo de Incentivos Robustos)] (https://ethereum.github.io/beaconrunner/)
-
-#### Pesquisa recente {#recent-research-11}
-
-- [Aumento da resistência à censura de transações sob separação entre proponente e construtor (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ)
-- [Três ataques ao PoS Ethereum](https://arxiv.org/abs/2110.10086)
-
-### Estaca líquida e derivativos {#liquid-staking-and-derivatives}
-
-A participação líquida permite que os usuários com menos de 32 ETH recebam rendimentos de participação ao trocar ether por um token que representa o ether participado que pode ser utilizado em DeFi. Entretanto, os incentivos e a dinâmica de mercado associados à participação líquida ainda estão sendo descobertos, bem como seu efeito na segurança do Ethereum (por exemplo, riscos de centralização).
-
-#### Leitura de apoio {#background-reading-12}
-
-- [Estaca líquida em Ethresear.ch](https://ethresear.ch/search?q=liquid%20staking)
-- [Lido: O caminho para o staking de Ethereum sem confiança](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/)
-- [Rocket Pool: Introdução ao protocolo de staking](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd)
-
-#### Pesquisa recente {#recent-research-12}
-
-- [Tratamento de retiradas do Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873)
-- [Credenciais de retirada] (https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722)
-- [Os riscos dos derivativos de estaca líquida] (https://notes.ethereum.org/@djrtwo/risks-of-lsd)
-
-## Testes {#testing}
-
-### Verificação formal {#formal-verification}
-
-A verificação formal consiste em escrever código para verificar se as especificações de consenso do Ethereum estão corretas e sem erros. Há uma versão executável da especificação escrita em Python que exige manutenção e desenvolvimento. Pesquisas adicionais podem ajudar a aprimorar a implementação da especificação em Python e adicionar ferramentas que possam verificar a correção e identificar problemas de uma maneira mais eficiente.
-
-#### Leitura de apoio {#background-reading-13}
-
-- [Introdução à verificação formal] (https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html)
-- [Verificação Formal (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf)
-
-#### Pesquisa recente {#recent-research-13}
-
-- [Verificação formal do contrato de depósito] (https://github.com/runtimeverification/deposit-contract-verification)
-- [Verificação formal da especificação da cadeia de Sinalizador] (https://github.com/runtimeverification/deposit-contract-verification)
-
-## Ciência de dados e Analíticos {#data-science-and-analytics}
-
-São necessárias mais ferramentas de análise de dados e painéis que ofereçam informações detalhadas sobre a atividade no Ethereum e a integridade da rede.
-
-### Leitura de apoio {#background-reading-14}
-
-- [Analíticos Dune](https://dune.com/browse/dashboards)
-- [Painel de diversidade do cliente] (https://clientdiversity.org/)
-
-#### Pesquisa recente {#recent-research-14}
-
-- [Análise robusta de dados do grupo de incentivos] (https://ethereum.github.io/rig/)
-
-## Aplicativos e ferramentas {#apps-and-tooling}
-
-A camada de aplicativos oferece suporte a um ecossistema diversificado de programas que liquidam transações na camada de base do Ethereum. As equipes de desenvolvimento estão constantemente encontrando novas maneiras de utilizar o Ethereum para criar versões compostas, sem permissão e resistentes à censura de aplicativos importantes de Web2 ou criar conceitos nativos de Web3 completamente novos. Ao mesmo tempo, estão sendo desenvolvidas novas ferramentas que fazem com que a criação de dApps no Ethereum seja menos complexa.
-
-### DeFi {#defi}
-
-Finanças Descentralizadas (DeFi) é uma das principais classes de aplicações criadas com base no Ethereum. O objetivo da DeFi é criar "legos de dinheiro" compostos que permitam aos usuários armazenar, transferir, emprestar, tomar emprestado e investir ativos criptográficos utilizando contratos inteligentes. DeFi é um espaço em rápida evolução que está em constante atualização. Pesquisas sobre protocolos seguros, eficientes e acessíveis são continuamente necessárias.
-
-#### Leitura de apoio {#background-reading-15}
-
-- [DeFi](/defi/)
-- [Coinbase: O que é DeFi?](https://www.coinbase.com/learn/crypto-basics/what-is-defi)
-
-#### Pesquisa recente {#recent-research-15}
-
-- [Finanças descentralizadas, propriedade centralizada?](https://arxiv.org/pdf/2012.09306.pdf)
-- [Otimismo: O caminho para transações abaixo do dólar](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92)
-
-### DAOs {#daos}
-
-Um caso de uso de impacto para o Ethereum é a capacidade de se organizar de forma descentralizada por meio da utilização de DAOs. Há muitas pesquisas ativas sobre como as organizações autônomas descentralizadas (DAOs) no Ethereum podem ser desenvolvidas e utilizadas para executar formas aprimoradas de governança, como uma ferramenta de coordenação com minimização de confiança, o que amplia bastante as opções das pessoas além das corporações e organizações tradicionais.
-
-#### Leitura de apoio {#background-reading-16}
-
-- [Introdução aos DAOs](/dao/)
-- [Coletivo Dao] (https://daocollective.xyz/)
-
-#### Pesquisa recente {#recent-research-16}
-
-- [Mapeamento do ecossistema DAO](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy)
-
-### Ferramentas do desenvolvedor {#developer-tools}
-
-As ferramentas para desenvolvedores do Ethereum têm melhorado rapidamente. Há muita pesquisa e desenvolvimento ativos a serem feitos nessa área geral.
-
-#### Leitura de apoio {#background-reading-17}
-
-- [Ferramentas por linguagem de programação](/developers/docs/programming-languages/)
-- [Estruturas de desenvolvedor](/developers/docs/frameworks/)
-- [Lista de ferramentas de desenvolvedor do consenso] (https://github.com/ConsenSys/ethereum-developer-tools-list)
-- [Padrões de token](/developers/docs/standards/tokens/)
-- [CryptoDevHub: Ferramentas EVM](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools)
-
-#### Pesquisa recente {#recent-research-17}
-
-- [Canal no Discord de ferramentas de consenso do Eth R&D](https://discordapp.com/channels/595666850260713488/746343380900118528)
-
-### Oráculos {#oracles}
-
-Os oráculos importam dados fora da cadeia para o blockchain de uma maneira descentralizada e sem permissão. A obtenção desses dados em cadeia permite que os dApps sejam reativos a fenômenos reais, como flutuações de preço em ativos reais, eventos em aplicativos fora da cadeia ou inclusive alterações climáticas.
-
-#### Leitura de apoio {#background-reading-18}
-
-- [Introdução aos oráculos](/developers/docs/oracles/)
-
-#### Pesquisa recente {#recent-research-18}
-
-- [Pesquisa sobre oráculos de blockchain] (https://arxiv.org/pdf/2004.07140.pdf)
-- [Chainlink white paper](https://chain.link/whitepaper)
-
-### Segurança de aplicativos {#app-security}
-
-Os hacks na Ethereum geralmente exploram vulnerabilidades em aplicativos individuais, em vez de no próprio protocolo. Os hackers e os desenvolvedores de aplicativos estão em uma luta de braço para desenvolver novos ataques e defesas. Isso significa que sempre há necessidade de pesquisa e desenvolvimento importantes para manter os aplicativos protegidos contra invasões.
-
-#### Leitura de apoio {#background-reading-19}
-
-- [Relatório de exploração de wormhole](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/)
-- [Lista de post-mortems de hack de contrato da Ethereum] (https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191)
-- [Rekt News](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg)
-
-#### Pesquisa recente {#recent-research-19}
-
-- [Aplicativos em ethresear.ch] (https://ethresear.ch/c/applications/18)
-
-### Stack de tecnologia {#technology-stack}
-
-A descentralização de toda a pilha de tecnologia Ethereum é uma importante área de pesquisa. Atualmente, os dApps no Ethereum geralmente têm alguns pontos de centralização porque dependem de ferramental ou infraestrutura centralizadas.
-
-#### Leitura de apoio {#background-reading-20}
-
-- [Ethereum stack](/developers/docs/ethereum-stack/)
-- [Coinbase: Introdução ao Web3 Stack](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0)
-- [Introdução aos contratos inteligentes](/developers/docs/smart-contracts/)
-- [Introdução ao armazenamento descentralizado](/developers/docs/storage/)
-
-#### Pesquisa recente {#recent-research-20}
-
-- [Composição de contratos inteligentes](/developers/docs/smart-contracts/composability/)
diff --git a/public/content/translations/pt-br/14) Community Pages/community/support/index.md b/public/content/translations/pt-br/14) Community Pages/community/support/index.md
deleted file mode 100644
index 4d0e863c30d..00000000000
--- a/public/content/translations/pt-br/14) Community Pages/community/support/index.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-title: Suporte Ethereum
-description: Obtenha suporte no ecossistema Ethereum.
-lang: pt-br
----
-
-# Suporte Ethereum {#support}
-
-## Suporte oficial do Ethereum {#official-support}
-
-Você está procurando pelo suporte oficial do Ethereum? A primeira coisa que você deve saber é que o Ethereum é descentralizado. Isso significa que nenhuma organização central, entidade ou pessoa é proprietária do Ethereum, e, por isso, não existem canais de suporte oficiais.
-
-Compreender a natureza descentralizada do Ethereum é vital porque qualquer pessoa que afirme ser um suporte oficial para o Ethereum está provavelmente tentando enganar você! A melhor proteção contra os golpistas é educar-se e levar a segurança a sério.
-
-
- Segurança e prevenção de fraude do Ethereum
-
-
-
- Aprenda os conceitos básicos do Ethereum
-
-
-Apesar da falta de suporte oficial, muitos grupos, comunidades e projetos em todo o ecossistema Ethereum estão felizes em ajudar, e você pode encontrar muitas informações e recursos úteis nesta página. Ainda tem dúvidas? Junte-se ao [Discord ethereum.org](/discord/) e tentaremos ajudar.
-
-## Perguntas frequentes {#faq}
-
-### Enviei ETH para a carteira errada {#wrong-wallet}
-
-Uma transação enviada em Ethereum é irreversível. Infelizmente, se você enviou ETH para a carteira errada, não há como recuperar esses fundos. Nenhuma organização central, entidade ou pessoa é proprietária do Ethereum, o que significa que ninguém pode reverter transações. Portanto, é vital verificar sempre as suas transações antes de enviá-las.
-
-### Como eu posso solicitar minha doação de Ethereum? {#giveaway-scam}
-
-Doações/airdrops de Ethereum são golpes criados para roubar o seu ETH. Não se sinta tentado por ofertas que parecem boas demais para serem verdadeiras — se você enviar ETH para um endereço de doação, não receberá nenhuma doação/airdrop e não poderá recuperar seus fundos.
-
-[Mais sobre prevenção de fraudes](/security/#common-scams)
-
-### Minha transação está bloqueada {#stuck-transaction}
-
-Transações em Ethereum podem algumas vezes ficar bloqueadas se você tiver enviado uma taxa de transação menor do que a necessária devido à demanda na rede. Muitas carteiras oferecem uma opção para reenviar a mesma transação com uma taxa de transação maior para permitir que a transação seja processada. Como alternativa, você pode cancelar uma transação pendente enviando uma transação para seu próprio endereço e usando o mesmo nonce que a transação pendente.
-
-[Como acelerar ou cancelar uma transação pendente no MetaMask](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction)
-
-[Como cancelar transações pendentes no Ethereum](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/)
-
-### Como minero Ethereum? {#mining-ethereum}
-
-A mineração do Ethereum não é mais possível. A mineração foi desativada quando a Ethereum passou de [proof-of-work](/glossary/#pow) para [proof-of-stake](/glossary/#pos). Agora, em vez de mineradores, o Ethereum tem validadores. Qualquer pessoa pode [stake](/glossary/#staking) ETH e receber recompensas de staking por executar software validador para manter a rede segura.
-
-### Como se tornar um staker ou validador? {#how-to-stake}
-
-Para se tornar um validador, você deve participar com 32 ETH no contrato de depósito do Ethereum e configurar um nó validador. Mais informações estão disponíveis em nossas [páginas de participação](/staking) e na [plataforma de lançamento de participação](https://launchpad.ethereum.org/).
-
-## Criando dapps {#building-support}
-
-Desevolver um dapp pode ser difícil. Aqui estão alguns espaços voltados ao desenvolvimento com desenvolvedores Ethereum experientes dispostos a ajudar.
-
-- [Universidade Alchemy](https://university.alchemy.com/#starter_code)
-- [Discord CryptoDevs](https://discord.com/invite/5W5tVb3)
-- [Stackexchange do Ethereum](https://ethereum.stackexchange.com/)
-- [StackOverflow](https://stackoverflow.com/questions/tagged/web3)
-- [Universidade Web3](https://www.web3.university/)
-- [LearnWeb3](https://discord.com/invite/learnweb3)
-
-Você também pode encontrar documentação e guias de desenvolvimento em nossa seção [Recursos de desenvolvedor Ethereum](/developers/).
-
-### Ferramentas {#dapp-tooling}
-
-Sua pergunta está relacionada a uma ferramenta, projeto ou biblioteca em particular? A maioria dos projetos tem servidores de bate-papo ou fóruns dedicados a apoiar você.
-
-Aqui estão alguns exemplos populares:
-
-- [Solidity](https://gitter.im/ethereum/solidity)
-- [ethers.js](https://discord.gg/6jyGVDK6Jx)
-- [web3.js](https://discord.gg/GsABYQu4sC)
-- [Hardhat](https://discord.gg/xtrMGhmbfZ)
-- [Alchemy](http://alchemy.com/discord)
-- [Tenderly](https://discord.gg/fBvDJYR)
-
-## Executando um nó {#node-support}
-
-Se você estiver executando um nó ou validador, aqui estão algumas comunidades que se dedicam a ajudá-lo a começar.
-
-- [Discord EthStaker](https://discord.gg/ethstaker)
-- [Reddit EthStaker](https://www.reddit.com/r/ethstaker)
-
-A maioria das equipes que estão construindo clientes Ethereum também tem espaços dedicados ao público, onde você pode obter suporte e fazer perguntas.
-
-### Clientes de execução {#execution-clients}
-
-- [Geth](https://discord.gg/FqDzupGyYf)
-- [Nethermind](https://discord.gg/YJx3pm8z5C)
-- [Besu](https://discord.gg/p8djYngzKN)
-- [Erigon](https://github.com/ledgerwatch/erigon/issues)
-- [Reth](https://github.com/paradigmxyz/reth/discussions)
-
-### Clientes de consenso {#consensus-clients}
-
-- [Prysm](https://discord.gg/prysmaticlabs)
-- [Nimbus](https://discord.gg/nSmEH3qgFv)
-- [Lighthouse](https://discord.gg/cyAszAh)
-- [Teku](https://discord.gg/7hPv2T6)
-- [Lodestar](https://discord.gg/aMxzVcr)
-
-Você também pode [aprender a executar um nó aqui](/developers/docs/nodes-and-clients/run-a-node/).
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
deleted file mode 100644
index b142285700f..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Nó de arquivo Ethereum
-description: Uma visão geral dos nós de arquivo
-lang: pt-br
-sidebarDepth: 2
----
-
-Um nó de arquivo é uma instância de um cliente Ethereum configurado para construir um arquivo de todos os estados históricos. É uma ferramenta útil para certos casos de uso, mas pode ser mais complicado de executar do que um nó completo.
-
-## Pré-requisitos {#prerequisites}
-
-Você deve entender o conceito de um [nó Ethereum](/developers/docs/nodes-and-clients/), [a arquitetura deles, assim como suas](/developers/docs/nodes-and-clients/node-architecture/) [estratégias de sincronização](/developers/docs/nodes-and-clients/#sync-modes), práticas de [execução](/developers/docs/nodes-and-clients/run-a-node/), e como [usá-los](/developers/docs/apis/json-rpc/).
-
-## O que é um nó de arquivo
-
-Para compreender a importância de um nó de arquivo, vamos esclarecer o conceito de "estado". O Ethereum pode ser chamado de _máquina de estado baseada em transações_. Consiste em contas e aplicativos que executam transações que estão mudando o seu estado. Os dados globais com informações sobre cada conta e contrato são armazenados em uma árvore de banco de dados chamado estado. Isso é tratado pelo cliente da camada de execução (EL) e inclui:
-
-- Saldos de conta e nonces
-- Código do contrato e armazenamento
-- Dados relacionados ao consenso, por exemplo, Contrato de Depósito de Staking
-
-Para interagir com a rede, verificar e produzir novos blocos, os clientes Ethereum precisam acompanhar as mudanças mais recentes (a ponta da cadeia) e, portanto, o estado atual. Um cliente da camada de execução configurado como um nó completo verifica e segue o último estado da rede, mas apenas armazena em cache os últimos estados, por exemplo, o estado associado aos últimos 128 blocos, para ele que possa lidar com a reorganização da cadeia e fornecer acesso rápido a dados recentes. O estado recente é o que todos os clientes precisam para verificar as transações recebidas e usar a rede.
-
-Você pode imaginar o estado como uma captura de rede em um determinado bloco e o arquivo como uma repetição do histórico.
-
-Os estados históricos podem ser podados com segurança porque não são necessários para operar a rede e, seria inútil para o cliente manter todos os dados desatualizados. Os estados que existiam antes de algum bloco recente (por exemplo, 128 blocos antes da ponta) são efetivamente jogados fora. Os nós completos só mantêm dados históricos da blockchain (blocos e transações) e capturas históricas ocasionais, que eles podem usar para regenerar estados mais antigos mediante solicitação. Eles fazem isso reexecutando transações passadas no EVM, que podem ser computacionalmente rigorosos quando o estado desejado está longe da imagem instantânea mais próxima.
-
-No entanto, isso significa que acessar um estado histórico em um nó completo consome muita computação. O cliente pode precisar executar todas as transações passadas e calcular um estado histórico desde a origem. Os nós de arquivo resolvem isso armazenando não apenas os estados mais recentes, mas cada estado histórico criado após cada bloco. Basicamente, isso implica um compromisso com um maior requisito de espaço em disco.
-
-É importante notar que a rede não depende de nós de arquivo para manter e fornecer todos os dados históricos. Conforme mencionado acima, todos os estados históricos provisórios podem ser derivados de um nó completo. As transações são armazenadas por qualquer nó completo (atualmente com menos de 400G) e podem ser reproduzidas para construir todo o arquivo.
-
-### Casos de uso
-
-O uso regular do Ethereum, como envio de transações, implantação de contratos, verificação de consenso, etc., não requer acesso a estados históricos. Os usuários nunca precisam de um nó de arquivo para uma interação padrão com a rede.
-
-O principal benefício do arquivo de estado é um acesso rápido a consultas sobre estados históricos. Por exemplo, o nó de arquivo retornaria prontamente resultados como:
-
-- _Qual era o saldo da conta ETH 0x1337... no bloco 15537393?_
-- _Qual é o saldo do token 0x no contrato 0x no bloco 1920000?_
-
-Conforme explicado acima, um nó completo precisaria gerar esses dados pela execução do EVM, que usa a CPU e leva tempo. Os nós de arquivo os acessam no disco e fornecem respostas imediatamente. Esse recurso é útil para certas partes da infraestrutura, por exemplo:
-
-- Provedores de serviços como exploradores de blocos
-- Pesquisadores
-- Analistas de segurança
-- Desenvolvedores de Dapp
-- Auditoria e conformidade
-
-Existem vários [serviços](/developers/docs/nodes-and-clients/nodes-as-a-service/) gratuitos que também permitem acesso a dados históricos. Como é mais exigente administrar um nó de arquivo, esse acesso é, na maioria das vezes, limitado e funciona apenas para acesso ocasional. Se o seu projeto requer acesso constante a dados históricos, considere a possibilidade de executar um você mesmo.
-
-## Implementações e uso
-
-O nó de arquivo, neste contexto, significa dados servidos pelos clientes da camada de execução voltados para o usuário, enquanto eles lidam com o banco de dados de estado e fornecem pontos de extremidade JSON-RPC. As opções de configuração, tempo de sincronização e tamanho do banco de dados podem variar conforme o cliente. Para mais detalhes, consulte a documentação fornecida pelo seu cliente.
-
-Antes de iniciar seu próprio nó de arquivo, aprenda sobre as diferenças entre os clientes e especialmente os vários [requisitos de hardware](/developers/docs/nodes-and-clients/run-a-node/#requirements). A maioria dos clientes não é otimizada para esse recurso e seus arquivos exigem mais de 12 TB de espaço. Por outro lado, implementações como Erigon podem armazenar os mesmos dados em menos de 3 TB, o que as torna a forma mais eficaz de executar um nó de arquivo.
-
-## Práticas recomendadas
-
-Além das [recomendações gerais para executar um nó](/developers/docs/nodes-and-clients/run-a-node/), um nó de arquivo pode exigir mais hardware e manutenção. Considerando as [principais funcionalidades](https://github.com/ledgerwatch/erigon#key-features) do Erigon, a abordagem mais prática é usar a implementação cliente do [Erigon](/developers/docs/nodes-and-clients/#erigon).
-
-### Hardware
-
-Sempre verifique os requisitos de hardware para um determinado modo na documentação de um cliente. O maior requisito para nós de arquivo é o espaço em disco. Dependendo do cliente, varia de 3 TB a 12 TB. Mesmo que o HDD possa ser considerado uma solução melhor para grandes quantidades de dados, sincronizá-lo e atualizar constantemente o topo da cadeia exigirá unidades SSD. As unidades [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) são boas o suficiente, mas devem ser de qualidade confiável, pelo menos [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). Os discos podem ser inseridos em um computador ou servidor com slots suficientes. Esses dispositivos dedicados são ideais para executar um nó de alto tempo de atividade. É totalmente possível executá-lo em um laptop, mas a portabilidade virá com um custo adicional.
-
-Todos os dados precisam se encaixar em um volume, portanto, os discos devem estar unidos, por exemplo, com [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) ou [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html). Também pode valer a pena considerar o uso de [ZFS](https://en.wikipedia.org/wiki/ZFS), pois ele suporta "Copy-on-write", que garante que os dados sejam gravados corretamente no disco sem quaisquer erros de baixo nível.
-
-Para obter mais estabilidade e segurança na prevenção de corrupção acidental do banco de dados, especialmente em uma configuração profissional, considere usar [memória ECC](https://en.wikipedia.org/wiki/ECC_memory) se o seu sistema a suportar. O tamanho de RAM é geralmente recomendado para ser o mesmo de um nó completo, mas mais RAM pode ajudar a acelerar a sincronização.
-
-Durante a sincronização inicial, os clientes no modo arquivo executarão todas as transações desde a origem. A velocidade de execução é limitada principalmente pela CPU, portanto, uma CPU mais rápida pode ajudar com o tempo de sincronização inicial. Em um computador de consumo médio, a sincronização inicial pode levar até um mês.
-
-## Leitura adicional {#further-reading}
-
-- [Nó completo Ethereum vs Nó de arquivo](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) — *QuickNode, setembro de 2022*
-- [Construindo seu próprio nó de arquivo Ethereum](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) — _Thomas Jay Rush, agosto de 2021_
-- [Como configurar Erigon, o RPC do Erigon e TrueBlocks (extração e API) como serviços](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, atualizado em setembro de 2022_
-
-## Tópicos relacionados {#related-topics}
-
-- [ Nós e clientes](/developers/docs/nodes-and-clients/)
-- [Executando um nó](/developers/docs/nodes-and-clients/run-a-node/)
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
deleted file mode 100644
index 20511b0ae30..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Introdução aos bootnodes Ethereum
-description: As informações básicas de que você precisa para entender os bootnodes
-lang: pt-br
----
-
-Quando um novo nó se junta à rede Ethereum, ele precisa se conectar aos nós que já estão na rede para descobrir novos pares. Esses pontos de entrada na rede Ethereum são chamados de bootnodes. Geralmente, os clientes têm uma lista de bootnodes codificados neles. Esses bootnodes são tipicamente executados pela equipe de devops da Ethereum Foundation ou pelas próprias equipes de clientes. Observe que os nós de inicialização não são iguais aos nós estáticos. Os nós estáticos são chamados por várias vezes, enquanto os bootnodes são chamados apenas se não houver pares suficientes para se conectar e um nó precisar inicializar algumas novas conexões.
-
-## Conectar-se a um bootnode {#connect-to-a-bootnode}
-
-A maioria dos clientes tem uma lista de bootnodes construídos, mas você também pode querer executar seu próprio bootnode ou usar um que não faça parte da lista codificada do cliente. Nesse caso, você pode especificá-los ao iniciar seu cliente, como a seguir (este exemplo é para Geth. Verifique a documentação do seu cliente):
-
-```
-geth --bootnodes "enode://@:"
-```
-
-## Executar um bootnode {#run-a-bootnode}
-
-Bootnodes são nós completos que não estão por trás de um NAT ([Conversão de Endereços de Rede](https://www.geeksforgeeks.org/network-address-translation-nat/)). Cada nó completo pode atuar como um bootnode, desde que esteja disponível publicamente.
-
-Quando você inicia um nó, ele deve registrar o seu [enode](/developers/docs/networking-layer/network-addresses/#enode), que é um identificador público que outras pessoas podem usar para se conectar ao seu nó.
-
-Normalmente, o enode é regenerado a cada reinicialização, portanto, verifique a documentação do seu cliente sobre como gerar um enode persistente para o seu bootnode.
-
-Para ter um bom bootnode, recomenda-se aumentar o número máximo de pares que podem se conectar a ele. Executar um bootnode com muitos pares aumentará significativamente o requisito de largura de banda.
-
-## Bootnodes disponíveis {#available-bootnodes}
-
-Uma lista de bootnodes integrados ao go-ethereum pode ser encontrada [aqui](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Esses bootnodes são mantidos pela Ethereum Foundation e pela equipe go-ethereum.
-
-Existem outras listas de bootnodes mantidas por voluntários disponíveis. Certifique-se de sempre incluir pelo menos um bootnode oficial, caso contrário, você poderá sofrer um ataque eclipse.
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
deleted file mode 100644
index 4f791c966cc..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Diversidade dos clientes
-description: Uma explicação de alto nível sobre a importância da diversidade de clientes do Ethereum.
-lang: pt-br
-sidebarDepth: 2
----
-
-O comportamento de um nó Ethereum é controlado pelo software do cliente que ele executa. Existem vários clientes Ethereum em nível de produção, cada um desenvolvido e mantido em diferentes idiomas por equipes separadas. Os clientes são construídos para uma especificação comum que garante que os clientes se comuniquem perfeitamente entre si e tenham a mesma funcionalidade e forneçam uma experiência de usuário equivalente. No entanto, no momento, a distribuição de clientes entre os nós não é igual o suficiente para realizar essa fortificação de rede em todo o seu potencial. O ideal é que os usuários se dividam de forma aproximadamente igualitária entre os vários clientes para trazer o máximo de diversidade de clientes possível para a rede.
-
-## Pré-requisitos {#prerequisites}
-
-Se você ainda não entende o que são nós e clientes, confira [nós e clientes](/developers/docs/nodes-and-clients/). As camadas de [execução](/glossary/#execution-layer) e [consenso](/glossary/#consensus-layer) estão definidas no glossário.
-
-## Por que existem vários clientes? {#why-multiple-clients}
-
-Vários clientes desenvolvidos e mantidos de forma independente existem porque a diversidade do cliente torna a rede mais resiliente a ataques e bugs. Vários clientes são uma força única para o Ethereum – outras cadeias de blocos dependem da infalibilidade de um único cliente. No entanto, não basta simplesmente ter vários clientes disponíveis, eles têm que ser adotados pela comunidade e o total de nós ativos distribuídos de forma relativamente uniforme entre eles.
-
-## Por que a diversidade de clientes é importante? {#client-diversity-importance}
-
-Ter muitos clientes desenvolvidos e mantidos de forma independente é vital para a saúde de uma rede descentralizada. Vamos explorar as razões do porquê.
-
-### Bugs {#bugs}
-
-Um bug em um cliente individual é um risco menor para a rede ao representar uma minoria de nós Ethereum. Com uma distribuição aproximadamente uniforme de nós entre muitos clientes, a probabilidade de a maioria dos clientes sofrer de um problema compartilhado é pequena e, como resultado, a rede é mais robusta.
-
-### Resiliência a ataques {#resilience}
-
-A diversidade de clientes também oferece resiliência a ataques. Por exemplo, um ataque que [engana um determinado cliente](https://twitter.com/vdWijden/status/1437712249926393858) em um determinado ramo da cadeia, provavelmente não será bem-sucedido porque é improvável que outros clientes sejam explorados da mesma forma e a cadeia canônica permanece incorruptível. A baixa diversidade de clientes aumenta o risco associado a um hack no cliente dominante. A diversidade de clientes já provou ser uma defesa importante contra ataques maliciosos na rede, por exemplo, o ataque de negação de serviço do Shanghai em 2016 foi possível porque os invasores foram capazes de enganar o cliente dominante (Geth) para executar uma operação lenta de E/S de disco dezenas de milhares de vezes por bloco. Como clientes alternativos também estavam online e não compartilharam a vulnerabilidade, o Ethereum foi capaz de resistir ao ataque e continuar operando enquanto a vulnerabilidade no Geth foi corrigida.
-
-### Finalidade da prova de participação {#finality}
-
-Um erro em um cliente de consenso com mais de 33% dos nós Ethereum poderia impedir a finalização da camada de consenso, e isso deixaria os utilizadores em dúvida com respeito à probabilidade de as transações não serem revertidas ou alteradas em algum momento. Isso seria muito problemático para muitos dos aplicativos construídos em cima do Ethereum, particularmente o DeFi.
-
- Pior ainda, um bug crítico em um cliente com uma maioria de dois terços poderia fazer com que a cadeia se dividisse e finalizasse incorretamente, gerando um grande conjunto de validadores que ficam presos em uma cadeia inválida. Se quiserem voltar a integrar à cadeia correta, esses validadores enfrentam cortes ou uma lenta e cara retirada e reativação voluntária. A magnitude de uma escala de remoção com o número de nós culpáveis com uma maioria de dois terços reduzido ao máximo (32 ETH).
-
-Embora estes sejam cenários improváveis, o ecossistema Ethereum pode mitigar seus riscos nivelando a distribuição de clientes entre os nós ativos. Idealmente, nenhum cliente de consenso chegaria a uma participação de 33% dos nós totais.
-
-### Responsabilidade compartilhada {#responsibility}
-
-Há também um custo humano para ter a maioria dos clientes. Isso coloca excesso de tensão e responsabilidade em uma pequena equipe de desenvolvimento. Quanto menor a diversidade de clientes, maior a carga de responsabilidade para os desenvolvedores que mantêm a maioria dos clientes. Promover essa responsabilidade em várias equipes é bom tanto para a saúde da rede de nós do Ethereum quanto para sua rede de pessoas.
-
-## Diversidade do cliente atual {#current-client-diversity}
-
- _Dados do diagrama de [ethernodes.org](https://ethernodes.org) e [clientdiversity.org](https://clientdiversity.org/)_
-
-Os dois gráficos de pizza acima mostram imagens da diversidade atual do cliente para as camadas de execução e consenso (no momento da escrita em janeiro de 2022). A camada de execução é dominada esmagadoramente por [Geth](https://geth.ethereum.org/), com [Open Ethereum](https://openethereum.github.io/) a um segundo de distância, [Erigon](https://github.com/ledgerwatch/erigon) em terceiro e [Nethermind](https://nethermind.io/) em quarto, com outros clientes compostos por menos de 1% da rede. O cliente mais comumente usado na camada de consenso – [Prysm](https://prysmaticlabs.com/#projects) – não é tão dominante quanto o Geth, mas ainda representa mais de 60% da rede. [Lighthouse](https://lighthouse.sigmaprime.io/) e [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) compõem ~20% e ~14% respectivamente, e outros clientes são raramente usados.
-
-Os dados da camada de execução foram obtidos de [Ethernodes](https://ethernodes.org) em 23 de janeiro de 2022. Os dados para clientes de consenso foram obtidos de [Michael Sproul](https://github.com/sigp/blockprint). Os dados dos clientes de consenso são mais difíceis de obter porque os clientes da camada de consenso nem sempre têm traços inequívocos que possam ser utilizados para identificá-los. Os dados foram gerados usando um algoritmo de classificação que confunde às vezes alguns dos clientes minoritários (consulte [aqui](https://twitter.com/sproulM_/status/1440512518242197516) para obter mais detalhes). No diagrama acima, essas classificações ambíguas são tratadas com um rótulo (por exemplo, Nimbus/Teku). No entanto, é claro que a maior parte da rede está executando o Prysm. Os dados são um retrato sobre um conjunto fixo de blocos (neste caso, blocos Beacon nos espaços 2048001 a 2164916) e o domínio do Prysm às vezes foi maior, excedendo 68%. Apesar de serem apenas capturas, os valores no diagrama fornecem uma boa noção geral do estado atual da diversidade do cliente.
-
-Os dados da diversidade do cliente atualizados para a camada de consenso agora estão disponíveis em [clientdiversity.org](https://clientdiversity.org/).
-
-## Camada de execução {#execution-layer}
-
-Até agora, a conversação em torno da diversidade do cliente tem se concentrado principalmente na camada de consenso. No entanto, o cliente de execução [Geth](https://geth.ethereum.org) atualmente representa cerca de 85% de todos os nós. Essa porcentagem é problemática pelos mesmos motivos dos clientes de consenso. Por exemplo, um bug no Geth afetando a manipulação de transações ou a construção de cargas de execução pode fazer com que clientes de consenso finalizem transações problemáticas ou com bugs. Portanto, o Ethereum seria mais saudável com uma distribuição mais uniforme dos clientes de execução, idealmente sem nenhum cliente representando mais de 33% da rede.
-
-## Use um cliente minoritário {#use-minority-client}
-
-Endereçar a diversidade do cliente requer mais do que usuários individuais para escolher clientes minoritários – requer pools de mineração/validadores e instituições como os principais dapps e exchanges para mudar também os clientes. No entanto, todos os usuários podem fazer sua parte para reparar o desequilíbrio atual e normalizar o uso de todo o software Ethereum disponível. Após A Fusão, todos os operadores de nó serão obrigados a executar um cliente de execução e um cliente de consenso. Escolher combinações dos clientes sugeridos abaixo ajudará a aumentar a diversidade do cliente.
-
-### Clientes de execução {#execution-clients}
-
-[Besu](https://www.hyperledger.org/use/besu)
-
-[Nethermind](https://downloads.nethermind.io/)
-
-[Erigon](https://github.com/ledgerwatch/erigon)
-
-[Go-Ethereum](https://geth.ethereum.org/)
-
-### Clientes de consenso {#consensus-clients}
-
-[Nimbus](https://nimbus.team/)
-
-[Lighthouse](https://github.com/sigp/lighthouse)
-
-[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
-
-[Lodestar](https://github.com/ChainSafe/lodestar)
-
-[Prysm](https://docs.prylabs.network/docs/getting-started)
-
-Os usuários técnicos podem ajudar a acelerar esse processo escrevendo mais tutoriais e documentações para clientes minoritários e encorajando seus pares operacionais de nó a migrar para longe dos clientes dominantes. Guias para mudar para um cliente de consenso minoritário estão disponíveis em [clientdiversity.org](https://clientdiversity.org/).
-
-## Painéis de diversidade de clientes {#client-diversity-dashboards}
-
-Vários painéis fornecem estatísticas de diversidade de cliente em tempo real para a camada de execução e consenso.
-
-**Camada de consenso:**
-
-- [Rated.network](https://www.rated.network/)
-- [clientdiversity.org](https://clientdiversity.org/) **Camada de execução:**
-
-- [supermajority.info](https://supermajority.info//)
-- [Ethernodes](https://ethernodes.org/)
-
-## Leitura adicional {#further-reading}
-
-- [Diversidade de clientes na camada de consenso do Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
-- [A Fusão do Ethereume: execute o cliente majoritário por sua conta e risco!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fest, 24 de março de 2022_
-- [Importância da diversidade de cliente](https://our.status.im/the-importance-of-client-diversity/)
-- [Lista dos serviços de nós Ethereum](https://ethereumnodes.com/)
-- ["Cinco porquês" do problema da diversidade de clientes](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
-- [Diversidade do Ethereum e como resolvê-la (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
-- [clientdiversity.org](https://clientdiversity.org/)
-
-## Tópicos relacionados {#related-topics}
-
-- [Executando um nó Ethereum](/run-a-node/)
-- [Nós e clientes](/developers/docs/nodes-and-clients/)
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
deleted file mode 100644
index bd77053b181..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
+++ /dev/null
@@ -1,307 +0,0 @@
----
-title: Nós e clientes
-description: Uma visão geral dos nós do Ethereum e do software do cliente, além de como configurar um nó e por que você deve fazer isso.
-lang: pt-br
-sidebarDepth: 2
----
-
-O Ethereum é uma rede distribuída de computadores (conhecidos como nós) executando softwares que podem verificar blocos e dados de transação. O software tem de ser rodado no seu computador para ele se tornar um nó Ethereum. Existem dois pedaços separados de software (conhecidos como 'clientes') necessários para formar um nó.
-
-## Pré-requisitos {#prerequisites}
-
-Você deve entender o conceito de uma rede peer-to-peer e os conceitos básicos [do EVM](/developers/docs/evm/) antes de mergulhar mais fundo e executar a sua própria instância de um cliente Ethereum. Veja nossa [introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-Se você é novo no tema dos nós, recomendamos primeiro verificar nossa introdução amigável no [rodando um nó Ethereum](/run-a-node).
-
-## O que são nós e clientes? {#what-are-nodes-and-clients}
-
-Um "nó" é qualquer instância de software do cliente Ethereum que esteja conectado a outros computadores também executando o software Ethereum, formando uma rede. Um cliente é uma implementação do Ethereum que verifica os dados em relação às regras do protocolo e mantém a rede segura. Um nó tem que rodar dois clientes: um cliente de consenso e um cliente de execução.
-
-- O cliente de execução (também conhecido como Execution Engine, cliente EL ou anteriormente cliente Eth1) ouve novas transações transmitidas na rede, executa-as na EVM e mantém o estado mais recente e o banco de dados de todos os dados atuais do Ethereum.
-- O cliente de consenso (também conhecido como Beacon Node, cliente CL ou anteriormente cliente Eth2) implementa o algoritmo de consenso de prova de participação, o qual permite que a rede realize um acordo com base nos dados validados do cliente de execução. Há também um terceiro pedaço de software, conhecido como 'validador' que pode ser adicionado ao cliente de consenso, permitindo que um nó participe na segurança da rede.
-
-Estes clientes trabalham juntos para manter rastreabilidade da cabeça da cadeia Ethereum e permitir usuários interagir com a rede Ethereum. O desenho modular com várias peças de software trabalhando em conjunto é chamado de [complexidade encapsulada](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Esta abordagem facilitou executar o [The Merge](/roadmap/merge) perfeitamente, faz softwares clientes mais fáceis de manter e desenvolver, e permite reusar clientes individuais, por exemplo, no [ecossistema camada 2](/layer-2/).
-
- Diagrama simplificado de uma execução associada e de um cliente de consenso.
-
-### Diversidade dos clientes {#client-diversity}
-
-Tanto [clientes de execução](/developers/docs/nodes-and-clients/#execution-clients) quanto [clientes de consenso](/developers/docs/nodes-and-clients/#consensus-clients) existem em uma variedade de linguagens de programação desenvolvidas por diferentes equipes.
-
-As implementações de vários clientes podem tornar a rede mais forte, reduzindo sua dependência de uma única base de código. O objetivo ideal é alcançar a diversidade sem que nenhum cliente domine a rede, eliminando assim um ponto único de falha potencial. A variedade de idiomas também convida uma comunidade de desenvolvedores mais ampla e permite que eles criem integrações em seu idioma preferido.
-
-Saiba mais sobre a [diversidade do cliente](/developers/docs/nodes-and-clients/client-diversity/).
-
-O que essas implementações têm em comum é que todas seguem uma única especificação. As especificações ditam como a rede Ethereum e a cadeia de blocos funcionam. Cada detalhe técnico é definido e as especificações podem ser encontradas como:
-
-- Originalmente, o [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [Especificações de execução](https://github.com/ethereum/execution-specs/)
-- [Especificações de consenso](https://github.com/ethereum/consensus-specs)
-- [EIPs](https://eips.ethereum.org/) implementados em várias [atualizações de rede](/history/)
-
-### Rastreamento de nós na rede {#network-overview}
-
-Vários rastreadores oferecem uma visão geral em tempo real dos nós na rede Ethereum. Observe que, devido à natureza das redes descentralizadas, esses rastreadores podem fornecer apenas uma visão limitada da rede e podem relatar resultados diferentes.
-
-- Mapa de nós pela Etherscan
-- Ethernodes da Bitfly
-- [Nodewatch](https://www.nodewatch.io/) por Chainsafe, rastreando nós de consenso
-
-## Tipos de nó {#node-types}
-
-Se você quer [executar o seu próprio nó](/developers/docs/nodes-and-clients/run-a-node/), você deve entender que existem diferentes tipos de nós que consomem dados de modo diferente. Na verdade, os clientes podem executar 3 tipos diferentes de nó: leve, completo e arquivo. Existem também opções de diferentes estratégias de sincronização que permitem um tempo de sincronização mais rápida. A sincronização se refere ao quão rápido ele pode obter as informações mais atualizadas sobre o estado do Ethereum.
-
-### Nó completo {#full-node}
-
-Nós completos fazem uma validação bloco-a-bloco do blockchain, incluindo baixar e verificar o corpo do bloco e dados de estado para cada bloco. Há diferentes classes de nó completo - algumas começam do bloco gênesis e verificam cada bloco no histórico inteiro do blockchain. Outras começam sua verificação em um bloco mais recente que eles confiam ser válido (por exemplo, o 'snap sync' do Geth). Independente de onde a verificação começa, nós completos somente mantém uma cópia local de dados relativamente recentes (tipicamente os 128 blocos mais recentes), permitindo dados mais antigos serem excluídos para economizar espaço em disco. Dados mais antigos podem ser regerados quando necessário.
-
-- Armazena os dados completos da cadeia de blocos (embora isso seja periodicamente reduzido para que um nó completo não armazene todos os dados de estado de volta à origem)
-- Participa na validação de bloco, verifica todos os blocos e estados.
-- Todos os estados podem ser recuperados do storage local ou regerados dos 'snapshots' por um nó completo.
-- Serve a rede e fornece dados mediante solicitação.
-
-### Nó de arquivo {#archive-node}
-
-Nós de arquivo são nós completos que verificam cada bloco desde o gênese e nunca excluem nada dos dados baixados.
-
-- Armazena tudo o que é mantido no nó completo e constrói um arquivo de estados históricos. Ele é necessário se você quiser consultar algo como um saldo de conta no bloco #4.000.000, ou testar de forma simples e confiável seu próprio conjunto de transações sem minerá-las usando rastreamento.
-- Esses dados representam unidades de terabytes, o que torna os nós de arquivo menos atraentes para usuários comuns, mas pode ser útil para serviços como exploradores de blocos, fornecedores de carteiras e análises da cadeia.
-
-Sincronizar clientes em qualquer modo que não seja o de arquivo resultará na remoção de dados da cadeia de blocos. Isso significa que não há arquivo de todo o estado histórico, mas o nó completo é capaz de criá-lo sob demanda.
-
-Saiba mais sobre [Nós de arquivo](/developers/docs/nodes-and-clients/archive-nodes).
-
-### Nó leve {#light-node}
-
-Em vez de baixar cada bloco, nós leves baixam somente os cabeçalhos dos blocos. Esses cabeçalhos contêm informações resumidas sobre o conteúdo dos blocos. Qualquer outra informação necessária pelo nó leve é solicitada de um nó completo. O nó leve pode então verificar de modo independente os dados que ele recebe em relação às raízes de estado nos cabeçalhos de bloco. Os nós leves permitem que os usuários participem da rede Ethereum sem o hardware poderoso ou a alta largura de banda necessária para executar nós completos. Por fim, os nós leves podem ser executados em telefones celulares ou dispositivos embutidos. Os nós leves não participam do consenso (ou seja, eles não podem ser mineradores/validadores), mas podem acessar a cadeia de blocos Ethereum com as mesmas funcionalidades e garantias de segurança de um nó completo.
-
-Clientes leves são uma área de desenvolvimento ativo para o Ethereum e esperamos ver em breve novos clientes leves para a camada de consenso e a camada de execução. Também existem rotas em potencial para fornecer dados de clientes leves pela [rede gossip](https://www.ethportal.net/). Isso é vantajoso porque a rede gossip pode suportar uma rede de nós leves sem exigir nós completos para atender às solicitações.
-
-O Ethereum ainda não suporta uma grande quantidade de nós leves, mas o suporte a nós leves é uma área que deve se desenvolver rapidamente em um futuro próximo. Em particular, clientes como [Nimbus](https://nimbus.team/), [Hélios](https://github.com/a16z/helios), e [LodeStar](https://lodestar.chainsafe.io/) atualmente estão bastante concentrados em nós leves.
-
-## Por que devo executar um nó Ethereum? {#why-should-i-run-an-ethereum-node}
-
-A execução de um nó permite que você use o Ethereum de forma direta, confiável e privada, enquanto dá suporte à rede, mantendo-a mais robusta e descentralizada.
-
-### Vantagens para você {#benefits-to-you}
-
-A execução de seu próprio nó permite que você use o Ethereum de maneira privada, autossuficiente e confiável. Você não precisa confiar na rede porque você pode verificar os dados por conta própria com seu cliente. “Não confie, verifique” é um mantra popular da cadeia de blocos.
-
-- Seu nó verifica todas as transações e blocos contra as regras de consenso por si só. Isso significa que você não precisa confiar em nenhum outro nó da rede nem confiar totalmente neles.
-- Você pode usar uma carteira Ethereum com seu próprio nó. Você pode usar dapps com mais segurança e privacidade porque você não precisará vazar seus endereços e saldos para intermediários. Tudo pode ser verificado com seu próprio cliente. [MetaMask](https://metamask.io), [Frame](https://frame.sh/) e [muitas outras carteiras](/wallets/find-wallet/) oferecem importação de RPC, permitindo que elas usem seu nó.
-- Você pode executar e auto-hospedar outros serviços que dependem de dados do Ethereum. Por exemplo, isso pode ser um validador Beacon Chain, software como camada 2, infraestrutura, exploradores de bloco, processadores de pagamento etc.
-- Você pode fornecer seus próprios [pontos de extremidade RPC](/developers/docs/apis/json-rpc/) personalizados. Você pode até oferecer endpoints publicamente para a comunidade para ajudá-los a evitar fornecedores grandes centralizados.
-- Você pode se conectar ao seu nó usando **Comunicações entre processos (IPC)** ou reescrever o nó para carregar seu programa como um plugin. Isso garante baixa latência, o que ajuda muito, por exemplo, ao processar muitos dados usando bibliotecas Web3 ou quando você precisa substituir suas transações o mais rápido possível (isto é, de forma acelerada).
-- Você pode colocar ETH diretamente para proteger a rede e ganhar recompensas. Veja [participação solo](/staking/solo/) para começar.
-
-
-
-### Benefícios da rede {#network-benefits}
-
-Um conjunto diversificado de nós é importante para a integridade, segurança e resiliência operacional do Ethereum.
-
-- Os nós completos impõem as regras de consenso para que não possam ser induzidos a aceitar blocos que não as seguem. Isso fornece segurança extra na rede, pois se todos os nós fossem nós leves, que não fazem a verificação completa, os validadores poderiam atacar a rede.
-- No caso de um ataque que supere as defesas criptoeconômicas de [prova de participação](/developers/docs/consensus-mechanisms/pos/#what-is-pos), uma recuperação social pode ser realizada por nós completos escolhendo seguir a cadeia honesta.
-- Mais nós na rede resultam em uma rede mais diversificada e robusta, o objetivo final da descentralização, que permite um sistema confiável e resistente à censura.
-- Nós completos fornecem acesso a dados do blockchain para clientes leves que dependem disso. Os nós leves não armazenam toda a cadeia de blocos. Em vez disso, eles verificam dados por meio das [raízes do estado nos cabeçalhos de blocos](/developers/docs/blocks/#block-anatomy). Eles podem solicitar mais informações dos nós completos, se precisarem.
-
-Se você rodar um nó completo, toda a rede Ethereum se beneficia dele, mesmo se você não rodar um validador.
-
-## Executando seu próprio nó {#running-your-own-node}
-
-Interessado em executar o seu próprio cliente Ethereum?
-
-Para ver uma introdução simplificada para iniciantes, visite a nossa página [Executar um nó](/run-a-node) para saber mais.
-
-Se você é mais que um usuário técnico, mergulhe em mais detalhes e opções sobre como [executar o seu próprio nó](/developers/docs/nodes-and-clients/run-a-node/).
-
-## Alternativas {#alternatives}
-
-Configurar seu próprio nó pode custar tempo e recursos, mas nem sempre você precisa executar sua própria instância. Nesse caso, é possível usar um provedor de APIs externo. Para obter uma visão geral do uso desses serviços, confira [nós como serviço](/developers/docs/nodes-and-clients/nodes-as-a-service/).
-
-Se alguém executar um nó do Ethereum com uma API pública em sua comunidade, você pode apontar suas carteiras para um nó da comunidade por meio de um RPC personalizado.
-
-Por outro lado, se você executar um cliente, você pode compartilhá-lo com quem precisar.
-
-## Clientes de execução {#execution-clients}
-
-A comunidade do Ethereum mantém vários clientes de execução (previamente conhecidos como clientes “Eth1”, ou apenas “clientes Ethereum”) de código aberto, desenvolvidos por diferentes equipes usando diferentes linguagens de programação. Isso torna a rede mais forte e [diversificada](/developers/docs/nodes-and-clients/client-diversity/). O objetivo ideal é alcançar a diversidade sem que nenhum cliente predomine, a fim de reduzir os pontos únicos de falha.
-
-Essa tabela resume os diferentes clientes. Todos eles passam por [testes de cliente](https://github.com/ethereum/tests) e são mantidos ativamente para ter as atualizações de rede em dia.
-
-| Client | Linguagem de programação | Sistemas operacionais | Redes | Estratégias de sincronização | Limpeza de estado |
-| ------------------------------------------------------------------------ | ------------------------ | --------------------- | -------------------------------- | ----------------------------------------------------------------------- | ----------------- |
-| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Rede principal, Sepolia, Holesky | [Instantânea](#snap-sync), [Completa](#full-sync) | Arquivo, Removido |
-| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Rede principal, Sepolia, Holesky | [Instantânea](#snap-sync) (sem serviço), Rápida, [Completa](#full-sync) | Arquivo, Removido |
-| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Rede principal, Sepolia, Holesky | [Instantânea](#snap-sync), [Rápida](#fast-sync), [Completa](#full-sync) | Arquivo, Removido |
-| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Rede principal, Sepolia, Holesky | [Completo](#full-sync) | Arquivo, Removido |
-| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Rede principal, Sepolia, Holesky | [Completo](#full-sync) | Arquivo, Removido |
-| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | Linux, Windows, macOS | Sepolia, Holesky | [Completo](#full-sync) | Removido |
-
-Para saber mais sobre redes suportadas, leia sobre as [redes Ethereum](/developers/docs/networks/).
-
-Cada cliente tem casos de uso e vantagens exclusivas, então você deve escolher um com base nas suas próprias preferências. A diversidade permite que as implementações se concentrem em diferentes recursos e públicos de usuários. Você pode escolher um cliente baseado em recursos, suporte, linguagem de programação ou licenças.
-
-### Besu {#besu}
-
-Hyperledger Besu é um cliente Ethereum de nível empresarial para redes públicas e autorizadas. Ele executa todos os recursos da Rede principal (Mainnet) do Ethereum, do rastreamento ao GraphQL, possui monitoramento extensivo e é suportado pela ConsenSys, tanto em canais comunitários abertos, quanto por meio de SLAs (contratos) comerciais para empresas. Ele é escrito em Java e tem licença Apache 2.0.
-
-A extensa [documentação](https://besu.hyperledger.org/en/stable/) do Besu irá guiar você por todos os detalhes sobre seus recursos e configurações.
-
-### Erigon {#erigon}
-
-Erigon, anteriormente conhecido como Turbo-Geth, começou como uma bifurcação do Go Ethereum orientado para velocidade e eficiência de espaço em disco. Erigon é uma implementação completamente rearquitetada do Ethereum, atualmente escrita em Go, mas com implementações em outras linguagens em desenvolvimento. O objetivo do Erigon é fornecer uma implementação mais rápida, modular e otimizada do Ethereum. Ele pode realizar uma sincronização completa do nó de arquivamento usando cerca de 2 TB de espaço em disco, em menos de 3 dias.
-
-### Go Ethereum {#geth}
-
-Go Ethereum (Geth, para abreviar) é uma das implementações originais do protocolo Ethereum. Atualmente, ele é o cliente mais difundido, com a maior base de usuários e variedade de ferramentas para usuários e desenvolvedores. Ele está escrito em Go, é totalmente de código aberto e sob licença GNU LGPL v3.
-
-Saiba mais sobre Geth em sua [documentação](https://geth.ethereum.org/docs/).
-
-### Nethermind {#nethermind}
-
-Nethermind é uma implementação do Ethereum criada com a pilha de tecnologia C# .NET, licenciada com LGPL-3.0, em execução em todas as principais plataformas, incluindo ARM. Ela oferece grande desempenho com:
-
-- uma máquina virtual otimizada
-- acesso ao estado
-- rede e recursos avançados, como painéis Prometheus/Grafana, suporte a registro de logs com Seq. Enterprise, rastreamento JSON-RPC e plugins de análise.
-
-Nethermind também tem uma [documentação detalhada](https://docs.nethermind.io), um suporte eficaz ao desenvolvedor, uma comunidade online e suporte 24 horas por dia disponível para usuários Premium.
-
-### Reth {#reth}
-
-O Reth (abreviação de Rust Ethereum) é uma implementação de nó completo do Ethereum fácil de usar, altamente modular, rápida e eficiente. O Reth foi originalmente desenvolvido e impulsionado pela Paradigm e está sob as licenças Apache e MIT.
-
-O Reth está pronto para produção e é adequado para uso em ambientes de essenciais, como staking ou serviços que exigem um tempo de atividade alto. Apresenta bom desempenho em casos de uso em que é necessário alto desempenho com grandes margens, como RPC, MEV, indexação, simulações e atividades P2P.
-
-Para saber mais, consulte o [Reth Book](https://reth.rs/) ou o repositório [Reth GitHub](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth).
-
-### Em desenvolvimento {#execution-in-development}
-
-Esses clientes ainda estão em estágios iniciais de desenvolvimento e ainda não são recomendados para uso em produção.
-
-#### EthereumJS {#ethereumjs}
-
-O cliente de execução EthereumJS (EthereumJS) foi escrito em TypeScript e é composto de vários pacotes, incluindo os principais primitivos do Ethereum representados pelas classes Block, Transaction e Merkle-Patricia Trie e os principais componentes do cliente, incluindo uma implementação da Máquina Virtual do Ethereum (EVM), uma classe de blockchain, e a pilha de rede DevP2P.
-
-Saiba mais sobre ele lendo a [documentação](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) correspondente
-
-## Clientes de consenso {#consensus-clients}
-
-Existem vários clientes de consenso (anteriormente conhecidos como clientes “Eth2”) para oferecer suporte às [atualizações de consenso](/roadmap/beacon-chain/). Eles são responsáveis por toda lógica de consenso, incluindo o algoritmo de escolha de fork, atestados de processamento e gerenciamento de recompensas e penalidades [proof-of-stake](/developers/docs/consensus-mechanisms/pos).
-
-| Cliente | Linguagem de programação | Sistemas operacionais | Redes |
-| ------------------------------------------------------------- | ------------------------ | --------------------- | -------------------------------------------------------------- |
-| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Goerli, Pyrmont, Sepolia, Ropsten e mais |
-| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten e mais |
-| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten e mais |
-| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten e mais |
-| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten e mais |
-
-### Lighthouse {#lighthouse}
-
-Lighthouse é uma implementação de cliente de consenso escrita em Rust sob licença Apache-2.0. Ele é mantido pela Sigma Prime e tem estado estável e pronto para produção desde a origem da Beacon Chain. Ele é utilizado por várias empresas, pools de participação (staking) e indivíduos. Ela visa ser segura, eficiente e interoperável em uma ampla variedade de ambientes, de PCs desktop a implantações automatizadas sofisticadas.
-
-A documentação está disponível no [Livro da Lighthouse](https://lighthouse-book.sigmaprime.io/)
-
-### Lodestar {#lodestar}
-
-Lodestar é uma implementação de cliente de consenso pronta para produção escrita em Typescript sob a licença LGPL-3.0. Ele é mantido pela ChainSafe Systems e é o mais novo dos clientes de consenso para participantes-solo (solo-stakers), desenvolvedores e pesquisadores. A Lodestar consiste em um nó beacon e um cliente validador alimentado por implementações JavaScript de protocolos Ethereum. O Lodestar visa melhorar a usabilidade do Ethereum com clientes leves, expandir a acessibilidade a um grupo maior de desenvolvedores e contribuir ainda mais para a diversidade do ecossistema.
-
-Mais informações podem ser encontradas em nosso [site da Lodestar](https://lodestar.chainsafe.io/)
-
-### Nimbus {#nimbus}
-
-Nimbus é uma implementação de cliente de consenso escrita em Nim sob a licença Apache-2.0. Ele é um cliente pronto para produção em uso por participantes-solo e pools de participação (staking). A Nimbus foi projetada para eficiência de recursos, facilitando a execução em dispositivos com recursos restritos e infraestrutura corporativa com a mesma facilidade, sem comprometer a estabilidade ou o desempenho da recompensa. Uma memória de recursos mais leve significa que o cliente tem uma maior margem de segurança quando a rede está sob estresse.
-
-Saiba mais na [documentação da Nimbus](https://nimbus.guide/)
-
-### Prysm {#prysm}
-
-O Prysm é um cliente de consenso de código aberto completo, escrito em Go sob a licença GPL-3.0. Ele apresenta uma interface de usuário de aplicativo Web opcional e prioriza a experiência do usuário, a documentação e a configurabilidade para usuários institucionais e particulares.
-
-Visite a [documentação do Prysm](https://docs.prylabs.network/docs/getting-started/) para saber mais.
-
-### Teku {#teku}
-
-Teku é um dos clientes originais da origem da Beacon Chain. Além dos objetivos habituais (segurança, robustez, estabilidade, usabilidade, desempenho), o Teku visa especificamente cumprir integralmente todos os padrões de cliente de consenso.
-
-O Teku oferece opções de implantação muito flexíveis. O nó beacon e o cliente validador podem ser executados juntos como um único processo, o que é extremamente conveniente para participantes solo (solo stakers), ou os nós podem ser executados separadamente para operações de participação sofisticadas. Além disso, o Teku é totalmente interoperável com o [Web3Signer](https://github.com/ConsenSys/web3signer/) para proteger as chaves de assinatura e protegê-las contra remoções.
-
-O Teku é escrito em Java e sob a licença Apache 2.0. Ele é desenvolvido pela equipe de Protocolos da ConsenSys, que também é responsável pelo Besu e Web3Signer. Saiba mais na [documentação do Teku](https://docs.teku.consensys.net/en/latest/).
-
-## Modos de sincronização {#sync-modes}
-
-Para acompanhar e verificar os dados atuais na rede, o cliente Ethereum precisa sincronizar com o estado da rede mais recente. Para isso, é necessário baixar dados de pares, verificar criptograficamente sua integridade e construir um banco de dados local da cadeia de blocos.
-
-Os modos de sincronização representam diferentes abordagens para esse processo com várias compensações. Os clientes também variam em sua implementação de algoritmos de sincronização. Sempre consulte a documentação oficial do cliente escolhido para obter detalhes sobre a implementação.
-
-### Modos de sincronização na camada de execução {#execution-layer-sync-modes}
-
-A camada de execução pode ser executada em diferentes modos para se adequar a diferentes casos de uso, desde a reexecução do estado geral da blockchain até a sincronização apenas com a parte inicial da cadeia a partir de um ponto de verificação confiável.
-
-#### Sincronização completa {#full-sync}
-
-Uma sincronização completa faz o download de todos os blocos (incluindo cabeçalhos e corpos de blocos) e regenera o estado da blockchain de forma incremental, executando cada bloco desde a gênese.
-
-- Minimiza a confiança e oferece a mais alta segurança, verificando cada transação.
-- Com um número crescente de transações, pode levar dias ou semanas para processar todas as transações.
-
-Os [nós de arquivo](#archive-node) realizam uma sincronização completa para criar (e manter) um histórico completo das alterações de estado feitas por cada transação em cada bloco.
-
-#### Sincronização rápida {#fast-sync}
-
-Assim como uma sincronização completa, uma sincronização rápida baixa todos os blocos (incluindo cabeçalhos, transações e recibos). No entanto, em vez de reprocessar as transações históricas, uma sincronização rápida se baseia nos recibos até chegar a um cabeçalho recente, quando passa a importar e processar blocos para fornecer um nó completo.
-
-- Estratégia de sincronização rápida.
-- Reduz a demanda de processamento em favor do uso da largura de banda.
-
-#### Sincronização instantânea {#snap-sync}
-
-As sincronizações instantâneas também verificam a cadeia bloco a bloco. No entanto, em vez de começar no bloco de gênese, uma sincronização instantânea começa em um ponto de verificação "confiável" mais recente conhecido por fazer parte da verdadeira blockchain. O nó grava pontos de checagem periódicos enquanto exclui dados mais velhos que uma certa idade. Esses instantâneos são usados para regenerar os dados de estado conforme necessário, em vez de armazená-los para sempre.
-
-- Estratégia de sincronização mais rápida, atualmente padrão na rede principal Ethereum.
-- Economiza muito uso de disco e largura de banda de rede sem sacrificar a segurança.
-
-[Mais sobre sincronização instantânea](https://github.com/ethereum/devp2p/blob/master/caps/snap.md).
-
-#### Sincronização leve {#light-sync}
-
-O modo cliente leve baixa todos os cabeçalhos de bloco, dados de bloco e verifica alguns aleatoriamente. Somente sincroniza a ponta da cadeia do ponto de verificação confiável.
-
-- Obtém apenas o estado mais recente, enquanto conta com a confiança dos desenvolvedores e o mecanismo de consenso.
-- Cliente pronto para uso com o estado atual da rede em poucos minutos.
-
-**NB** A sincronização leve ainda não funciona com a prova de participação do Ethereum — novas versões de sincronização leve deverão ser lançadas em breve!
-
-[Mais sobre clientes leves](/developers/docs/nodes-and-clients/light-clients/)
-
-### Modos de sincronização de camada de consenso {#consensus-layer-sync-modes}
-
-#### Sincronização otimista {#optimistic-sync}
-
-A sincronização otimista é uma estratégia de sincronização pós-fusão projetada para ser compatível por aceitação (opt-in) e com versões anteriores, permitindo que os nós de execução sincronizem por meio de métodos estabelecidos. O mecanismo de execução pode, de modo _otimista_, importar blocos beacon sem verificá-los completamente, encontrar o cabeçalho mais recente e começar a sincronizar a cadeia com os métodos acima. Em seguida, após a atualização do cliente de execução, ele informará ao cliente de consenso sobre a validade das transações na Beacon Chain.
-
-[Mais sobre sincronização otimista](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md)
-
-#### Sincronização de ponto de verificação {#checkpoint-sync}
-
-Uma sincronização de ponto de verificação, também conhecida como sincronização de subjetividade fraca, cria uma experiência de usuário superior para a sincronização de um Beacon Node. Ela se baseia em suposições de [subjetividade fraca](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) que permitem a sincronização da Beacon Chain a partir de um ponto de verificação recente de subjetividade fraca em vez da gênese. As sincronizações de ponto de verificação tornam o tempo de sincronização inicial significativamente mais rápido com suposições de confiança semelhantes às da sincronização de [gênese](/glossary/#genesis-block).
-
-Na prática, isso significa que seu nó se conecta a um serviço remoto para baixar os estados finalizados recentes e continua verificando os dados a partir desse ponto. O terceiro que fornece os dados é confiável e deve ser escolhido com cuidado.
-
-Mais sobre [sincronização do ponto de verificação](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)
-
-## Leitura adicional {#further-reading}
-
-- [Ethereum 101 – Parte 2 – Entendendo os nós](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _–Wil Barnes, 13 de fevereiro de 2019_
-- [Executando nós completos do Ethereum: um guia para os pouco motivados](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _— Justin Leroux, 7 de novembro de 2019_
-
-## Tópicos relacionados {#related-topics}
-
-- [Blocos](/developers/docs/blocks/)
-- [Redes](/developers/docs/networks/)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Transforme seu Raspberry Pi 4 em um nó validador apenas instalando o cartão MicroSD – Guia de instalação](/developers/tutorials/run-node-raspberry-pi/) _– Ligue seu Raspberry Pi 4, conecte um cabo Ethernet, conecte o disco SSD e ligue o dispositivo para transformar o Raspberry Pi 4 em um nó Ethereum completo executando a camada de execução (Rede principal) e/ou a camada de consenso (Beacon Chain / validador)._
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
deleted file mode 100644
index 5ed3da6c93c..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Clientes leves
-description: Introdução aos clientes leves Ethereum.
-lang: pt-br
----
-
-Executar um nó completo é a maneira mais confiável, privada, descentralizada e resistente à censura para interagir com o Ethereum. Com um nó completo, você mantém sua própria cópia da blockchain, que pode consultar instantaneamente e obter acesso direto à rede ponto a ponto do Ethereum. No entanto, executar um nó completo requer uma quantidade significativa de memória, armazenamento e CPU. Isso significa que não é viável para todos executar seu próprio nó. Existem várias soluções para isso no roteiro do Ethereum, incluindo a falta de estado, mas elas estão a vários anos de serem implementadas. A resposta a curto prazo é trocar alguns dos benefícios de executar um nó completo para grandes melhorias de desempenho, que permitem que os nós sejam executados com requisitos de hardware muito baixos. Os nós que fazem essa troca são conhecidos como nós leves.
-
-## O que é um cliente leve {#what-is-a-light-client}
-
-Um nó leve é um nó executando um software de cliente leve. Em vez de manter cópias locais dos dados da blockchain e verificar independentemente todas as mudanças, eles solicitam os dados necessários de algum provedor. O provedor pode ser uma conexão direta com um nó completo ou uma conexão por meio de um servidor RPC centralizado. Em seguida, os dados são verificados pelo nó leve, permitindo-lhe manter o início da cadeia. O nó leve processa apenas cabeçalhos de blocos, baixando apenas ocasionalmente o conteúdo real do bloco. Os nós podem variar em sua leveza, dependendo das combinações de software cliente leve e completo que eles executam. Por exemplo, a configuração mais leve seria executar um cliente de execução leve e um cliente de consenso leve. Também é provável que muitos nós optem por executar clientes de consenso leve, com clientes de execução completos ou vice-versa.
-
-## Como funcionam os clientes leves? {#how-do-light-clients-work}
-
-Quando o Ethereum começou a usar um mecanismo de consenso baseado em prova de participação, uma nova infraestrutura foi introduzida especificamente para dar suporte a clientes leves. Isso funciona selecionando aleatoriamente um subconjunto de 512 validadores a cada 1,1 dias para atuar como um **comitê de sincronização**. O comitê de sincronização assina o cabeçalho dos blocos recentes. Cada cabeçalho de bloco contém a assinatura agregada dos validadores no comitê de sincronização e um "bitfield" que mostra quais validadores assinaram e quais não. Cada cabeçalho também inclui uma lista de validadores esperados a participar da assinatura do bloco seguinte. Isso significa que um cliente leve pode ver rapidamente que o comitê de sincronização assinou os dados recebidos, e também pode verificar se o comitê de sincronização é o genuíno, comparando o que ele recebeu em relação ao que era previsto no bloco anterior. Dessa forma, o cliente leve pode continuar atualizando seu conhecimento do último bloco Ethereum, sem realmente baixar o bloco em si, apenas o cabeçalho que contém informações resumidas.
-
-Na camada de execução não há uma especificação única para um cliente de execução leve. O escopo de um cliente de execução leve pode variar de um "modo leve" de um cliente de execução completo com todas as funcionalidades EVM e de rede de um nó completo. No entanto, ele apenas verifica cabeçalhos de bloco, sem baixar os dados associados, ou pode ser um cliente mais enxuto, que depende muito do encaminhamento de solicitações a um provedor RPC para interagir com o Ethereum.
-
-## Por que os clientes leves são importantes? {#why-are-light-clients-important}
-
-Os clientes leves são importantes porque permitem aos usuários verificar os dados recebidos, em vez de confiar cegamente que seu provedor de dados seja correto e honesto, enquanto utilizam apenas uma pequena fração dos recursos computacionais de um nó completo. Os dados dos clientes leves recebidos podem ser verificados em relação aos cabeçalhos de bloco que eles sabem que foram assinados por pelo menos 2/3 de um conjunto aleatório de 512 validadores Ethereum. Essa é uma evidência muito forte de que os dados estão corretos.
-
-O cliente leve usa apenas uma pequena quantidade de poder de computação, memória e armazenamento para poder ser executado em um telefone celular, embutido em um aplicativo ou como parte de um navegador. Os clientes leves são uma forma de tornar o acesso minimizado por confiança ao Ethereum tão sem atritos quanto confiar em um provedor terceirizado.
-
-Vamos dar um exemplo simples. Imagine que você quer verificar o saldo da sua conta. Para fazer isso, você tem que fazer uma solicitação a um nó Ethereum. Esse nó irá verificar o saldo de sua cópia local do estado do Ethereum e o devolverá a você. Se você não tiver acesso direto a um nó, existem operadores centralizados que fornecem esses dados como um serviço. É possível enviar uma solicitação para eles, que verificam o nó deles e enviam o resultado de volta para você. O problema disso é que você tem de confiar no provedor para dar a você as informações corretas. Você nunca poderá realmente saber se as informações estão corretas se não puder verificá-las por si mesmo.
-
-Um cliente leve aborda essa questão. Você ainda solicita dados de algum provedor externo, mas quando recebe os dados de volta, eles vêm com uma prova de que seu nó leve pode comprovar as informações recebidas no cabeçalho do bloco. Isso significa que o Ethereum está verificando a exatidão de seus dados em vez de algum operador confiável.
-
-## Que inovações os clientes leves permitem? {#what-innovations-do-light-clients-enable}
-
-O principal benefício de clientes leves é permitir que mais pessoas acessem o Ethereum de forma independente, com requisitos de hardware insignificantes e dependência mínima de terceiros. Isso é bom para os usuários, porque eles podem verificar seus próprios dados e é bom para a rede, porque aumenta o número e a diversidade de nós que estão verificando a cadeia.
-
-A capacidade de executar nós Ethereum em dispositivos com armazenamento, memória e poder de processamento muito pequenos é uma das principais áreas de inovação desbloqueadas por clientes leves. Enquanto hoje os nós do Ethereum exigem muitos recursos de computação, os clientes leves podem ser incorporados em navegadores, executados em telefones celulares e talvez até em dispositivos menores, como relógios inteligentes. Isso significa que as carteiras Ethereum com clientes embutidos poderiam funcionar em um telefone celular. Isso significa que as carteiras móveis poderiam ser muito mais descentralizadas, já que elas não teriam que confiar em provedores de dados centralizados para seus dados.
-
-Isso pode ser expandido com a ativação de dispositivos para a **internet das coisas (IoT)**. Um cliente leve pode estar acostumado a provar rapidamente a propriedade de algum saldo de token ou NFT, com todas as garantias de segurança fornecidas pelos comitês de sincronização, disparando alguma ação em uma rede IoT. Imagine um [serviço de aluguel de bicicletas](https://youtu.be/ZHNrAXf3RDE?t=929), que usa um aplicativo com um cliente leve integrado para verificar rapidamente se você possui o NFT do serviço de aluguel e, em caso afirmativo, desbloqueia uma bicicleta para você pedalar!
-
-Os rollups do Ethereum também se beneficiariam de clientes leves. Um dos grandes problemas para os rollups são os hacks direcionados às pontes, que permitem a transferência de fundos da rede principal Ethereum para um rollup. Uma vulnerabilidade são os oráculos que os rollups usam para detectar que um usuário fez um depósito na ponte. Se um oráculo fornecer dados ruins, eles poderão enganar o rollup a pensar que houve um depósito para a ponte e liberar fundos incorretamente. Um cliente leve embutido no rollup poderia ser usado para proteger contra oráculos corrompidos, pois o depósito na ponte poderia vir com uma prova que pode ser verificada pelo rollup antes de liberar qualquer token. O mesmo conceito também poderia ser aplicado a outras pontes entre cadeias.
-
-Os clientes leves também poderiam ser usados para atualizar carteiras Ethereum. Em vez de confiar nos dados fornecidos por um provedor de RPC, sua carteira poderia verificar diretamente os dados apresentados a você usando um cliente leve incorporado. Isso adicionaria segurança à sua carteira. Se o seu provedor de RPC foi desonesto e forneceu a você dados incorretos, o cliente leve integrado poderá lhe dizer!
-
-## Qual é o estado atual do desenvolvimento do cliente leve? {#current-state-of-development}
-
-Existem vários clientes leves em desenvolvimento, incluindo clientes leves de execução, de consenso e de execução/consenso combinados. Estas são as implementações de cliente leve que conhecemos no momento em que escrevemos esta página:
-
-- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): cliente leve de consenso no TypeScript
-- [Helios](https://github.com/a16z/helios): cliente leve de execução e consenso combinado no Rust
-- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): modo leve para cliente de execução (em desenvolvimento) no Go
-- [Nimbus](https://nimbus.guide/el-light-client.html): cliente leve de consenso no Nim
-
-Até onde sabemos, nenhum deles ainda é considerado pronto para produção.
-
-Também há muito trabalho sendo feito para melhorar as formas pelas quais os clientes leves podem acessar os dados do Ethereum. Atualmente, os clientes leves dependem de solicitações RPC para nós completos usando um modelo cliente/servidor. Porém, no futuro, os dados poderão ser solicitados de maneira mais descentralizada usando uma rede dedicada como o [Portal Network](https://www.ethportal.net/), que pode servir os dados para clientes leves usando um protocolo de propagação ponto a ponto.
-
-Outros itens do [roteiro](/roadmap/) como [árvores Verkle](/roadmap/verkle-trees/) e [ausência de estado](/roadmap/statelessness/) acabarão por trazer as garantias de segurança de clientes leves iguais às de clientes completos.
-
-## Leitura adicional {#further-reading}
-
-- [Zsolt Felfodhi sobre clientes leves do Geth](https://www.youtube.com/watch?v=EPZeFXau-RE)
-- [Etan Kissling sobre redes de clientes leves](https://www.youtube.com/watch?v=85MeiMA4dD8)
-- [Etan Kissling sobre clientes leves após o The Merge](https://www.youtube.com/watch?v=ZHNrAXf3RDE)
-- [Piper Merriam: A estrada sinuosa rumo a clientes leves e funcionais](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
deleted file mode 100644
index 67dc5ea5181..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: Arquitetura do nó
-description: Introdução de como os nós Ethereum são organizados.
-lang: pt-br
----
-
-Um nó Ethereum é composto por dois clientes: um [cliente de execução](/developers/docs/nodes-and-clients/#execution-clients) e um [cliente de consenso](/developers/docs/nodes-and-clients/#consensus-clients).
-
-Quando o Ethereum estava usando [prova de trabalho](/developers/docs/consensus-mechanisms/pow/), um cliente de execução era suficiente para executar um nó completo Ethereum. No entanto, desde a implementação da [prova de participação](/developers/docs/consensus-mechanisms/pow/), o cliente de execução precisa ser usado com outro software, chamado [“cliente de consenso”](/developers/docs/nodes-and-clients/#consensus-clients).
-
-O diagrama abaixo mostra a relação entre os dois clientes Ethereum. Os dois clientes se conectam às suas respectivas redes ponto a ponto (P2P). As redes P2P separadas são necessárias à medida que os clientes de execução espalham transações em sua rede P2P, permitindo que eles gerenciem seu pool de transações local, enquanto os clientes de consenso distribuem blocos em sua rede P2P, permitindo consenso e crescimento da cadeia.
-
-
-
-Para que essa estrutura de dois clientes funcione, os clientes de consenso devem ser capazes de passar pacotes de transações para o cliente de execução. Executar transações localmente é como o cliente valida que as transações não violam nenhuma regra do Ethereum e que a atualização proposta para o estado do Ethereum está correta. Da mesma forma, quando o nó é selecionado para ser um produtor de bloco, o cliente de consenso deve ser capaz de solicitar pacotes de transações ao Geth para incluir no novo bloco e executá-los para atualizar o estado global. Essa comunicação entre clientes é tratada por uma conexão RPC local usando a [API engine](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md).
-
-## O que o cliente de execução faz? {#execution-client}
-
-O cliente de execução é responsável pelo tratamento de transações, transmissão de transações, gerenciamento de estado e suporte à Máquina Virtual Ethereum ([EVM](/developers/docs/evm/)). No entanto, ele **não** é responsável pela construção de blocos, transmissão de blocos ou tratamento da lógica de consenso. Eles estão no âmbito do cliente de consenso.
-
-O cliente de execução cria payloads (cargas) de execução — a lista de transações, triagem de estado atualizada e outros dados relacionados à execução. Os clientes de consenso incluem o payload em cada bloco. O cliente de execução também é responsável por reexecutar transações em novos blocos, para garantir que eles sejam válidos. A execução das transações é feita no computador embutido do cliente de execução, conhecido como [Máquina Virtual Ethereum (EVM)](/developers/docs/evm).
-
-O cliente de execução também oferece uma interface de usuário para Ethereum por meio de [métodos RPC](/developers/docs/apis/json-rpc), que permitem aos usuários consultar a blockchain Ethereum, enviar transações e implantar contratos inteligentes. É comum que as chamadas RPC sejam tratadas por uma biblioteca como [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/) ou por uma interface de usuário, como uma carteira de navegador.
-
-Em resumo, o cliente de execução é:
-
-- um gateway de usuário no Ethereum
-- o local da Máquina Virtual Ethereum, do estado e do pool de transações do Ethereum.
-
-## O que o cliente de consenso faz? {#consensus-client}
-
-O cliente de consenso lida com toda a lógica que permite que um nó permaneça sincronizado com a rede Ethereum. Isso inclui receber blocos de pares e executar um algoritmo de escolha de um fork, para garantir que o nó sempre siga a cadeia com o maior acúmulo de atestações (ponderados pelos saldos efetivos do validador). Semelhante ao cliente de execução, os clientes de consenso têm sua própria rede P2P, através da qual eles compartilham blocos e atestações.
-
-O cliente de consenso não participa do atestado ou da proposta de blocos — isso é feito por um validador, um complemento opcional para um cliente de consenso. Um cliente de consenso sem um validador acompanha apenas a ponta da cadeia, permitindo que o nó permaneça sincronizado. Isso permite que um usuário faça transações com o Ethereum usando seu cliente de execução, confiante de que está na cadeia correta.
-
-## Validadores {#validators}
-
-Os operadores de nó podem adicionar um validador aos seus clientes de consenso depositando 32 ETH no contrato de depósito. O cliente validador vem em conjunto com o cliente de consenso e pode ser adicionado a um nó a qualquer momento. O validador trata atestações e propostas de blocos. Eles permitem que um nó acumule recompensas ou perca ETH por meio de penalidades ou remoções. Executar o software do validador também torna um nó qualificado para propor um novo bloco.
-
-[Mais sobre staking](/staking/).
-
-## Comparação de componentes de um nó {#node-comparison}
-
-| Cliente de execução | Cliente de consenso | Validador |
-| -------------------------------------------------- | ----------------------------------------------------------------------- | -------------------------------------- |
-| Transmissão de transações em sua rede p2p | Transmissão de blocos e atestações em sua rede p2p | Propõe blocos |
-| Executa/reexecuta transações | Executa o algoritmo de escolha do fork | Acumula recompensas/penalizações |
-| Verifica mudanças de estado recebidas | Mantém o controle da ponta da cadeia | Faz atestações |
-| Gerencia tentativas de estado e recibos | Gerencia o estado do Beacon (contém informações de consenso e execução) | Requer 32 ETH para participar em stake |
-| Cria payload de execução | Mantém o rastreamento da aleatoriedade acumulada no RANDAO | Pode ser removido |
-| Expõe a API JSON-RPC para interagir com o Ethereum | Mantém o rastreamento de justificativa e finalização | |
-
-## Leitura adicional {#further-reading}
-
-- [Prova de participação](/developers/docs/consensus-mechanisms/pos)
-- [Proposta de bloqueio](/developers/docs/consensus-mechanisms/pos/block-proposal)
-- [Recompensas e penalidades do validador](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
deleted file mode 100644
index 6a875dc2e18..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
+++ /dev/null
@@ -1,419 +0,0 @@
----
-title: Nós como serviço
-description: Uma visão inicial dos nós como um serviço, os prós e contras e os provedores mais populares.
-lang: pt-br
-sidebarDepth: 2
----
-
-## Introdução {#Introduction}
-
-Executar o seu próprio [nó Ethereum](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) pode ser desafiador, especialmente quando for iniciado ou escalando rápido. Há [vários serviços](#popular-node-services) que executam a infraestrutura do nó otimizada para você, para que você possa se concentrar no desenvolvimento da sua aplicação ou produto. Vamos explicar como os serviços de nó funcionam, os prós e os contras para usá-los e listar provedores se você estiver interessado em começar.
-
-## Pré-requisitos {#prerequisites}
-
-Se você ainda não sabe o que são os nós e os clientes e como eles funcionam, confira [Nós e clientes](/developers/docs/nodes-and-clients/).
-
-## Participantes {#stakoooooooooooooors}
-
-Os participantes individuais devem executar sua própria infraestrutura, em vez de depender de provedores de terceiros. Isso significa executar um cliente de execução acoplado a um cliente de consenso. Antes da [Fusão](/roadmap/merge) (The Merge), era possível executar apenas um cliente de consenso e usar um provedor centralizado para dados de execução. Porém, isso não é mais possível: um participante individual deve executar ambos os clientes. No entanto, há serviços disponíveis para facilitar este processo.
-
-[Leia mais sobre execução de um nó](/developers/docs/nodes-and-clients/run-a-node/).
-
-Os serviços descritos nesta página são para nós não participantes.
-
-## Como funcionam os serviços de nós? {#how-do-node-services-work}
-
-Os provedores de nós disponibilizam sua infraestrutura para você não precisar de uma.
-
-Esses serviços são geralmente fornecem uma chave API que você pode usar para gravar e ler as informações dentro da cadeia de blocos. Muitas vezes, incluindo acesso a [redes de testes Ethereum](/developers/docs/networks/#ethereum-testnets) além da rede principal.
-
-Alguns serviços oferecem a você o seu próprio nó dedicado que eles gerenciam para você, enquanto outros usam os balanceadores de carga para distribuir atividade entre nós.
-
-Quase todos os serviços de nó são extremamente fáceis de integrar, envolvendo uma alteração de linha no seu código para trocar seu nó hospedado, ou até mesmo alternar entre os próprios serviços.
-
-Muitas vezes os serviços de nó executam uma variedade de [clientes de nó](/developers/docs/nodes-and-clients/#execution-clients) e [tipos](/developers/docs/nodes-and-clients/#node-types), permitindo que você acesse nós completos e arquive, além dos métodos específicos do cliente em uma API.
-
-É importante notar que os serviços de nós não armazenam nem devem armazenar suas chaves ou informações privadas.
-
-## Quais são os benefícios do uso do serviço de nós? {#benefits-of-using-a-node-service}
-
-O principal benefício para usar um serviço de nós é não ter de gastar tempo de engenharia mantendo e gerenciando nós você mesmo. Isso permite que você se concentre na construção do seu produto em vez de se preocupar com a manutenção da infraestrutura.
-
-Executar seus próprios nós pode ser muito caro, quer seja de armazenamento, largura de banda, quer de tempo de engenharia. Dispor de mais nós ao dimensionar, atualizar nós para as versões mais recentes e garantir a consistência dos estados pode roubar tempo para criar e usar recursos no seu produto web3 desejado.
-
-## Quais são os contras do uso do serviço de nós? {#cons-of-using-a-node-service}
-
-Usando um serviço nó você está centralizando o aspecto da infraestrutura do seu produto. Por esse motivo, os projetos que dão à descentralização a maior importância podem preferir nós de auto-hospedagem a terceirizar o serviço a terceiros.
-
-Leia mais sobre os [benefícios de executar o seu próprio nó](/developers/docs/nodes-and-clients/#benefits-to-you).
-
-## Serviços de nós populares {#popular-node-services}
-
-Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. Sinta-se à vontade para adicionar qualquer um que estiver faltando! Cada nó de serviço oferece diferentes benefícios e recursos, além de níveis gratuitos ou pagos. Você deve analisar quais deles melhor se adaptam às suas necessidades antes de tomar uma decisão.
-
-- [**Alchemy**](https://alchemy.com/)
- - [Documentos](https://docs.alchemyapi.io/)
- - Recursos
- - Maior camada gratuita com 300M unidades de computação por mês (aproximadamente 30M solicitações getLatestBlock)
- - Suporte multicadeia para Polygon, Starknet, Otimizm, Arbitrum
- - Atingindo cerca de 70% do maior volume de transações DeFi e dapps Ethereum
- - Webhooks em tempo real via Alchemy Notify
- - O melhor suporte e confiabilidade / estabilidade
- - API NFT da Alchemy
- - Painel com Request Explorer, Mempool Watcher e Composer
- - Acesso à torneira para testes integrados
- - Comunidade ativa de construtores do Discord com 18 mil usuários
-
-- [**Todo esse nó**](https://allthatnode.com/)
- - [Documentos](https://docs.allthatnode.com/)
- - Funcionalidades
- - 50.000 solicitações por dia com o nível gratuito
- - Suporte para mais de 40 protocolos
- - APIs JSON-RPC (EVM, Tendermint), REST e Websocket suportadas
- - Acesso ilimitado por data do arquivo
- - Suporte técnico 24/7 e 99,9% de tempo de atividade
- - Faucet disponível em múltiplas cadeias
- - Acesso ilimitado a endpoints com um número ilimitado de chaves de API
- - API de rastreamento/depuração suportada
- - Atualizações automatizadas
-
-- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/)
- - [Documentação](https://aws.amazon.com/managed-blockchain/resources/)
- - Recursos
- - Os nós de Ethereum são completamente gerenciados
- - Disponíveis em seis regiões
- - JSON-RPC sobre HTTP e WebSockets seguros
- - Suporta 3 cadeias
- - SLA, Suporte AWS 24/7
- - Go-ethereum and Lighthouse
-
-- [**Ankr**](https://www.ankr.com/)
- - [Documentação](https://docs.ankr.com/)
- - Recursos
- - Protocolo Ankr – Código livre para pontos de extremidade de API RPC públicos para mais de 8 cadeias
- - Monitoramento da integridade do nó e balanceamento de carga para um gateway rápido de confiável até o nó mais próximo disponível
- - Nível premium que habilita o ponto de extremidade WSS e o limite de taxa sem teto
- - Implementação de um nó completo em um clique e um nó validador para mais de 40 cadeias
- - Dimensione conforme suas necessidades
- - Ferramentas de análise
- - Painel
- - Pontos de extremidade RPC, HTTPS e WSS
- - Suporte direto
-
-- [**Blast**](https://blastapi.io/)
- - [Documentação](https://docs.blastapi.io/)
- - Recursos
- - Suporte a RPC e WSS
- - Hospedagem de nós multirregiões
- - Infraestrutura descentralizada
- - API pública
- - Plano Gratuito Dedicado
- - Suporte a multicadeias (mais de 17 cadeias de blocos)
- - Nós de arquivo
- - Suporte ao Discord 24/7
- - Monitoramento e alertas 24/7
- - Um SLA geral de 99,9%
- - Pague em criptomoedas
-
-- [**BlockDaemon**](https://blockdaemon.com/)
- - [Documentação](https://ubiquity.docs.blockdaemon.com/)
- - Benefícios
- - Painel
- - Base por nó
- - Análise
-
-- [**BlockPI**](https://blockpi.io/)
- - [Documentação](https://docs.blockpi.io/)
- - Recursos
- - Estrutura de nós robusta & distribuída
- - Até 40 pontos de extremidade HTTPS e WSS
- - Pacote gratuito de inscrição e pacote mensal
- - Método de rastreamento + suporte aos dados de arquivos
- - Validade dos pacotes até 90 dias,
- - Plano personalizado e pagamento conforme o uso
- - Pague em criptomoedas
- - Suporte direto & Suporte técnico
-
-- [**Chainbase**](https://www.chainbase.com/)
- - [Documentação](https://docs.chainbase.com)
- - Recursos
- - Serviço RPC altamente disponível, rápido e escalável
- - Suporte multicadeia
- - Tarifas gratuitas
- - Painel amigável
- - Fornece serviços de dados blockchain além do RPC
-
-- [**Chainstack**](https://chainstack.com/)
- - [Documentação](https://docs.chainstack.com/)
- - Recursos
- - Nós compartilhados gratuitos
- - Arquivos compartilhados de nós
- - Suporte ao GraphQL
- - Pontos de extremidade RPC e WSS
- - Nós dedicados completos e arquivados
- - Tempo de sincronização rápido para implantações dedicadas
- - Traga sua própria nuvem
- - Valor do pagamento por hora
- - Suporte direto 24/7
-
-- [**DataHub**](https://datahub.figment.io)
- - [Documentos](https://docs.figment.io/)
- - Recursos
- - Opção de camada gratuita com 3.000.000 pedidos/mês
- - Pontos de extremidade RPC e WSS
- - Nós dedicados completos e arquivados
- - Escalonamento automático (Descontos de volume)
- - Dados de arquivamento grátis
- - Análise do Serviço
- - Painel
- - Suporte Direto 24/7
- - Pague em criptomoedas (Enterprise)
-
-- [**DRPC**](https://drpc.org/)
- - [Documentação](https://docs.drpc.org/)
- - Recursos
- - Nós RPC descentralizados
- - Mais de 15 provedores de nós
- - Balanceamento de nós
- - Unidades de computação ilimitadas por mês na camada gratuita
- - Verificação de dados
- - Pontos de extremidade personalizados
- - Endpoints HTTP e WSS
- - Chaves ilimitadas (camada paga e gratuita)
- - Opções de fallback flexíveis
- - [Endpoint público](https://eth.drpc.org)
- - Nós de arquivos compartilhados gratuitos
-
-- [**GetBlock**](https://getblock.io/)
- - [Documentação](https://getblock.io/docs/get-started/authentication-with-api-key/)
- - Recursos
- - Acesso a mais de 40 nós de blockchain
- - 40.000 solicitações diárias gratuitas
- - Número ilimitado de chaves de API
- - Alta velocidade de conexão em 1GB/segundo
- - Rastrear+Arquivar
- - Análises avançadas
- - Atualizações automatizadas
- - Suporte técnico
-
-- [**InfStones**](https://infstones.com/)
- - Recursos
- - Opção de nível gratuito
- - Dimensione conforme suas necessidades
- - Análise
- - Painel
- - Terminais de API únicos
- - Nós completos dedicados
- - Tempo de sincronização rápido para implantações dedicadas
- - Suporte direto 24/7
- - Acesso a mais de 50 nós da blockchain
-
-- [**Infura**](https://infura.io/)
- - [Documentação](https://infura.io/docs)
- - Recursos
- - Opção de nível gratuito
- - Dimensione conforme suas necessidades
- - Dados de arquivos pagos
- - Suporte direto
- - Painel
-
-- [**Kaleido**](https://kaleido.io/)
- - [Documentação](https://docs.kaleido.io/)
- - Recursos
- - Nível inicial gratuito
- - Implementação do nó Ethereum em um clique
- - Clientes e algoritmos personalizáveis (Geth, Quorum e Besu || PoA, IBFT e Raft)
- - Mais de 500 APIs administrativas e de serviço
- - Interface RESTful para envio de transação Ethereum (com Apache Kafka)
- - Fluxos de saída para entrega de eventos (com Apache Kafka)
- - Profunda coleção de serviços “fora da cadeia” e auxiliares (por exemplo, transporte de mensagens criptografadas bilaterais)
- - Integração de rede direta com controle de governança e acesso baseado em funções
- - Gerenciamento de usuários sofisticado para administradores e usuários finais
- - Infraestrutura altamente escalonável, resiliente e de nível empresarial
- - Gerenciamento de chaves privadas HSM
- - Compartilhamento de Internet da Mainnet (Rede principal) Ethereum
- - Certificações de tipo 2, ISO 27k e SOC 2
- - Configuração dinâmica de execução (por exemplo, adicionar integrações na nuvem, alterar entradas do nó, etc.)
- - Suporte a orquestrações multinuvem, multirregião e de implantação híbrida
- - Preços simples baseados em SaaS por hora
- - SLAs e suporte 24x7
-
-- [**Lava Network**](https://www.lavanet.xyz/)
- - [Documentação](https://docs.lavanet.xyz/)
- - Recursos
- - Utilização gratuita da Testnet
- - Redundância descentralizada para um tempo de atividade elevado
- - Código aberto
- - SDK totalmente descentralizado
- - Integração Ethers.js
- - Interface intuitiva de gestão de projetos
- - Integridade dos dados baseada em consenso
- - Suporte multicadeia
-
-- [**Moralis**](https://moralis.io/)
- - [Documentação](https://docs.moralis.io/)
- - Recursos
- - Nós compartilhados gratuitos
- - Nós de arquivos compartilhados gratuitos
- - Focado na privacidade (sem política de registros)
- - Suporte entre cadeias
- - Dimensione conforme suas necessidades
- - Painel
- - SDK único do Ethereum
- - Terminais de API únicos
- - Suporte técnico direto
-
-- [**NodeReal MegaNode**](https://nodereal.io/)
- - [Documentação](https://docs.nodereal.io/nodereal/meganode/introduction)
- - Recursos
- - Serviços confiáveis, rápidos e dimensionáveis da API RPC
- - API aprimorada para desenvolvedores Web3
- - Suporte multicadeia
- - Comece gratuitamente
-
-- [**NOWNodes**](https://nownodes.io/)
- - [Documentos](https://documenter.getpostman.com/view/13630829/TVmFkLwy)
- - Recursos
- - Acesso a mais de 50 nós da blockchain
- - Chave de API gratuita
- - Exploradores de bloco
- - Tempo de resposta da API ⩽ 1 segundo
- - Equipe de suporte 24/7
- - Gerente de conta pessoal
- - Nós compartilhados, de arquivo, de cópia de segurança e dedicados
-
-- [**Pocket Network**](https://www.pokt.network/)
- - [Documentos](https://docs.pokt.network/home/)
- - Recursos
- - Protocolo RPC descentralizado e mercado
- - 1 milhão de solicitações gratuitas por dia (por ponto de extremidade, máx. 2)
- - [Pontos de extremidade públicos](https://docs.pokt.network/developers/public-endpoints)
- - Programa Pre-Stake+ (se você precisar de mais de 1 milhão de solicitações por dia)
- - Mais de 15 blockchains compatíveis
- - Mais de 6.400 nós com ganhos de POKT a serviço dos aplicativos
- - Nó de arquivamento, nó de arquivamento com rastreamento e suporte a nós na rede de teste
- - Diversidade do cliente do nó da rede principal Ethereum
- - Nenhum ponto único de falha
- - Sem tempo de inatividade
- - Tokenomics rentáveis e perto de zero (participação de POKT uma vez para a largura de banda da rede)
- - Sem custos irrecuperáveis mensais. Transforme sua infraestrutura em um ativo
- - Balanceamento de carga incorporado ao protocolo
- - Dimensione infinitamente o número de solicitações por dia e nós por hora conforme o uso
- - A opção mais particular e resistente à censura
- - Suporte prático para desenvolvedores
- - Painel e ferramentas de análise do [Pocket Portal](https://bit.ly/ETHorg_POKTportal)
-
-- [**QuickNode**](https://www.quicknode.com)
- - [Documentos](https://www.quicknode.com/docs/)
- - Recursos
- - Suporte técnico 24/7 e comunidade de desenvolvedores do Discord
- - Rede de baixa latência, geograficamente equilibrada e multinuvem/metal
- - Suporte multicadeia (Optimism, Arbitrum, Polygon + 11 outros)
- - Camadas intermediárias para velocidade e estabilidade (roteamento de chamadas, cache, indexação)
- - Monitoramento de contratos inteligentes via Webhooks
- - Painel intuitivo, conjunto de análises, compositor RPC
- - Funcionalidades avançadas de segurança (JWT, mascaramento, lista de permissões)
- - Dados e API de análise de NFT
- - [Certificação SOC2](https://www.quicknode.com/security)
- - Adequado para desenvolvedores e empresas
-
-- [**Rivet**](https://rivet.cloud/)
- - [Documentos](https://rivet.readthedocs.io/en/latest/)
- - Recursos
- - Opção de nível gratuito
- - Dimensione conforme suas necessidades
-
-- [**SenseiNode**](https://senseinode.com)
- - [Documentos](https://docs.senseinode.com/)
- - Recursos
- - Nós dedicados e compartilhados
- - Painel
- - Hospedagem fora da AWS em vários provedores de hospedagem em diferentes locais da América Latina
- - Clientes Prysm e Lighthouse
-
-- [**SettleMint**](https://console.settlemint.com/)
- - [Documentos](https://docs.settlemint.com/)
- - Recursos
- - Avaliação gratuita
- - Dimensione conforme suas necessidades
- - Suporte ao GraphQL
- - Pontos de extremidade RPC e WSS
- - Nós completos dedicados
- - Traga sua própria nuvem
- - Ferramentas de análise
- - Painel
- - Valor do pagamento por hora
- - Suporte direto
-
-- [**Tenderly**](https://tenderly.co/web3-gateway)
- - [Documentos](https://docs.tenderly.co/web3-gateway/web3-gateway)
- - Recursos
- - Nível gratuito, incluindo 25 milhões de unidades Tenderly por mês
- - Acesso gratuito aos dados históricos
- - Cargas de trabalho de leitura pesada até 8 vezes mais rápidas
- - Acesso de leitura 100% consistente
- - Endpoints JSON-RPC
- - Construtor de solicitações RPC baseado em interface de usuário e pré-visualização de solicitações
- - Integração rigorosa com as ferramentas de desenvolvimento, depuração e teste do Tenderly
- - Simulações de transação
- - Análise de uso e filtragem
- - Gerenciamento fácil de chaves de acesso
- - Suporte técnico dedicado via chat, e-mail e Discord
-
-- [**Tokenview**](https://services.tokenview.io/)
- - [Documentos](https://services.tokenview.io/docs?type=nodeService)
- - Recursos
- - Suporte técnico 24/7 & comunidade Telegram de desenvolvedores
- - Suporte multichain (Bitcoin, Ethereum, Tron, BNB Smart Chain, Ethereum Classic)
- - Ambos endpoints RPC e WSS estão disponíveis para uso
- - Acesso ilimitado para a API de dados de arquivo
- - Painel com Request Explorer e Mempool Watcher
- - API de dados NFT e notificador Webhook
- - Pagamento em Cripto
- - Suporte externo para requisitos extras de comportamento
-
-- [**Watchdata**](https://watchdata.io/)
- - [Documentos](https://docs.watchdata.io/)
- - Recursos
- - Confiabilidade dos dados
- - Conexão ininterrupta sem tempo de inatividade
- - Automação do processo
- - Tarifas gratuitas
- - Limites altos que se adaptam a qualquer usuário
- - Suporte a vários nós
- - Dimensionamento de recursos
- - Velocidades de processamento altas
-
-- [**ZMOK**](https://zmok.io/)
- - [Documentos](https://docs.zmok.io/)
- - Recursos
- - Front-running como serviço
- - Mempool de transações globais com métodos de pesquisa/filtragem
- - Taxa TX ilimitada e Gás infinito para envio de transações
- - O máximo de velocidade na obtenção do novo bloco e leitura da blockchain
- - O melhor preço garantido por chamada de API
-
-- [**Zeeve**](https://www.zeeve.io/)
- - [Documentos](https://www.zeeve.io/docs/)
- - Recursos
- - Plataforma de automação sem código de nível empresarial que fornece implantação, monitoramento e gerenciamento de nós e redes da Blockchain
- - Mais de 30 protocolos e integrações, e adicionando mais
- - Valor adicionado à infraestrutura de serviços web3 como armazenamento decentralizado, identidade decentralizada e APIs de dados do Blockchain Ledger para casos reais
- - Suporte 24/7 e monitoramento proativo garantem a saúde dos nós o tempo todo.
- - Os endpoints RPC oferecem acesso autenticado às APIs, gerenciamento sem complicações com painel intuitivo e análise.
- - Fornece nuvem gerenciada e traz suas próprias opções de nuvem para escolher, além de oferecer suporte a todos os maiores provedores de nuvem como AWS, Azure, Google Cloud, Digital Ocean e local.
- - Usamos roteamento inteligente para sempre atingir o nó mais próximo de seu usuário
-
-
-## Leitura adicional {#further-reading}
-
-- [Lista dos serviços de nós Ethereum](https://ethereumnodes.com/)
-
-## Tópicos relacionados {#related-topics}
-
-- [ Nós e clientes](/developers/docs/nodes-and-clients/)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Introdução ao desenvolvimento de Ethereum usando Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/)
-- [Guia para enviar transações usando web3 e Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
diff --git "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" "b/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
deleted file mode 100644
index 2ec03791d46..00000000000
--- "a/public/content/translations/pt-br/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
+++ /dev/null
@@ -1,480 +0,0 @@
----
-title: Execute seu próprio nó Ethereum
-description: Introdução geral para a execução da sua própria instância de um cliente Ethereum.
-lang: pt-br
-sidebarDepth: 2
----
-
-Exdcutar um nó próprio proporciona vários benefícios, abre novas possibilidades e ajuda a dar suporte ao ecossistema. Esta página vai ajudar você a iniciar seu próprio nó, para assim participar na validação das transações de Ethereum.
-
-Observe que após [A Fusão](/roadmap/merge) (The Merge), são necessários dois clientes para executar um nó Ethereum; um cliente da **camada de execução (EL)** e um cliente da **camada de consenso (CL)**. Esta página mostrará como instalar, configurar e conectar esses dois clientes para executar um nó Ethereum.
-
-## Pré-requisitos {#prerequisites}
-
-Você deve entender o que é um nó Ethereum e por que é importante executar um cliente. Isso é abordado em [Nós e clientes](/developers/docs/nodes-and-clients/).
-
-Se você é novo no tópico de executar um nó ou está procurando um caminho menos técnico, recomendamos primeiro verificar nossa introdução simplificada sobre como [executar um nó Ethereum](/run-a-node).
-
-## Escolhendo um método {#choosing-approach}
-
-O primeiro passo para iniciar um nó é escolher sua abordagem. Com base nos requisitos e várias possibilidades, você deve selecionar a implementação do cliente (de ambos os clientes de execução e consenso), o ambiente (hardware, sistema) e os parâmetros para as configurações do cliente.
-
-Esta página guiará você por essas decisões e ajudará você a encontrar a maneira mais adequada para executar sua instância do Ethereum.
-
-Para escolher entre as implementações de cliente, veja todos os [clientes de execução](/developers/docs/nodes-and-clients/#execution-clients) prontos para a Rede principal disponíveis, [clientes de consenso](/developers/docs/nodes-and-clients/#consensus-clients) e saiba mais sobre a [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity).
-
-Decida se deseja executar o software em seu próprio [hardware ou na nuvem](#local-vs-cloud), considerando os [requisitos](#requirements) dos clientes.
-
-Após preparar o ambiente, instale os clientes escolhidos com [interface simples para iniciantes](#automatized-setup) ou [manualmente](#manual-setup) usando um terminal com opções avançadas.
-
-Quando o nó estiver em execução e sincronização, você estará pronto para [usá-lo](#using-the-node), mas fique de olho em sua [manutenção](#operating-the-node).
-
-
-
-### Ambiente e hardware {#environment-and-hardware}
-
-#### Local ou nuvem {#local-vs-cloud}
-
-Os clientes Ethereum são capazes de executar em computadores de grau de consumo e não exigem nenhum hardware especial, como máquinas de mineração, por exemplo. Portanto, você tem várias opções para implantar o nó de acordo com suas necessidades. Para simplificar, vamos analisar como executar um nó em uma máquina física local e um servidor na nuvem:
-
-- Nuvem
- - Os provedores oferecem alto tempo de atividade do servidor e endereços IP públicos estáticos
- - Obter um servidor dedicado ou virtual pode ser mais cômodo que desenvolver o seu próprio
- - A desvantagem está em ter que confiar em um terceiro: o servidor
- - Por causa do tamanho do armazenamento necessário para o nó completo, o preço de um servidor alugado pode ficar alto
-- Hardware próprio
- - Um método mais confiável e soberano
- - Investimento único
- - Existe a opção para comprar máquinas pré-configuradas
- - Você tem que fisicamente preparar, manter e solucionar os problemas potenciais que surgirem
-
-Ambas as opções têm vantagens e desvantagens, as quais foram resumidas acima. Caso estiver procurando uma solução para a nuvem, além de muitos provedores tradicionais de computação na nuvem, também existem serviços focados em executar nós. Confira [nós como serviço](/developers/docs/nodes-and-clients/nodes-as-a-service/) para obter mais opções de nós hospedados.
-
-#### Hardware {#hardware}
-
-No entanto, uma rede descentralizada que resiste à censura não deve depender de provedores na nuvem. Em vez disso, executar seu nó em seu próprio hardware local é mais saudável para o ecossistema. As [estimativas](https://www.ethernodes.org/networkType/Hosting) mostram uma grande parte dos nós executados na nuvem, o que pode se tornar um único ponto de falha.
-
-Os clientes Ethereum podem ser executados no seu computador, laptop, servidor ou até mesmo em um computador de placa única. Enquanto for possível executar clientes em seu computador pessoal, ter um computador dedicado apenas para seu nó poderá melhorar significativamente seu desempenho e segurança, ao mesmo tempo que minimiza o impacto em seu computador principal.
-
-O uso de seu próprio hardware pode ser muito fácil. Existem muitas opções simples, bem como configurações avançadas para pessoas mais técnicas. Então, vamos analisar os requisitos e meios para executar clientes Ethereum em seu computador.
-
-#### Requisitos {#requirements}
-
-Os requisitos de hardware diferem conforme o cliente, mas geralmente não são tão altos, já que o nó só precisa ser sincronizado. Não confunda isso com mineração, que requer muito mais poder de computação. No entanto, os tempos de sincronização e desempenho melhoram com hardware mais potente.
-
-Antes de instalar qualquer cliente, verifique se o seu computador tem recursos suficientes para executá-lo. Você pode encontrar os requisitos mínimos e recomendados abaixo.
-
-O afunilamento do seu hardware é, geralmente, o espaço em disco. Sincronizar a blockchain Ethereum é muito intensivo em termos de entrada/saída e requer muito espaço. É melhor ter uma **unidade de estado sólido (SSD)** com centenas de GBs de espaço livre para economizar, mesmo após a sincronização.
-
-O tamanho do banco de dados e a velocidade da sincronização inicial dependem do cliente escolhido, sua configuração e [estratégia de sincronização](/developers/docs/nodes-and-clients/#sync-modes).
-
-Verifique também se sua conexão de Internet não está limitada devido a um [limite de largura de banda](https://wikipedia.org/wiki/Data_cap). É recomendado usar uma conexão ilimitada para que a sincronização inicial e os dados transmitidos à rede possam exceder seu limite.
-
-##### Sistema operacional
-
-Todos os clientes dão suporte aos principais sistemas operacionais: Linux, MacOS e Windows. Isso significa que você pode executar seu nó em computadores ou servidores regulares com o sistema operacional (SO) que melhor atenda às suas necessidades. Verifique se o seu sistema operacional está atualizado para evitar possíveis problemas e vulnerabilidades de segurança.
-
-##### Requisitos mínimos
-
-- CPU com mais de 2 núcleos
-- 8 GB de RAM
-- SSD de 2 TB
-- Mais de 10 MBit/s de largura de banda
-
-##### Especificações recomendadas
-
-- CPU rápida com mais de 4 núcleos
-- Mais de 16 GB de RAM
-- SSD rápido com mais de 2 TB
-- Mais de 25 MBit/s de largura de banda
-
-O modo de sincronização e o cliente que você escolher afetará os requisitos de espaço, mas estimamos o espaço em disco necessário para cada cliente abaixo.
-
-| Cliente | Tamanho do disco (sincronização rápida) | Tamanho do disco (arquivo completo) |
-| ---------- | --------------------------------------- | ----------------------------------- |
-| Besu | + de 800 GB | + de 12 TB |
-| Erigon | N/D | + de 2,5 TB |
-| Geth | + de 500 GB | + de 12 TB |
-| Nethermind | + de 500 GB | + 12 TB |
-| Reth | N/D | 2.2TB+ |
-
-- Nota: Erigon e Reth não oferecem sincronização instantânea, mas é possível fazer o Full Pruning (~2 Tb para Erigon, ~1,2 Tb para Reth)
-
-Para clientes de consenso, o requisito de espaço também depende da implementação do cliente e dos recursos habilitados (por exemplo, removedor de validador), mas geralmente contam com outros 200 GB necessários para dados do beacon. Com um grande número de validadores, a carga de largura de banda também aumenta. Você pode encontrar [detalhes sobre os requisitos do cliente de consenso nesta análise](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc).
-
-#### Soluções "Plug-and-play" {#plug-and-play}
-
-A opção mais fácil para executar um nó com seu próprio hardware é usando ferramentas plug-and-play. Máquinas pré-configuradas de fornecedores oferecem a experiência mais direta: pedir, conectar, executar. Tudo é pré-configurado e roda automaticamente com um guia intuitivo e painel de controle para monitorar e controlar o software.
-
-- [DappNode](https://dappnode.io/)
-- [Avado](https://ava.do/)
-
-#### Ethereum em um computador de placa única {#ethereum-on-a-single-board-computer}
-
-Uma maneira fácil e barata de executar um nó Ethereum é usar um computador de placa única, mesmo com uma arquitetura ARM como o Raspberry Pi. O [Ethereum no ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) fornece imagens fáceis de executar de múltipla execução e cliente de consenso para Raspberry Pi e outras placas ARM.
-
-Dispositivos pequenos, acessíveis e eficientes como esses são ideais para executar um nó em casa, porém, lembre-se de seu desempenho limitado.
-
-## Executando seu nó {#spinning-up-node}
-
-A configuração real do cliente pode ser feita com programas automatizados ou manualmente, configurando o software do cliente diretamente.
-
-Para usuários menos avançados, a abordagem recomendada é usar um programa, ou seja, um software que orienta você durante a instalação e automatiza o processo de configuração do cliente. No entanto, se você tiver alguma experiência em usar um terminal, as etapas da configuração manual deverão ser simples de seguir.
-
-### Guia de configuração {#automatized-setup}
-
-Vários projetos de fácil utilização visam melhorar a experiência de configuração de um cliente. Esses programas fornecem instalação e configuração automáticas de cliente, com alguns até oferecendo uma interface gráfica para configuração guiada e monitoramento de clientes.
-
-Abaixo estão alguns projetos que podem ajudar você a instalar e controlar clientes com apenas alguns cliques:
-
-- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) — O DappNode não vem apenas com o computador de um fornecedor. O software, o verdadeiro inicializador de nós e o centro de controle com muitos recursos podem ser usados em hardwares aleatórios.
-- [eth-docker](https://eth-docker.net/) — Configuração automatizada usando o Docker, focada em participação (staking) fácil e segura. Requer conhecimento básico de terminal e Docker, sendo recomendada para usuários um pouco mais avançados.
-- [Stereum](https://stereum.net/ethereum-node-setup/) — Inicializador para instalar clientes em um servidor remoto via conexão SSH com um guia de configuração GUI, centro de controle e muitos outros recursos.
-- [NiceNode](https://www.nicenode.xyz/) — Programa com uma experiência de usuário simples para executar um nó em seu computador. Basta escolher os clientes e iniciá-los em alguns cliques. Ainda em desenvolvimento.
-- [Sedge](https://docs.sedge.nethermind.io/docs/intro) — Ferramenta de configuração de nós que gera automaticamente uma configuração do Docker usando o assistente da CLI. Escrito em Go pela Nethermind.
-
-### Configuração manual do cliente {#manual-setup}
-
-A outra opção é baixar, verificar e configurar o software cliente manualmente. Mesmo que alguns clientes ofereçam uma interface gráfica, uma configuração manual ainda requer habilidades básicas com o terminal, mas oferece muito mais versatilidade.
-
-Conforme explicado anteriormente, configurar seu próprio nó Ethereum exigirá executar um par de clientes de consenso e execução. Alguns clientes podem incluir um cliente leve de outro tipo e sincronizar sem a necessidade de qualquer outro software. No entanto, a verificação sem confiança completa requer as duas implementações.
-
-#### Obtendo o software do cliente {#getting-the-client}
-
-Primeiro, você precisa obter o software do [cliente de execução](/developers/docs/nodes-and-clients/#execution-clients) e do [cliente de consenso](/developers/docs/nodes-and-clients/#consensus-clients) de sua preferência.
-
-Você pode simplesmente baixar um aplicativo executável ou um pacote de instalação que se adapte ao seu sistema operacional e à sua arquitetura. Sempre verifique as assinaturas e as somas de verificação dos pacotes baixados. Alguns clientes também oferecem repositórios ou imagens do Docker para instalação e atualizações mais fáceis. Todos os clientes são de código aberto, portanto, você também pode construí-los a partir do código-fonte. Esse método é mais avançado, mas, em alguns casos, pode ser necessário.
-
-As instruções para instalar cada cliente são fornecidas na documentação associada às listas de clientes acima.
-
-Aqui estão as páginas de lançamento dos clientes, nas quais você pode encontrar seus binários pré-compilados ou instruções sobre instalação:
-
-##### Clientes de execução
-
-- [Besu](https://github.com/hyperledger/besu/releases)
-- [Erigon](https://github.com/ledgerwatch/erigon/releases)
-- [Geth](https://geth.ethereum.org/downloads/)
-- [Nethermind](https://downloads.nethermind.io/)
-- [Reth](https://reth.rs/installation/installation.html)
-
-Também é relevante observar que a diversidade de clientes é um [problema na camada de execução](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Recomenda-se que os leitores considerem a execução de um cliente de execução minoritário.
-
-##### Clientes de consenso
-
-- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest)
-- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (não fornece um binário pré-compilado, apenas uma imagem do Docker ou para ser compilado a partir da fonte)
-- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest)
-- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest)
-- [Teku](https://github.com/ConsenSys/teku/releases)
-
-A [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity/) é fundamental para nós de consenso executando validadores. Se a maioria dos validadores estiver executando uma única implementação do cliente, a segurança da rede estará em risco. Portanto, é recomendável considerar a escolha de um cliente minoritário.
-
-[Veja o uso mais recente do cliente de rede](https://clientdiversity.org/) e saiba mais sobre a [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity).
-
-##### Verificando o software
-
-Ao baixar o software da Internet, é recomendável verificar sua integridade. Essa etapa é opcional, mas, especialmente com uma parte de infraestrutura crucial como o cliente Ethereum, é importante estar ciente dos possíveis vetores de ataque e evitá-los. Se você baixou um binário pré-compilado, você precisa confiar nele e correr o risco de um invasor substituir o executável por um malicioso.
-
-Os desenvolvedores assinam binários lançados com suas chaves PGP para que você possa verificar criptograficamente se está executando exatamente o software que eles criaram. Você só precisa obter as chaves públicas usadas pelos desenvolvedores, que podem ser encontradas nas páginas de lançamento do cliente ou na documentação. Após baixar a versão do cliente e sua assinatura, você pode usar uma implementação PGP, por exemplo, [GnuPG](https://gnupg.org/download/index.html) para verificá-los facilmente. Confira um tutorial sobre como verificar software de código aberto usando `GPG` no [Linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) ou [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/).
-
-Outra forma de verificação é garantir que o hash, uma impressão digital criptográfica exclusiva do software que você baixou, corresponde ao fornecido pelos desenvolvedores. Isso é ainda mais fácil do que usar o PGP, e alguns clientes oferecem apenas essa opção. Basta executar a função de hash no software baixado e compará-lo com o da página de lançamento. Por exemplo:
-
-```sh
-sha256sum teku-22.6.1.tar.gz
-
-9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde
-```
-
-#### Configuração do cliente {#client-setup}
-
-Depois de instalar, baixar ou compilar o software cliente, você estará pronto para executá-lo. Isso só significa que ele tem de ser executado com a configuração adequada. Os clientes oferecem opções de configuração variadas, que podem habilitar vários recursos.
-
-Vamos começar com opções que podem influenciar significativamente o desempenho do cliente e o uso de dados. Os [modos de sincronização](/developers/docs/nodes-and-clients/#sync-modes) representam diferentes métodos de download e validação de dados da blockchain. Antes de iniciar o nó, você deve decidir que rede e modo de sincronização deve ser usado. As coisas mais importantes a considerar são o espaço em disco e o tempo de sincronização de que o cliente precisará. Preste atenção nos documentos do cliente para determinar qual modo de sincronização é o padrão. Se não for adequado para você, escolha outro com base no nível de segurança, nos dados disponíveis e no custo. Além do algoritmo de sincronização, você também pode definir a remoção de diferentes tipos de dados antigos. A limpeza habilita a exclusão de dados desatualizados, por exemplo, a remoção de nós de árvore de estado inacessíveis em blocos recentes.
-
-Outras opções básicas de configuração são, por exemplo, escolher uma rede, Mainnet (Rede principal) ou redes de teste, habilitando o ponto de extremidade HTTP para RPC ou WebSockets, etc. Você pode encontrar todos os recursos e opções na documentação do cliente. Várias configurações de cliente podem ser definidas executando o cliente com os marcadores correspondentes diretamente na CLI ou no arquivo de configuração. Cada cliente é um pouco diferente, por isso, sempre consulte a documentação oficial ou a página de ajuda do cliente para obter detalhes sobre as opções de configuração.
-
-Para fins de teste, você pode preferir executar um cliente em uma das redes de testes. [Veja a visão geral das redes suportadas](/developers/docs/nodes-and-clients/#execution-clients).
-
-Exemplos de execução de clientes de execução com configuração básica podem ser encontrados na próxima seção.
-
-#### Iniciando a execução do cliente {#starting-the-execution-client}
-
-Antes de iniciar o software cliente do Ethereum, faça uma última verificação para ter certeza de que seu ambiente está pronto. Por exemplo, verifique se:
-
-- Há espaço em disco suficiente, considerando a rede escolhida e o modo de sincronização.
-- A memória e a CPU não são interrompidas por outros programas.
-- O sistema operacional é atualizado para a versão mais recente.
-- O sistema tem a hora e a data corretas.
-- Seu roteador e seu firewall aceitam conexões nas portas de escuta. Por padrão, os clientes do Ethereum usam uma porta de escuta (TCP) e uma porta de descoberta (UDP), ambas na porta 30303 por padrão.
-
-Execute seu cliente primeiro em uma rede de testes para garantir que tudo esteja funcionando corretamente.
-
-Ao iniciar, você precisa declarar alguma configuração de cliente que não seja a padrão. Você pode usar sinalizadores ou o arquivo de configuração para declarar sua configuração preferida. O conjunto de recursos e a sintaxe de configuração de cada cliente diferem. Confira a documentação do seu cliente para ver as especificações.
-
-Os clientes de execução e consenso se comunicam por meio de um terminal autenticado especificado na [API Engine](https://github.com/ethereum/execution-apis/tree/main/src/engine). Para se conectar a um cliente de consenso, o cliente de execução deve gerar um [`jwtsecret`](https://jwt.io/) em um caminho conhecido. Por razões de segurança e estabilidade, os clientes devem ser executados no mesmo computador e ambos os clientes devem conhecer esse caminho, pois ele é usado para autenticar uma conexão RPC local entre eles. O cliente de execução também deve definir uma porta de escuta para APIs autenticadas.
-
-Esse token é gerado automaticamente pelo software cliente, mas, em alguns casos, talvez você precise fazer isso sozinho. Você pode gerá-lo usando o [OpenSSL](https://www.openssl.org/):
-
-```sh
-openssl rand -hex 32 > jwtsecret
-```
-
-#### Iniciando a execução do cliente {#running-an-execution-client}
-
-Esta seção guiará você na inicialização dos clientes de execução. Ela serve apenas como exemplo de configuração básica, que iniciará o cliente com estas configurações:
-
-- Especifica a rede para conectar. A rede principal, em nossos exemplos
- - Em vez disso, você pode escolher [uma das redes de teste](/developers/docs/networks/) para fazer um teste preliminar da sua configuração
-- Define o diretório de dados, no qual todos os dados, incluindo a blockchain, serão armazenados
- - Certifique-se de substituir o caminho por um real, por exemplo, apontando para sua unidade externa
-- Habilita interfaces para comunicação com o cliente
- - Incluindo JSON-RPC e Engine API para comunicação com o cliente de consenso
-- Define o caminho até `jwtsecret` para a API autenticada
- - Certifique-se de substituir o caminho de exemplo por um real que possa ser acessado pelos clientes, por exemplo, `/tmp/jwtsecret`
-
-Lembre-se de que este é apenas um exemplo básico, todas as outras configurações serão definidas como padrão. Preste atenção na documentação de cada cliente para saber mais sobre valores padrão, configurações e recursos. Para mais recursos, por exemplo, para executar validadores, monitoramento, etc., consulte a documentação específica do cliente.
-
-> Observe que as barras invertidas `\` nos exemplos são apenas para fins de formatação; marcadores de configuração podem ser definidos em uma única linha.
-
-##### Executando o Besu
-
-Este exemplo inicia o Besu na rede principal, armazena dados da blockchain no formato padrão em `/data/ethereum` e habilita o RPC JSON e o RPC Engine para conectar o cliente de consenso. A API Engine é autenticada com o token `jwtsecret` e somente chamadas de `localhost` são permitidas.
-
-```sh
-besu --network=mainnet \
- --data-path=/data/ethereum \
- --rpc-http-enabled=true \
- --engine-rpc-enabled=true \
- --engine-host-allowlist="*" \
- --engine-jwt-enabled=true \
- --engine-jwt-secret=/path/to/jwtsecret
-```
-
-O Besu também vem com uma opção de inicializador, que fará uma série de perguntas e gerará o arquivo de configuração. Execute o inicializador interativo usando:
-
-```sh
-besu --Xlauncher
-```
-
-A [documentação do Besu](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) contém opções adicionais e detalhes de configuração.
-
-##### Executando o Erigon
-
-Este exemplo inicia o Erigon na rede principal, armazena dados da blockchain em `/data/ethereum`, habilita o RPC JSON, define quais namespaces são permitidos e habilita a autenticação para conectar o cliente de consenso, definido pelo caminho `jwtsecret`.
-
-```sh
-erigon --chain mainnet \
- --datadir /data/ethereum \
- --http --http.api=engine,eth,web3,net \
- --authrpc.jwtsecret=/path/to/jwtsecret
-```
-
-O Erigon, por padrão, executa uma sincronização completa com um HDD de 8 GB, que resultará em mais de 2 TB de dados de arquivo. Verifique se o `datadir` está apontando para o disco com espaço livre suficiente ou olha para o sinalizador `--prune`, que pode ajustar diferentes tipos de dados. Verifique o `--help` do Erigon para saber mais.
-
-##### Executando o Geth
-
-Este exemplo inicia o Geth na rede principal, armazena os dados da blockchain em `/data/ethereum`, habilita o RPC JSON e define quais namespaces são permitidos. Ele também habilita a autenticação para conectar o cliente de consenso, que requer o caminho para `jwtsecret` e também a opção que define quais conexões são permitidas, em nosso exemplo apenas no `localhost`.
-
-```sh
-geth --mainnet \
- --datadir "/data/ethereum" \
- --http --authrpc.addr localhost \
- --authrpc.vhosts="localhost" \
- --authrpc.port 8551
- --authrpc.jwtsecret=/path/to/jwtsecret
-```
-
-Confira a [documentação para todas as opções de configuração](https://geth.ethereum.org/docs/fundamentals/command-line-options) e saiba mais sobre [como executar Geth com um cliente de consenso](https://geth.ethereum.org/docs/getting-started/consensus-clients).
-
-##### Executando o Nethermind
-
-O Nethermind oferece várias [opções de instalação](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started). O pacote vem com vários binários, incluindo um Inicializador com configuração guiada, que ajudará você a criar a configuração interativamente. Como alternativa, você encontrará o Executor, que é o executável em si, que simplesmente pode ser executado com os sinalizadores de configuração. O RPC-JSON é habilitado por padrão.
-
-```sh
-Nethermind.Runner --config mainnet \
- --datadir /data/ethereum \
- --JsonRpc.JwtSecretFile=/path/to/jwtsecret
-```
-
-Os documentos do Nethermind oferecem um [guia completo](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) sobre como executar o Nethermind com o cliente de consenso.
-
-Um cliente de execução iniciará suas funções principais, pontos de extremidade escolhidos e começará a procurar por pares. Após conseguir descobrir os pares, o cliente inicia a sincronização. O cliente de execução aguardará uma conexão do cliente de consenso. Os dados atuais da cadeia de blocos estarão disponíveis assim que o cliente for sincronizado com sucesso com o estado atual.
-
-##### Executando o Reth
-
-Este exemplo inicia o Reth na rede principal, usando o local de dados padrão. Habilita a autenticação JSON-RPC e Engine RPC para conectar o cliente de consenso definido pelo caminho `jwtsecret`, permitindo chamadas somente de `localhost`.
-
-```sh
-reth node \
- --authrpc.jwtsecret /path/to/jwtsecret \
- --authrpc.addr 127.0.0.1 \
- --authrpc.port 8551
-```
-
-Consulte [Configuração do Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) para saber mais sobre os diretórios de dados padrão. A [documentação do Reth](https://reth.rs/run/mainnet.html) contém opções adicionais e detalhes de configuração.
-
-#### Iniciando um cliente de consenso {#starting-the-consensus-client}
-
-O cliente de consenso deve ser iniciado com a configuração de porta correta para estabelecer uma conexão RPC local com o cliente de execução. Os clientes de consenso têm de ser executados com a porta do cliente de execução exposta como argumento de configuração.
-
-O cliente de consenso também precisa do caminho para o `jwt-secret` do cliente de execução para autenticar a conexão RPC entre eles. Semelhante aos exemplos de execução acima, cada cliente de consenso tem um parâmetro de configuração que usa o caminho do arquivo do token jwt como argumento. Isso deve ser consistente com o caminho `jwtsecret` fornecido ao cliente de execução.
-
-Se você planeja executar um validador, certifique-se de adicionar um marcador de configuração especificando o endereço Ethereum do destinatário da taxa. É aí que as recompensas do ether para o validador se acumulam. Cada cliente de consenso tem uma opção, por exemplo, `--suggested-fee-recipient=0xabcd1`, que recebe um endereço Ethereum como argumento.
-
-Ao iniciar um Beacon Node em uma rede de testes, você pode economizar um tempo de sincronização significativo usando um ponto de extremidade público para [sincronização de ponto de verificação](https://notes.ethereum.org/@launchpad/checkpoint-sync).
-
-#### Executando um cliente de consenso {#running-a-consensus-client}
-
-##### Executando o Lighthouse
-
-Antes de executar o Lighthouse, saiba mais sobre como instalá-lo e configurá-lo na [Documentação do Lighthouse](https://lighthouse-book.sigmaprime.io/installation.html).
-
-```sh
-lighthouse beacon_node \
- --network mainnet \
- --datadir /data/ethereum \
- --http \
- --execution-endpoint http://127.0.0.1:8551 \
- --execution-jwt /path/to/jwtsecret
-```
-
-##### Executando o Lodestar
-
-Instale o software Lodestar compilando-o ou baixando a imagem do Docker. Saiba mais na [documentação](https://chainsafe.github.io/lodestar/) e no [guia de configuração](https://hackmd.io/@philknows/rk5cDvKmK) mais abrangente.
-
-```sh
-lodestar beacon \
- --rootDir="/data/ethereum" \
- --network=mainnet \
- --eth1.enabled=true \
- --execution.urls="http://127.0.1:8551" \
- --jwt-secret="/path/to/jwtsecret"
-```
-
-##### Executando o Nimbus
-
-O Nimbus vem com ambos os clientes de consenso e de execução. Ele pode ser executado em vários dispositivos, até mesmo com um poder de computação bem modesto. Após [instalar as dependências e o próprio Nimbus](https://nimbus.guide/quick-start.html), você pode executar seu cliente de consenso:
-
-```sh
-nimbus_beacon_node \
- --network=mainnet \
- --web3-url=http://127.0.0.1:8551 \
- --rest \
- --jwt-secret="/path/to/jwtsecret"
-```
-
-##### Executando o Prysm
-
-O Prysm vem com um script que permite uma instalação automática fácil. Os detalhes podem ser encontrados na [documentação do Prysm](https://docs.prylabs.network/docs/install/install-with-script).
-
-```sh
-./prysm.sh beacon-chain \
- --mainnet \
- --datadir /data/ethereum \
- --execution-endpoint=http://localhost:8551 \
- --jwt-secret=/path/to/jwtsecret
-```
-
-##### Executando o Teku
-
-```sh
-teku --network mainnet \
- --data-path "/data/ethereum" \
- --ee-endpoint http://localhost:8551 \
- --ee-jwt-secret-file "/path/to/jwtsecret"
-```
-
-Quando um cliente de consenso se conecta ao cliente de execução para ler o contrato de depósito e identificar validadores, ele também se conecta a outros pares do Beacon Node e começa a sincronizar os slots de consenso da origem. Quando o Beacon Node atinge a época atual, a API Beacon se torna utilizável para seus validadores. Saiba mais sobre [APIs do Beacon Node](https://eth2docs.vercel.app/).
-
-### Adicionando validadores {#adding-validators}
-
-Um cliente de consenso serve como um Beacon Node para os validadores se conectarem. Cada cliente de consenso tem seu próprio software de validador descrito em detalhes em sua respectiva documentação.
-
-Executar seu próprio validador permite a [participação individual](/staking/solo/), o método mais impactante e não confiável para dar suporte à rede Ethereum. No entanto, isso requer um depósito de 32 ETH. Para executar um validador em seu próprio nó com uma quantidade menor, um pool descentralizado com operadores de nós sem permissão, como [Rocket Pool](https://rocketpool.net/node-operators), poderá ser interessante.
-
-A maneira mais fácil de começar a usar a geração de chaves de validação e staking é usar o [Holesky Testnet Staking Launchpad](https://holesky.launchpad.ethereum.org/), que permite testar sua configuração ao [executar nós no Holesky](https://notes.ethereum.org/@launchpad/holesky). Quando você estiver pronto para a Mainnet (Rede principal), você poderá repetir essas etapas usando a [Plataforma de lançamento de participação da Mainnet](https://launchpad.ethereum.org/).
-
-Consulte a [página de staking (participação)](/staking) para obter uma visão geral sobre as opções de participação.
-
-### Usando o nó {#using-the-node}
-
-Os clientes de execução oferecem [pontos de extremidade da API RPC](/developers/docs/apis/json-rpc/) que você pode usar para enviar transações, interagir ou implantar contratos inteligentes na rede Ethereum de várias maneiras:
-
-- Chamando-os manualmente com um protocolo adequado (por exemplo, usando `curl`)
-- Anexando um console (por exemplo, `geth attach`)
-- Implementá-los em aplicações usando bibliotecas da Web3, por exemplo, [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/)
-
-Diferentes clientes têm diferentes implementações dos pontos de extremidade RPC. Porém, existe um JSON-RPC padrão que você pode usar com cada cliente. Para obter uma visão geral, [leia a documentação sobre JSON-RPC](/developers/docs/apis/json-rpc/). Os aplicativos que precisam de informações da rede Ethereum podem usar esse RPC. Por exemplo, a popular carteira MetaMask permite que você [se conecte ao seu próprio ponto de extremidade RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), que conta com grandes benefícios de privacidade e segurança.
-
-Todos os clientes de consenso expõem uma [API Beacon](https://ethereum.github.io/beacon-APIs), que pode ser usada para verificar o status do cliente de consenso ou baixar blocos e dados de consenso enviando solicitações usando ferramentas como [Curl](https://curl.se). Mais informações sobre isso podem ser encontradas na documentação de cada cliente de consenso.
-
-#### Comunicação com o RPC {#reaching-rpc}
-
-A porta padrão para o cliente de execução JSON-RPC é `8545`, mas você pode modificar as portas dos pontos de extremidade locais na configuração. Por padrão, a interface RPC só pode ser acessada no host local do seu computador. Para torná-lo acessível remotamente, você pode expô-lo ao público alterando o endereço para `0.0.0.0`. Isso o tornará acessível pela rede local e endereços IP públicos. Na maioria dos casos, você também precisará configurar o encaminhamento de porta no seu roteador.
-
-Tenha cuidado ao expor as portas à Internet, pois isso permitirá que qualquer pessoa na Internet controle seu nó. Atores maliciosos poderão acessar seu nó para derrubar seu sistema ou roubar seus fundos se você estiver usando seu cliente como uma carteira.
-
-Uma forma de contornar isso é evitar que métodos RPC potencialmente nocivos sejam modificáveis. Por exemplo, com o Geth, você pode declarar métodos modificáveis com um sinalizador: `--http.api web3,eth,txpool`.
-
-O acesso à interface RPC pode ser estendido por meio do desenvolvimento de APIs da camada de borda ou aplicativos de servidor Web, como o Nginx, e conectando-os ao endereço e porta locais do seu cliente. A utilização de uma camada intermediária também pode permitir que os desenvolvedores configurem um certificado para conexões `https` seguras na interface RPC.
-
-Configurar um servidor Web, um proxy ou uma API Rest externa não é a única maneira de fornecer acesso ao ponto de extremidade RPC do seu nó. Outra maneira de preservar a privacidade para configurar um ponto de extremidade publicamente acessível é hospedar o nó em seu próprio serviço onion da rede [Tor](https://www.torproject.org/). Isso permitirá que você se comunique com o RPC fora da sua rede local sem um endereço público estático de IP ou portas abertas. No entanto, usar essa configuração só permitirá que o ponto de extremidade RPC seja acessível pela da rede Tor, que não é suportada por todos os aplicativos e poderá resultar em problemas de conexão.
-
-Para fazer isso, você precisa criar seu próprio [serviço onion](https://community.torproject.org/onion-services/). Confira [a documentação](https://community.torproject.org/onion-services/setup/) sobre a configuração do serviço onion para hospedar o seu próprio serviço. Você pode direcioná-lo para um servidor Web com proxy para a porta RPC ou apenas diretamente para o RPC.
-
-Por fim, e uma das formas mais populares de fornecer acesso a redes internas, é por meio de uma conexão VPN. Dependendo do seu caso de uso e da quantidade de usuários que precisam de acesso ao seu nó, uma conexão VPN segura pode ser uma opção. [OpenVPN](https://openvpn.net/) é uma VPN SSL completa que implementa a extensão de rede segura da camada OSI 2 ou 3 usando o protocolo SSL/TLS padrão da indústria, dá suporte a métodos flexíveis de autenticação de cliente com base em certificados, cartões inteligentes e/ou credenciais de usuário/senha e permite políticas de controle de acesso específicas de usuário ou grupo usando regras de firewall aplicadas à interface virtual VPN.
-
-### Operando o nó {#operating-the-node}
-
-Você deve monitorar regularmente seu nó para garantir que ele esteja funcionando corretamente. Talvez seja necessário realizar manutenções ocasionais.
-
-#### Mantendo o nó online {#keeping-node-online}
-
-Seu nó não precisa estar online o tempo todo, mas você deve mantê-lo online o máximo possível para mantê-lo sincronizado com a rede. Você pode desligá-lo para reiniciá-lo, mas lembre-se de que:
-
-- O encerramento pode levar alguns minutos se o estado recente ainda estiver sendo gravado no disco.
-- Encerramentos forçados podem danificar o banco de dados, exigindo que você ressincronize todo o nó.
-- Seu cliente ficará dessincronizado com a rede e precisará ser ressincronizado quando você o reiniciar. Embora o nó possa começar a sincronizar a partir do ponto do último encerramento, o processo pode demorar dependendo de quanto tempo ele esteve offline.
-
-_Isso não se aplica a nós validadores da camada de consenso._ Colocar seu nó offline afetará todos os serviços dependentes dele. Se você estiver rodando um nó para fins de _staking (participação)_, você deve tentar minimizar o tempo de inatividade tanto quanto possível.
-
-#### Criando serviços de clientes {#creating-client-services}
-
-Considere criar um serviço para executar seus clientes automaticamente na inicialização. Por exemplo, em servidores Linux, a boa prática seria criar um serviço, por exemplo, com `systemd`, que executa o cliente com a configuração adequada em um usuário com privilégios limitados, e reiniciar automaticamente.
-
-#### Atualizando clientes {#updating-clients}
-
-Você precisa manter seu software cliente atualizado com os patches de segurança, recursos e [EIPs](/eips/) mais recentes. Sobretudo antes das [bifurcações permanentes](/history/), verifique se você está executando as versões corretas do cliente.
-
-> Antes de atualizações importantes da rede, a EF publica uma postagem em seu [blog](https://blog.ethereum.org). Você pode [fazer a inscrição nesses anúncios](https://blog.ethereum.org/category/protocol#subscribe) para receber uma notificação no seu e-mail quando o seu nó precisar de uma atualização.
-
-Atualizar clientes é muito simples. Cada cliente tem instruções específicas em sua documentação, mas o processo geralmente é apenas baixar a versão mais recente e reiniciar o cliente com o novo executável. O cliente deve continuar de onde parou, mas com as atualizações aplicadas.
-
-Cada implementação de cliente tem uma cadeia de caracteres de versão legível por humanos usada no protocolo ponto a ponto, mas também é acessível a partir da linha de comando. Essa cadeia de caracteres de versão permite que os usuários verifiquem se estão executando a versão correta e possibilita exploradores de blocos e outras ferramentas analíticas interessadas em quantificar a distribuição de clientes específicos na rede. Consulte a documentação de cada cliente para obter mais informações sobre cadeias de caracteres de versão.
-
-#### Executando serviços adicionais {#running-additional-services}
-
-Executar seu próprio nó permite que você use serviços que exigem acesso direto ao cliente RPC do Ethereum. Estes são serviços construídos em cima do Ethereum, como [soluções de camada 2](/developers/docs/scaling/#layer-2-scaling), back-end para carteiras, exploradores de blocos, ferramentas de desenvolvimento e outras infraestruturas do Ethereum.
-
-#### Monitorando o nó {#monitoring-the-node}
-
-Para monitorar seu nó corretamente, considere coletar métricas. Os clientes fornecem pontos de extremidade de métricas para que você possa obter dados abrangentes sobre seu nó. Use ferramentas como [InfluxDB](https://www.influxdata.com/get-influxdb/) ou [Prometheus](https://prometheus.io/) para criar bancos de dados que você pode transformar em visualizações e gráficos em softwares como o [Grafana](https://grafana.com/). Existem muitas configurações para usar esse software e diferentes painéis do Grafana para você visualizar seu nó e a rede como um todo. Por exemplo, confira o [tutorial sobre como monitorar o Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/).
-
-Como parte do seu monitoramento, fique de olho no desempenho do seu computador. Durante a sincronização inicial do seu nó, o software cliente pode sobrecarregar muito a CPU e a memória RAM. Para fazer isso, além do Grafana, você pode usar as ferramentas que seu sistema operacional oferece, como `htop` ou `uptime`.
-
-## Leitura adicional {#further-reading}
-
-- [Guias de participação do Ethereum](https://github.com/SomerEsat/ethereum-staking-guides) — _Somer Esat, atualizado regularmente_
-- [Guia | Como configurar um validador para participação do Ethereum na rede principal](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _— CoinCashew, atualizado regularmente_
-- [Guias do ETHStaker sobre como executar validadores em redes de teste](https://github.com/remyroy/ethstaker#guides) — _ETHStaker, atualizado regularmente_
-- [Perguntas frequentes sobre o The Merge para operadores de nós](https://notes.ethereum.org/@launchpad/node-faq-merge) — _julho de 2022_
-- [Analisando os requisitos de hardware para tornar um nó totalmente validado no Ethereum](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau, 24 de setembro de 2018_
-- [Executando nós completos do Ethereum: um guia para os pouco motivados](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _— Justin Leroux, 7 de novembro de 2019_
-- [Executando um nó do Hyperledger Besu na Mainnet (Rede principal) do Ethereum: benefícios, requisitos e configurações](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _— Felipe Faraggi, 7 de maio de 2020_
-- [Implantando o cliente Nethermind do Ethereum com uma pilha de monitoramento](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _— Nethermind.eth, 8 de julho de 2020_
-
-## Tópicos relacionados {#related-topics}
-
-- [ Nós e clientes](/developers/docs/nodes-and-clients/)
-- [Blocos](/developers/docs/blocks/)
-- [Redes](/developers/docs/networks/)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
deleted file mode 100644
index 58765e328f7..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Mecanismos de consenso
-description: Uma explicação dos protocolos de consenso em sistemas distribuídos e o papel que desempenham no Ethereum.
-lang: pt-br
----
-
-O termo "mecanismo de consenso" é frequentemente usado de forma coloquial para se referir a protocolos de "prova de participação", "prova de trabalho" ou "prova de autoridade". No entanto, esses são apenas componentes nos mecanismos de consenso que protegem contra [ataques Sybil](/glossary/#sybil-attack). Mecanismos de consenso são a pilha completa de ideias, protocolos e incentivos que permitem que um conjunto distribuído de nós concorde com o estado da cadeia de blocos.
-
-## Pré-requisitos {#prerequisites}
-
-Para melhor entender esta página, recomendamos que você leia primeiro a nossa [Introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-## O que é consenso? {#what-is-consensus}
-
-Por consenso, queremos dizer que se chegou a um acordo geral. Considere um grupo de pessoas indo ao cinema. Se não houver desacordo sobre uma proposta de escolha de filme, então um consenso é alcançado. Se houver desacordo, o grupo deve ter meios para decidir qual filme assistir. Em casos extremos, o grupo eventualmente se separará.
-
-Em relação à cadeia de blocos Ethereum, o processo é formalizado e chegar a um consenso significa que pelo menos 66% dos nós da rede concordam com o estado global da rede.
-
-## O que é um mecanismo de consenso? {#what-is-a-consensus-mechanism}
-
-O termo mecanismo de consenso refere-se a toda a pilha de protocolos, incentivos e ideias que permitem que uma rede de nós concorde com o estado de uma cadeia de blocos.
-
-O Ethereum utiliza um mecanismo de consenso baseado em provas de participação que deriva sua segurança criptoeconômica de um conjunto de recompensas e penalidades aplicadas ao capital bloqueado pelos participantes. Essa estrutura de incentivos encoraja os participantes individuais a operar validadores honestos, pune aqueles que não o fazem e cria um custo extremamente alto para atacar a rede.
-
-Em seguida, existe um protocolo que rege como validadores honestos são selecionados para propor ou validar blocos, processar transações e votar por sua visão do topo da cadeia. Nas raras situações em que vários blocos estão na mesma posição perto do topo da cadeia, existe um mecanismo de escolha da bifurcação que seleciona os blocos que compõem a cadeia "mais pesada", medido pelo número de validadores que votaram nos blocos ponderados pelo seu equilíbrio de ether colocado.
-
-Alguns conceitos são importantes para o consenso que não estão explicitamente definidos no código, como a segurança adicional oferecida pela potencial coordenação social fora de banda como última linha de defesa contra ataques na rede.
-
-Esses componentes juntos formam o mecanismo de consenso.
-
-## Tipos de mecanismos de consenso {#types-of-consensus-mechanisms}
-
-### Baseado em prova de trabalho {#proof-of-work}
-
-Como o Bitcoin, o Ethereum já usou um protocolo de consenso baseado em **prova de trabalho (PoW)**.
-
-#### Criação de blocos {#pow-block-creation}
-
-Os mineradores competem para criar novos blocos preenchidos com transações processadas. O ganhador compartilha o novo bloco com o restante da rede e ganha alguns ETH recentemente cunhados. A corrida é vencida pelo computador que é capaz de resolver um quebra-cabeça matemático mais rápido. Isso produz o link criptográfico entre o bloco atual e o bloco anterior. Resolver o quebra-cabeça é o trabalho na “prova de trabalho”. A cadeia padrão é então determinada por uma regra de escolha de bifurcação que seleciona o conjunto de blocos que tiveram mais trabalho para minerá-los.
-
-#### Segurança {#pow-security}
-
-A rede é mantida segura pelo fato de que você precisaria de 51% da capacidade dos computadores da rede para defraudar a cadeia. Isso exigiria investimentos tão grandes em equipamentos e energia que é bastante provável que você teria mais prejuízos do que lucros.
-
-Mais sobre [prova de trabalho](/developers/docs/consensus-mechanisms/pow/)
-
-### Baseado em prova de participação {#proof-of-stake}
-
-O Ethereum agora usa um protocolo de consenso baseado em **prova de participação (PoS)**.
-
-#### Criação de blocos {#pos-block-creation}
-
-Validadores criam blocos. Um validador é selecionado aleatoriamente em cada espaço para ser o proponente do bloco. Seu cliente de consenso solicita um pacote de transações como uma “carga de execução” de seu cliente de execução emparelhado. Eles envolvem isso em dados de consenso para formar um bloco, o qual eles enviam para outros nós na rede Ethereum. Essa produção de blocos é recompensada em ETH. Em casos raros, quando existem múltiplos blocos possíveis para um único espaço, ou os nós ouvem sobre blocos em tempos diferentes, o algoritmo da bifurcação escolhido seleciona o bloco que forma a cadeia com o maior peso de atestações (em que o peso é o número de validadores que atestam a escala pelo seu saldo ETH).
-
-#### Segurança {#pos-security}
-
-Um sistema de prova de participação é cripto-economicamente seguro porque um invasor que tentar assumir o controle da cadeia deverá destruir uma enorme quantidade de ETH. Um sistema de recompensas incentiva os participantes individuais a se comportarem honestamente, e as penalidades desincentivam os participantes de agirem modo malicioso.
-
-Mais sobre [prova de participação](/developers/docs/consensus-mechanisms/pos/)
-
-### Um guia visual {#types-of-consensus-video}
-
-Saiba mais sobre os diferentes tipos de mecanismos de consenso utilizados no Ethereum:
-
-
-
-### Resistência a ataques Sybil e seleção de cadeia {#sybil-chain}
-
-Prova de trabalho e prova de participação por si só não são protocolos de consenso, mas são frequentemente referidos como tal por simplicidade. Na verdade, são mecanismos de resistência a ataques Sybil e bloqueiam os seletores de autores; eles são uma maneira de decidir quem é o autor do bloco mais recente. Outro componente importante é o algoritmo de seleção de cadeia (também conhecido como escolha da bifurcação), o qual permite que os nós escolham um único bloco correto no início da cadeia em cenários em que existem vários blocos na mesma posição.
-
-**A resistência a ataques Sybil** mede como um protocolo se comporta frente um ataque Sybil. A resistência a esse tipo de ataque é essencial para uma cadeia de blocos descentralizada e permite que os mineradores e validadores sejam recompensados igualmente com base nos recursos colocados. A prova de trabalho e a prova de participação protegem contra isso fazendo os usuários gastarem muita energia ou colocarem muitas garantias. Essas proteções são um elemento econômico de dissuasão dos ataques Sybil.
-
-Uma **regra de seleção de cadeia** é usada para decidir qual é a cadeia "correta". O Bitcoin usa a regra da "cadeia mais longa", o que significa que qualquer cadeia de blocos mais longa será aquela que o resto dos nós aceitam como válida e com a qual trabalha. Para as cadeias de prova de trabalho, a cadeia mais longa é determinada pela dificuldade cumulativa total da prova de trabalho. O Ethereum costumava usar a regra da cadeia mais longa também; no entanto, agora que o Ethereum é executado em prova de participação, ele adotou um algoritmo atualizado de escolha da bifurcação que mede o "peso" da cadeia. O peso é a soma acumulada dos votos do validador, ponderada pelos saldos de ether envolvidos do validador.
-
-O Ethereum usa um mecanismo de consenso conhecido como [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) que combina a [prova de participação do Casper FFG](https://arxiv.org/abs/1710.09437) com a [regra de escolha de bifurcação GHOST](https://arxiv.org/abs/2003.03052).
-
-## Leitura adicional {#further-reading}
-
-- [O que é um algoritmo de consenso de blockchain?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
-- [O que é Consenso de Nakamoto? Guia completo do principiante](https://blockonomi.com/nakamoto-consensus/)
-- [Como o Casper funciona?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
-- [Sobre a segurança e o desempenho das blockchains de prova de trabalho](https://eprint.iacr.org/2016/555.pdf)
-- [Falha bizantina](https://en.wikipedia.org/wiki/Byzantine_fault)
-
-_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione-o!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Prova de trabalho](/developers/docs/consensus-mechanisms/pow/)
-- [Mineração](/developers/docs/consensus-mechanisms/pow/mining/)
-- [Prova de participação](/developers/docs/consensus-mechanisms/pos/)
-- [Prova de autoridade](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
deleted file mode 100644
index 2f15a442482..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
+++ /dev/null
@@ -1,163 +0,0 @@
----
-title: Ataque e defesa da prova de participação do Ethereum
-description: Aprenda sobre os vetores de ataque conhecidos na prova de participação do Ethereum e como eles são defendidos.
-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 são adaptadas de uma [versão mais longa do formulário](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs).
-
-## Pré-requisitos {#prerequisites}
-
-São necessários alguns conhecimentos básicos de [prova de participação](/developers/docs/consensus-mechanisms/pos/). Além disso, será útil ter conhecimentos básicos sobre a [camada de incentivo](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) do Ethereum e do algoritmo de escolha de bifurcação (fork), [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper).
-
-## O que os invasores querem? {#what-do-attackers-want}
-
-Um equívoco comum é achar que um invasor bem-sucedido pode gerar um novo ether ou drenar ethers de contas arbitrárias. Nenhum desses dois é possível, pois todas as transações são executadas por todos os clientes de execução na rede. Eles devem satisfazer condições básicas de validade (por exemplo, transações são assinadas pela chave privada do remetente, o remetente tem saldo suficiente, etc.) ou então eles simplesmente se revertem. Há três classes de resultado que um invasor pode visar realistamente: reorgs, dupla finalidade ou atraso de finalidade.
-
-Um **“reorg”** é uma reembaralhamento de blocos em uma nova ordem, talvez com alguma adição ou subtração de blocos na cadeia padrão. Uma reorganização maliciosa pode garantir que blocos específicos sejam incluídos ou excluídos, permitindo gastos duplos ou extração de valores ao executar transações front-running e back-running (MEV). As reorgs também podem ser usadas para evitar que certas transações sejam incluídas na cadeia padrão, o que é uma espécie de censura. A forma mais extrema de reorg é a “reversão da finalidade”, que remove ou substitui blocos que foram previamente finalizados. Isso só é possível se mais de 1/3 do ether total em stake for destruído pelo invasor — esta garantia é conhecida como “finalidade econômica” — falaremos mais sobre isso mais tarde.
-
-**A finalidade dupla** é a condição improvável, mas severa, na qual dois forks são capazes de finalizar simultaneamente, criando uma cisão permanente na cadeia. Isso é teoricamente possível para um invasor que esteja disposto a arriscar 34% do total do ether em stake. A comunidade seria forçada a coordenar fora da cadeira 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 chegue às condições necessárias para finalizar as seções da cadeia. Sem finalidade, é difícil confiar em aplicativos financeiros construídos em cima do Ethereum. O objetivo de um ataque de atraso de finalidade é basicamente perturbar o Ethereum, em vez de lucrar diretamente com ele, a menos que o invasor tenha alguma posição vendida estratégica.
-
-Um ataque à camada social poderia visar 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 adversários atacariam o Ethereum, as seções a seguir examinam _como_ eles o fariam.
-
-## Métodos de ataque {#methods-of-attack}
-
-### Ataques na Camada 0 {#layer-0}
-
-Em primeiro lugar, os indivíduos que não participam ativamente no Ethereum (executando o software cliente) podem atacar visando a camada social (Camada 0). A Camada 0 é a fundação sobre a qual o Ethereum é construído, e, como tal, representa uma superfície potencial sujeita a ataques com consequências que se propagam pelo resto da pilha. Alguns exemplos podem incluir:
-
-- Uma campanha de desinformação poderia prejudicar a confiança que a comunidade tem no roteiro, equipes de desenvolvedores, aplicativos do Ethereum, etc. Isso poderia então diminuir o número de indivíduos dispostos a participar protegendo a rede, degradando tanto a descentralização quanto a segurança criptoeconômica.
-- Ataques direcionados e/ou intimidação voltados para a comunidade de desenvolvedores. Isso pode levar à saída voluntária de desenvolvedores e desacelerar o progresso do Ethereum.
-
-- Regulamentação excessivamente zelosa também poderia ser considerada um ataque à Camada 0, uma vez que poderia desincentivar rapidamente a participação e a adoção.
-- Infiltração de atores experientes, mas maliciosos, na comunidade de desenvolvedores, cujo objetivo é atrasar o progresso dando importância demais a questões simples, atrasando decisões-chave, criando spam, etc.
-- Subornos a atores-chave do ecossistema Ethereum para influenciar a tomada de decisões.
-
-O que torna estes ataques particularmente perigosos é que, em muitos casos, é necessário muito pouco capital ou conhecimentos técnicos. Um ataque à Camada 0 poderia ser um multiplicador em um ataque criptoeconômico. Por exemplo, se a censura ou a reversão da finalidade fossem alcançadas por uma parte interessada majoritária maliciosa, minar a camada social poderá tornar mais difícil coordenar uma resposta comunitária fora da banda.
-
-Defender-se contra ataques à Camada 0 provavelmente não é uma tarefa simples, mas alguns princípios básicos podem ser estabelecidos. Uma delas é manter um sinal global alto de relação de ruído para informações públicas sobre o Ethereum, criado e propagado por membros honestos da comunidade por meio de blogs, servidores discord, especificações anotadas, livros, podcasts e Youtube. Aqui no ethereum.org, nos esforçamos para manter informações precisas e traduzi-las para o maior número de idiomas possível. Inundar um espaço com informações de alta qualidade e memes é uma defesa eficaz contra a desinformação.
-
-Outro reforço importante contra os ataques às camadas sociais é uma declaração clara de missão e um protocolo de governança. O Ethereum se posicionou como o campeão de descentralização e segurança entre a camada 1 de contrato inteligente, enquanto também tem um elevado valor de escalabilidade e sustentabilidade. Independentemente dos desacordos que surgem na comunidade Ethereum, esses princípios fundamentais são minimamente comprometidos. A avaliação de uma narrativa contra esses princípios fundamentais e a análise destes por meio de sucessivas revisões no processo de EIP (Proposta de Melhoria Ethereum), poderá ajudar a comunidade a distinguir os bons dos maus atores e limitar o campo de influência de atores maliciosos na direção futura do Ethereum.
-
-Por fim, é fundamental que a comunidade Ethereum permaneça aberta e receptiva a todos os participantes. Uma comunidade com guardiões e exclusividade é uma comunidade especialmente vulnerável a ataques sociais, pois é fácil construir narrativas que façam a segregação entre “nós e eles”. A criação de tribos e os exageros tóxicos prejudicam a comunidade e desgastam a segurança da camada 0. Os Ethereanos com um interesse manifesto na segurança da rede devem avaliar sua conduta online e presencial como contribuidores diretos para a segurança da Camada 0 do Ethereum.
-
-### Atacando o protocolo {#attacking-the-protocol}
-
-Qualquer um pode executar o software do cliente Ethereum. Para adicionar um validador a um cliente, um usuário precisa depositar 32 ethers em stake no contrato de depósito. Um validador permite que um usuário participe ativamente da segurança de rede Ethereum, propondo e atestando novos blocos. Os validadores agora têm voz ativa para influenciar o conteúdo futuro da blockchain. Eles podem fazer isso de forma honesta e, assim, aumentar seus ethers por meio de recompensas, ou podem tentar manipular o processo em benefício próprio, arriscando seu stake. Uma maneira de organizar um ataque é acumular uma maior proporção do stake total e, em seguida, usar isso para superar os votos dos validadores honestos. Quanto maior a proporção do stake controlado pelo atacante, maior será o seu poder de voto, especialmente em certos marcos econômicos que exploraremos mais tarde. No entanto, a maioria dos invasores não conseguirá acumular ethers suficientes para atacar dessa forma, portanto, eles têm de utilizar técnicas sutis para manipular a maioria honesta a agir de certa maneira.
-
-Essencialmente, todos os ataques com pouco stake são variações sutis de dois tipos de mau comportamento: subatividade (sem conseguir atestar/propor ou fazendo-o tardiamente) ou superatividade (propondo/atestando muitas vezes em um slot). Nas suas formas mais simples essas ações são facilmente manipuladas pelo algoritmo de escolha de fork e camada de incentivo, mas existem maneiras mais inteligentes de manipular o sistema em benefício de um invasor.
-
-### Ataques usando pequenas quantidades de ETH {#attacks-by-small-stakeholders}
-
-#### reorgs {#reorgs}
-
-Vários artigos descreveram ataques no Ethereum que obtêm reorgs ou atraso de finalidade com apenas uma pequena proporção do total de ethers em stake. Esses ataques geralmente dependem de que o atacante retenha algumas informações de outros validadores e, em seguida, divulgue-as 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 invasor pode criar e atestar um bloco (`B`) para um determinado slot `n+1` mas evita propagá-lo para outros nós da 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 invasor pode liberar seu bloco retido (`B`) e suas atestações retidos para isso, e também atestar `B` como a cabeça da cadeia com seus votos no slot `n+2`, efetivamente negando a existência de um bloco honesto `C`. Quando o bloco honesto `D` é lançado, o algoritmo de escolha de fork vê `D` construir em cima de `B` como mais pesado do que `D` construindo em `C`. O invasor consegue então remover o bloco honesto `C` no slot `n+2` da cadeia padrão usando uma reorganização anterior de 1 bloco. [Um invasor com 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) do stake tem uma grande chance de sucesso nesse ataque, conforme 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 um stake de 30%, que mais tarde revelou-se viável com [2% do stake total](https://arxiv.org/pdf/2009.04987.pdf) e depois novamente para um [único validador](https://arxiv.org/abs/2110.10086#) usando técnicas de balanceamento que iremos examinar na próxima seção.
-
-
-
-Um diagrama conceitual do ataque de reorganização 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 invasor 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. Em seguida, ao liberar seletivamente as atestações favorecendo um ou outro fork para apenas uma quantidade de validadores suficiente enquanto o algoritmo de escolha de fork está em execução, eles fazem pender o peso acumulado das atestações a favor de um ou outro fork. Isso pode continuar indefinidamente, com os validadores invasores 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.
-
-Os **ataques de salto** são semelhantes. Os votos são novamente retidos pelos validadores atacantes. Em vez de liberar os votos para manter uma divisão entre dois forks, eles usam seus votos em momentos oportunos para justificar pontos de verificação que alternam entre o fork A e o fork B. Esse vai e vem de justificações entre dois forks impede que existam pares de fontes justificadas e pontos de verificação que possam ser finalizados em qualquer cadeia, parando a finalidade.
-
-
-
-Tanto os ataques de salto, quanto os ataques de balanceamento, dependem de o atacante ter um controle muito preciso sobre o momento das mensagens por toda a rede, o que é improvável. No entanto, as defesas são construídas no protocolo sob a forma de ponderação adicional dada às mensagens rápidas quando comparadas com as lentas. Isso é conhecido como [aceleração de peso do proponente](https://github.com/ethereum/consensus-specs/pull/2730). Para se defender contra ataques de salto, o algoritmo escolhido para o fork foi atualizado de modo que o último ponto de verificação justificado somente possa mudar para uma cadeia alternativa durante o [primeiro 1/3 dos slots em cada época](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114). Essa condição impede que o invasor economize votos para implantar mais tarde — o algoritmo de escolha do fork simplesmente permanece fiel ao ponto de verificação escolhido no primeiro 1/3 da época, durante o qual os validadores mais honestos teriam votado.
-
-Combinadas, essas medidas criam um cenário em que um proponente de blocos 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), no qual esse novo bloco pode fazer com que o algoritmo de escolha de fork alterne para outra cadeia. Depois desse mesmo prazo, as atestações que chegam de validadores lentos têm peso reduzido em comparação com os que chegaram mais cedo. 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 salto ou balanceamento bem-sucedido.
-
-É importante observar que o proponente apenas defende contra “reorganizações baratas”, ou seja, tentativas feitas por um invasor com um stake pequeno. Na verdade, o próprio acelerador proponente pode ser induzido por partes interessadas maiores. Os autores [desta postagem](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) descrevem como um invasor com 7% de stake pode implantar seus votos estrategicamente para enganar validadores honestos para construir sobre seu fork, reorganizando um bloco honesto. Esse ataque foi concebido assumindo condições de latência ideais muito improváveis. As probabilidades são ainda muito grandes para o invasor, e o stake maior também significa mais capital em risco e um desincentivo econômico maior.
-
-Um [ataque de balanceamento especificamente direcionado à regra de LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) também foi proposto, o que foi sugerido para ser viável, apesar do aumento do proponente. Um invasor cria duas cadeias concorrentes equivocando sua proposta de bloco e propagando cada bloco para cerca de metade da rede cada, estabelecendo um equilíbrio aproximado entre os forks. Em seguida, os validadores em conluio confundem seus votos, calculando o tempo para que metade da rede receba seus votos no fork `A` primeiro, e a outra metade receba seus votos no fork `B` primeiro. Já que a regra de LMD descarta o segundo certificado e mantém apenas o primeiro para cada validador, metade da rede vê os votos para `A` e nenhum para `B`, sendo que a outra metade vê votos para `B` e nenhum para `A`. Os autores descrevem a regra de LMD como dando ao adversário “poder notável” para montar um ataque de balanceamento.
-
-Esse vetor de ataque LMD foi fechado [atualizando o algoritmo de escolha de fork](https://github.com/ethereum/consensus-specs/pull/2845) de modo que ele descarte os validadores equivocados da consideração da escolha do fork. Os validadores equivocados também têm sua futura influência descontada pelo algoritmo de escolha do fork. Isso evita o ataque de balanceamento descrito acima e mantém também resiliência contra ataques em avalanche.
-
-Outra categoria de ataque, chamada [**ataques em avalanche**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3), foi descrita em um [artigo de março de 2022](https://arxiv.org/pdf/2203.01315.pdf). Para montar um ataque em avalanche, o invasor precisa controlar vários proponentes de bloco consecutivos. Em cada um dos slots da proposta de bloco, o invasor retém seus blocos, coletando-os até que a cadeia honesta atinja um peso igual de sub-árvore com os blocos retidos. Depois, os blocos retidos são liberados para causarem o máximo de equívoco. Os autores sugerem que o proponente impulsionando — a defesa primária contra os ataques de balanceamento e salto — não protege contra algumas variantes de ataque em avalanche. No entanto, os autores também só demonstraram o ataque a uma versão altamente idealizada do algoritmo de escolha de fork do Ethereum (eles usaram GHOST sem LMD).
-
-O ataque em avalanche é mitigado pela porção de LMD do algoritmo de escolha do fork LMD-GHOST. LMD significa “latest-message-driven” (dirigido à última mensagem) e se refere 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 em particular. Na prática, isso significa que em cada slot, a primeira mensagem recebida é aquela que aceitou e todas as mensagens adicionais são equívocos a serem ignorados. Por outras palavras, os clientes de consenso não contam equívocos — eles usam a primeira mensagem de cada validador e os equívocos são simplesmente descartados, evitando ataques em avalanche.
-
-Há várias outras atualizações futuras possíveis para a regra de escolha do fork que podem aumentar a segurança fornecida pelo impulsionador do proponente. Uma delas é a [visualização mesclada](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), na qual os atestadores congelam sua visualização da escolha do fork `n` segundos antes do início de um slot e, em seguida, o proponente ajuda a sincronizar a visualização da cadeia pela rede. Outra potencial melhoria é a [finalidade de slot único](https://notes.ethereum.org/@vbuterin/single_slot_finality), que protege contra ataques baseados no tempo da mensagem, finalizando a cadeia após apenas um slot.
-
-#### Atraso de finalidade {#finality-delay}
-
-[O mesmo artigo](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) que descreveu primeiro o ataque de reorganização 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 atacante ser o proponente do 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 mantém seu bloco até que um número suficiente de validadores honestos usem seus votos FFG em favor do bloco anterior com limite de época como o atual alvo de finalização. Em seguida, eles liberam seus blocos retidos. Eles atestam seus blocos e os restantes validadores honestos o fazem também criando forks com pontos de verificação de destino diferentes. Se o fizerem no momento certo, evitarão a finalidade, pois não haverá uma supermaioria de 2/3 atestando outro fork. Quanto menor for o stake, mais preciso deverá ser o tempo, pois o invasor controla menos atestações diretamente, e menor será a probabilidade de o invasor controlar o validador propondo um determinado bloco de limites de época.
-
-#### Ataques de longo alcance {#long-range-attacks}
-
-Também existe uma classe de ataque específico para blockchains de prova de participação que envolve um validador que participou do bloco de origem, mantendo um fork separado da blockchain junto com o honesto, finalmente convencendo o validador honesto definido a mudar para ele em algum tempo oportuno mais tarde. Este tipo de ataque não é possível no Ethereum devido ao dispositivo 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, pois os clientes do Ethereum simplesmente não irão reorganizar blocos finalizados. Novos nós que participam da rede fazem isso encontrando um hash confiável do estado recente (um “ponto de verificação de[subjetividade fraca](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)”) e usando-o como um pseudo bloco de origem sobre o qual se construir. Isso cria um “gateway de confiança” para um novo nó que entra na rede antes de começar a verificar as informações por si mesmo.
-
-#### Negação de serviço {#denial-of-service}
-
-O mecanismo PoS da Ethereum escolhe um único validador do conjunto total de validadores para ser o proponente de blocos em cada slot. Isso pode ser calculado usando uma função conhecida publicamente e é possível para um adversário identificar o próximo proponente de blocos um pouco antes de sua proposta de bloco. Em seguida, o invasor pode enviar spam ao proponente de bloco para evitar que eles troquem informações com seus pares. Para o resto da rede, vai parecer que o proponente de blocos estava offline e que o slot simplesmente iria ficar vazio. Isso pode ser uma forma de censura contra validadores específicos, impedindo-os de adicionar informações à blockchain. A implementação de eleições de líder único secretas (SSLE) ou eleições de líder não único secretas atenuarão os riscos de DoS, pois só o proponente de blocos sabe que foram eles selecionados e a seleção não é conhecida antecipadamente. Isso ainda não está implementado, mas é uma área ativa de [pesquisa e desenvolvimento](https://ethresear.ch/t/secret-non-single-leader-election/11789).
-
-Tudo isso aponta para o fato de que é muito difícil atacar com sucesso o Ethereum com um pequeno stake. Os ataques viáveis descritos aqui requerem um algoritmo de seleção de fork idealizado, condições de rede improváveis, ou os vetores de ataque já foram fechados com patches relativamente menores para o software cliente. Isso, claro, não exclui a possibilidade de existirem zero dias na natureza, mas demonstra a alta exigência de aptidão técnica, conhecimento da camada de consenso e sorte necessárioa para que um invasor minoritário de stakes seja eficaz. Do ponto de vista de um invasor, sua melhor aposta podeá ser a de acumular o máximo de ethers possível e retornar equipado com uma maior proporção de stakes total.
-
-### Ataques usando >= 33% do stake total {#attackers-with-33-stake}
-
-Todos os ataques mencionados anteriormente neste artigo se tornam mais propensos a terem êxito quando o invasor tiver mais ethers em stake para votar, e mais validadores que podem ser escolhidos para propor blocos em cada slot. Um validador malicioso pode buscar, portanto, controlar o máximo possível de ethers em stake.
-
-33% do ether em stake é um ponto de referência para um invasor porque, com qualquer coisa maior que essa quantidade, eles têm a habilidade de evitar que a cadeia finalize sem ter que controlar com precisão as ações dos outros validadores. Eles simplesmente podem desaparecer todos juntos. Se 1/3 ou mais do ether em stake estiver atestando de forma maliciosa ou falhando em atestar, não poderá existir uma supermaioria de 2/3 e a cadeia não poderá finalizar. A defesa contra isso é o vazamento de inatividade. O vazamento de inatividade identifica os validadores que estão falhando em atestar ou atestando contrário à maioria. O ether em stake pertencente a esses validadores que não atestam é esvaziado gradualmente até que, por fim, eles representem coletivamente menos de 1/3 do total, de modo que a cadeia possa ser finalizada novamente.
-
-O propósito do vazamento de inatividade é finalizar a cadeia novamente. No entanto, o invasor também perde uma parte do seu ether em stake. Inatividade persistente entre validadores que representam 33% do ether total em stake é muito caro, mesmo que os validadores não tenham sido removidos.
-
-Presumindo que a rede Ethereum seja assíncrona (ou seja, há atrasos entre as mensagens sendo enviadas e recebidas), um atacante controlando 34% do stake total poderia causar dupla finalidade. Isso ocorre porque o invasor pode se enganar quando é escolhido para ser produtor de bloco e votar duas vezes com todos os seus validadores. Isso cria uma situação em que existe um fork da blockchain, cada um com 34% do ether em stake votando por ele. Cada fork requer apenas 50% dos validadores restantes para votar em seu favor para que ambos os forks sejam apoiados por uma supermaioria, devendo nesses caso ambas as cadeias poderem finalizar (pois 34% dos invasores validadores + metade do restante de 66% = 67% em cada fork). Cada um dos blocos concorrentes teria que ser recebido por cerca de 50% dos validadores honestos para que esse ataque seja viável somente quando o invasor tiver algum grau de controle sobre o tempo das mensagens que se propagam pela rede, para que eles possam levar metade dos validadores honestos para cada cadeia. O invasor destruiria necessariamente toda o seu stake (34% de ~10 milhões de ethers com o conjunto de validadores atual) para alcançar essa dupla finalidade, pois 34% de seus validadores teriam voto duplo simultaneamente — uma infração sujeita a remoção com penalidade máxima. A defesa contra este ataque é o custo muito elevado de destruir 34% do total do ethers em stake. Para se recuperar desse ataque, seria necessário que a comunidade Ethereum se coordenasse “fora de banda” e concordasse em seguir um ou outro dos forks e ignorar o outro.
-
-### Invasores usando ~50% do stake total {#attackers-with-50-stake}
-
-A 50% do ether em stake, um grupo malicioso de validadores poderia, teoricamente, dividir a cadeia em dois forks de tamanho igual e, em seguida, simplesmente usar todo seu stake de 50% para votar contrariamente ao conjunto de validadores honestos, mantendo assim os dois forks e impedindo a finalidade. O vazamento de inatividade em ambos os forks levaria, por fim, ambas as cadeias a finalizar. A essa altura, a única opção é recorrer a uma recuperação social.
-
-É muito improvável que um grupo adversário de validadores possa controlar, de forma consistente, precisamente 50% do stake total, dado um determinado grau de fluxo em números de validadores honestos, latência de rede, etc. Porém, o enorme custo de montar tal ataque, combinado com a baixa probabilidade de sucesso, parece ser um grande desincentivo para um invasor racional, especialmente quando um pequeno investimento adicional para obter _mais do que_ 50% proporciona muito mais poder.
-
-Com >50% do stake total, o invasor poderia dominar o algoritmo de escolha do fork. Nesse caso, o invasor poderia atestar com o voto majoritário, dando-lhes controle suficiente para fazer pequenas reorganizações sem precisar enganar clientes honestos. Os validadores honestos seguiriam o exemplo, pois seu algoritmo de escolha de fork também veria a cadeia preferida do invasor como a mais pesada, permitindo que a cadeia finalize. Isso permite ao invasor censurar certas transações, fazer reorganizações de curto alcance e extrair o máximo de MEV reordenando blocos a seu favor. A defesa contra isso é o enorme custo de um stake majoritário (atualmente, pouco menos de 19 bilhões de dólares) posto em risco por um invasor, pois a camada social é susceptível de intervir e adotar um fork de minoria honesta, desvalorizando o stake do invasor drasticamente.
-
-### Invasores usando >= 66% do stake total {#attackers-with-66-stake}
-
-Um invasor com 66% ou mais do ether total em stake pode finalizar sua cadeia preferida sem ter que coagir nenhum validador honesto. O invasor pode simplesmente votar no seu fork preferido e depois finalizá-lo, simplesmente porque ele pode votar com uma supermaioria desonesta. Como parte interessada de supermaioria, o invasor sempre controlaria o conteúdo dos blocos finalizados, com o poder de gastar, retroceder e gastar novamente, censurar determinadas transações e reorganizar a cadeia como quisesse. Comprando mais ethers para controlar 66% em vez de 51%, o invasor está efetivamente comprando a habilidade de fazer reorganizações ex post e reversões de finalidade (ou seja, alterar o passado e controlar o futuro). As únicas defesas reais aqui são o enorme custo de 66% do total do ethers em stake e a opção de voltar à camada social para coordenar a adoção de um fork alternativo. Podemos explorar isso com mais detalhes na próxima seção.
-
-## Pessoas: a última linha de defesa {#people-the-last-line-of-defense}
-
-Se os validadores desonestos conseguirem finalizar sua versão preferida da cadeia, a comunidade Ethereum é colocada em uma situação difícil. A cadeia padrão inclui uma seção desonesta produzida em seu histórico, enquanto validadores honestos podem acabar sendo punidos por atestar uma cadeia alternativa (honesta). Observe que uma cadeia finalizada, mas incorreta, também poderia surgir de um bug em um cliente maioritário. No final, o último recurso é confiar na camada social — Camada 0 — para resolver a situação.
-
-Um dos pontos fortes do consenso do Ethereum no PoS é que há uma [gama de estratégias defensivas](https://youtu.be/1m12zgJ42dI?t=1712) que a comunidade pode empregar diante de um ataque. Uma resposta mínima poderia ser tirar forçadamente os validadores dos atacantes da rede sem nenhuma penalidade adicional. Para entrar novamente na rede, o invasor teria que entrar em uma fila de ativação que garantisse que o validador definido crescesse gradualmente. Por exemplo, adicionar validadores suficientes para dobrar a quantidade de ethers em stake leva cerca de 200 dias, efetivamente fazendo com que os validadores honestos ganhem 200 dias antes que o atacante possa tentar outro ataque de 51%. No entanto, a comunidade também poderia decidir penalizar o invasor de forma mais severa, revogando recompensas passadas ou queimando alguma porção (até 100%) do seu capital em stake.
-
-Seja qual for a penalidade imposta ao invasor, a comunidade também tem de decidir em conjunto se a cadeia desonesta, apesar de ser a favorita pelo algoritmo de escolha do fork codificado nos clientes Ethereum, é de fato inválida e se a comunidade deve construir por cima da cadeia honesta. Os validadores honestos poderiam concordar coletivamente em construir sobre um fork aceito pela comunidade da blockchain Ethereum que poderia, por exemplo, ter feito o fork da cadeia padrão antes de o ataque começar ou ter os validadores dos invasores removidos forçadamente. Os validadores honestos seriam incentivados a construir nessa cadeia, pois eles evitariam as penalidades aplicadas a eles por falhar (devidamente) em atestar a cadeia do invasor. Agências de câmbio, rampas de acesso e aplicativos construídos no Ethereum provavelmente prefeririam estar na cadeia honesta e seguir os validadores honestos na blockchain honesta.
-
-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 revertidas, 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 revertidas, 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. Já foram feitos pedidos para simular a resposta da comunidade a ataques de >51%, a fim de coordenar uma ação de mitigação sensata que possa ser executada rapidamente. Existem algumas discussões úteis 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](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). O objetivo de uma resposta social coordenada é o de ser muito direcionada e específica para punir o invasor e minimizar os efeitos para outros usuários.
-
-Governança já é um tema complicado. Gerenciar uma resposta de emergência de Camada 0 para uma cadeia de finalização desonesta seria, sem dúvida, desafiante para a comunidade Ethereum, mas [aconteceu](/history/#dao-fork-summary) - [duas vezes](/history/#tangerine-whistle) no histórico do Ethereum).
-
-No entanto, há algo que é bastante satisfatório na última tentativa no mundo real. Em última análise, 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.
-
-## Resumo {#summary}
-
-Esta página explorou algumas das maneiras como os invasores poderiam tentar explorar o protocolo de consenso da prova de participação do Ethereum. Reorganizações e atrasos de finalidade foram explorados por invasores com proporções cada vez maiores do total de ethers em stake. No geral, um invasor mais rico tem mais chances de sucesso porque seu stake se traduz em poder de voto, que ele pode usar para influenciar o conteúdo de futuros blocos. Em certas quantidades limite de ether em stake, o poder do invasor aumenta de nível:
-
-33%: atraso de finalidade
-
-34%: atraso de finalidade, dupla finalidade
-
-51%: atraso de finalidade, dupla finalidade, censura, controle sobre o futuro da blockchain
-
-66%: atraso de finalidade, dupla finalidade, censura, controle sobre o futuro e 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 que tenha bom controle sobre o tempo das mensagens para influenciar o conjunto de validadores honestos a seu favor.
-
-Em geral, apesar desses potenciais vetores de ataque, o risco de um ataque bem-sucedido é baixo, certamente menor que os equivalentes da prova de trabalho. Isso é devido ao enorme custo do ether colocado em risco por um invasor visando esmagar validadores honestos com seu poder de voto. A camada de incentivo de “cenoura e bastão” incorporada protege contra a maioria das condutas ilegais, especialmente para os invasores de baixo stake. Ataques mais sutis de salto e balanceamento também têm poucas chances de êxito, pois as condições reais da rede tornam o controle detalhado da entrega de mensagens a subconjuntos específicos de validadores muito difícil de atingir, e as equipes de clientes fecharam rapidamente os vetores de ataque de salto, balanceamento e avalanche conhecidos usando patches simples.
-
-Para solucionar ataques de 34%, 51% ou 66% seria provavelmente necessário uma coordenação social fora de banda. Embora isso provavelmente seja doloroso para a comunidade, a capacidade de uma comunidade responder fora da banda é um forte desincentivo para um invasor. A camada social do Ethereum é o ponto final — um ataque tecnicamente bem-sucedido ainda poderia ser neutralizado se a comunidade concordar em adotar um fork honesto. Haveria uma corrida entre o invasor e a comunidade Ethereum — os bilhões de dólares gastos em um ataque de 66% seriam provavelmente eliminados por um ataque de coordenação social bem-sucedido, se fossem entregues com rapidez suficiente. Isso deixaria o invasor com enormes quantidades de ether em stake sem liquidez em uma cadeia desonesta conhecida, ignorada pela comunidade Ethereum. A probabilidade dessa ação ser lucrativa é tão baixa que se torna um dissuasor eficaz. É por isso que o investimento na manutenção de uma camada social coesa com valores fortemente alinhados é tão importante.
-
-## Leitura adicional {#further-reading}
-
-- [Versão mais detalhada desta página](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [Vitalik sobre finalidade de liquidação](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
-- [Artigo sobre o GHOST LMD](https://arxiv.org/abs/2003.03052)
-- [Artigo sobre o Casper-FFG](https://arxiv.org/abs/1710.09437)
-- [Artigo sobre o Gasper](https://arxiv.org/pdf/2003.03052.pdf)
-- [Especificações de consenso de aumento de peso do proponente](https://github.com/ethereum/consensus-specs/pull/2730)
-- [Ataques de salto em ethresear.ch](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
-- [Pesquisa SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
deleted file mode 100644
index d37ffa9b2c4..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Atestações
-description: Uma descrição de atestações em prova de participação Ethereum.
-lang: pt-br
----
-
-Espera-se que um validador crie, assine e transmita uma atestação durante cada época. Esta página descreve como são esses certificados e como eles são processados e comunicados entre clientes de consenso.
-
-## O que é uma atestação? {#what-is-an-attestation}
-
-A cada [época](/glossary/#epoch) (6,4 minutos) um validador propõe uma atestação para a rede. A atestação é para um espaço específico na época. O objetivo da atestação é votar a favor da visão do validador da cadeia, em particular, o bloco justificado mais recente e o primeiro bloco na época atual (conhecidos como pontos de verificação `source` e `target`). Essas informações são combinadas por todos os validadores participantes, permitindo que a rede chegue a consenso sobre o estado da blockchain.
-
-A atestação contém os seguintes componentes:
-
-- `aggregation_bits`: uma lista de bits de validadores onde a posição mapeia para o índice do validador em seu comitê; o valor (0/1) indica se o validador assinou os `data` (ou seja, se eles estão ativos e concordam com o proponente de blocos)
-- `data`: detalhes relacionados à atestação, conforme definido abaixo
-- `signature`: uma assinatura BLS que agrega as assinaturas de validadores individuais
-
-A primeira tarefa para um validador de atestação é construir os `data`. Os `data` contém as seguintes informações:
-
-- `slot`: O número do slot ao qual a atestação se refere
-- `index`: Um número que identifica a qual comitê o validador pertence em um determinado slot
-- `beacon_block_root`: Hash raiz do bloco que o validador vê à cabeça da cadeia (o resultado da aplicação do algoritmo de escolha de fork)
-- `source`: Parte do voto de finalidade indicando o que os validadores veem como o bloco justificado mais recente
-- `source`: Parte do voto de finalidade indicando o que os validadores veem como o primeiro bloco na época atual
-
-Quando o `data` for construído, o validador pode virar o bit em `agregation_bits` correspondente a seu próprio índice validador de 0 a 1 para mostrar que eles participaram.
-
-Finalmente, o validador assina a atestação e o transmite para a rede.
-
-### Atestação agregada {#aggregated-attestation}
-
-Há uma sobrecarga substancial associada ao envio desses dados em torno da rede para cada validador. Portanto, as atestações de validadores individuais são agregados dentro das sub-redes antes de serem transmitidas de forma mais ampla. Isso inclui agregar assinaturas juntas para que uma atestação que é transmitida inclua `data` de consenso e uma única assinatura formada por combinar as assinaturas de todos os validadores que concordam com `data`. Isso pode ser verificado usando `aggregation_bits` porque fornece o índice de cada validador em seu comitê (cuja ID é fornecida em `data`) que podem ser usados para consultar assinaturas individuais.
-
-Em cada período, 16 validadores em cada sub-rede são selecionados para serem os `agregadores`. Os agregadores coletam todas as atestações que ouvem na rede gossip que têm `dados` equivalentes aos deles. O remetente de cada atestação correspondente é registrado nos `agregation_bits`. Os agregadores então transmitem a agregação de atestação para a rede mais ampla.
-
-Quando um validador é selecionado para ser um proponente de blocos, eles empacotam as atestações das sub-redes até o último slot do novo bloco.
-
-### Ciclo de vida de inclusão da atestação {#attestation-inclusion-lifecycle}
-
-1. Geração
-2. Propagação
-3. Agregação
-4. Propagação
-5. Inclusão
-
-O ciclo de vida da atestação está delineado no esquema abaixo:
-
-
-
-## Recompensas {#rewards}
-
-Validadores são recompensados por enviar os atestações. A recompensa da atestação depende dos sinalizadores de participação (fonte, destino e cabeçalho), da recompensa básica e da taxa de participação.
-
-Cada um dos sinalizadores de participação pode ser verdadeiro ou falso, dependendo da atestação enviada e do atraso de inclusão dela.
-
-O melhor cenário ocorre quando todos os três sinalizadores são verdadeiros, caso em que um validador ganharia (por sinalizador correto):
-
-`recompensa += recompensa base * peso do sinalizador * taxa de atestação do sinalizador / 64`
-
-A taxa de atestação do sinalizador é medida usando a soma dos saldos efetivos de todos os validadores de atestação do sinalizador em questão em comparação com o saldo real do ativo total.
-
-### Recompensa base {#base-reward}
-
-A recompensa base é calculada de acordo com o número de validadores atestadores e seus saldos efetivos de ether em stake:
-
-`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)`
-
-#### Atraso de inclusão {#inclusion-delay}
-
-No momento em que os validadores votaram no topo da cadeia (`bloco n`), `bloco n+1` ainda não foi proposto. Portanto, as atestações naturalmente são incluídas **um bloco mais tarde** de modo que todas as atestações que votaram no `block n` sendo a cabeça da cadeia foram incluídos no `block n+1` e o **atraso de inclusão** é 1. Se o atraso de inclusão dobrar para dois slots, a recompensa da atestação cai pela metade, porque para calcular a recompensa da atestação, a recompensa base é multiplicada pelo recíproco do atraso de inclusão.
-
-### Cenários de atestação {#attestation-scenarios}
-
-#### Validador votante faltante {#missing-voting-validator}
-
-Validadores têm um máximo de 1 época para enviar sua atestação. Se a atestação foi perdido na época 0, eles podem enviá-lo com um atraso na inclusão na época 1.
-
-#### Agregador faltante {#missing-aggregator}
-
-Existem 16 Agregadores por época no total. Além disso, os validadores aleatórios inscrevem-se para **duas sub-redes por 256 épocas** e servem como um backup caso agregadores estejam faltando.
-
-#### Proponente de bloco faltante {#missing-block-proposer}
-
-Observe que, em alguns casos, um agregador de sorte também pode se tornar o proponente de blocos. Se a atestação não foi incluída porque o proponente de bloco foi perdido, o proponente do próximo bloco pega a atestação agregada e a inclui no próximo bloco. No entanto, o **atraso de inclusão** aumentará em um.
-
-## Leitura adicional {#further-reading}
-
-- [Atestações na especificação anotada de consenso de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
-- [Atestações em eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
-
-_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione!_
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
deleted file mode 100644
index 52527a8e786..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Proposta de bloqueio
-description: Explicação de como os blocos são propostos na prova de participação do Ethereum.
-lang: pt-br
----
-
-Os blocos são as unidades fundamentais da blockchain. Blocos são unidades discretas de informação passadas entre os nós, acordadas e adicionadas ao banco de dados de cada nó. Esta página explica como elas são produzidas.
-
-## Pré-requisitos {#prerequisites}
-
-A proposta de bloco faz parte do protocolo de prova de participação. Para ajudar a entender esta página, recomendamos que você leia sobre a [prova de participação](/developers/docs/consensus-mechanisms/pos/) e a [arquitetura de bloco](/developers/docs/blocks/).
-
-## Quem produz os blocos? {#who-produces-blocks}
-
-Contas validadoras propõem blocos. Contas validadoras são gerenciadas por operadores de nós que executam um software validador como parte de seus clientes de consenso e execução e que depositaram pelo menos 32 ETH no contrato de depósito. No entanto, cada validador é apenas ocasionalmente responsável por propor um bloco. O Ethereum mede o tempo em slots e épocas. Cada slot é de doze segundos, sendo que 32 slots (6,4 minutos) formam uma época. Cada slot é uma oportunidade de adicionar um novo bloco ao Ethereum.
-
-### Seleção aleatória {#random-selection}
-
-Um único validador é pseudo-aleatoriamente escolhido para propor um bloco em cada slot. Não existe algo realmente aleatório em uma blockchain, porque se cada nó gerou números genuinamente aleatórios, não há como chegar a um consenso. Em vez disso, o objetivo é tornar o processo de seleção do validador imprevisível. A aleatoriedade é alcançada no Ethereum usando um algoritmo chamado RANDAO, que mistura um hash do proponente do bloco com uma semente que é atualizada em todos os blocos. Esse valor é usado para selecionar um validador específico do validador total definido. A seleção do validador é fixa em duas épocas de antecedência como uma forma de proteção contra certos tipos de manipulação de sementes.
-
-Embora os validadores se adicionem ao RANDAO em cada slot, o valor global do RANDAO só é atualizado uma vez por época. Para calcular o índice do próximo proponente de bloco, o valor de RANDAO é misturado com o número do slot para dar um valor único a cada slot. A probabilidade de um validador individual ser selecionado não é simplesmente `1/N` (em que `N` = total de validadores ativos). Em vez disso, ele é ponderado pelo saldo de ETH efetivo de cada validador. O saldo máximo efetivo é de 32 ETH (isso significa que o `saldo < 32 ETH` leva a um peso menor do que o `saldo == 32 ETH`, mas `saldo > 32 ETH` não leva a uma ponderação maior que o saldo de `== 32 ETH`).
-
-Somente um proponente de blocos é selecionado em cada slot. Em condições normais, um único produtor de blocos cria e libera um único bloco no seu slot dedicado. A criação de dois blocos para o mesmo slot é uma ofensiva removível, geralmente conhecida como “ambiguidade”.
-
-## Como o bloco é criado? {#how-is-a-block-created}
-
-Espera-se que o proponente de blocos transmita um bloco beacon assinado que se baseia no cabeçalho mais recente da cadeia, de acordo com a visualização de seu próprio algoritmo de escolha de bifurcação (fork choice) local. O algoritmo de escolha de bifurcação (fork) aplica todas as atestações na fila deixadas no slot anterior e, em seguida, encontra o bloco com o maior peso acumulado de atestações em seu histórico. Esse bloco é o pai do novo bloco criado pelo proponente.
-
-O proponente de blocos cria um bloco coletando dados de seu próprio banco de dados local e visualização da cadeia. O conteúdo do bloco é mostrado no trecho de código abaixo:
-
-```rust
-class BeaconBlockBody(Container):
- randao_reveal: BLSSignature
- eth1_data: Eth1Data
- graffiti: Bytes32
- proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
- attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
- attestations: List[Attestation, MAX_ATTESTATIONS]
- deposits: List[Deposit, MAX_DEPOSITS]
- voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
- sync_aggregate: SyncAggregate
- execution_payload: ExecutionPayload
-```
-
-O campo `randao_reveal` leva um valor aleatório verificável que o proponente do bloco cria assinando o número da época atual. `eth1_data` é uma votação para a visualização do proponente do bloco no contrato de depósito, incluindo a raiz do depósito da árvore Merkle de depósito e o número total de depósitos que permitem a verificação de novos depósitos. `graffiti` é um campo opcional que pode ser usado para adicionar uma mensagem ao bloco. `proposer_slashings` e `attester_slashings` são campos que contêm provas de que alguns validadores cometeram ofensivas sujeitas a remoção segundo a visualização do proponente da cadeia. `depósitos` é uma lista de novos depósitos do validador dos quais o proponente de bloco está ciente, e `voluntary_exits` é uma lista de validadores que desejam sair, segundo o que o proponente de blocos ouviu falar na rede de fofocas da camada de consenso. O `sync_aggregate` é um vetor que mostra quais validadores foram previamente atribuídos a um comitê de sincronização (um subconjunto de validadores que atendem dados de cliente leve) e participaram da assinatura de dados.
-
-O `execution_payload` permite que informações sobre transações sejam passadas entre clientes de execução e clientes de consenso. O `execution_payload` é um bloco de dados de execução que fica aninhado em um bloco de sinal (beacon). Os campos dentro de `execution_payload` refletem a estrutura do bloco delineada nas especificações formais (Yellow Paper) do Ethereum, exceto pelo fato de não haver ommers e `prev_randao` existe no lugar de `difficulty`. O cliente de execução tem acesso a um conjunto de operações locais de que ouviu falar na sua própria rede de fofocas. Essas transações são executadas localmente para gerar uma árvore de estado atualizada, conhecida como pós-estado. As transações são incluídas no `execution_payload` como uma lista chamada `transactions` e o pós-estado é fornecido no campo `state-root`.
-
-Todos esses dados são coletados em um bloco de sinal, assinado e transmitido para os pares do proponente de blocos, que o propagam para seus pares, etc.
-
-Leia mais sobre a [anatomia dos blocos](/developers/docs/blocks).
-
-## O que acontece com os blocos? {#what-happens-to-blocks}
-
-O bloco é adicionado ao banco de dados local do proponente do bloco e transmitido aos pares pela rede de fofocas da camada de consenso. Quando um validador recebe o bloco, ele verifica os dados dentro dele, inclusive se o bloco tem o pai correto, corresponde ao pacote correto, se o índice do proponente é o esperado, se a revelação RANDAO é válida e se o proponente não foi removido. O `execution_payload` é descompactado e o cliente de execução do validador reexecuta as transações na lista para verificar a proposta de mudança de estado. Supondo que o bloco passe em todas essas verificações, cada validador adiciona o bloco à sua própria cadeia padronizada. O processo recomeça no próximo slot.
-
-## Recompensas do bloco {#block-rewards}
-
-O proponente de blocos recebe pagamento pelo seu trabalho. Há uma `base_reward` calculada como uma função do número de validadores ativos e seus saldos efetivos. O proponente de blocos recebe uma fração de `base_reward` por cada certificado válido incluído no bloco; quanto mais validadores atestarem o bloco, maior será a recompensa do seu proponente. Há também uma recompensa por reportar validadores que devem ser removidos, igual a `1/512 * saldo efetivo` para cada validador removido.
-
-[Recompensas e penalidades da PoS](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
-
-## Leitura adicional {#further-reading}
-
-- [Introdução aos blocos](/developers/docs/blocks/)
-- [Introdução à prova de participação](/developers/docs/consensus-mechanisms/pos/)
-- [Especificações do consenso do Ethereum](https://github.com/ethereum/consensus-specs)
-- [Introdução ao Gasper](/developers/docs/consensus-mechanisms/pos/)
-- [Atualizando o Ethereum](https://eth2book.info/)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
deleted file mode 100644
index c66156b53a3..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
+++ /dev/null
@@ -1,172 +0,0 @@
----
-title: Perguntas Frequentes
-description: Perguntas frequentes sobre a prova de participação do Ethereum.
-lang: pt-br
----
-
-## O que é prova de participação {#what-is-proof-of-stake}
-
-A prova de participação (PoS) é uma classe de algoritmo capaz de fornecer segurança às blockchains, garantindo que os ativos de valor sejam perdidos por invasores que atuam de forma desonesta. Sistemas de prova de participação demandam um conjunto de validadores para disponibilizar alguns ativos, que podem ser destruídos se o validador se envolver em um provável comportamento desonesto. Por esses motivos, o Ethereum usa um mecanismo prova de participação para assegurar a blockchain.
-
-## De que maneira a prova de participação se compara à prova de trabalho? {#comparison-to-proof-of-work}
-
-Tanto a prova de trabalho quanto a prova de participação são mecanismos que desincentivam economicamente agentes maliciosos de enviar spam ou a defraudar a rede. Em ambos os casos, nós que participam ativamente do consenso colocam ativos “na rede”, que poderão ser perdidos se eles não se comportarem corretamente.
-
-Na prova de trabalho, esse ativo é a energia. O nó, conhecido como um minerador, executa um algoritmo que visa calcular um valor mais rápido do que qualquer outro nó. O nó mais rápido tem o direito de propor um bloco à cadeia. Para mudar a história da cadeia ou dominar a proposta do bloco, um minerador teria que ter muita potência computacional para vencer a corrida. Isso é proibitivamente caro e difícil de executar, mas protege a cadeia contra ataques. A energia necessária para “minerar” usando a prova de trabalho é um ativo do mundo real, pago pelos mineradores.
-
-A prova de participação requer nós, conhecidos como validadores, para enviar explicitamente um ativo cripto para um contrato inteligente. Se um validador se comportar mal, esse criptoativo pode ser destruído porque eles estão colocando em participação (staking) seus ativos diretamente na cadeia, em vez de indiretamente por meio do gasto de energia.
-
-A prova de trabalho consome muito mais energia porque a eletricidade é consumida no processo de mineração. Por outro lado, a prova de participação requer apenas uma quantidade muito pequena de energia: os validadores do Ethereum podem até ser executados em um dispositivo de baixa potência, como o Raspberry Pi. O mecanismo de prova de participação do Ethereum é considerado mais seguro do que a prova de trabalho, porque o custo do ataque é maior e as consequências para um invasor são mais severas.
-
-A comparação entre prova de trabalho e prova de participação é um tópico controverso. [O blog do Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) e o debate entre Justin Drake e Lyn Alden fornecem um bom resumo dos argumentos.
-
-
-
-## A prova de participação é energeticamente eficiente? {#is-pos-energy-efficient}
-
-Sim. Os nós em uma rede com prova de participação usam uma pequena quantidade de energia. Um estudo de terceiros concluiu que toda a rede Ethereum com prova de participação consome em torno de 0,0026 TWh/ano, cerca de 13.000 vezes menos do que jogos só nos EUA.
-
-[Mais sobre o consumo de energia do Ethereum](/energy-consumption/).
-
-## A prova de participação é segura? {#is-pos-secure}
-
-A prova de participação do Ethereum é muito segura. O mecanismo foi pesquisado, desenvolvido e testado rigorosamente ao longo de oito anos de atividade antes de entrar em produção. As garantias de segurança são diferentes de blockchains com prova de trabalho. Na prova de participação, os validadores maliciosos podem ser punidos ativamente (“removidos”) e expulsos do conjunto de validadores, custando uma quantia substancial de ETH. Na prova de trabalho, um invasor pode continuar repetindo seu ataque enquanto ele tem poder de hash suficiente. Também é mais caro organizar ataques equivalentes na prova de participação do Ethereum do que na prova de trabalho. Para afetar a vitalidade da cadeia, é necessário pelo menos 33% do total de ether em participação (stake) na rede (exceto nos casos de ataques muito sofisticados com uma probabilidade de sucesso extremamente baixa). Para controlar o conteúdo de futuros blocos, é necessário pelo menos 51% do total de ETH em participação (stake) e, para reescrever o histórico, é necessário mais de 66% do total em participação (stake). O protocolo Ethereum destruiria esses ativos nos cenários de ataque de 33% ou 51% e por consenso social no cenário de ataque de 66%.
-
-- [Saiba mais sobre como defender a prova de participação do Ethereum contra invasores](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
-- [Mais sobre o design da prova de participação](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-
-## A prova de participação torna o Ethereum mais barato? {#does-pos-make-ethereum-cheaper}
-
-Não. O custo para enviar uma transação (taxa de gás) é determinado por um mercado dinâmico de taxas que aumenta com o aumento da demanda de rede. O mecanismo de consenso não influencia isso diretamente.
-
-[Mais sobre gás](/developers/docs/gas).
-
-## O que são nós, clientes e validadores? {#what-are-nodes-clients-and-validators}
-
-Nós são computadores conectados à rede Ethereum. Clientes são o software que eles executam que transforma o computador em um nó. Existem dois tipos de clientes: clientes de execução e clientes de consenso. Ambos são necessários para criar um nó. Um validador é um complemento opcional para um cliente de consenso que permite que o nó participe do consenso de prova de participação. Isso significa criar e propor blocos quando selecionados e atestar os blocos que eles ouvem na rede. Para executar um validador, o operador do nó deve depositar 32 ETH no contrato de depósito.
-
-- [Mais sobre nós e clientes](/developers/docs/nodes-and-clients)
-- [Mais sobre participação](/staking)
-
-## A prova de participação é uma nova ideia? {#is-pos-new}
-
-Não. Um usuário do BitcoinTalk [propôs a ideia básica de prova de participação](https://bitcointalk.org/index.php?topic=27787.0) como uma atualização para o Bitcoin em 2011. Passaram-se onze anos antes de estar pronto para ser implementado na Rede principal (Mainnet) do Ethereum. Algumas outras cadeias implementaram a prova de participação antes do Ethereum, mas não o mecanismo específico do Ethereum (conhecido como Gasper).
-
-## O que tem de especial na prova de participação do Ethereum? {#why-is-ethereum-pos-special}
-
-O mecanismo de prova de participação do Ethereum possui um design único. Esse mecanismo não foi o primeiro a ser planejado ou implementado, mas é o mais robusto. O mecanismo de prova de participação é conhecido como “Casper”. O Casper é definido a partir de como os validadores são selecionados para propor blocos, como e quando os certificados são feitos, como os certificados são contados, as recompensas e penalidades dadas aos validadores, condições de redução, mecanismos seguros, assim como a fuga de inatividade e as condições de “finalidade”. Enquanto isso, “finalidade” é a condição de que, para que um bloco seja considerado uma parte permanente da cadeia padronizada, ele deve ter sido votado pelo menos por 66% do ETH total em participação na rede. Os pesquisadores desenvolveram o Casper especificamente para o Ethereum, que é a primeira e única blockchain a ter implementado tal mecanismo.
-
-Além do Casper, a prova de participação do Ethereum usa um algoritmo de escolha de bifurcação (fork) chamado LMD-GHOST. Isso é necessário no caso de surgir uma condição em que há dois blocos para o mesmo slot. Isso cria duas bifurcações (forks) na blockchain. O LMD-GHOST escolhe a que tem o maior “peso” de atestações. O peso é o número de atestações ponderado pelo saldo efetivo dos validadores. O LMD-GHOST é de exclusividade do Ethereum.
-
-A combinação do Casper com o LMD_GHOST é conhecida como Gasper.
-
-[Mais sobre o Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)
-
-## O que é remoção (slashing)? {#what-is-slashing}
-
-Remoção (slashing) é o termo dado à destruição de parte da participação do validador e à expulsão do validador da rede. A quantidade de ETH perdida em escalas de remoção com o número de validadores sendo reduzidos — isso significa que os validadores cúmplices são punidos com mais severidade do que indivíduos.
-
-[Mais sobre remoção (slashing)](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing)
-
-## Por que os validadores precisam de 32 ETH? {#why-32-eth}
-
-Os validadores têm que colocar ETH em participação (stake) para que tenham algo a perder caso se comportem indevidamente. A razão pela qual eles têm que colocar 32 ETH em participação (stake) especificamente é para permitir que os nós executem em hardware modestos. Se o mínimo de ETH por validador fosse menor, então o número de validadores e, portanto, o número de mensagens que devem ser processadas em cada slot aumentaria, o que significa que seria necessário um hardware mais potente para executar um nó.
-
-## Como os validadores são selecionados? {#how-are-validators-selected}
-
-Um único validador é pseudo-aleatoriamente escolhido para propor um bloco em cada slot usando um algoritmo chamado RANDAO, que mistura um hash do proponente do bloco com uma semente que é atualizada em cada bloco. Esse valor é usado para selecionar um validador específico do conjunto total de validadores. A seleção do validador é fixada com duas épocas de antecedência.
-
-[Mais sobre a seleção do validador](/developers/docs/consensus-mechanisms/pos/block-proposal)
-
-## O que significa ataque forçado de participação (stake grinding)? {#what-is-stake-grinding}
-
-O ataque forçado de participação é uma categoria de ataque em redes de prova de participação na qual o invasor tenta influenciar o algoritmo de seleção do validador para beneficiar seus próprios validadores. Os ataques forçados de participação (grinding attacks) em RANDAO exigem cerca de metade do total de ETH em participação (stake).
-
-[Mais sobre forçar participação (stake grinding)](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability)
-
-## O que é a remoção social? {#what-is-social-slashing}
-
-A remoção social consiste na capacidade de uma comunidade em coordenar uma bifurcação (fork) da blockchain em resposta a um ataque. Ela permite à comunidade se recuperar do ataque de um invasor, finalizando uma cadeia desonesta. O corte social também pode ser utilizado contra ataques de censura.
-
-- [Mais a respeito de remoção social](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7)
-- [Vitalik Buterin sobre remoção social](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-
-## Eu serei removido? {#will-i-get-slashed}
-
-Como validador, é muito difícil ser removido, a menos que você se envolva deliberadamente em um comportamento malicioso. A remoção só é implementada em cenários muito específicos, nos quais os validadores propõem vários blocos para o mesmo slot ou se contradizem com suas atestações, o que é muito improvável acontecer acidentalmente.
-
-[Mais sobre condições de remoção](https://eth2book.info/altair/part2/incentives/slashing)
-
-## Qual é o problema do “nada em participação” (nothing-at-stake)? {#what-is-nothing-at-stake-problem}
-
-O problema do nada em participação (stake) é uma questão conceitual com alguns mecanismos de prova de participação, nos quais há apenas recompensas e nenhuma penalidade. Se não há nada em participação (stake), um validador pragmático poderá sem problemas atestar qualquer uma, ou mesmo várias, bifurcações (forks) da blockchain, pois isso aumenta suas recompensas. O Ethereum contorna isso usando condições de finalidade e remoções para garantir uma cadeia padronizada.
-
-[Mais sobre o problema do “nada em participação”](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
-
-## O que é um algoritmo de escolha de bifurcação (fork)? {#what-is-a-fork-choice-algorithm}
-
-Um algoritmo de escolha de bifurcação (fork) implementa regras que determinam qual cadeia é a padronizada. Em condições ideais, não há necessidade de uma regra de escolha de bifurcação (fork), pois há apenas um proponente de bloco por slot e um bloco para escolher. Ocasionalmente, porém, vários blocos para o mesmo slot ou informações que chegam com atraso levam a várias opções de como os blocos próximos ao topo da cadeia são organizados. Nesses casos, todos os clientes devem implementar algumas regras de forma idêntica para garantir que todos escolham a sequência correta de blocos. O algoritmo de escolha da bifurcação (fork) codifica essas regras.
-
-O algoritmo de escolha da bifurcação (fork) do Ethereum é chamado LMD-GHOST. Ele escolhe a bifurcação (fork) com o maior peso de atestações, ou seja, aquele que tem votado mais ETH em participação (stake).
-
-[Mais sobre LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice)
-
-## Qual a finalidade da prova de participação? {#what-is-finality}
-
-A finalidade da prova de participação é a garantia de que um determinado bloco é uma parte permanente da cadeia padronizada e não pode ser revertido, a menos que haja uma falha de consenso, na qual um invasor consome 33% do total de ether em participação (stake). Essa é a finalidade “criptoeconômica”, em oposição à “finalidade probabilística”, relevante para blockchains de prova de trabalho. Na finalidade probabilística, não há estados explícitos finalizados/não finalizados para blocos; simplesmente, torna-se cada vez menos provável que um bloco possa ser removido da cadeia à medida que envelhece, e os usuários determinam por conta própria quando estão suficientemente confiantes de que um bloco é “seguro”. Com finalidade criptoeconômica, pares de blocos de pontos de verificação têm que ser votados por 66% do ether em participação (stake). Se essa condição for satisfeita, os blocos entre esses pontos de verificação são explicitamente “finalizados”.
-
-[Mais sobre finalidade](/developers/docs/consensus-mechanisms/pos/#finality)
-
-## O que é “subjetividade fraca”? {#what-is-weak-subjectivity}
-
-A subjetividade fraca é um recurso de redes de prova de participação, em que informações sociais são usadas para confirmar o estado atual da blockchain. Novos nós ou nós que se juntam à rede após ficarem offline por um longo período podem ter recebido um estado recente para o nó poder ver imediatamente se eles estão na cadeia correta. Esses estados são conhecidos como “pontos de verificação de subjetividade fraca” e eles podem ser obtidos de outros operadores de nó fora de banda, ou de exploradores de bloco, ou de vários terminais públicos.
-
-[Mais sobre subjetividade fraca](/developers/docs/consensus-mechanisms/pos/weak-subjectivity)
-
-## A censura da prova de participação é resistente? {#is-pos-censorship-resistant}
-
-No momento, é difícil provar resistência à censura. No entanto, ao contrário da prova de trabalho, a prova de participação oferece a opção de coordenar remoções para punir os validadores que censuram. Há mudanças futuras no protocolo que separam os construtores de blocos dos proponentes de blocos e implementam listas de transações que os construtores devem incluir em cada bloco. Essa proposta é conhecida como separação apropriada do construtor e ajuda a evitar que os validadores censurem as transações.
-
-[Mais sobre separação apropriada do construtor](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
-
-## O sistema de prova de participação do Ethereum pode ser atacado em 51%? {#pos-51-attack}
-
-Sim. A prova de participação é vulnerável a 51% dos ataques, bem como a prova de trabalho. Ao invés do atacante precisar de 51% do poder de hash da rede, o atacante requer 51% do total de ETH em stake. Um invasor que acumula 51% do total em participação (stake) consegue controlar o algoritmo de escolha da bifurcação (fork). Isso permite que o invasor censure certas transações, faça reorganizações de curto alcance e extraia MEV reordenando blocos a seu favor.
-
-[Leia mais sobre ataques na prova de participação](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
-
-## O que é coordenação social e por que ela é necessária? {#what-is-social-coordination}
-
-A coordenação social é a última linha de defesa do Ethereum que permitiria uma cadeia honesta ser recuperada de um ataque que finalizou blocos desonestos. Nesse caso, a comunidade do Ethereum teria que se coordenar “fora de banda” e concordar em usar uma bifurcação (fork) minoritária honesta, removendo os validadores mal-intencionados no processo. Isso exigiria aplicativos e corretoras para reconhecer também a bifurcação (fork) honesta.
-
-[Leia mais a respeito da coordenação social](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
-
-## O rico fica mais rico na prova de participação? {#do-rich-get-richer}
-
-Quanto mais ETH alguém tiver para colocar em participação (stake), mais os validadores podem operar e mais recompensas podem acumular. As recompensas escalam linearmente com a quantidade de ETH em participação (stake) e todos recebem a mesma porcentagem de retorno. A prova de trabalho enriquece mais os ricos do que a prova de participação, pois os mineradores mais ricos que compram hardware em escala se beneficiam de economias de escala, o que significa que a relação entre riqueza e recompensa não é linear.
-
-## A prova de participação é mais centralizada do que a prova de trabalho? {#is-pos-decentralized}
-
-Não, a prova de trabalho tende à centralização, porque os custos de mineração aumentam e tiram indivíduos do mercado, depois tiram pequenas empresas do mercado, e assim por diante. O problema atual com prova de participação é a influência dos derivados líquidos de participação (LSDs). Eles são tokens que representam o ETH em participação (stake) por algum provedor, com o qual qualquer pessoa pode fazer swap cambial em mercados secundários sem que o ETH real seja retirado da participação (stake). Os LSDs permitem que usuários coloquem em participação (stake) menos de 32 ETH, mas também criam um risco de centralização, permitindo que algumas organizações importantes acabem controlando grande parte da participação (stake). É por isso que a [participação individual](/staking/solo) (solo staking) é a melhor opção para o Ethereum.
-
-[Mais sobre a centralização de participação (stake) em LSDs](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
-
-## Por que eu só posso colocar ETH em participação (stake)? {#why-can-i-only-stake-eth}
-
-O ETH é a moeda nativa da Ethereum. É essencial ter uma moeda única em que todas as participações (stakes) sejam denominadas, tanto para contabilizar saldos efetivos, quanto para ponderar votos e segurança. Por si só, o ETH é um componente fundamental do Ethereum, em vez de um contrato inteligente. A incorporação de outras moedas aumentaria significativamente a complexidade e diminuiria a segurança da participação (stake).
-
-## O Ethereum é a única blockchain com prova de participação? {#is-ethereum-the-only-pos-blockchain}
-
-Não, há várias blockchains que possuem prova de participação. No entanto, nenhuma é idêntica à do Ethereum, o que torna o mecanismo de prova de participação único.
-
-## O que é A Fusão (The Merge)? {#what-is-the-merge}
-
-A Fusão (The Merge) foi o momento em que o Ethereum desligou o seu mecanismo de consenso baseado em prova de trabalho e ativou o seu mecanismo de consenso baseado em prova de participação. A Fusão (The Merge) ocorreu em 15 de setembro de 2022.
-
-[Mais sobre a integração](/roadmap/merge)
-
-## O que é atividade e segurança? {#what-are-liveness-and-safety}
-
-Atividade e segurança são as duas preocupações fundamentais relativas à segurança de uma blockchain. Atividade é a disponibilidade de uma cadeia de finalização. São consideradas falhas de atividade se a cadeia parar de finalizar ou se os usuários não conseguirem acessá-la facilmente. Custos de acesso extremamente elevados também poderiam ser considerados como falha de atividade. Já a segurança se refere ao quão difícil é atacar a cadeia, ou seja, finalizar os pontos de verificação conflitantes.
-
-[Leia mais no artigo do Casper](https://arxiv.org/pdf/1710.09437.pdf)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
deleted file mode 100644
index 4a633193622..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Gasper
-description: Uma explicação do mecanismo de prova de participação do Gasper.
-lang: pt-br
----
-
-Gasper é uma combinação de Casper, o Gadget de Finalidade Amigável (Casper-FFG) e o algoritmo de escolha do fork de LMD-GHOST. Juntos, esses componentes formam o mecanismo de consenso que garante a prova de participação do Ethereum. Casper é o mecanismo que atualiza certos blocos para "finalizados" para que os novos participantes da rede possam ter certeza de que estão sincronizando a cadeia canônica. O algoritmo de escolha de fork usa votos acumulados para garantir que os nós possam selecionar facilmente o correto quando surgirem forks na blockchain.
-
-**Observe** que a definição original de Casper-FFG foi levemente atualizada para inclusão no Gasper. Nesta página consideramos a versão atualizada.
-
-## Pré-requisitos
-
-Para entender este material, é necessário ler a página introdutória em [prova de participação](/developers/docs/consensus-mechanisms/pos/).
-
-## O papel do Gasper {#role-of-gasper}
-
-Gasper se encontra no topo de uma blockchain de prova de participação onde os nós fornecem ether como um depósito de segurança que pode ser destruído se eles forem lentos ou desonestos em propor ou validar blocos. Gasper é o mecanismo que define como os validadores são recompensados e punidos, decide quais blocos aceitar e rejeitar, e em qual fork da blockchain se baseará.
-
-## O que é a finalidade? {#what-is-finality}
-
-Finalidade é uma propriedade de certos blocos que significa que eles não podem ser revertidos a menos que tenha havido um fracasso crítico do consenso e um atacante tenha destruído pelo menos 1/3 do ether total em stake. Blocos finalizados podem ser considerados informações sobre as quais a blockchain está totalmente segura. Um bloco deve passar por um procedimento de atualização em duas etapas para que seja finalizado:
-
-1. Dois terços do total do ether em stake devem ter votado a favor da inclusão desse bloco na cadeia canônica. Essa condição atualiza o bloco para "justificado". Blocos justificados dificilmente serão revertidos, mas podem ser em determinadas condições.
-2. Quando outro bloco é justificado em cima de um bloco justificado, ele é atualizado para "finalizado". Finalizar um bloco é um compromisso de incluí-lo na cadeia canônica. Não pode ser revertido, a menos que um atacante destrua milhões de ether (bilhões de $USD).
-
-Estas atualizações de blocos não acontecem em todos os slots. Em vez disso, apenas blocos adjacentes ao epoch podem ser justificados e finalizados. Estes blocos são conhecidos como "checkpoints". A atualização considera pares de checkpoints. Um "link da grande maioria" deve existir entre dois checkpoints sucessivos (ou seja, dois terços do total em stake de ether votam que o checkpoint B é o descendente correto do checkpoint A) para atualizar o checkpoint menos recente para finalizado e o bloco mais recente para justificado.
-
-Dado que a finalidade requer um acordo de dois terços de que um bloco é canônico, um atacante não pode possivelmente criar uma cadeia finalizada alternativa sem:
-
-1. Possuir ou manipular dois terços do ether em stake.
-2. Destruir pelo menos um terço do ether em stake.
-
-A primeira condição surge porque dois terços do ether em stake são necessários para finalizar uma cadeia. A segunda condição surge porque se dois terços do stake total votaram a favor de ambos forks, então um terço deve ter votado em ambos. O voto duplicado é uma condição de corte, que seria punida ao máximo, e um terço do stake total seria destruído. Desde maio de 2022, isto requer que um atacante queime cerca de US$ 10 bilhões de ether. O algoritmo que justifica e finaliza os blocos no Gasper é uma forma ligeiramente modificada de [Casper o Gadget de Finalidade Amigável (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf).
-
-### Incentivos e cortes {#incentives-and-slashing}
-
-Os validadores são recompensados por propor e validar blocos honestamente. Ether é dado como recompensa e adicionado ao stake deles. Por outro lado, validadores que estão ausentes e não conseguem agir quando chamados perdem essas recompensas e, às vezes, perdem uma pequena parte de seu stake existente. No entanto, as penalizações por estar off-line são pequenas e, na maioria dos casos, equivalem ao custo das recompensas perdidas. No entanto, algumas ações do validador são muito difíceis de fazer acidentalmente e significam alguma intenção maliciosa, tais como propor vários blocos para o mesmo slot, atestar em vários blocos para o mesmo slot, ou contradizer votos anteriores de checkpoint. Estes são comportamentos "de remoção" que são penalizados mais duramente: destruição de parte da participação do validador e o validador sendo removido da rede de validadores. Este processo dura 36 dias. No dia 1, há uma penalidade inicial de até 1 ETH. O ether do validador removido drena lentamente ao longo do período de saída, mas no dia 18 eles recebem uma “penalidade de correlação”, que é maior quando mais validadores são removidos ao mesmo tempo. A pena máxima é todo o stake. Essas recompensas e penalidades são concebidas para incentivar validadores honestos e desincentivar ataques na rede.
-
-### Perda por inatividade {#inactivity-leak}
-
-Além da segurança, o Gasper também fornece "uma vivacidade plausível". Esta condição prevê que enquanto dois terços do ether total em stake votarem honestamente e seguirem o protocolo, a cadeia poderá finalizar independentemente de qualquer outra atividade (como ataques, problemas de latência ou cortes). Em outras palavras, um terço do ether total em stake deve estar comprometido de alguma forma para evitar que a cadeia finalize. No Gasper, existe uma linha de defesa adicional contra uma falha de vivacidade, conhecida como o "perda por inatividade". Este mecanismo é ativado quando a cadeia falhou em finalizar por mais de quatro epochs. Os validadores que não estão atestando ativamente a cadeia da maioria, têm seu stake gradualmente drenado até que a maioria recupere dois terços do stake total, assegurando que as falhas de vivacidade sejam apenas temporárias.
-
-### Escolha do fork {#fork-choice}
-
-A definição original do Casper-FFG incluía um algoritmo de escolha de fork que determinava a regra: `follow the chain containing the justified checkpoint that has the greatest height` em que a altura é definida como a maior distância do bloco de início. No Gasper, a regra de escolha do fork original está descontinuada em favor de um algoritmo mais sofisticado chamado LMD-GHOST. É importante compreender que, em condições normais, uma regra de escolha de fork é desnecessária – há um único proponente de bloco para cada slot, e validadores honestos atestam isso. Um algoritmo de escolha de fork é necessário somente quando há uma grande assincronicidade de rede ou quando um proponente de blocos desonesto se equivoca. Quando esses casos surgem, o algoritmo de escolha do fork é uma defesa fundamental que protege a cadeia correta.
-
-LMD-GHOST são as siglas de "latest message-driven greedy heaviest observed sub-tree". Esta é uma definição em jargão de um algoritmo que seleciona o fork com o maior peso acumulado de confimações como a canônica (subárvore mais pesada) e que se várias mensagens forem recebidas de um validador, apenas a última será considerada (orientada pela última mensagem). Antes de adicionar o bloco mais pesado à sua cadeia canônica, todo validador avalia cada bloco usando esta regra.
-
-## Leitura Adicional {#further-reading}
-
-- [Gasper: Combinando GHOST e Casper](https://arxiv.org/pdf/2003.03052.pdf)
-- [Casper, o Mecanismo de Finalidade Amigável](https://arxiv.org/pdf/1710.09437.pdf)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
deleted file mode 100644
index d3bae61b6cd..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Prova de participação (PoS)
-description: Explicação do protocolo de consenso "Prova de participação" e seu papel no Ethereum.
-lang: pt-br
----
-
-A prova de participação (PoS) é a base do [mecanismo de consenso](/developers/docs/consensus-mechanisms/) do Ethereum. O Ethereum ativou seu mecanismo de prova de participação em 2022 porque é mais seguro, consome menos energia e é melhor para implementar novas soluções de escalabilidade em comparação com a arquitetura de [prova de trabalho](/developers/docs/consensus-mechanisms/pow) anterior.
-
-## Pré-requisitos {#prerequisites}
-
-Para entender melhor esta página, recomendamos que você primeiro leia [mecanismos de consenso](/developers/docs/consensus-mechanisms/).
-
-## O que é prova de participação (PoS)? {#what-is-pos}
-
-A prova de participação é um meio de provar que os validadores colocam algo de valor na rede, para que possa ser destruído se agirem de forma desonesta. Na prova de participação do Ethereum, os validadores colocam explicitamente o capital na forma de ETH em um contrato inteligente no Ethereum. O validador é então responsável por verificar se os novos blocos propagados pela rede são válidos e se, ocasionalmente, criam e propagam novos blocos por conta própria. Se eles tentarem defraudar a rede (por exemplo, propondo múltiplos blocos, quando eles deveriam enviar um só ou estar enviando atestações conflitantes), alguns ou todos os seus ETH colocados podem ser destruídos.
-
-## Validadores {#validators}
-
-Para participar como validador, um usuário deve depositar 32 ETH no contrato de depósito e executar três softwares separados: um cliente de execução, um cliente de consenso e um cliente validador. Ao depositar seu ETH, o usuário entra em uma fila de ativação que limita a taxa de novos validadores que entram na rede. Uma vez ativados, os validadores recebem novos blocos de pares na rede Ethereum. As transações entregues no bloco são reexecutadas para verificar se, as alterações propostas para o estado do Ethereum são válidas e a assinatura do bloco é verificada. O validador então envia um voto (chamado de atestação) a favor desse bloco para toda a rede.
-
-Enquanto na prova de trabalho, o tempo dos blocos é determinado pela dificuldade de mineração, na prova de participação o tempo é fixo. O tempo na prova de participação do Ethereum é dividido em slots (12 segundos) e épocas (32 slots). Um validador é selecionado aleatoriamente para ser um proponente de bloco em cada espaço. Esse validador é responsável por criar um novo bloco e enviá-lo para outros nós da rede. Também em cada slot, um comitê de validadores é escolhido aleatoriamente, cujos votos são utilizados para determinar a validade do bloco proposto. Dividir o validador configurado em comitês é importante para manter a carga de rede gerenciável. Os comitês dividem o conjunto de validadores, de modo que cada validador ativo ateste em cada época, mas não em cada espaço (slot).
-
-## Como uma transação é executada na Ethereum PoS {#transaction-execution-ethereum-pos}
-
-O seguinte fornece uma explicação de ponta a ponta de como uma transação é executada na proof-of-stake da Ethereum.
-
-1. Um usuário cria e assina uma href="/developers/docs/transactions/">transação/a> com sua chave privada. Isso geralmente é feito por uma carteira ou uma biblioteca como a [ether.js](https://docs.ethers.io/v5/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) etc, mas sem o conhecimento do usuário está fazendo uma solicitação para um nó usando o Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/). O usuário define a quantidade de gás que está disposto a pagar como gorjeta a um validador para incentivá-lo a incluir a transação em um bloco. As [dicas](/developers/docs/gas/#priority-fee) são pagas ao validador enquanto a [taxa básica](/developers/docs/gas/#base-fee) é paga queimado.
-2. A transação é enviada para um [cliente de execução](/developers/docs/nodes-and-clients/#execution-client) Ethereum que verifica a sua validade. Isto significa garantir que o remetente tem ETH suficiente para realizar a transação e eles o assinaram com a chave correta.
-3. Se a transação for válida, o cliente de execução adiciona-o à sua mempool local (lista de transações pendentes) e também a transmite para outros nós por meio da rede gossip da camada de execução. Quando outros nós ouvem sobre a transação, eles a adicionam à sua mempool local também. Os usuários avançados podem abster-se de transmitir sua transações e, em vez disso, encaminhá-la a criadores de blocos especializados, como [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Isso permite que eles organizem as transações nos próximos blocos para obter o máximo lucro ([MEV](/developers/docs/mev/#mev-extraction)).
-4. Um dos nós validadores na rede é o proponente de bloco para o slot atual, tendo sido selecionado pseudo-aleatoriamente usando RANDAO. Este nó é responsável pela construção e transmissão do próximo bloco a ser adicionado à blockchain Ethereum e pela atualização do estado global. O nó é composto por três partes: um cliente de execução, um cliente de consenso e um cliente validador. O cliente de execução empacota transações da mempool local em um "payload de execução" e executa-os localmente para gerar uma mudança de estado. Essas informações são passadas para o cliente de consenso em que a carga da execução é agrupada como parte de um "bloco de sinalização" que também contém informações sobre as recopensas, penalidades, cortes, atestações etc. que permitem que a rede entre em acordo sobre a sequência de blocks no topo da cadeia. A comunicação entre os clientes de execução e consenso é descrita em mais detalhes em [Conectando os clientes de consenso e de execução](/developers/docs/networking-layer/#connecting-clients).
-5. Outros nós recebem o novo bloco beacon na rede gossip na camada de consenso. Eles o passam para seu cliente de execução onde as transações são novamente executadas localmente para garantir que a proposta alteração de estado é válida. O cliente validador então atesta que o bloco é válido e é o bloco seguinte lógico em sua visão da cadeia (ou seja, ele constrói na cadeia com o maior peso de atestações, conforme definido nas [regras de escolha de fork (bifurcação)](/developers/docs/consensus-mechanisms/pos/#fork-choice)). O bloco é adicionado ao banco de dados local em cada nó que o atestar.
-6. A transação pode ser considerada "finalizada", se fizer parte de uma cadeia com um "vínculo majoritário" entre dois pontos de verificação. Os pontos de verificação ocorrem no início de cada época e existem para explicar o fato de que apenas um subconjunto de validadores ativos atestam em cada espaço, mas todos os validadores ativos atestam em cada época. Portanto, é apenas entre as épocas que um 'vínculo de supermaioria' pode ser demonstrado (isto é onde 66% do total de ETH envolvido na rede concorda em dois pontos de verificação).
-
-Mais detalhes sobre finalidade podem ser encontrados abaixo.
-
-## Finalidade {#finality}
-
-Uma transação tem "finalidade" em redes distribuídas quando faz parte de um bloco que não pode mudar, sem que uma grande quantidade de ETH seja queimada. Na prova de participação da Ethereum, isto é gerenciado usando blocos de pontos de verificação. O primeiro bloco em cada época é um ponto de verificação. Os validadores votam nos pares de pontos de verificação que eles consideram válidos. Se um par de pontos de verificação atrair votos que representem pelo menos dois terços do total de ETH envolvido, os checkpoints serão atualizados. O mais recente dos dois (alvo) torna-se "justificado". O primeiro dos dois já é justificado porque era o "alvo" na época anterior. Agora ele é atualizado para "finalizado".
-
-Para reverter um bloco finalizado, um invasor se comprometeria a perder pelo menos um terço do fornecimento total de ETH envolvido. A razão exata para isso é explicada nesta [postagem do blog da Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Uma vez que a finalidade exige a maioria de dois terços, um invasor poderia impedir que a rede chegue à finalidade votando com um terço da participação total. Existe um mecanismo de defesa contra isso: o [vazamento de inatividade](https://eth2book.info/bellatrix/part2/incentives/inactivity). Isso é ativado sempre que a cadeia falha em finalizar por mais de quatro épocas. O vazamento de inatividade afasta o ETH envolvido dos validadores que votam contra a maioria, permitindo que a maioria recupere uma maioria de dois terços e finalize a cadeia.
-
-## Segurança criptoeconômica {#crypto-economic-security}
-
-A execução de um validador é um compromisso. Espera-se que o validador mantenha hardware e conectividade suficientes para participar da validação e proposta de bloco. Em troca, o validador é pago em ETH (seu saldo colocado aumenta). Por outro lado, participar como validador também abre novos caminhos para os usuários atacarem a rede para ganho pessoal ou sabotagem. Para evitar isso, os validadores perdem as recompensas de ETH se não participarem quando chamados, e sua participação existente pode ser destruída ao se comportarem de forma desonesta. Dois comportamentos principais podem ser considerados desonestos: propor múltiplos blocos em um único espaço (equívoco) e apresentar atestações contraditórias.
-
-A quantidade de ETH reduzida depende de quantos validadores também estão sendo removidos ao mesmo tempo. Isso é conhecido como ["penalidade de correlação"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) e pode ser menor (em torno de ~1% de participação para um único validador reduzido por si só) ou pode resultar na destruição de 100% da participação do validador (evento de remoção em massa). É imposto no meio de um período de saída forçada que começa com uma penalidade imediata (até 1 ETH) no dia 1, a penalidade de correlação no dia 18 e, finalmente, a ejeção da rede no dia 36. Os validadores recebem todos os dias pequenas penalidades de atestações porque estão presentes na rede, mas não enviam votos. Tudo isso significa que um ataque coordenado seria muito caro para o invasor.
-
-## Escolha da bifurcação {#fork-choice}
-
-Quando a rede funciona de maneira otimizada e honesta, há apenas um novo bloco no início da cadeia, e todos os validadores o atestam. No entanto, é possível que os validadores tenham visões diferentes do cabeçalho da cadeia devido à latência de rede ou porque um proponente de bloco se equivocou. Portanto, os clientes de consenso exigem um algoritmo para decidir qual deles favorecer. O algoritmo usado na prova de participação do Ethereum se chama [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) e funciona identificando a bifurcação que tem o maior peso de atestações em seu histórico.
-
-## Prova de participação e segurança {#pos-and-security}
-
-A ameaça de um [ataque de 51%](https://www.investopedia.com/terms/1/51-attack.asp) ainda existe na prova de participação, como na prova de trabalho, mas ainda é mais arriscada para os invasores. Um invasor precisaria de 51% do ETH colocado em participação. Eles poderiam então usar suas próprias atestações para garantir que sua bifurcação preferida fosse aquela com o maior número de atestações acumuladas. O “peso” das atestações acumuladas é o que os clientes de consenso usam para determinar a cadeia correta, de modo que esse invasor conseguiria tornar sua bifurcação a opção padrão. No entanto, um ponto forte da prova de participação sobre a prova de trabalho é que a comunidade tem flexibilidade para montar um contra-ataque. Por exemplo, os validadores honestos podem decidir continuar construindo a cadeia minoritária e ignorar a bifurcação do invasor enquanto encorajam aplicativos, agências de câmbio e pools a fazerem o mesmo. Eles também podem decidir remover forçadamente o invasor da rede e destruir o ETH colocado em participação. Estas são defesas econômicas fortes contra um ataque de 51%.
-
-Além dos ataques de 51%, agentes maliciosos também podem tentar outros tipos de atividades prejudiciais, como:
-
-- ataques de longo prazo (embora o gadget de finalização neutralize esse vetor de ataque)
-- reorganizações de curto prazo (embora o reforço do proponente e os prazos de atestação mitiguem isso)
-- ataques de "bouncing" e "balancing" (também mitigados pelo reforço do proponente, e esses ataques, de qualquer forma, foram demonstrados apenas em condições de rede idealizadas)
-- ataques de avalanche (neutralizados pela regra dos algoritmos de escolha de fork de considerar apenas a mensagem mais recente)
-
-No geral, a prova de participação, conforme implementada no Ethereum, demonstrou ser economicamente mais segura do que a prova de trabalho.
-
-## Prós e contras {#pros-and-cons}
-
-| Prós | Contras |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
-| O staking facilita a participação dos indivíduos na segurança da rede, promovendo a descentralização. o nó validador pode ser executado em um laptop normal. Os pools de participação permitem que os usuários participem sem ter 32 ETH. | A prova de participação é mais recente e menos testada na prática em comparação com a prova de trabalho |
-| A participação é mais descentralizada, As economias de escala não se aplicam da mesma forma que para a mineração de PoW. | A prova de participação é mais complexa de implementar do que a prova de trabalho |
-| A prova de participação oferece maior segurança criptoeconômica do que a prova de trabalho | Os usuários precisam executar três softwares para participar da prova de participação do Ethereum. |
-| É necessário emitir uma quantidade menor de novos ETH para incentivar os participantes da rede | |
-
-### Comparação com a prova de trabalho {#comparison-to-proof-of-work}
-
-O Ethereum originalmente usava prova de trabalho, mas mudou para prova de participação em setembro de 2022. A PoS oferece várias vantagens sobre a PoW, como:
-
-- melhor eficiência energética – não há necessidade de usar muita energia em cálculos de prova de trabalho
-- barreiras de entrada mais baixas, requisitos de hardware reduzidos — não há necessidade de hardware de elite para ter a possibilidade de criar novos blocos
-- risco de centralização reduzido — a prova de participação deve levar a mais nós protegendo a rede
-- devido à baixa necessidade de energia, é necessário emitir menos ETH para incentivar a participação
-- as penalidades econômicas por mau comportamento tornam os custos de ataques 51% mais caros para um invasor em comparação com a prova de trabalho
-- a comunidade pode recorrer à recuperação social de uma cadeia honesta se um ataque de 51% tiver que superar as defesas criptoeconômicas.
-
-## Leitura adicional {#further-reading}
-
-- [Perguntas frequentes sobre prova de participação](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_
-- [O que é prova de participação](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_
-- [O que prova de participação é por que é importante](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_
-- [Por que a prova de participação (nov. de 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_
-- [Prova da participação: como aprendi a amar a pouca subjetividade](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_
-- [Ataque e defesa da prova de participação do Ethereum](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [A filosofia por trás do design da prova de participação](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_
-- [Vídeo: Vitalik buterin explica a prova de participação para Lex Fridman](https://www.youtube.com/watch?v=3yrqBG-7EVE)
-
-## Tópicos relacionados {#related-topics}
-
-- [Prova de trabalho](/developers/docs/consensus-mechanisms/pow/)
-- [Prova de autoridade](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
deleted file mode 100644
index dcb720a62fa..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Chaves na prova de participação do Ethereum
-description: Uma explicação das chaves usadas no mecanismo de consenso da prova de participação do Ethereum
-lang: pt-br
----
-
-O Ethereum protege os ativos do usuário usando a criptografia de chave pública-privada. A chave pública é usada como base para um endereço Ethereum — ou seja, é visível para o público em geral e utilizada como um identificador único. A chave privada (ou “secret”) deve sempre ser acessível apenas ao proprietário da conta. A chave privada é usada para “assinar” as transações e os dados para que a criptografia possa provar que o proprietário aprova alguma ação de uma chave privada específica.
-
-As chaves do Ethereum são geradas usando a [criptografia de curva elíptica](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography).
-
-No entanto, quando o Ethereum mudou de [prova de trabalho](/developers/docs/consensus-mechanisms/pow) para [prova de participação](/developers/docs/consensus-mechanisms/pos), um novo tipo de chave foi adicionado ao Ethereum. As chaves originais ainda funcionam exatamente como antes — não houve alterações nas chaves baseadas em curva elíptica que protegem as contas. No entanto, os usuários precisavam de um novo tipo de chave para participar da prova de participação colocando ETH em stake e executando validadores. Essa necessidade surgiu dos desafios de escalabilidade associados a muitas mensagens trocadas entre inúmeros validadores que exigiam um método criptográfico que pudesse ser agregado facilmente para reduzir a quantidade de comunicação necessária para a rede chegar a consenso.
-
-Este novo tipo de chave usa o esquema de assinatura [**Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). O BLS permite uma agregação de assinaturas muito eficiente, mas também permite a engenharia reversa de chaves agregadas de validadores individuais e é ideal para gerenciar ações entre validadores.
-
-## Os dois tipos de chaves de validação {#two-types-of-keys}
-
-Antes da mudança para prova de participação, os usuários do Ethereum tinham uma única chave privada baseada em curva elíptica para acessar seus fundos. Com a introdução da prova de participação, os usuários que quisessem ser participantes individuais também precisavam de uma **chave de validação** e uma **chave de saque**.
-
-### A chave de validação {#validator-key}
-
-A chave de assinatura de validação consiste em dois elementos:
-
-- Chave de validação **privada**
-- Chave de validação **pública**
-
-O objetivo da chave de validação privada é assinar operações em cadeia, como propostas de bloco e atestações. Por causa disso, essas chaves devem estar guardadas numa carteira quente.
-
-Essa flexibilidade tem a vantagem de mover rapidamente as chaves de assinatura do validador de um dispositivo para outro, no entanto, se elas se perderem ou forem roubadas, um ladrão poderá **agir maliciosamente** de algumas maneiras:
-
-- Remover o validador por:
- - Ser um proponente e assinar dois blocos diferentes da beacon para o mesmo slot
- - Ser um atestador e assinar uma atestação que "envolve" outra
- - Ser um atestador e assinar duas atestações diferentes com o mesmo destino
-- Forçar uma saída voluntária, que interrompe o validador de fazer stake, e conceder acesso ao seu saldo de ETH para o proprietário da chave de saque
-
-A **chave pública do validador** é incluída nos dados de transação quando um usuário deposita ETH no contrato de depósito de stake. Isso é conhecido como _dados de depósito_ e permite que o Ethereum identifique o validador.
-
-### Credenciais de saque {#withdrawal-credentials}
-
-Todo validador tem uma propriedade conhecida como _credenciais de saque_. Esse campo de 32 bytes começa com um `0x00`, representando credenciais de saque do BLS, ou um `0x01`, representando credenciais que apontam para um endereço de execução.
-
-Os validadores com chaves BLS `0x00` devem atualizar estas credenciais para apontar para um endereço de execução e ativar pagamentos de saldo em excesso ou saque total de participação (stake). Isso pode ser feito fornecendo um endereço de execução nos dados de depósito durante a geração inicial da chave, _OU_ usando a chave de saque posteriormente para assinar e transmitir uma mensagem `BLSToExecutionChange`.
-
-### Chave de saque {#withdrawal-key}
-
-A chave de saque será necessária para atualizar as credenciais de saque para apontar para um endereço de execução, se não for definido durante o depósito inicial. Isso permitirá que os pagamentos do saldo em excesso comecem a ser processados e também permitirá que os usuários saquem totalmente seus ETH em participação (stake).
-
-Assim como as chaves de validador, as chaves de saque também consistem em dois componentes:
-
-- Chave de saque **privada**
-- Chave de saque **pública**
-
-Perder esta chave antes de atualizar as credenciais de saque para o tipo `0x01` significa perder o acesso ao saldo do validador. O validador pode ainda assinar atestações e bloqueios, pois essas ações exigem a chave privada do validador, no entanto, há pouco ou nenhum incentivo se as chaves de saque forem perdidas.
-
-Separar as chaves de validação das chaves da conta Ethereum permite que vários validadores sejam executados por um único usuário.
-
-
-
-## Obtendo chaves de uma frase semente {#deriving-keys-from-seed}
-
-Se cada 32 ETH em stake precisavam de um novo conjunto de 2 chaves completamente independentes, o gerenciamento de chaves se tornaria rapidamente complicado, especialmente para usuários que executam vários validadores. Em vez disso, várias chaves de validação podem ser obtidas de um único segredo comum e armazenar esse segredo único permite acesso a várias chaves de validação.
-
-[Mnemônicos](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) e caminhos são recursos importantes que os usuários geralmente encontram ao [acessar](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) suas carteiras. Mnemônico é uma sequência de palavras que atuam como uma semente inicial para uma chave privada. Quando combinado com dados adicionais, o mnemônico gera um hash conhecido como “chave mestra”. Isso pode ser considerado como a raiz de uma árvore. Os galhos dessa raiz podem ser obtidos usando um caminho hierárquico de forma que os nós filhos possam existir como combinações de hash do nó pai e de seus índices na árvore. Leia sobre as normas [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) e [ BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) para geração de chaves baseadas em mnemônicos.
-
-Esses caminhos possuem a seguinte estrutura, que será familiar para usuários que já interagiram com carteiras de hardware:
-
-```
-m/44'/60'/0'/0`
-```
-
-As barras nesse caminho separam os componentes da chave privada da seguinte forma:
-
-```
-master_key / purpose / coin_type / account / change / address_index
-```
-
-Essa lógica permite aos usuários anexar o maior número possível de validadores a uma única **frase mnemônica**, pois a raiz da árvore pode ser comum e a diferenciação pode ocorrer nas ramificações. O usuário pode **obter qualquer número de chaves** da frase mnemônica.
-
-```
- [m / 0]
- /
- /
-[m] - [m / 1]
- \
- \
- [m / 2]
-```
-
-Cada galho é separado por uma `/`, então `m/2` significa iniciar com a chave mestra e seguir a ramificação 2. No esquema abaixo, uma única frase mnemônica é usada para armazenar três chaves de saque, cada uma com dois validadores associados.
-
-
-
-## Leitura adicional {#further-reading}
-
-- [Postagem no blog da Ethereum Foundation por Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/)
-- [Geração de chave EIP-2333 BLS12-381](https://eips.ethereum.org/EIPS/eip-2333)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
deleted file mode 100644
index 5f774fa10ab..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Prova de participação versus Prova de trabalho
-description: Uma comparação entre o mecanismo de consenso baseado em prova de participação e prova de trabalho do Ethereum
-lang: pt-br
----
-
-Quando o Ethereum foi lançado, a prova de participação ainda precisava de muita pesquisa e desenvolvimento antes que pudesse ser confiável para proteger o Ethereum. A prova de trabalho era um mecanismo mais simples que já havia sido comprovado pelo Bitcoin, o que significa que os principais desenvolvedores poderiam implementá-lo imediatamente para lançar o Ethereum. Levou mais oito anos para desenvolver a prova de participação até o ponto em que poderia ser implementada.
-
-Esta página explica a lógica por trás da mudança do Ethereum para prova de participação de prova de trabalho e as compensações envolvidas.
-
-## Segurança {#security}
-
-Os pesquisadores da Ethereum consideram a prova de participação mais segura do que a prova de trabalho. No entanto, ele só foi implementado recentemente para a rede principal real do Ethereum e é menos comprovado pelo tempo do que a prova de trabalho. As seções a seguir discutem os prós e os contras do modelo de segurança da prova de participação, em comparação com a prova de trabalho.
-
-### Custo de ataque {#cost-to-attack}
-
-Na prova de participação, os validadores são obrigados a depositar ("participação") pelo menos 32 ETH em um contrato inteligente. O Ethereum pode destruir o ether em participação para punir os validadores que se comportam mal. Para chegar a um consenso, pelo menos 66% do total de ether em participação deve votar a favor de um determinado conjunto de blocos. Os blocos votados por >=66% da participação tornam-se "finalizados", o que significa que não podem ser removidos ou reorganizados.
-
-Atacar a rede pode significar impedir a cadeia de finalizar ou garantir uma certa organização de blocos na cadeia canônica, que de alguma forma beneficia um atacante. Isso exige o atacante desviar o caminho do consenso honesto, seja acumulando uma grande quantidade de ether, seja votando diretamente com ele ou enganando os validadores honestos para que votem de uma maneira particular. Ataques sofisticados e de baixa probabilidade que enganam validadores honestos à parte, o custo para atacar o Ethereum é o custo da participação que um invasor precisa acumular para influenciar o consenso a seu favor.
-
-O menor custo de ataque é >33% da participação total. Um atacante com >33% da participação total pode causar um atraso de finalização simplesmente ficando offline. Este é um problema relativamente menor para a rede, pois existe um mecanismo conhecido como "vazamento de inatividade" que vaza a participação dos validadores offline até que a maioria online represente 66% de participação e possa finalizar a cadeia novamente. Também é teoricamente possível para um atacante causar dupla finalidade com um pouco mais de 33% da participação total, criando dois blocos em vez de um quando ele for solicitado para ser um produtor de bloco e, em seguida, votar duas vezes com todos os seus validadores. Cada fork (bifurcação) requer apenas 50% dos validadores honestos restantes para ver cada bloco primeiro, portanto, se eles conseguirem gerenciar o tempo de suas mensagens da maneira certa, eles poderão finalizar ambos os forks. Isso tem uma baixa probabilidade de sucesso, mas se um atacante for capaz de causar dupla finalidade, a comunidade Ethereum teria que decidir seguir um fork, nesse caso, os validadores do atacante seriam necessariamente cortados no outro fork.
-
-Com >33% da participação total, um atacante tem a chance de ter um efeito menor (atraso de finalização) ou mais grave (finalidade dupla) na rede Ethereum. Com mais de 14.000.000 ETH em participação na rede e um preço representativo de US$ 1.000/ETH, o custo mínimo para montar esses ataques é `1.000 x 14.000.000 x 0,33 = US$ 4.620.000.000`. O atacante perderia esse dinheiro cortando e seria expulso da rede. Para atacar novamente, eles teriam que acumular >33% da participação (novamente) e queimá-la (novamente). Cada tentativa de ataque à rede custaria >$ 4,6 bilhões (US$ 1.000/ETH e 14 milhões de ETH em participação). O atacante também é ejetado da rede quando ele é cortado, e precisa entrar em uma fila de ativação para entrar novamente. Isso significa que a taxa de um ataque repetido é limitado não apenas à taxa que o atacante pode acumular >33% da participação total, mas também ao tempo que leva para incluir todos os seus validadores à rede. Cada vez que o atacante ataca, eles ficam muito mais pobres e o resto da comunidade fica mais rico, graças ao choque da oferta resultante.
-
-Outros ataques, como ataques de 51% ou reversão de finalidade com 66% da participação total, exigem substancialmente mais ETH e são muito mais caros para o atacante.
-
-Compare isso com a prova de trabalho. O custo de lançar um ataque à prova de trabalho Ethereum era o custo de possuir consistentemente >50% da taxa total de hash da rede. Isso somado aos custos de hardware e funcionamento do poder de computação suficiente, para superar outros mineradores a computar soluções de prova de trabalho de forma consistente. O Ethereum foi minerado principalmente usando GPUs em vez de ASICs, o que manteve o custo baixo (embora o Ethereum tivesse continuado na prova de trabalho, a mineração ASIC poderia ter se tornado mais popular). Um adversário teria que adquirir muito hardware e pagar pela eletricidade para executá-lo para atacar uma rede Ethereum de prova de trabalho, mas o custo total seria menor que o custo necessário para acumular ETH suficiente para lançar um ataque. Um ataque de 51% é ~[20 vezes mais barato](https://youtu.be/1m12zgJ42dI?t=1562) na prova de trabalho do que na prova de participação. Se o ataque for detectado e a cadeia realizasse o fork para remover suas alterações, o atacante poderia usar repetidamente o mesmo hardware para atacar o novo fork.
-
-### Complexidade {#complexity}
-
-A prova de participação é muito mais complexa do que a prova de trabalho. Isso poderia ser um ponto a favor da prova de trabalho, pois é mais difícil de introduzir bugs ou efeitos não intencionais em protocolos mais simples acidentalmente. No entanto, a complexidade tem sido domada por anos de pesquisa e desenvolvimento, simulações e implementações na rede de teste. O protocolo de prova de participação tem sido implementado independentemente por cinco equipes separadas (em cada uma das camadas de execução e consenso) em cinco linguagens de programação, fornecendo resiliência contra bugs de cliente.
-
-Para desenvolver e testar com segurança a lógica de consenso da prova de participação, a Beacon Chain foi lançada dois anos antes da prova de participação ser implementada na rede principal do Ethereum. A Beacon Chain atuou como um ambiente para testes da prova de participação, já que era uma blockchain ativa implementando a lógica de consenso da prova de participação, mas sem tocar em transações reais do Ethereum - apenas efetivamente chegando a um consenso sobre si mesmo. Uma vez que isso tem sido estável e livre de bugs por tempo suficiente, a Beacon Chain foi "fundida" com a rede principal do Ethereum. Tudo isso contribuiu para domar a complexidade da prova de participação a ponto que o risco de consequências não intencionais ou bugs de cliente serem muito baixos.
-
-### Superfície de Ataque {#attack-surface}
-
-A prova de participação é mais complexa do que a prova de trabalho, o que significa que há mais vetores de ataque em potencial a tratar. Em vez de uma rede ponto-a-ponto conectando clientes, há duas, cada uma implementando um protocolo separado. Ter um validador específico pré-selecionado para propor um bloco em cada slot, cria o potencial de negação de serviço quando grandes quantidades de tráfego de rede colocam esse validador específico off-line.
-
-Também há maneiras pelos quais atacantes podem programar cuidadosamente a liberação de seus blocos ou atestações, para que sejam recebidos por uma certa proporção da rede honesta, influenciando-os a votar em certas maneiras. Por fim, um atacante pode simplesmente acumular ETH suficiente para participar e dominar o mecanismo de consenso. Cada um desses [vetores de ataque tem defesas associadas](/developers/docs/consensus-mechanisms/pos/attack-and-defense), mas eles não existem para serem defendidos sob a prova de trabalho.
-
-## Descentralização {#decentralization}
-
-A prova de participação é mais descentralizada do que a prova de trabalho, por isso que as corridas armamentistas de hardware para mineração tendem a prejudicar indivíduos e pequenas organizações. Enquanto qualquer pessoa possa tecnicamente começar a minerar com hardware modesto, sua probabilidade de receber qualquer recompensa é muito pequena comparada com as operações de mineração institucionais. Com a prova de participação, o custo de staking (participação) e a porcentagem de retorno dessa participação são os mesmos para todos. Atualmente, custa 32 ETH para executar um validador.
-
-Por outro lado, a invenção de derivativos de staking líquido levou a preocupações de centralização, porque alguns grandes provedores gerenciam grandes quantidades de ETH em participação. Isso é problemático e precisa ser corrigido o mais rápido possível, mas também tem mais nuances do que parece. Provedores de staking centralizados não têm necessariamente controle centralizado de validadores - muitas vezes é apenas uma maneira de criar um pool central de ETH que muitos operadores de nós independentes podem participar sem que cada participante exija seus 32 ETH próprios.
-
-A melhor opção para o Ethereum é que os validadores sejam executados localmente em computadores domésticos, maximizando a descentralização. É por isso que o Ethereum resiste a mudanças que aumentam os requisitos de hardware para executar um nó/validador.
-
-## Sustentabilidade {#sustainability}
-
-A prova de participação é uma forma barata de proteger a blockchain. Na prova de trabalho, os mineradores competem pelo direito de minerar um bloco. Os mineradores são mais bem-sucedidos quando podem realizar cálculos mais rápidos, incentivando o investimento em hardware e o consumo de energia. Isso foi observado no Ethereum antes de mudar para a prova de participação. Pouco antes da transição para prova de participação, o Ethereum consumia aproximadamente 78 TWh/ano - tanto quanto um pequeno país. No entanto, a mudança para a prova de participação reduziu esse gasto de energia em ~99,98%. A prova de participação tornou o Ethereum uma plataforma de baixo carbono e eficiência energética.
-
-[Saiba mais sobre o consumo energético do Ethereum](/energy-consumption)
-
-## Emissão {#issuance}
-
-A prova de participação do Ethereum pode pagar por sua segurança emitindo muito menos moedas do que a prova de trabalho do Ethereum, porque os validadores não precisam pagar altos custos de eletricidade. Como resultado, o ETH pode reduzir sua inflação ou até mesmo se tornar deflacionário quando grandes quantidades de ETH são queimadas. Níveis mais baixos de inflação significam que a segurança do Ethereum é mais barata do que era na prova de trabalho.
-
-## Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner}
-
-Assista Justin Drake explicando os benefícios da prova de participação em relação à prova de trabalho:
-
-
-
-## Leitura adicional {#further-reading}
-
-- [Filosofia de design da prova de participação de Vitalik](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-- [Perguntas frequentes sobre a prova de participação de Vitalik](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-- [Vídeo "Simplesmente Explicado" sobre pos vs pow](https://www.youtube.com/watch?v=M3EFi_POhps)
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
deleted file mode 100644
index 86968ab5739..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: Recompensas e penalidades na prova de participação
-description: Saiba mais sobre os incentivos no protocolo da prova de participação Ethereum.
-lang: pt-br
----
-
-Ethereum é protegido usando sua criptomoeda nativa, ether (ETH). Os operadores de nós que desejam participar da validação de blocos e da identificação do cabeçalho da cadeia depositam ether no [contrato de depósito](/staking/deposit-contract/) do Ethereum. Eles são então pagos em ether para executar um software validador que verifica a validade de novos blocos recebidos pela rede ponto a ponto e aplicam o algoritmo de escolha de bifurcação para identificar o cabeçalho da cadeia.
-
-Existem duas funções principais para um validador: 1) verificar novos blocos e “atestar” se eles são válidos para eles, 2) propor novos blocos quando selecionados aleatoriamente a partir do pool total de validadores. Se o validador falhar em realizar qualquer uma dessas tarefas quando solicitado, eles perdem um pagamento em ether. Às vezes, os validadores também são encarregados de agregar assinaturas e participar dos comitês de sincronização.
-
-Existem também algumas ações que são muito difíceis de fazer acidentalmente e são indício de alguma intenção maliciosa, como propor múltiplos blocos para o mesmo slot ou atestar vários blocos para o mesmo slot. Esses são comportamentos “passíveis de remoção” fazem com que uma certa quantidade de ether (até 1 ETH) do validador seja queimada antes de ele ser removido da rede, o que leva 36 dias. O ether do validador removido drena lentamente ao longo do período de saída, mas no dia 18 eles recebem uma “penalidade de correlação” que é maior quando mais validadores são removidos ao mesmo tempo. Portanto, a estrutura de incentivos da Beacon Chain paga pela honestidade e pune os infrat
-
-Todas as recompensas e penalidades são aplicadas uma vez por época.
-
-Leia para obter mais detalhes...
-
-## Recompensas e penalidades {#rewards}
-
-### Recompensas {#rewards}
-
-Os validadores recebem recompensas quando votam de modo consistente com a maioria dos outros validadores, quando propõem blocos e quando participam de comitês de sincronização. O valor das recompensas em cada época são calculadas a partir de um `base_reward`. Essa é a unidade base a partir da qual outras recompensas são calculadas. O `base_reward` representa a recompensa média recebida por um validador em condições ideais por época. Isso é calculado a partir do saldo efetivo do validador e do número total de validadores ativos da seguinte forma:
-
-```
-base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))
-```
-
-quando `base_reward_factor` é 64, `base_rewards_per_epoch` é 4 e `sum(active balance)` é o total de ether colocado por todos os validadores ativos.
-
-Isso significa que a recompensa base é proporcional ao saldo efetivo do validador e inversamente proporcional ao número de validadores na rede. Quanto mais validadores, maior a emissão geral (como `sqrt(N)`, mas menor a `base_reward` por validador (como `1/sqrt(N)`). Esses fatores influenciam o APR para um nó de staking. Leia a justificativa para isso nas [notas de Vitalik](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards).
-
-A recompensa total é então calculada como a soma de cinco componentes, sendo que cada um tem uma ponderação que determina quanto cada componente adiciona à recompensa total. Os componentes são:
-
-```
-1. voto de origem: o validador fez um voto oportuno para o ponto de verificação de origem correta
-2. voto de destino: o validador fez um voto oportuno para o ponto de verificação de destino correto
-3. voto de cabeçalho: o validador fez um voto oportuno para o bloco de cabeçalho correto
-4. recompensa do comitê de sincronização: o validador participou de um comitê de sincronização
-5. recompensa do proponente: o validador propôs um bloco no slot correto
-```
-
-As ponderações para cada componente são as seguintes:
-
-```
-TIMELY_SOURCE_WEIGHT uint64(14)
-TIMELY_TARGET_WEIGHT uint64(26)
-TIMELY_HEAD_WEIGHT uint64(14)
-SYNC_REWARD_WEIGHT uint64(2)
-PROPOSER_WEIGHT uint64(8)
-```
-
-Esses pesos somam 64. A recompensa é calculada como a soma dos pesos aplicáveis dividido por 64. Um validador que tenha feito votos oportunos de origem, destino e cabeçalho propôs um bloco e participou de um comitê de sincronização poderá receber `64/64 * base_reward == base_reward`. No entanto, um validador geralmente não é um proponente de bloco, então sua recompensa máxima é `64-8 /64 * base_reward == 7/8 * base_reward`. Os validadores que não são proponentes de bloco nem estão em um comitê de sincronização podem receber `64-8-2 / 64 * base_reward == 6,75/8 * base_reward`.
-
-Uma recompensa adicional é incluída para incentivar atestações rápidas. Esse é o `inclusion_delay_reward`. Isso tem um valor igual a `base_reward` multiplicado por `1/delay`, no qual o `delay` é o número de slots que separam a proposta do bloco e o atestado. Por exemplo, se o atestado for enviado dentro de um slot da proposta do bloco, o atestante receberá `base_reward * 1/1 == base_reward`. Se o atestado chegar no próximo slot, o atestador receberá `base_reward * 1/2` e assim por diante.
-
-Os proponentes de bloco recebem `8 / 64 * base_reward` para **cada atestado válido** incluída no bloco, logo, o valor real da recompensa varia com o número de validadores atestantes. Os proponentes de bloco também podem aumentar sua recompensa incluindo evidências de mau comportamento de outros validadores em seu bloco proposto. Essas recompensas são as “cenouras” que encorajam a honestidade do validador. Um proponente de bloco que inclui uma punição será recompensado com o `slashed_validators_effective_balance / 512`.
-
-### Penalidades {#penalties}
-
-Até agora, temos considerado validadores perfeitamente bem comportados, mas o que acontece quando os validadores não fazem votos de cabeçalho, origem e destino em tempo hábil ou o fazem lentamente?
-
-As penalidades por perda de votos de destino e de origem são iguais às recompensas que o atestador teria recebido se as tivesse enviado. Isso significa que, em vez de ter a recompensa adicionada ao seu saldo, eles têm um valor igual retirado do seu saldo. Não há penalidade por perder o voto de cabeçalho (ou seja, os votos de cabeçalhos são apenas recompensados, nunca penalizados). Não há penalidade associada ao `inclusion_delay` – a recompensa simplesmente não será adicionada ao saldo do validador. Também não existe nenhuma penalidade por falhar em propor um bloco.
-
-Leia mais sobre recompensas e penalidades nas [especificações de consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Recompensas e penalidades foram ajustadas na atualização Bellatrix – assista a Danny Ryan e Vitalik falando sobre isso neste vídeo: [Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ).
-
-## Remoção {#slashing}
-
-Remoção é uma ação mais severa que resulta na remoção forçada de um validador da rede e na perda associada de seu ether em participação. Há três maneiras que um validador pode ser removido: pela proposta ou atestação desonestas de blocos:
-
-- Ao propor e assinar dois blocos diferentes para o mesmo espaço
-- Ao confirmar um bloco “em volta” de outro (mudando efetivamente o histórico)
-- Por “votação dupla”, atestando dois candidatos para o mesmo bloco
-
-Se essas ações forem detectadas, o validador é removido. Isso significa que 1/32 do seu ether em risco (até um máximo de 1 ether) é imediatamente queimado, então um período de remoção de 36 dias é iniciado. Durante esse período de remoção, a participação dos validadores vai diminuir gradualmente. No meio do período (dia 18) é aplicada uma penalidade adicional cuja magnitude é escalada com o total de ether em stake de todos os validadores cortados nos 36 dias anteriores ao evento de corte. Isso significa que quanto mais validadores são removidos, a magnitude da remoção aumenta. A remoção máxima é o saldo total efetivo de todos os validadores removidos (ou seja, se houver muitos validadores sendo removidos, eles poderiam perder toda a sua participação). Por outro lado, um evento único e isolado de remoção apenas queima uma pequena parte da participação do validador. Esta penalidade de ponto médio que escala com o número de validadores removidos é chamada de “penalidade de correlação”.
-
-## Vazamento de inatividade {#inactivity-leak}
-
-Se a camada de consenso tiver passado mais de quatro épocas sem finalizar, um protocolo de emergência chamado "vazamento de inatividade" é ativado. O objetivo final do vazamento de inatividade é criar as condições necessárias para a cadeia recuperar a finalidade. Como explicado acima, a finalidade requer uma maioria 2/3 do ether total em participação para concordar sobre os pontos de verificação de origem e destino. Se os validadores representando mais de 1/3 do total dos validadores ficarem offline ou falharem em enviar os atestados corretos, então não é possível que uma supermaioria de 2/3 finalize os pontos de verificação. O vazamento de inatividade deixa o stake pertencente aos validadores inativos esvaziar gradualmente até que eles controlem menos de 1/3 do stake total, permitindo que os validadores ativos restantes finalizem a cadeia. Por maior que seja o pool de validadores inativos, os validadores ativos restantes acabarão controlando >2/3 do stake. A perda de stake é um forte incentivo para os validadores inativos reativarem o mais rápido possível! Um cenário de vazamento de inatividade foi encontrado na rede de testes Medalla quando < 66% dos validadores ativos conseguiram chegar a um consenso sobre a cabeça atual da blockchain. O vazamento de inatividade foi ativado e a finalidade acabou sendo recuperada!
-
-O design de recompensa, penalidade e corte do mecanismo de consenso incentiva os validadores individuais a se comportarem corretamente. No entanto, dessas escolhas de design surge um sistema que incentiva fortemente a distribuição igualitária de validadores entre vários clientes e deve desincentivar fortemente o domínio de cliente único.
-
-## Leitura adicional {#further-reading}
-
-- [Atualizando o Ethereum: a camada de incentivo](https://eth2book.info/altair/part2/incentives)
-- [Incentivos no protocolo Casper híbrido do Ethereum](https://arxiv.org/pdf/1903.04205.pdf)
-- [Especificação anotada de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
-- [Dicas para evitar remoções no Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
-
-_Fontes_
-
-- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_
diff --git "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" "b/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
deleted file mode 100644
index 38810b0feed..00000000000
--- "a/public/content/translations/pt-br/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Subjetividade fraca
-description: Uma explicação de subjetividade fraca e o seu papel na prova de participação do Ethereum.
-lang: pt-br
----
-
-Subjetividade em blockchains refere-se à dependência de informações sociais para concordar com o estado atual. Pode haver vários forks válidos que são escolhidos de acordo com as informações coletadas de outros pares na rede. A questão é a objetividade a que se refere às cadeias onde existe apenas uma cadeia válida possível e que todos os nós necessariamente concordarão aplicando as suas regras codificadas. Há também um terceiro estado, conhecido como subjetivo fraco. Isso se refere a uma cadeia que pode progredir objetivamente após alguma semente inicial de informação ser recuperada socialmente.
-
-## Pré-Requisitos {#prerequisites}
-
-Para entender esta página é necessário primeiro entender os fundamentos de [prova de participação](/developers/docs/consensus-mechanisms/pos/).
-
-## Quais são os problemas que a subjetividade fraca resolve? {#problems-ws-solves}
-
-A subjetividade é inerente às blockchains de prova de participação porque a seleção da cadeia correta de vários forks é feita contando votos históricos. Isso expõe a blockchain a vários vetores de ataque, incluindo ataques de longo alcance em que nós que participaram muito cedo na cadeia mantêm um fork alternativo que eles liberam muito mais tarde para sua própria vantagem. Como alternativa, se 33% dos validadores retirarem seus stakes mas continuarem a atestar e produzir blocos, eles poderão gerar um fork alternativo que entra em conflito com a cadeia canônica. Novos nós ou nós que ficaram offline por um longo tempo podem não estar cientes de que estes validadores atacantes retiraram seus fundos, para que os atacantes possam enganá-los para que sigam uma cadeia incorreta. O Ethereum pode resolver estes vetores de ataque impondo restrições que diminuem ao mínimo los aspectos subjetivos do mecanismo, e com isso as suposições de confiança.
-
-## Pontos de verificação de subjetividade fraca {#ws-checkpoints}
-
-A subjetividade fraca é implementada na prova de participação do Ethereum usando "pontos de verificação de subjetividade fraca". Estes são raízes de estado que todos os nós da rede concordam em integrar à cadeia canônica. Eles servem o mesmo propósito de "verdade universal" para blocos de início, exceto que eles não se colocam na posição de início na blockchain. O algoritmo de escolha de fork confia em que o estado definido naquele ponto de verificação é correto e que ele verifica a cadeia de forma independente e objetiva a partir desse ponto. Os pontos de verificação atuam como "limites de reversão" porque os blocos localizados antes dos pontos de verificação de subjetividade fraca não podem ser alterados. Isto mina os ataques de longo alcance simplesmente definindo forks de longo alcance como inválidos como parte do modelo do mecanismo. Garantir que os pontos de verificação de subjetividade fraca sejam separados por uma distância menor que o período de retirada do validador garante que um validador que faz o fork da cadeia tenha removido pelo menos algum valor limite antes que eles possam retirar seu stake e que novos participantes não possam ser enganados em forks incorretos por validadores cuja participação foi retirada.
-
-## Diferença entre pontos de verificação de subjetividade fraca e blocos finalizados {#difference-between-ws-and-finalized-blocks}
-
-Blocos finalizados e pontos de verificação de subjetividade fraca são tratados de forma diferente pelos nós de Ethereum. Se um nó percebe que há de dois blocos finalizados concorrentes, então está dividida entre os dois – não tem como identificar automaticamente qual é o fork canônico. Isto indica uma falha de consenso. Por outro lado, um nó simplesmente rejeita qualquer bloco que esteja em conflito com seu ponto de verificação subjetividade fraca. Do ponto de vista do nó, o ponto de verificação de subjetividade fraca representa uma verdade absoluta que não pode ser minada por novos conhecimentos de seus pares.
-
-## Quão fraco é fraco? {#how-weak-is-weak}
-
-O aspecto subjetivo da prova de participação do Ethereum é o requisito de um estado recente (ponto de verificação de subjetividade fraca) a partir de uma fonte confiável com a qual se sincronizar. O risco de obter um ponto de verificação de subjetividade fraca incorreto é muito baixo, porque eles podem ser verificados contra várias fontes públicas independentes, como exploradores de blocos ou vários nós. No entanto, sempre há algum grau de confiança necessário para executar qualquer aplicativo de software, por exemplo, confiando que os desenvolvedores de software produziram software honesto.
-
-Um ponto de verificação de subjetividade fraca pode até vir como parte do software cliente. Sem dúvida, um atacante pode corromper o checkpoint no software e pode simplesmente corromper o próprio software. Não existe nenhum caminho criptoeconômico em torno deste problema, mas o impacto dos desenvolvedores não confiáveis é minimizado no Ethereum, tendo várias equipes de clientes independentes, cada uma desenvolvendo software equivalente em diferentes línguagens, tudo com um interesse em manter uma cadeia honesta. Exploradores de blocos também podem fornecer pontos de verificação de subjetividade fraca ou uma maneira de fazer referência cruzada de pontos de verificação obtidos de outros lugares em relação a uma fonte adicional.
-
-Finalmente, os pontos de verificação podem ser solicitados a partir de outros nós; talvez outro usuário Ethereum que execute um full node possa fornecer um ponto de verificação que os validadores possam verificar em relação ao dados de um explorador de bloco. Em geral, confiar no provedor de um ponto de verificação de subjetividade fraca pode ser considerado tão problemático quanto confiar nos desenvolvedores do cliente. A confiança geral que é necessária é baixa. É importante notar que essas considerações só se tornam importantes no caso muito improvável em que a maioria dos validadores conspire para produzir um fork alternativo da blockchain. Em qualquer outra circunstância, existe apenas uma cadeia Ethereum para se escolher.
-
-## Leitura adicional {#further-reading}
-
-- [Subjetividade fraca em Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
-- [Vitalik: Como eu aprendi a amar a subjetividade fraca](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
-- [Subjetividade fraca (documentos Teku)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/)
-- [Guia de subjetividade fraca: fase-0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md)
-- [Análise de subjetividade fraca no Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf)
diff --git "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" "b/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
deleted file mode 100644
index fcd9ff2e07c..00000000000
--- "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Prova de autoridade (PoA)
-description: Uma explicação do protocolo de consenso de prova de autoridade e seu papel no ecossistema.
-lang: pt-br
----
-
-**Prova de autoridade (PoA)** é um algoritmo de consenso baseado em reputação que é uma versão modificada de [prova de participação](/developers/docs/consensus-mechanisms/pos/). É usado principalmente por cadeias privadas, redes de teste e redes de desenvolvimento local. PoA é um algoritmo de consenso baseado em reputação que exige confiança em um conjunto de signatários autorizados para produzir blocos, e não em um mecanismo baseado em participação na PoS.
-
-## Pré-requisitos {#prerequisites}
-
-Para entender melhor esta página, recomendamos que você leia primeiro sobre [transações](/developers/docs/transactions/), [blocos](/developers/docs/blocks/) e [mecanismo de consenso](/developers/docs/consensus-mechanisms/).
-
-## O que é Prova de autoridade (PoA)? {#what-is-poa}
-
-Prova de autoridade é uma versão modificada de **[prova de participação](/developers/docs/consensus-mechanisms/pos/) (PoS)**, que é um algoritmo de consenso baseado em participação na PoS. O termo foi introduzido pela primeira vez em 2017 por Gavin Wood, e esse algoritmo de consenso tem sido usado principalmente por cadeias privadas, redes de teste e redes de desenvolvimento local, pois elimina a necessidade de recursos de alta qualidade, como a PoW, e supera os problemas de dimensionamento da PoS ao ter um pequeno subconjunto de nós armazenando a blockchain e produzindo blocos.
-
-A Prova de autoridade requer a confiança em um conjunto de signatários autorizados definidos no [bloco gênesis](/glossary/#genesis-block). Na maioria das implementações atuais, todos os signatários autorizados mantêm o mesmo poder e privilégios ao determinar o consenso da cadeia. A ideia por trás do staking de reputação é que cada validador autorizado seja conhecido por todos por meio de processos como "conheça seu cliente" (KYC), ou por ter uma organização conhecida como a única validadora. Dessa forma, se um validador fizer algo errado, sua identidade será conhecida.
-
-Existem várias implementações da PoA, mas a implementação padrão do Ethereum é **clique**, que implementa [EIP-225](https://eips.ethereum.org/EIPS/eip-225). Clique é um padrão fácil de implementar e de fácil utilização para desenvolvedores, suportando todos os tipos de sincronização de clientes. Outras implementações incluem [IBFT- 2.0](https://besu.hyperledger.org/stable/private-networks/concepts/poa) e [Aura](https://openethereum.github.io/Chain-specification).
-
-## Como funciona {#how-it-works}
-
-Na PoA, um conjunto de signatários autorizados é selecionado para criar novos blocos. Os signatários são selecionados com base em sua reputação e são os únicos autorizados a criar novos blocos. Os signatários são selecionados em turnos alternados, e cada signatário pode criar um bloco em um período de tempo específico. O tempo de criação do bloco é fixo, e os signatários são obrigados a criar um bloco dentro desse prazo.
-
-A reputação neste contexto não é algo quantificado, e sim a reputação de corporações conhecidas como Microsoft e Google. Portanto, a maneira de selecionar os signatários confiáveis não é algorítmica, e sim o ato humano normal de confiança, em que uma entidade, por exemplo, a Microsoft, cria uma rede privada de PoA entre centenas ou milhares de startups e o papel propriamente dito como o único signatário confiável com a possibilidade de adicionar outros signatários conhecidos como o Google no futuro. Assim sendo, sem dúvida, as startups confiariam que a Microsoft agiria de maneira honesta o tempo todo e usaria a rede. Isso resolve a necessidade de participar de diferentes redes pequenas/privadas que foram construídas para diferentes propósitos para mantê-las descentralizadas e funcionando, juntamente com a necessidade de mineradores, o que consome muita energia e recursos. Algumas redes privadas usam o padrão PoA, como a VeChain, e algumas o modificam, como a Binance, que usa [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa), que é uma versão modificada personalizada da PoA e da PoS.
-
-O processo de votação é feito pelos próprios signatários. Cada signatário vota para adicionar ou remover um signatário em seu bloco ao criar um novo bloco. Os votos são contados pelos nós, e os signatários são adicionados ou removidos com base nos votos que atingem um certo limite `SIGNER_LIMIT`.
-
-Pode haver uma situação em que ocorre pequenas bifurcações; a dificuldade de um bloco depende de saber se o bloco foi assinado na sequência ou fora da sequência. Os blocos "dentro da sequência" têm dificuldade 2 e os blocos "fora da sequência" têm dificuldade 1. No caso de bifurcações pequenas, a cadeia com mais signatários validando blocos "na sequência" acumulará a maior dificuldade e vencerá.
-
-## Vetores de ataque {#attack-vectors}
-
-### Signatários maliciosos {#malicious-signers}
-
-Um usuário malicioso pode ser adicionado à lista de signatários, ou uma chave/máquina de assinatura pode ser comprometida. Nesse cenário, o protocolo precisa ser capaz de se defender contra reorganizações e spam. A solução proposta é que, dada uma lista de N signatários autorizados, qualquer signatário pode cunhar apenas 1 bloco de cada K. Isso garante que o dano seja limitado e o restante dos validadores pode votar para eliminar o usuário malicioso.
-
-### Censura {#censorship-attack}
-
-Outro vetor de ataque interessante é quando um signatário (ou grupo de signatários) tenta censurar blocos que votam para removê-lo da lista de autorização. Para contornar isso, a frequência de cunhagem permitida de signatários é restrita a 1 em N/2. Isso garante que signatários mal-intencionados precisem controlar pelo menos 51% das contas signatárias, momento em que eles efetivamente se tornariam a nova fonte de verdade para a cadeia.
-
-### Spam {#spam-attack}
-
-Outro pequeno vetor de ataque são signatários maliciosos injetando novas propostas de votação dentro de cada bloco que eles cunham. Como os nós precisam contabilizar todos os votos para criar a lista real de signatários autorizados, eles devem registrar todos os votos ao longo do tempo. Sem impor um limite à janela de votação, ela poderia crescer lentamente, mas sem limites. A solução é colocar uma janela _móvel_ de blocos W, após a qual os votos são considerados obsoletos. _Uma janela razoável pode ser de 1 a 2 épocas._
-
-### Blocos simultâneos {#concurrent-blocks}
-
-Em uma rede PoA, quando há N signatários autorizados, cada signatário tem permissão para cunhar 1 bloco de K, o que significa que N-K+1 validadores têm permissão para cunhar em qualquer momento. Para evitar que esses validadores corram para conseguir os blocos, cada signatário deve adicionar um pequeno "deslocamento" aleatório ao tempo de liberação de um novo bloco. Embora esse processo garanta que pequenas bifurcações sejam raras, bifurcações ocasionais ainda podem acontecer, assim como na rede principal. Se for descoberto que um signatário está abusando de seu poder e causando caos, os outros signatários poderão votar para expulsá-lo.
-
-Se, por exemplo, houver 10 signatários autorizados e cada signatário tiver permissão para criar 1 bloco entre 20, então, a qualquer momento, 11 validadores poderão criar blocos. Para evitar que esses validadores corram para conseguir blocos, cada signatário adiciona um pequeno "deslocamento" aleatório ao tempo de liberação de um novo bloco. Isso reduz a ocorrência de pequenas bifurcações, mas ainda permite bifurcações ocasionais, como visto na Rede principal do Ethereum. Se um signatário abusar de sua autoridade e causar interrupções, ele poderá ser eliminado da rede.
-
-## Prós e contras {#pros-and-cons}
-
-| Prós | Contras |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Mais dimensionável do que outros mecanismos populares como PoS e PoW, pois é baseado em um número limitado de signatários de bloco | As redes PoA normalmente têm um número relativamente pequeno de nós de validação. Isso torna uma rede PoA mais centralizada. |
-| As blockchains PoA são incrivelmente baratas de executar e manter | Tornar-se um signatário autorizado geralmente está fora do alcance de uma pessoa comum, porque a blockchain requer entidades com reputação estabelecida. |
-| As transações são confirmadas muito rapidamente, podendo levar menos de 1 segundo, pois apenas um número limitado de signatários é necessário para validar novos blocos | Os signatários maliciosos podem reorganizar, duplicar os gastos, censurar transações na rede. Esses tipos de ataque são mitigados, mas ainda são possíveis |
-
-## Leitura adicional {#further-reading}
-
-- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique padrão_
-- [Estudo de Prova de autoridade](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_
-- [O que é Prova de autoridade](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_
-- [Prova de autoridade explicada](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_
-- [PoA em blockchain](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba)
-- [Clique explicado](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d)
-- [PoA obsoleta, especificação Aura](https://openethereum.github.io/Chain-specification)
-- [IBFT 2.0, outra implementação da PoA](https://besu.hyperledger.org/stable/private-networks/concepts/poa)
-
-### Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner}
-
-Assista a uma explicação visual da prova de autoridade:
-
-
-
-## Tópicos relacionados {#related-topics}
-
-- [Prova de trabalho](/developers/docs/consensus-mechanisms/pow/)
-- [Prova de participação](/developers/docs/consensus-mechanisms/pos/)
diff --git "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" "b/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
deleted file mode 100644
index 746a5036b45..00000000000
--- "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Prova de trabalho (PoW)
-description: Uma explicação do protocolo de consenso de prova de trabalho e seu papel no Ethereum.
-lang: pt-br
----
-
-A rede Ethereum começou usando um mecanismo de consenso que envolvia **[Prova de trabalho (PoW)](/developers/docs/consensus-mechanisms/pow)**. Isso permitiu que os nós da rede Ethereum concordassem com o estado de todas as informações registradas na cadeia de blocos Ethereum e impediu certos tipos de ataques econômicos. No entanto, o Ethereum desativou a prova de trabalho em 2022 e começou a usar a [prova de participação](/developers/docs/consensus-mechanisms/pos).
-
-
- A prova de trabalho agora está obsoleta. O Ethereum não usa mais a prova de trabalho como parte de seu mecanismo de consenso. Em vez disso, ele usa a prova de participação. Leia mais sobre prova de participação e participação.
-
-
-## Pré-requisitos {#prerequisites}
-
-Para entender melhor esta página, recomendamos ler primeiro sobre [ transações ](/developers/docs/transactions/), [blocos](/developers/docs/blocks/) e [mecanismos de consenso](/developers/docs/consensus-mechanisms/).
-
-## O que é prova de trabalho (PoW)? {#what-is-pow}
-
-O consenso de Nakamoto, que utiliza prova de trabalho, é o mecanismo que uma vez permitiu que a rede descentralizada Ethereum chegasse a um consenso (ou seja, todos os nós concordam) em coisas como saldos de contas e a ordem das transações. Isso impediu os usuários de "gastar duas vezes" suas moedas e garantiu que a cadeia Ethereum se tornasse tremendamente difícil de atacar ou manipular. Essas propriedades de segurança agora vêm da prova de participação usando o mecanismo de consenso conhecido como [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/).
-
-## Prova de trabalho e mineração {#pow-and-mining}
-
-A prova de trabalho é o algoritmo subjacente que define a dificuldade e as regras para os mineiros trabalharem em cadeias de blocos de prova de trabalho. Minerar é o "trabalho" em si. É o ato de adicionar blocos válidos à cadeia. Isso é importante porque o comprimento da cadeia ajuda a rede a seguir a bifurcação correta da blockchain. Quanto mais "trabalho" feito, mais longa é a cadeia, e quanto maior o número do bloco, mais a rede pode ter certeza do estado atual das coisas.
-
-[Mais sobre mineração](/developers/docs/consensus-mechanisms/pow/mining/)
-
-## Como funcionou a prova de trabalho do Ethereum? {#how-it-works}
-
-As transações Ethereum são processadas em blocos. Na agora obsoleta prova de trabalho do Ethereum, cada bloco continha:
-
-- dificuldade de bloco - por exemplo: 3,324,092,183,262,715
-- mixHash – por exemplo: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
-- nonce – por exemplo: `0xd3ee432b4fb3d26b`
-
-Esses dados de bloco estavam diretamente relacionados à prova de trabalho.
-
-### O trabalho em prova-de-trabalho {#the-work}
-
-O protocolo de prova de trabalho, Ethash, exigia que os mineradores passassem por uma intensa corrida de tentativa e erro para encontrar o nonce para um bloco. Apenas blocos com um nonce válido podem ser adicionados à cadeia.
-
-Ao correr para criar um bloco, um minerador repetidamente coloca um conjunto de dados, que só poderia ser obtido baixando e executando a cadeia completa (como um minerador faz), por meio de uma função matemática. O conjunto de dados foi usado para gerar um mixHash abaixo de um alvo que é ditado pela dificuldade do bloco. A melhor maneira de fazer isso é através de tentativa e erro.
-
-A dificuldade determinou o alvo para o hash. Quanto menor o alvo, menor será o conjunto de hashes válidos. Uma vez gerado, isso foi incrivelmente fácil para outros mineradores e clientes verificarem. Mesmo que uma transação mudasse, o hash seria completamente diferente, sinalizando fraude.
-
-O hashing facilita a detecção de fraude. Mas a prova de trabalho como um processo também foi um grande impedimento para atacar a cadeia.
-
-### Prova de trabalho e segurança {#security}
-
-Os mineradores foram incentivados a fazer esse trabalho na cadeia principal do Ethereum. Havia pouco incentivo para um subconjunto de mineradores iniciar sua própria cadeia – isso prejudica o sistema. As cadeias de blocos dependem de ter uma única fonte de verdade.
-
-O objetivo da prova de trabalho era estender a cadeia. A cadeia mais longa era mais aceita como válida porque teve o maior trabalho computacional feito para gerá-la. No sistema PoW do Ethereum, era quase impossível criar novos blocos que apagassem transações, criassem transações falsas ou mantivessem uma segunda cadeia. Isso porque um minerador malicioso precisaria sempre resolver o bloco nonce mais rápido do que todos os outros.
-
-Para criar consistentemente blocos maliciosos, ainda que válidos, um minerador mal-intencionado precisaria de mais de 51% do poder de mineração da rede para superar todos os demais. Essa quantidade de "trabalho" requer muito poder de computação caro e a energia gasta pode até ter superado os ganhos obtidos em um ataque.
-
-### Aspectos econômicos da prova de trabalho {#economics}
-
-A prova de trabalho também foi responsável por emitir novas moedas no sistema e incentivar os mineradores a fazer o trabalho.
-
-Desde a [atualização de Constantinopla](/history/#constantinople), os mineradores que criaram com sucesso um bloco foram recompensados com dois ETH recém-cunhados e parte das taxas de transação. Os blocos Omner também compensaram 1,75 ETH. Os blocos Ommer eram blocos válidos criados por um minerador praticamente ao mesmo tempo que outro minerador criava o bloco canônico, o que foi determinado em última instância por qual cadeia foi construída em cima da primeira. Os blocos Ommer geralmente aconteciam devido à latência da rede.
-
-## Finalidade {#finality}
-
-Uma transação tem "finalidade" no Ethereum quando ela faz parte de um bloco que não pode mudar.
-
-Como os mineradores trabalhavam de maneira descentralizada, dois blocos válidos poderiam ser minerados ao mesmo tempo. Isso cria uma bifurcação temporária. Por fim, uma dessas cadeias se tornou a cadeia aceita depois que os blocos subsequentes foram minerados e adicionados a ela, tornando-a mais longa.
-
-Para complicar ainda mais, as transações rejeitadas na bifurcação temporária podem não ter sido incluídas na cadeia aceita. Ou seja, isso poderia ser revertido. Portanto, a finalização se refere ao tempo que você deve esperar antes de considerar uma transação irreversível. Na prova de trabalho Ethereum anterior, quanto mais blocos foram extraídos em cima de um bloco `N` específico, maior a confiança de que as transações em `N` foram bem-sucedidas e não seriam revertidas. Agora, com a prova de participação, a finalização é uma propriedade explícita, e não probabilística, de um bloco.
-
-## Uso de energia na prova de trabalho {#energy}
-
-Uma importante crítica à prova de trabalho é a quantidade de energia necessária para manter a rede segura. Para manter a segurança e a descentralização, o Ethereum na prova de trabalho consumia grandes quantidades de energia. Pouco antes de mudar para a prova de participação, os mineradores do Ethereum consumiam coletivamente cerca de 70 TWh/ano (aproximadamente o mesmo que a República Tcheca, de acordo com [digiconomist](https://digiconomist.net/) em 18 de julho de 2022).
-
-## Prós e contras {#pros-and-cons}
-
-| Prós | Contras |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| A prova de trabalho é neutra. Você não precisa de ETH para começar, e as recompensas por bloco permitem que você vá de 0 ETH a um saldo positivo. Na [prova de participação](/developers/docs/consensus-mechanisms/pos/), você precisa de ETH para começar. | A prova de trabalho consome tanta energia que é prejudicial ao meio ambiente. |
-| A prova de trabalho é um mecanismo de consenso testado que manteve o Bitcoin e o Ethereum seguros e descentralizados por muitos anos. | Se você quer minerar, você precisa de equipamento especializado, e isso é um grande investimento para começar. |
-| Comparada com a prova de participação, é relativamente fácil de implementar. | Devido ao aumento necessário do cálculo de mineração, as pools de mineração poderiam potencialmente dominar o mercado de mineração, levando à centralização e a riscos de segurança. |
-
-## Comparação com a prova de participação {#compared-to-pos}
-
-Em termos gerais, a prova de participação tem o mesmo objetivo final que a prova de trabalho: ajudar a rede descentralizada alcançar consenso de forma segura. No entanto, existem algumas diferenças em termos de processo e de pessoal:
-
-- A prova de participação substitui a importância do poder computacional pelo ETH de participação.
-- A prova de participação substitui mineradores por validadores. Os validadores apostam seus ETH para poder ter a capacidade de criar novos blocos.
-- Os validadores não competem para criar blocos, em vez disso, eles são escolhidos aleatoriamente por um algoritmo.
-- A finalidade é clara: em certos pontos de controle, se 2/3 dos validadores concordam com o estado do bloco então ele é considerado finalizado. Os validadores devem apostar todas as suas fichas nisso, assim, caso tentem conspirar, irão perder toda a aposta.
-
-[Mais sobre prova de participação](/developers/docs/consensus-mechanisms/pos/)
-
-## Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner}
-
-
-
-## Leitura adicional {#further-reading}
-
-- [Ataque majoritário](https://en.bitcoin.it/wiki/Majority_attack)
-- [Finalidade do acordo](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
-
-### Vídeos {#videos}
-
-- [Uma explicação técnica dos protocolos de prova de trabalho](https://youtu.be/9V1bipPkCTU)
-
-## Tópicos relacionados {#related-topics}
-
-- [Mineração](/developers/docs/consensus-mechanisms/pow/mining/)
-- [Prova de participação](/developers/docs/consensus-mechanisms/pos/)
-- [Prova de autoridade](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" "b/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
deleted file mode 100644
index 318a785b7fb..00000000000
--- "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Mineração
-description: Uma explicação de como a mineração funcionava no Ethereum.
-lang: pt-br
----
-
-
-A prova de trabalho não está mais subjacente ao mecanismo de consenso do Ethereum, o que significa que a mineração foi desativada. Em vez disso, o Ethereum é garantido por validadores que apostam em ETH. Você pode começar a participar com o seu ETH hoje. Leia mais sobre A Fusão (The MErge), prova de participação e participação (stake). Esta página é apenas para interesse histórico.
-
-
-## Pré-requisitos {#prerequisites}
-
-Para melhor entender esta página, recomendamos que você leia primeiro [transações](/developers/docs/transactions/), [blocos](/developers/docs/blocks/) e [prova de trabalho ](/developers/docs/consensus-mechanisms/pow/).
-
-## O que é mineração de Ethereum? {#what-is-ethereum-mining}
-
-A mineração é o processo de criação de um bloco de transações a ser adicionado à cadeia de blocos do Ethereum na arquitetura de prova de trabalho agora obsoleta do Ethereum.
-
-A palavra mineração se origina no contexto da analogia do ouro para criptomoedas. Ouro ou metais preciosos são escassos, assim como tokens digitais, e a única maneira de aumentar o volume total em um sistema de prova de trabalho é por meio da mineração. Na prova de trabalho do Ethereum, o único modo de emissão foi por meio da mineração. Ao contrário de ouro ou metais preciosos, no entanto, a mineração Ethereum também foi a maneira de proteger a rede criando, verificando, publicando e propagando blocos na cadeia de blocos.
-
-Ether de mineração = Protegendo a rede
-
-A mineração é a força vital de qualquer cadeia de blocos de prova de trabalho. Os mineradores do Ethereum — computadores executando software — usaram seu tempo e poder de computação para processar transações e produzir blocos antes da transição para a prova de participação.
-
-## Por que existem mineradores? {#why-do-miners-exist}
-
-Em sistemas descentralizados como o Ethereum, precisamos garantir que todos concordem com a ordem das transações. Os mineradores ajudaram isso a acontecer resolvendo quebra-cabeças computacionalmente difíceis para produzir blocos, protegendo a rede contra-ataques.
-
-[Mais sobre prova de trabalho](/developers/docs/consensus-mechanisms/pow/)
-
-Anteriormente, qualquer era capaz de minerar na rede Ethereum usando seu computador. No entanto, nem todos podem minerar ether (ETH) de forma lucrativa. Na maioria dos casos, os mineradores tiveram que comprar hardware de computador dedicado e ter acesso a fontes de energia barata. Um computador médio provavelmente não ganhava recompensas de bloco suficientes para cobrir os custos associados à mineração.
-
-### Custo da mineração {#cost-of-mining}
-
-- Custos potenciais do hardware necessário para construir e manter uma plataforma de mineração
-- Custo elétrico para alimentar a plataforma de mineração
-- Se você estivesse minerando em um pool, esses pools normalmente cobravam uma taxa percentual fixa de cada bloco gerado pelo pool
-- Custo potencial do equipamento para apoiar a plataforma de mineração (ventilação, monitoramento de energia, fiação elétrica, etc.)
-
-Para conhecer ainda mais a rentabilidade da mineração, use uma calculadora de mineração, como a fornecida pela [Etherscan](https://etherscan.io/ether-mining-calculator).
-
-## Como as transações do Ethereum eram mineradas {#how-ethereum-transactions-were-mined}
-
-O seguinte fornece uma visão geral de como as transações foram mineradas na prova de trabalho Ethereum. Uma descrição análoga deste processo para a prova de participação Ethereum pode ser encontrada [aqui](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos).
-
-1. Um usuário escreve e assina uma solicitação de [ transação ](/developers/docs/transactions/) com a chave privada de alguma [ conta ](/developers/docs/accounts/).
-2. O usuário transmite a solicitação de transação para toda a rede Ethereum de algum [nó](/developers/docs/nodes-and-clients/).
-3. Ao ouvir tomar conhecimento da nova solicitação de transação, cada nó na rede Ethereum adiciona a solicitação ao seu mempool local, uma lista de todas as solicitações de transação sobre as quais eles têm conhecimento que ainda não foram confirmadas na blockchain em um bloco.
-4. Em algum ponto, um nó de mineração agrega várias dezenas ou centenas de solicitações de transação a um [bloco](/developers/docs/blocks/) potencial, de uma forma que maximiza as [taxas de transação](/developers/docs/gas/) que eles ganham enquanto ainda estão abaixo do limite de gás de bloco. Então, o nó de mineração:
- 1. Verifica a validade de cada pedido de transação (por exemplo, ninguém está tentando transferir o ether de uma conta para a qual não produziu uma assinatura, a solicitação não está malformada, etc.), e em seguida executa o código da solicitação, alterando o estado de sua cópia local do EVM. O minerador atribui a taxa de transação para cada um desses pedidos de transação à sua própria conta.
- 2. Começa o processo de produção do "certificado de legitimidade" da Prova de participação para o bloco em potencial, uma vez que todas as solicitações de transação no bloco tenham sido verificadas e executadas na cópia local do EVM.
-5. Eventualmente, um minerador terminará de produzir um certificado para um bloco que inclui nossa solicitação específica de transação. O minerador, em seguida, transmite o bloco completo, que inclui o certificado e uma soma de verificação do novo estado EVM requerido.
-6. Outros nós obtêm informação sobre o novo bloco. Eles verificam o certificado, executam todas as transações no próprio bloco (incluindo a transação originalmente transmitida pelo nosso usuário) e verifique se a soma de verificação de seu novo estado EVM após a execução de todas as transações corresponde à soma de verificação do estado reivindicada pelo bloco do minerador. Só então esses nós adicionam este bloco à cauda do blockchain e aceitam o novo estado EVM como o estado canônico.
-7. Cada nó remove todas as transações do novo bloco de suas memórias locais de pedidos de transações não atendidos.
-8. Novos nós que se juntam à rede baixam todos os blocos em sequência, incluindo o bloco que contém nossa transação de interesse. Eles inicializam uma cópia local de EVM (que começa como uma EVM em branco) e, em seguida, passa pelo processo de execução de cada transação em cada bloco em cima de sua cópia de EVM local, verificando as somas de verificação de estado em cada bloco ao longo do caminho.
-
-Cada transação é extraída (incluída em um novo bloco e propagada pela primeira vez) uma vez, mas executada e verificada por cada participante no processo de avanço do estado EVM padrão. Isso destaca um dos mantras centrais da cadeia de blocos: ** Não confie, verifique **.
-
-## Blocos Ommer (tio) {#ommer-blocks}
-
-Mineração de blocos na prova de trabalho era probabilística, o que significa que às vezes dois blocos válidos eram publicados simultaneamente devido à latência da rede. Nesse caso, o protocolo tinha que determinar a cadeia mais longa (e, portanto, mais “válida”), enquanto garante justiça para os mineradores, recompensando parcialmente o bloco válido proposto não incluído. Isso encorajou uma maior descentralização da rede, pois mineradores menores, que podem enfrentar maior latência, ainda poderiam gerar retornos por meio de recompensas de bloco [ommer](/glossary/#ommer).
-
-O termo "ommer" é o termo neutro de gênero preferido para o irmão de um bloco pai, mas às vezes também é chamado de "tio". **Desde a mudança do Ethereum para prova de participação, os blocos ommer não são mais minerados**, pois apenas um proponente é eleito em cada espaço. Você pode ver essa mudança visualizando o [gráfico histórico](https://ycharts.com/indicators/ethereum_uncle_rate) dos blocos ommer minerados.
-
-## Uma demonstração visual {#a-visual-demo}
-
-Acompanhe o Austin enquanto ele explica como funciona o processo de mineração e o conceito de prova de trabalho da cadeia de blocos.
-
-
-
-## O algoritmo de mineração {#mining-algorithm}
-
-A Rede principal do Ethereum usou apenas um algoritmo de mineração, o ["Ethash"](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash foi o sucessor de um algoritmo original de pesquisa e desenvolvimento conhecido como ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/).
-
-[Mais sobre algoritmos de mineração](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/).
-
-## Tópicos relacionados {#related-topics}
-
-- [Gás](/developers/docs/gas/)
-- [EVM](/developers/docs/evm/)
-- [Prova de trabalho](/developers/docs/consensus-mechanisms/pow/)
diff --git "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" "b/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
deleted file mode 100644
index fd11cc3183b..00000000000
--- "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
+++ /dev/null
@@ -1,334 +0,0 @@
----
-title: Dagger-Hashimoto
-description: O algoritmo Dagger-Hashimoto em detalhes
-lang: pt-br
----
-
-Dagger-Hashimoto foi a implementação original de pesquisa e especificação para o algoritmo de mineração do Ethereum. Dagger-Hashimoto foi substituído por [Ethash](#ethash). A mineração foi completamente interrompida na [Fusão](/roadmap/merge/) no dia 15 de setembro de 2022. Desde então, o Ethereum foi protegido usando um mecanismo [prova de participação](/developers/docs/consensus-mechanisms/pos). Esta página é para fins históricos. As informações aqui não são mais relevantes para o Ethereum posterior à Fusão.
-
-## Pré-Requisitos {#prerequisites}
-
-Para melhor entender esta página, recomendamos que você leia primeiro o[ consenso de prova de trabalho, ](/developers/docs/consensus-mechanisms/pow)[mineração](/developers/docs/consensus-mechanisms/pow/mining) e [algoritmos de mineração](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms).
-
-## Dagger-Hashimoto {#dagger-hashimoto}
-
-Dagger-Hashimoto pretende satisfazer dois objetivos:
-
-1. **Resistência a ASIC**: o benefício de criar hardware especializado para o algoritmo deve ser o menor possível.
-2. **Cliente leve verificável**: um bloco deve ser verificável eficientemente por um cliente leve.
-
-Com uma modificação adicional, também especificamos como atingir um terceiro objetivo se desejado, mas à custa de uma complexidade adicional:
-
-**Armazenamento completo da cadeia**: a mineração deveria exigir o armazenamento do estado completo da blockchain (devido à estrutura irregular da árvore de estado Ethereum, esperamos que haja um pouco de perda, especialmente de alguns contratos muitas vezes usados, mas queremos minimizar isso).
-
-## Geração do DAG {#dag-generation}
-
-O código do algoritmo será definido em Python abaixo. Primeiro, damos `encode_int` para combinar inteiros sem sinal de precisão especificada em strings. Sua inversa também é dada:
-
-```python
-NUM_BITS = 512
-
-def encode_int(x):
- "Encode an integer x as a string of 64 characters using a big-endian scheme"
- o = ''
- for _ in range(NUM_BITS / 8):
- o = chr(x % 256) + o
- x //= 256
- return o
-
-def decode_int(s):
- "Unencode an integer x from a string using a big-endian scheme"
- x = 0
- for c in s:
- x *= 256
- x += ord(c)
- return x
-```
-
-Em seguida assumimos que `sha3` é uma função que recebe um inteiro e retorna um inteiro, e `dbl_sha3` é uma função double-sha3, se converter este código de referência em uma implementação de uso:
-
-```python
-from pyethereum import utils
-def sha3(x):
- if isinstance(x, (int, long)):
- x = encode_int(x)
- return decode_int(utils.sha3(x))
-
-def dbl_sha3(x):
- if isinstance(x, (int, long)):
- x = encode_int(x)
- return decode_int(utils.sha3(utils.sha3(x)))
-```
-
-### Parâmetros {#parameters}
-
-Os parâmetros usados para o algoritmo são:
-
-```python
-SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512
-
-params = {
- "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536
- "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536
- # with epochtime=20000 gives 882 MB growth per year
- "cache_size": 2500, # Size of the light client's cache (can be chosen by light
- # client; not part of the algo spec)
- "diff": 2**14, # Difficulty (adjusted during block evaluation)
- "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated)
- "k": 1, # Number of parents of a node
- "w": w, # Used for modular exponentiation hashing
- "accesses": 200, # Number of dataset accesses during hashimoto
- "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation
-}
-```
-
-`P` neste caso é uma primeira escolha tal que `log(P)` é apenas ligeiramente menor que 512, que corresponde aos 512 bits que temos usado para representar nossos números. Observe que apenas a última metade do DAG precisa realmente ser armazenado, assim o requisito de RAM de-facto começa em 1 GB e cresce 441 MB por ano.
-
-### Construção de gráfico Dagger {#dagger-graph-building}
-
-A construção primitiva de gráfico dagger é definida da seguinte forma:
-
-```python
-def produce_dag(params, seed, length):
- P = params["P"]
- picker = init = pow(sha3(seed), params["w"], P)
- o = [init]
- for i in range(1, length):
- x = picker = (picker * init) % P
- for _ in range(params["k"]):
- x ^= o[x % i]
- o.append(pow(x, params["w"], P))
- return o
-```
-
-Essencialmente, ele começa um gráfico como um único nó, `sha3(seed)`, e de lá começa a adicionar sequencialmente outros nós com base em nós aleatórios anteriores. Quando um novo nó é criado, uma potência modular da semente é computada para aleatoriamente selecionar alguns índices menores que `i` (usando `x % i` acima), e os valores dos nós desses índices são usados em um cálculo para gerar um novo valor para `x`, que é então alimentada em uma pequena função de prova de trabalho (baseada em XOR) para finalmente gerar o valor do gráfico no índice `i`. A lógica por trás deste design específico é forçar o acesso sequencial do DAG; o próximo valor do DAG que será acessado não pode ser determinado até que o valor atual seja conhecido. Finalmente, a exponenciação modular faz o hash do resultado ainda mais.
-
-Este algoritmo depende de vários resultados da teoria numérica. Veja o apêndice abaixo para uma discussão.
-
-## Avaliação de cliente leve {#light-client-evaluation}
-
-A construção do gráfico acima pretende permitir que cada nó no gráfico seja reconstruído computando uma subárvore com apenas um pequeno número de nós e exigindo uma pequena quantidade de memória auxiliar. Note que com k=1, a subárvore é apenas uma cadeia de valores que vai subindo até o primeiro elemento do DAG.
-
-A função de computação do cliente leve para o DAG funciona da seguinte forma:
-
-```python
-def quick_calc(params, seed, p):
- w, P = params["w"], params["P"]
- cache = {}
-
- def quick_calc_cached(p):
- if p in cache:
- pass
- elif p == 0:
- cache[p] = pow(sha3(seed), w, P)
- else:
- x = pow(sha3(seed), (p + 1) * w, P)
- for _ in range(params["k"]):
- x ^= quick_calc_cached(x % p)
- cache[p] = pow(x, w, P)
- return cache[p]
-
- return quick_calc_cached(p)
-```
-
-Essencialmente, é simplesmente uma reescrita do algoritmo acima que remove o loop de computação dos valores de todo o DAG e substitui a pesquisa anterior de nó por uma chamada recursiva ou uma pesquisa de cache. Observe que para `k=1` o cache é desnecessário, embora uma otimização maior na verdade pré-calcula os primeiros poucos milhares de valores do DAG e o mantém como um cache estático para computações; ver o apêndice para uma implementação de código disso.
-
-## Buffer duplo de DAGs {#double-buffer}
-
-Em um cliente completo, é usado um [_buffer duplo_](https://wikipedia.org/wiki/Multiple_buffering) de 2 DAGs produzidos pela fórmula acima. A ideia é que DAGs são produzidos a cada `epochtime` número de blocos de acordo com os parâmetros acima. Em vez do cliente usar o último DAG produzido, ele usa o anterior. A vantagem disto é permitir que os DAG sejam substituídos com o passar do tempo, sem necessidade de incorporar um passo em que os mineradores devem, de repente, recriar todos os dados. Caso contrário, existe o potencial para um abrandamento abrupto temporário do processamento da cadeia a intervalos regulares e um aumento dramático da centralização. Assim, existe o risco de ataques de 51% dentro desses poucos minutos antes de todos os dados serem recomputados.
-
-O algoritmo usado para gerar o conjunto de DAGs usados para computar o trabalho de um bloco é o seguinte:
-
-```python
-def get_prevhash(n):
- from pyethereum.blocks import GENESIS_PREVHASH
- from pyethereum import chain_manager
- if n <= 0:
- return hash_to_int(GENESIS_PREVHASH)
- else:
- prevhash = chain_manager.index.get_block_by_number(n - 1)
- return decode_int(prevhash)
-
-def get_seedset(params, block):
- seedset = {}
- seedset["back_number"] = block.number - (block.number % params["epochtime"])
- seedset["back_hash"] = get_prevhash(seedset["back_number"])
- seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0)
- seedset["front_hash"] = get_prevhash(seedset["front_number"])
- return seedset
-
-def get_dagsize(params, block):
- return params["n"] + (block.number // params["epochtime"]) * params["n_inc"]
-
-def get_daggerset(params, block):
- dagsz = get_dagsize(params, block)
- seedset = get_seedset(params, block)
- if seedset["front_hash"] <= 0:
- # No back buffer is possible, just make front buffer
- return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
- "block_number": 0}}
- else:
- return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
- "block_number": seedset["front_number"]},
- "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz),
- "block_number": seedset["back_number"]}}
-```
-
-## Hashimoto {#hashimoto}
-
-A ideia por trás do Hashimoto original é usar a blockchain como um conjunto de dados, executando um cálculo que seleciona N índices da blockchain, reúne as transações nesses índices, executa um XOR desses dados e retorna o hash do resultado. O algoritmo original de Thaddeus Dryja, convertido para Python para consistência, é o seguinte:
-
-```python
-def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce):
- hash_output_A = sha256(prev_hash + merkle_root + nonce)
- txid_mix = 0
- for i in range(64):
- shifted_A = hash_output_A >> i
- transaction = shifted_A % len(list_of_transactions)
- txid_mix ^= list_of_transactions[transaction] << i
- return txid_mix ^ (nonce << 192)
-```
-
-Infelizmente, enquanto Hashimoto é considerado de uso intenso de RAM, ele depende da aritmética de 256 bits, o que tem uma sobrecarga computacional considerável. No entanto, Dagger-Hashimoto usa apenas os 64 bits menos significativos ao indexar seu conjunto de dados para resolver esta questão.
-
-```python
-def hashimoto(dag, dagsize, params, header, nonce):
- m = dagsize / 2
- mix = sha3(encode_int(nonce) + header)
- for _ in range(params["accesses"]):
- mix ^= dag[m + (mix % 2**64) % m]
- return dbl_sha3(mix)
-```
-
-O uso duplo do SHA3 permite uma forma de zero dados, pré-verificação quase instantânea, verificando apenas se foi fornecido um valor intermediário correto. Esta camada exterior de prova de trabalho é altamente favorável a ASIC e razoavelmente fraca, mas existe para tornar a DDoS ainda mais difícil, uma vez que essa pequena quantidade de trabalho tem de ser feita para produzir um bloco que não seja imediatamente rejeitado. Aqui está a versão de cliente leve:
-
-```python
-def quick_hashimoto(seed, dagsize, params, header, nonce):
- m = dagsize // 2
- mix = sha3(nonce + header)
- for _ in range(params["accesses"]):
- mix ^= quick_calc(params, seed, m + (mix % 2**64) % m)
- return dbl_sha3(mix)
-```
-
-## Mineração e verificação {#mining-and-verifying}
-
-Agora, vamos colocar tudo junto no algoritmo de mineração:
-
-```python
-def mine(daggerset, params, block):
- from random import randint
- nonce = randint(0, 2**64)
- while 1:
- result = hashimoto(daggerset, get_dagsize(params, block),
- params, decode_int(block.prevhash), nonce)
- if result * params["diff"] < 2**256:
- break
- nonce += 1
- if nonce >= 2**64:
- nonce = 0
- return nonce
-```
-
-Aqui está o algoritmo de verificação:
-
-```python
-def verify(daggerset, params, block, nonce):
- result = hashimoto(daggerset, get_dagsize(params, block),
- params, decode_int(block.prevhash), nonce)
- return result * params["diff"] < 2**256
-```
-
-Verificação amigável do cliente leve:
-
-```python
-def light_verify(params, header, nonce):
- seedset = get_seedset(params, block)
- result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block),
- params, decode_int(block.prevhash), nonce)
- return result * params["diff"] < 2**256
-```
-
-Além disso, note que Dagger-Hashimoto impõe requisitos adicionais no cabeçalho do bloco:
-
-- Para que a verificação em duas camadas funcione, um cabeçalho de bloco deve ter ambos o nonce e o valor do meio pre-sha3
-- Um cabeçalho de bloco deve armazenar o sha3 do seedset atual em algum lugar
-
-## Leitura adicional {#further-reading}
-
-_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_
-
-## Apêndice {#appendix}
-
-Como mencionado acima, o RNG usado para geração de DAGs depende de alguns resultados da teoria de números. Primeiro, nós fornecemos garantias de que o Lehmer RNG, que é a base para a variável `picker`, tenha um longo período. Segundo, mostramos que `pow(x,3,P)` não vai correlacionar `x` para `1` ou `P-1` fornecer `x ∈ [2,P-2]` para começar. Finalmente, mostramos que `pow(x,3,P)` tem uma baixa taxa de colisão quando tratado como uma função de hashing.
-
-### Gerador de números aleatórios Lehmer {#lehmer-random-number}
-
-Enquanto a função `produce_dag` não precisa produzir números aleatórios sem viés, uma ameaça potencial é que `seed**i % P` só absorve um punhado de valores. Isto poderia proporcionar uma vantagem aos mineradores reconhecendo o padrão em relação aos que não o fazem.
-
-Para evitar isso, apela-se a um resultado da teoria dos números. Um [_número primo seguro_](https://en.wikipedia.org/wiki/Safe_prime) é definido como sendo um `P` primo tal que `(P-1)/2` também é primo. A _ordem_ de um membro `x` do [grupo multiplicativo](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `Z/nZ` é definido como o mínimo de `m` tal que
xᵐ mod P ≡ 1
-Dadas essas definições, temos:
-
-> Observação 1. Deixe `x` ser um membro do grupo multiplicador `Z/PZ` para um `P` primo seguro. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, então a ordem de `x` é `P-1` ou `(P-1)/2`.
-
-_Prova_. Já que `P` é um primo seguro, então pelo \[Teorema de Lagrange\]\[lagrange\] temos que a ordem de `x` é `1`, `2`, `(P-1)/2` ou `P-1`.
-
-A ordem de `x` não pode ser `1`, já que pelo Pequeno Teorema de Fermat, nós temos:
-
-
xP-1 mod P ≡ 1
-
-Daí `x` deve ser uma identidade multiplicadora de `Z/nZ`, que é única. Como partimos do princípio de que `x ≠ 1` por suposição, isso não é possível.
-
-A ordem de `x` não pode ser `2` a menos que `x = P-1`, já que isso violaria o princípio de que `P` é primo.
-
-A partir da proposta acima, podemos reconhecer que a iteração `(picker * init) % P` terá um ciclo de comprimento de pelo menos `(P-1)/2`. Isso acontece porque selecionamos `P` para ser um primo seguro aproximadamente igual a uma potência de dois mais alta, e `init` está no intervalo `[2,2**256+1]`. Dada a magnitude de `P`, nunca deveríamos esperar um ciclo da exponenciação modular.
-
-Quando estamos atribuindo a primeira célula no DAG (a variável rotulada como `init`), nós computamos `pow (sha3(seed) + 2, 3, P)`. À primeira vista, isso não garante que o resultado não é `1` nem `P-1`. No entanto, como `P-1` é um primo seguro, temos a seguinte garantia adicional, que é uma afirmação deduzida da Observação 1:
-
-> Observação 2. Deixe `x` ser um membro do grupo multiplicador `Z/PZ` para um `P` primo seguro, e deixe `w` ser um número natural. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, assim como `w mod P ≠ P-1 mod P` e `w mod P ≠ 0 mod P`, então `xʷ mod P ≠ 1 mod P` e `xʷ mod P ≠ P-1 mod P`
-
-### Exponenciação modular como uma função hash {#modular-exponentiation}
-
-Para certos valores de `P` e `w`, a função `pow(x, w, P)` pode ter muitas colisões. Por exemplo, `pow(x,9,19)` recebe apenas valores `{1,18}`.
-
-Dado que `P` é primo, então um `w` apropriado para uma função hash de exponenciação modular pode ser escolhida usando o seguinte resultado:
-
-> Observação 3. Considere `P` um primo; `w` e `P-1` são relativamente primos, se e somente se para todos `a` e `b` em `Z/PZ`:
->
->
-> `aʷ mod P ≡ bʷ mod P` se e somente se `a mod P ≡ b mod P`
->
-
-Assim, dado que `P` é primo e `w` é relativamente primo de `P-1`, temos que `|{pow(x, w, P) : x ∈ ℤ}| = P`, implicando que a função tem a taxa mínima de colisão possível.
-
-No caso especial que `P` é um primo seguro como selecionamos, então `P-1` só tem fatores 1, 2, `(P-1)/2` e `P-1`. Como `P` > 7, sabemos que 3 é relativamente primo de `P-1`, daí `w=3` satisfaz a proposta acima.
-
-## Algoritmo de avaliação baseado em cache mais eficiente {#cache-based-evaluation}
-
-```python
-def quick_calc(params, seed, p):
- cache = produce_dag(params, seed, params["cache_size"])
- return quick_calc_cached(cache, params, p)
-
-def quick_calc_cached(cache, params, p):
- P = params["P"]
- if p < len(cache):
- return cache[p]
- else:
- x = pow(cache[0], p + 1, P)
- for _ in range(params["k"]):
- x ^= quick_calc_cached(cache, params, x % p)
- return pow(x, params["w"], P)
-
-def quick_hashimoto(seed, dagsize, params, header, nonce):
- cache = produce_dag(params, seed, params["cache_size"])
- return quick_hashimoto_cached(cache, dagsize, params, header, nonce)
-
-def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
- m = dagsize // 2
- mask = 2**64 - 1
- mix = sha3(encode_int(nonce) + header)
- for _ in range(params["accesses"]):
- mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
- return dbl_sha3(mix)
-```
diff --git "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" "b/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
deleted file mode 100644
index 20bc33435ee..00000000000
--- "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
+++ /dev/null
@@ -1,1014 +0,0 @@
----
-title: Ethash
-description: O algoritmo de mineração Ethash em detalhes
-lang: pt-br
----
-
-
- Ethash foi o algoritmo de mineração da prova de trabalho do Ethereum. A prova de trabalho foi agora **totalmente desativada** e o Ethereum agora está protegido usando a prova de participação. Leia mais sobre A Fusão (The Merge), prova de participação e participação (stake). Esta página é de interesse histórico!
-
-
-[Ethash](https://github.com/ethereum/wiki/wiki/Ethash) é uma versão modificada do algoritmo [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). A prova de trabalho Ethash faz uso de [muita memória](https://wikipedia.org/wiki/Memory-hard_function), o que foi pensado para tornar o algoritmo ASIC resistente. Os ASICs Ethash foram eventualmente desenvolvidos, mas a mineração de GPU ainda era uma opção viável até que a prova de trabalho fosse desativada. Ethash ainda é usado para minerar outras moedas em outras redes de prova de trabalho não Ethereum.
-
-## Como o Ethash funciona? {#how-does-ethash-work}
-
-Dificuldade de memória é alcançada com um algoritmo de prova de trabalho que requer a escolha de subconjuntos de um recurso fixo dependente do nonce e do cabeçalho do bloco. Este recurso (alguns gigabytes em tamanho) é chamado de DAG. O DAG é alterado a cada 30.000 blocos, uma janela de cerca de 125 horas chamada de período eletrônico (aproximadamente 5,2 dias) e leva um tempo para gerar. Como o DAG depende apenas da altura do bloco, ele pode ser pré-gerado, mas o cliente não precisa esperar até o final deste processo para produzir um bloco. Se os clientes não pré-geraram e armazenaram em cache os DAGs antes, a rede pode sofrer um grande atraso em blocos em cada transição de período eletrônico (epoch). Note que o DAG não precisa ser gerado para verificar a prova de trabalho, permitindo essencialmente a verificação com baixa CPU e pouca memória.
-
-A rota geral que o algoritmo faz é a seguinte:
-
-1. Existe uma **seed** que pode ser calculada para cada bloco escaneando os cabeçalhos dos blocos até esse ponto.
-2. Da seed, pode-se calcular um **cache pseudo-randômico de 16 MB**. Clientes leves armazenam o cache.
-3. A partir do cache, podemos gerar um **conjunto de dados de 1 GB**, com a propriedade que cada item no conjunto de dados depende de apenas um pequeno número de itens do cache. Clientes e mineradores completos armazenam o conjunto de dados. O conjunto de dados cresce linearmente com o tempo.
-4. Mineração envolve pegar fatias aleatórias do conjunto de dados e fazer hashing deles juntos. A verificação pode ser feita com pouca memória usando o cache para regenerar os pedaços específicos do conjunto de dados que você precisa, então você só precisa armazenar o cache.
-
-O grande conjunto de dados é atualizado uma vez a cada 30.000 blocos, então o maior esforço de um minerador é ler o conjunto de dados, e não fazer alterações nele.
-
-## Definições {#definitions}
-
-Nós empregamos as seguintes definições:
-
-```
-WORD_BYTES = 4 # bytes in word
-DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis
-DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch
-CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis
-CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch
-CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache
-EPOCH_LENGTH = 30000 # blocks per epoch
-MIX_BYTES = 128 # width of mix
-HASH_BYTES = 64 # hash length in bytes
-DATASET_PARENTS = 256 # number of parents of each dataset element
-CACHE_ROUNDS = 3 # number of rounds in cache production
-ACCESSES = 64 # number of accesses in hashimoto loop
-```
-
-### O uso de 'SHA3' {#sha3}
-
-O desenvolvimento do Ethereum coincidiu com o desenvolvimento do padrão SHA3, e o processo de padrões fez uma alteração tardia no preenchimento do algoritmo de hash finalizado, para que os hashes "sha3_256" e "sha3_512" do Ethereum não sejam hashes sha3 padrão, mas uma variante muitas vezes referida como "Keccak-256" e "Keccak-512" em outros contextos. Veja a discussão, por exemplo, [aqui](https://eips.ethereum.org/EIPS/eip-1803), [aqui](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) ou [aqui](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057).
-
-Tenha isso em mente, já que hashes "sha3" são referidos na descrição do algoritmo abaixo.
-
-## Parâmetros {#parameters}
-
-Os parâmetros do cache Ethash e do conjunto de dados dependem do número do bloco. Tamanho do cache e tamanho do conjunto de dados crescem linearmente; entretanto, sempre tomamos o mais alto prime abaixo do limiar de crescimento linear, a fim de reduzir o risco de regularidades acidentais que conduzem a comportamentos cíclicos.
-
-```python
-def get_cache_size(block_number):
- sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
- sz -= HASH_BYTES
- while not isprime(sz / HASH_BYTES):
- sz -= 2 * HASH_BYTES
- return sz
-
-def get_full_size(block_number):
- sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
- sz -= MIX_BYTES
- while not isprime(sz / MIX_BYTES):
- sz -= 2 * MIX_BYTES
- return sz
-```
-
-Tabelas de conjunto de dados e valores de tamanho do cache são fornecidos no apêndice.
-
-## Geração de cache {#cache-generation}
-
-Agora, especificamos a função para produzir um cache:
-
-```python
-def mkcache(cache_size, seed):
- n = cache_size // HASH_BYTES
-
- # Sequentially produce the initial dataset
- o = [sha3_512(seed)]
- for i in range(1, n):
- o.append(sha3_512(o[-1]))
-
- # Use a low-round version of randmemohash
- for _ in range(CACHE_ROUNDS):
- for i in range(n):
- v = o[i][0] % n
- o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v]))
-
- return o
-```
-
-O processo de produção de cache envolve primeiro preenchimento sequencial de 32 MB de memória e depois executar duas passagens do algoritmo _RandMemoHash_ de Sergio Demian Lerner de [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). A saída é um conjunto de 524288 valores de 64-bytes.
-
-## Função de agregação de dados {#date-aggregation-function}
-
-Usamos um algoritmo inspirado no [FNV hash](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) em alguns casos como um substituto não associativo para o XOR. Observe que multiplicamos o primo com a entrada completa de 32 bits, em contraste com a especificação FNV-1 que multiplica o primo por um byte (octeto) por sua vez.
-
-```python
-FNV_PRIME = 0x01000193
-
-def fnv(v1, v2):
- return ((v1 * FNV_PRIME) ^ v2) % 2**32
-```
-
-Observe que até mesmo o yellow paper especifica fnv como v1\*(FNV_PRIME ^ v2). Todas as implementações atuais usam consistentemente a definição acima.
-
-## Cálculo completo do conjunto de dados {#full-dataset-calculation}
-
-Cada item de 64 bytes no conjunto de dados completo de 1 GB é calculado da seguinte forma:
-
-```python
-def calc_dataset_item(cache, i):
- n = len(cache)
- r = HASH_BYTES // WORD_BYTES
- # initialize the mix
- mix = copy.copy(cache[i % n])
- mix[0] ^= i
- mix = sha3_512(mix)
- # fnv it with a lot of random cache nodes based on i
- for j in range(DATASET_PARENTS):
- cache_index = fnv(i ^ j, mix[j % r])
- mix = map(fnv, mix, cache[cache_index % n])
- return sha3_512(mix)
-```
-
-Essencialmente, combinamos dados de 256 nós de cache selecionados de maneira pseudo-aleatória e fazemos o hash para calcular o nó do conjunto de dados. Todo o conjunto de dados é então gerado por:
-
-```python
-def calc_dataset(full_size, cache):
- return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
-```
-
-## Loop principal {#main-loop}
-
-Agora, especificamos o loop padrão "hashimoto" principal, onde agregamos dados do conjunto de dados completo para produzir nosso valor final para um cabeçalho em particular ou nonce. No código abaixo, `header` representa o _hash _SHA3-256 da representação RLP de um cabeçalho de bloco _truncado_, ou seja, de um cabeçalho excluindo os campos **mixHash** e **nonce**. `nonce` é os oito bytes de um inteiro sem sinal de 64 bits na ordem big-endian. Então `nonce[::-1]` é a representação little-endian de oito bytes desse valor:
-
-```python
-def hashimoto(header, nonce, full_size, dataset_lookup):
- n = full_size / HASH_BYTES
- w = MIX_BYTES // WORD_BYTES
- mixhashes = MIX_BYTES / HASH_BYTES
- # combine header+nonce into a 64 byte seed
- s = sha3_512(header + nonce[::-1])
- # start the mix with replicated s
- mix = []
- for _ in range(MIX_BYTES / HASH_BYTES):
- mix.extend(s)
- # mix in random dataset nodes
- for i in range(ACCESSES):
- p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
- newdata = []
- for j in range(MIX_BYTES / HASH_BYTES):
- newdata.extend(dataset_lookup(p + j))
- mix = map(fnv, mix, newdata)
- # compress mix
- cmix = []
- for i in range(0, len(mix), 4):
- cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
- return {
- "mix digest": serialize_hash(cmix),
- "result": serialize_hash(sha3_256(s+cmix))
- }
-
-def hashimoto_light(full_size, cache, header, nonce):
- return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))
-
-def hashimoto_full(full_size, dataset, header, nonce):
- return hashimoto(header, nonce, full_size, lambda x: dataset[x])
-```
-
-Essencialmente, mantemos um "mix" de 128 bytes de largura, e de maneira sequencial e repetida buscamos 128 bytes do conjunto de dados completo e usamos a função `fnv` para combiná-lo com o mix. 128 bytes de acesso sequencial são usados para que cada rodada do algoritmo sempre busque uma página inteira de RAM, minimizando a possibilidade de que o buffer de pesquisa de tradução perca o que os ASICs teoricamente seriam capazes de evitar.
-
-Se a saída deste algoritmo está abaixo do alvo desejado, então o nonce é válido. Observe que a aplicação extra de `sha3_256` no final garante que existe um nonce intermediário que pode ser fornecido para provar que pelo menos uma pequena quantidade de trabalho foi feita; esta rápida verificação de prova de trabalho pode ser usada para fins anti-DDoS. Serve também para dar garantias estatísticas de que o resultado é um número imparcial de 256 bits.
-
-## Mineração {#mining}
-
-O algoritmo de mineração é definido da seguinte forma:
-
-```python
-def mine(full_size, dataset, header, difficulty):
- # zero-pad target to compare with hash on the same digit
- target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
- from random import randint
- nonce = randint(0, 2**64)
- while hashimoto_full(full_size, dataset, header, nonce) > target:
- nonce = (nonce + 1) % 2**64
- return nonce
-```
-
-## Definição do hash seed {#seed-hash}
-
-Para calcular o hash seed que seria usado para minerar no topo de um determinado bloco, usamos o seguinte algoritmo:
-
-```python
- def get_seedhash(block):
- s = '\x00' * 32
- for i in range(block.number // EPOCH_LENGTH):
- s = serialize_hash(sha3_256(s))
- return s
-```
-
-Observe que, para que a mineração e a verificação aconteçam sem contratempos, recomendamos pré-computar os hashes seed e conjuntos de dados futuros em threads separadas.
-
-## Leitura adicional {#further-reading}
-
-_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_
-
-## Apêndice {#appendix}
-
-O código a seguir deve ser precedido se você estiver interessado em executar a especificação python acima como código.
-
-```python
-import sha3, copy
-
-# Assumes little endian bit ordering (same as Intel architectures)
-def decode_int(s):
- return int(s[::-1].encode('hex'), 16) if s else 0
-
-def encode_int(s):
- a = "%x" % s
- return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1]
-
-def zpad(s, length):
- return s + '\x00' * max(0, length - len(s))
-
-def serialize_hash(h):
- return ''.join([zpad(encode_int(x), 4) for x in h])
-
-def deserialize_hash(h):
- return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)]
-
-def hash_words(h, sz, x):
- if isinstance(x, list):
- x = serialize_hash(x)
- y = h(x)
- return deserialize_hash(y)
-
-def serialize_cache(ds):
- return ''.join([serialize_hash(h) for h in ds])
-
-serialize_dataset = serialize_cache
-
-# sha3 hash function, outputs 64 bytes
-def sha3_512(x):
- return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
-
-def sha3_256(x):
- return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x)
-
-def xor(a, b):
- return a ^ b
-
-def isprime(x):
- for i in range(2, int(x**0.5)):
- if x % i == 0:
- return False
- return True
-```
-
-### Tamanho dos dados {#data-sizes}
-
-As tabelas de pesquisa a seguir fornecem aproximadamente 2.048 períodos eletrônicos (epoch) tabulados de tamanhos de dados e tamanhos de cache.
-
-```python
-def get_datasize(block_number):
- return data_sizes[block_number // EPOCH_LENGTH]
-
-def get_cachesize(block_number):
- return cache_sizes[block_number // EPOCH_LENGTH]
-
-data_sizes = [
-1073739904, 1082130304, 1090514816, 1098906752, 1107293056,
-1115684224, 1124070016, 1132461952, 1140849536, 1149232768,
-1157627776, 1166013824, 1174404736, 1182786944, 1191180416,
-1199568512, 1207958912, 1216345216, 1224732032, 1233124736,
-1241513344, 1249902464, 1258290304, 1266673792, 1275067264,
-1283453312, 1291844992, 1300234112, 1308619904, 1317010048,
-1325397376, 1333787776, 1342176128, 1350561664, 1358954368,
-1367339392, 1375731584, 1384118144, 1392507008, 1400897408,
-1409284736, 1417673344, 1426062464, 1434451072, 1442839168,
-1451229056, 1459615616, 1468006016, 1476394112, 1484782976,
-1493171584, 1501559168, 1509948032, 1518337664, 1526726528,
-1535114624, 1543503488, 1551892096, 1560278656, 1568669056,
-1577056384, 1585446272, 1593831296, 1602219392, 1610610304,
-1619000192, 1627386752, 1635773824, 1644164224, 1652555648,
-1660943488, 1669332608, 1677721216, 1686109312, 1694497664,
-1702886272, 1711274624, 1719661184, 1728047744, 1736434816,
-1744829056, 1753218944, 1761606272, 1769995904, 1778382464,
-1786772864, 1795157888, 1803550592, 1811937664, 1820327552,
-1828711552, 1837102976, 1845488768, 1853879936, 1862269312,
-1870656896, 1879048064, 1887431552, 1895825024, 1904212096,
-1912601216, 1920988544, 1929379456, 1937765504, 1946156672,
-1954543232, 1962932096, 1971321728, 1979707264, 1988093056,
-1996487552, 2004874624, 2013262208, 2021653888, 2030039936,
-2038430848, 2046819968, 2055208576, 2063596672, 2071981952,
-2080373632, 2088762752, 2097149056, 2105539712, 2113928576,
-2122315136, 2130700672, 2139092608, 2147483264, 2155872128,
-2164257664, 2172642176, 2181035392, 2189426048, 2197814912,
-2206203008, 2214587264, 2222979712, 2231367808, 2239758208,
-2248145024, 2256527744, 2264922752, 2273312128, 2281701248,
-2290086272, 2298476672, 2306867072, 2315251072, 2323639168,
-2332032128, 2340420224, 2348808064, 2357196416, 2365580416,
-2373966976, 2382363008, 2390748544, 2399139968, 2407530368,
-2415918976, 2424307328, 2432695424, 2441084288, 2449472384,
-2457861248, 2466247808, 2474637184, 2483026816, 2491414144,
-2499803776, 2508191872, 2516582272, 2524970368, 2533359232,
-2541743488, 2550134144, 2558525056, 2566913408, 2575301504,
-2583686528, 2592073856, 2600467328, 2608856192, 2617240448,
-2625631616, 2634022016, 2642407552, 2650796416, 2659188352,
-2667574912, 2675965312, 2684352896, 2692738688, 2701130624,
-2709518464, 2717907328, 2726293376, 2734685056, 2743073152,
-2751462016, 2759851648, 2768232832, 2776625536, 2785017728,
-2793401984, 2801794432, 2810182016, 2818571648, 2826959488,
-2835349376, 2843734144, 2852121472, 2860514432, 2868900992,
-2877286784, 2885676928, 2894069632, 2902451584, 2910843008,
-2919234688, 2927622784, 2936011648, 2944400768, 2952789376,
-2961177728, 2969565568, 2977951616, 2986338944, 2994731392,
-3003120256, 3011508352, 3019895936, 3028287104, 3036675968,
-3045063808, 3053452928, 3061837696, 3070228352, 3078615424,
-3087003776, 3095394944, 3103782272, 3112173184, 3120562048,
-3128944768, 3137339264, 3145725056, 3154109312, 3162505088,
-3170893184, 3179280256, 3187669376, 3196056704, 3204445568,
-3212836736, 3221224064, 3229612928, 3238002304, 3246391168,
-3254778496, 3263165824, 3271556224, 3279944576, 3288332416,
-3296719232, 3305110912, 3313500032, 3321887104, 3330273152,
-3338658944, 3347053184, 3355440512, 3363827072, 3372220288,
-3380608384, 3388997504, 3397384576, 3405774208, 3414163072,
-3422551936, 3430937984, 3439328384, 3447714176, 3456104576,
-3464493952, 3472883584, 3481268864, 3489655168, 3498048896,
-3506434432, 3514826368, 3523213952, 3531603584, 3539987072,
-3548380288, 3556763264, 3565157248, 3573545344, 3581934464,
-3590324096, 3598712704, 3607098752, 3615488384, 3623877248,
-3632265856, 3640646528, 3649043584, 3657430144, 3665821568,
-3674207872, 3682597504, 3690984832, 3699367808, 3707764352,
-3716152448, 3724541056, 3732925568, 3741318016, 3749706368,
-3758091136, 3766481536, 3774872704, 3783260032, 3791650432,
-3800036224, 3808427648, 3816815488, 3825204608, 3833592704,
-3841981568, 3850370432, 3858755968, 3867147904, 3875536256,
-3883920512, 3892313728, 3900702592, 3909087872, 3917478784,
-3925868416, 3934256512, 3942645376, 3951032192, 3959422336,
-3967809152, 3976200064, 3984588416, 3992974976, 4001363584,
-4009751168, 4018141312, 4026530432, 4034911616, 4043308928,
-4051695488, 4060084352, 4068472448, 4076862848, 4085249408,
-4093640576, 4102028416, 4110413696, 4118805632, 4127194496,
-4135583104, 4143971968, 4152360832, 4160746112, 4169135744,
-4177525888, 4185912704, 4194303616, 4202691968, 4211076736,
-4219463552, 4227855488, 4236246656, 4244633728, 4253022848,
-4261412224, 4269799808, 4278184832, 4286578048, 4294962304,
-4303349632, 4311743104, 4320130432, 4328521088, 4336909184,
-4345295488, 4353687424, 4362073472, 4370458496, 4378852736,
-4387238528, 4395630208, 4404019072, 4412407424, 4420790656,
-4429182848, 4437571456, 4445962112, 4454344064, 4462738048,
-4471119232, 4479516544, 4487904128, 4496289664, 4504682368,
-4513068416, 4521459584, 4529846144, 4538232704, 4546619776,
-4555010176, 4563402112, 4571790208, 4580174464, 4588567936,
-4596957056, 4605344896, 4613734016, 4622119808, 4630511488,
-4638898816, 4647287936, 4655675264, 4664065664, 4672451968,
-4680842624, 4689231488, 4697620352, 4706007424, 4714397056,
-4722786176, 4731173248, 4739562368, 4747951744, 4756340608,
-4764727936, 4773114496, 4781504384, 4789894784, 4798283648,
-4806667648, 4815059584, 4823449472, 4831835776, 4840226176,
-4848612224, 4857003392, 4865391488, 4873780096, 4882169728,
-4890557312, 4898946944, 4907333248, 4915722368, 4924110976,
-4932499328, 4940889728, 4949276032, 4957666432, 4966054784,
-4974438016, 4982831488, 4991221376, 4999607168, 5007998848,
-5016386432, 5024763776, 5033164672, 5041544576, 5049941888,
-5058329728, 5066717056, 5075107456, 5083494272, 5091883904,
-5100273536, 5108662144, 5117048192, 5125436032, 5133827456,
-5142215296, 5150605184, 5158993024, 5167382144, 5175769472,
-5184157568, 5192543872, 5200936064, 5209324928, 5217711232,
-5226102656, 5234490496, 5242877312, 5251263872, 5259654016,
-5268040832, 5276434304, 5284819328, 5293209728, 5301598592,
-5309986688, 5318374784, 5326764416, 5335151488, 5343542144,
-5351929472, 5360319872, 5368706944, 5377096576, 5385484928,
-5393871232, 5402263424, 5410650496, 5419040384, 5427426944,
-5435816576, 5444205952, 5452594816, 5460981376, 5469367936,
-5477760896, 5486148736, 5494536832, 5502925952, 5511315328,
-5519703424, 5528089984, 5536481152, 5544869504, 5553256064,
-5561645696, 5570032768, 5578423936, 5586811264, 5595193216,
-5603585408, 5611972736, 5620366208, 5628750464, 5637143936,
-5645528192, 5653921408, 5662310272, 5670694784, 5679082624,
-5687474048, 5695864448, 5704251008, 5712641408, 5721030272,
-5729416832, 5737806208, 5746194304, 5754583936, 5762969984,
-5771358592, 5779748224, 5788137856, 5796527488, 5804911232,
-5813300608, 5821692544, 5830082176, 5838468992, 5846855552,
-5855247488, 5863636096, 5872024448, 5880411008, 5888799872,
-5897186432, 5905576832, 5913966976, 5922352768, 5930744704,
-5939132288, 5947522432, 5955911296, 5964299392, 5972688256,
-5981074304, 5989465472, 5997851008, 6006241408, 6014627968,
-6023015552, 6031408256, 6039796096, 6048185216, 6056574848,
-6064963456, 6073351808, 6081736064, 6090128768, 6098517632,
-6106906496, 6115289216, 6123680896, 6132070016, 6140459648,
-6148849024, 6157237376, 6165624704, 6174009728, 6182403712,
-6190792064, 6199176064, 6207569792, 6215952256, 6224345216,
-6232732544, 6241124224, 6249510272, 6257899136, 6266287744,
-6274676864, 6283065728, 6291454336, 6299843456, 6308232064,
-6316620928, 6325006208, 6333395584, 6341784704, 6350174848,
-6358562176, 6366951296, 6375337856, 6383729536, 6392119168,
-6400504192, 6408895616, 6417283456, 6425673344, 6434059136,
-6442444672, 6450837376, 6459223424, 6467613056, 6476004224,
-6484393088, 6492781952, 6501170048, 6509555072, 6517947008,
-6526336384, 6534725504, 6543112832, 6551500672, 6559888768,
-6568278656, 6576662912, 6585055616, 6593443456, 6601834112,
-6610219648, 6618610304, 6626999168, 6635385472, 6643777408,
-6652164224, 6660552832, 6668941952, 6677330048, 6685719424,
-6694107776, 6702493568, 6710882176, 6719274112, 6727662976,
-6736052096, 6744437632, 6752825984, 6761213824, 6769604224,
-6777993856, 6786383488, 6794770816, 6803158144, 6811549312,
-6819937664, 6828326528, 6836706176, 6845101696, 6853491328,
-6861880448, 6870269312, 6878655104, 6887046272, 6895433344,
-6903822208, 6912212864, 6920596864, 6928988288, 6937377152,
-6945764992, 6954149248, 6962544256, 6970928768, 6979317376,
-6987709312, 6996093824, 7004487296, 7012875392, 7021258624,
-7029652352, 7038038912, 7046427776, 7054818944, 7063207808,
-7071595136, 7079980928, 7088372608, 7096759424, 7105149824,
-7113536896, 7121928064, 7130315392, 7138699648, 7147092352,
-7155479168, 7163865728, 7172249984, 7180648064, 7189036672,
-7197424768, 7205810816, 7214196608, 7222589824, 7230975104,
-7239367552, 7247755904, 7256145536, 7264533376, 7272921472,
-7281308032, 7289694848, 7298088832, 7306471808, 7314864512,
-7323253888, 7331643008, 7340029568, 7348419712, 7356808832,
-7365196672, 7373585792, 7381973888, 7390362752, 7398750592,
-7407138944, 7415528576, 7423915648, 7432302208, 7440690304,
-7449080192, 7457472128, 7465860992, 7474249088, 7482635648,
-7491023744, 7499412608, 7507803008, 7516192384, 7524579968,
-7532967296, 7541358464, 7549745792, 7558134656, 7566524032,
-7574912896, 7583300992, 7591690112, 7600075136, 7608466816,
-7616854912, 7625244544, 7633629824, 7642020992, 7650410368,
-7658794112, 7667187328, 7675574912, 7683961984, 7692349568,
-7700739712, 7709130368, 7717519232, 7725905536, 7734295424,
-7742683264, 7751069056, 7759457408, 7767849088, 7776238208,
-7784626816, 7793014912, 7801405312, 7809792128, 7818179968,
-7826571136, 7834957184, 7843347328, 7851732352, 7860124544,
-7868512384, 7876902016, 7885287808, 7893679744, 7902067072,
-7910455936, 7918844288, 7927230848, 7935622784, 7944009344,
-7952400256, 7960786048, 7969176704, 7977565312, 7985953408,
-7994339968, 8002730368, 8011119488, 8019508096, 8027896192,
-8036285056, 8044674688, 8053062272, 8061448832, 8069838464,
-8078227328, 8086616704, 8095006592, 8103393664, 8111783552,
-8120171392, 8128560256, 8136949376, 8145336704, 8153726848,
-8162114944, 8170503296, 8178891904, 8187280768, 8195669632,
-8204058496, 8212444544, 8220834176, 8229222272, 8237612672,
-8246000768, 8254389376, 8262775168, 8271167104, 8279553664,
-8287944064, 8296333184, 8304715136, 8313108352, 8321497984,
-8329885568, 8338274432, 8346663296, 8355052928, 8363441536,
-8371828352, 8380217984, 8388606592, 8396996224, 8405384576,
-8413772672, 8422161536, 8430549376, 8438939008, 8447326592,
-8455715456, 8464104832, 8472492928, 8480882048, 8489270656,
-8497659776, 8506045312, 8514434944, 8522823808, 8531208832,
-8539602304, 8547990656, 8556378752, 8564768384, 8573154176,
-8581542784, 8589933952, 8598322816, 8606705024, 8615099264,
-8623487872, 8631876992, 8640264064, 8648653952, 8657040256,
-8665430656, 8673820544, 8682209152, 8690592128, 8698977152,
-8707374464, 8715763328, 8724151424, 8732540032, 8740928384,
-8749315712, 8757704576, 8766089344, 8774480768, 8782871936,
-8791260032, 8799645824, 8808034432, 8816426368, 8824812928,
-8833199488, 8841591424, 8849976448, 8858366336, 8866757248,
-8875147136, 8883532928, 8891923328, 8900306816, 8908700288,
-8917088384, 8925478784, 8933867392, 8942250368, 8950644608,
-8959032704, 8967420544, 8975809664, 8984197504, 8992584064,
-9000976256, 9009362048, 9017752448, 9026141312, 9034530688,
-9042917504, 9051307904, 9059694208, 9068084864, 9076471424,
-9084861824, 9093250688, 9101638528, 9110027648, 9118416512,
-9126803584, 9135188096, 9143581312, 9151969664, 9160356224,
-9168747136, 9177134464, 9185525632, 9193910144, 9202302848,
-9210690688, 9219079552, 9227465344, 9235854464, 9244244864,
-9252633472, 9261021824, 9269411456, 9277799296, 9286188928,
-9294574208, 9302965888, 9311351936, 9319740032, 9328131968,
-9336516736, 9344907392, 9353296768, 9361685888, 9370074752,
-9378463616, 9386849408, 9395239808, 9403629184, 9412016512,
-9420405376, 9428795008, 9437181568, 9445570688, 9453960832,
-9462346624, 9470738048, 9479121536, 9487515008, 9495903616,
-9504289664, 9512678528, 9521067904, 9529456256, 9537843584,
-9546233728, 9554621312, 9563011456, 9571398784, 9579788672,
-9588178304, 9596567168, 9604954496, 9613343104, 9621732992,
-9630121856, 9638508416, 9646898816, 9655283584, 9663675776,
-9672061312, 9680449664, 9688840064, 9697230464, 9705617536,
-9714003584, 9722393984, 9730772608, 9739172224, 9747561088,
-9755945344, 9764338816, 9772726144, 9781116544, 9789503872,
-9797892992, 9806282624, 9814670464, 9823056512, 9831439232,
-9839833984, 9848224384, 9856613504, 9865000576, 9873391232,
-9881772416, 9890162816, 9898556288, 9906940544, 9915333248,
-9923721088, 9932108672, 9940496512, 9948888448, 9957276544,
-9965666176, 9974048384, 9982441088, 9990830464, 9999219584,
-10007602816, 10015996544, 10024385152, 10032774016, 10041163648,
-10049548928, 10057940096, 10066329472, 10074717824, 10083105152,
-10091495296, 10099878784, 10108272256, 10116660608, 10125049216,
-10133437312, 10141825664, 10150213504, 10158601088, 10166991232,
-10175378816, 10183766144, 10192157312, 10200545408, 10208935552,
-10217322112, 10225712768, 10234099328, 10242489472, 10250876032,
-10259264896, 10267656064, 10276042624, 10284429184, 10292820352,
-10301209472, 10309598848, 10317987712, 10326375296, 10334763392,
-10343153536, 10351541632, 10359930752, 10368318592, 10376707456,
-10385096576, 10393484672, 10401867136, 10410262144, 10418647424,
-10427039104, 10435425664, 10443810176, 10452203648, 10460589952,
-10468982144, 10477369472, 10485759104, 10494147712, 10502533504,
-10510923392, 10519313536, 10527702656, 10536091264, 10544478592,
-10552867712, 10561255808, 10569642368, 10578032768, 10586423168,
-10594805632, 10603200128, 10611588992, 10619976064, 10628361344,
-10636754048, 10645143424, 10653531776, 10661920384, 10670307968,
-10678696832, 10687086464, 10695475072, 10703863168, 10712246144,
-10720639616, 10729026688, 10737414784, 10745806208, 10754190976,
-10762581376, 10770971264, 10779356288, 10787747456, 10796135552,
-10804525184, 10812915584, 10821301888, 10829692288, 10838078336,
-10846469248, 10854858368, 10863247232, 10871631488, 10880023424,
-10888412032, 10896799616, 10905188992, 10913574016, 10921964672,
-10930352768, 10938742912, 10947132544, 10955518592, 10963909504,
-10972298368, 10980687488, 10989074816, 10997462912, 11005851776,
-11014241152, 11022627712, 11031017344, 11039403904, 11047793024,
-11056184704, 11064570752, 11072960896, 11081343872, 11089737856,
-11098128256, 11106514816, 11114904448, 11123293568, 11131680128,
-11140065152, 11148458368, 11156845696, 11165236864, 11173624192,
-11182013824, 11190402688, 11198790784, 11207179136, 11215568768,
-11223957376, 11232345728, 11240734592, 11249122688, 11257511296,
-11265899648, 11274285952, 11282675584, 11291065472, 11299452544,
-11307842432, 11316231296, 11324616832, 11333009024, 11341395584,
-11349782656, 11358172288, 11366560384, 11374950016, 11383339648,
-11391721856, 11400117376, 11408504192, 11416893568, 11425283456,
-11433671552, 11442061184, 11450444672, 11458837888, 11467226752,
-11475611776, 11484003968, 11492392064, 11500780672, 11509169024,
-11517550976, 11525944448, 11534335616, 11542724224, 11551111808,
-11559500672, 11567890304, 11576277376, 11584667008, 11593056128,
-11601443456, 11609830016, 11618221952, 11626607488, 11634995072,
-11643387776, 11651775104, 11660161664, 11668552576, 11676940928,
-11685330304, 11693718656, 11702106496, 11710496128, 11718882688,
-11727273088, 11735660416, 11744050048, 11752437376, 11760824704,
-11769216128, 11777604736, 11785991296, 11794381952, 11802770048,
-11811157888, 11819548544, 11827932544, 11836324736, 11844713344,
-11853100928, 11861486464, 11869879936, 11878268032, 11886656896,
-11895044992, 11903433088, 11911822976, 11920210816, 11928600448,
-11936987264, 11945375872, 11953761152, 11962151296, 11970543488,
-11978928512, 11987320448, 11995708288, 12004095104, 12012486272,
-12020875136, 12029255552, 12037652096, 12046039168, 12054429568,
-12062813824, 12071206528, 12079594624, 12087983744, 12096371072,
-12104759936, 12113147264, 12121534592, 12129924992, 12138314624,
-12146703232, 12155091584, 12163481216, 12171864704, 12180255872,
-12188643968, 12197034112, 12205424512, 12213811328, 12222199424,
-12230590336, 12238977664, 12247365248, 12255755392, 12264143488,
-12272531584, 12280920448, 12289309568, 12297694592, 12306086528,
-12314475392, 12322865024, 12331253632, 12339640448, 12348029312,
-12356418944, 12364805248, 12373196672, 12381580928, 12389969024,
-12398357632, 12406750592, 12415138432, 12423527552, 12431916416,
-12440304512, 12448692352, 12457081216, 12465467776, 12473859968,
-12482245504, 12490636672, 12499025536, 12507411584, 12515801728,
-12524190592, 12532577152, 12540966272, 12549354368, 12557743232,
-12566129536, 12574523264, 12582911872, 12591299456, 12599688064,
-12608074624, 12616463488, 12624845696, 12633239936, 12641631616,
-12650019968, 12658407296, 12666795136, 12675183232, 12683574656,
-12691960192, 12700350592, 12708740224, 12717128576, 12725515904,
-12733906816, 12742295168, 12750680192, 12759071872, 12767460736,
-12775848832, 12784236928, 12792626816, 12801014656, 12809404288,
-12817789312, 12826181504, 12834568832, 12842954624, 12851345792,
-12859732352, 12868122496, 12876512128, 12884901248, 12893289088,
-12901672832, 12910067584, 12918455168, 12926842496, 12935232896,
-12943620736, 12952009856, 12960396928, 12968786816, 12977176192,
-12985563776, 12993951104, 13002341504, 13010730368, 13019115392,
-13027506304, 13035895168, 13044272512, 13052673152, 13061062528,
-13069446272, 13077838976, 13086227072, 13094613632, 13103000192,
-13111393664, 13119782528, 13128157568, 13136559232, 13144945024,
-13153329536, 13161724288, 13170111872, 13178502784, 13186884736,
-13195279744, 13203667072, 13212057472, 13220445824, 13228832128,
-13237221248, 13245610624, 13254000512, 13262388352, 13270777472,
-13279166336, 13287553408, 13295943296, 13304331904, 13312719488,
-13321108096, 13329494656, 13337885824, 13346274944, 13354663808,
-13363051136, 13371439232, 13379825024, 13388210816, 13396605056,
-13404995456, 13413380224, 13421771392, 13430159744, 13438546048,
-13446937216, 13455326848, 13463708288, 13472103808, 13480492672,
-13488875648, 13497269888, 13505657728, 13514045312, 13522435712,
-13530824576, 13539210112, 13547599232, 13555989376, 13564379008,
-13572766336, 13581154432, 13589544832, 13597932928, 13606320512,
-13614710656, 13623097472, 13631477632, 13639874944, 13648264064,
-13656652928, 13665041792, 13673430656, 13681818496, 13690207616,
-13698595712, 13706982272, 13715373184, 13723762048, 13732150144,
-13740536704, 13748926592, 13757316224, 13765700992, 13774090112,
-13782477952, 13790869376, 13799259008, 13807647872, 13816036736,
-13824425344, 13832814208, 13841202304, 13849591424, 13857978752,
-13866368896, 13874754688, 13883145344, 13891533184, 13899919232,
-13908311168, 13916692096, 13925085056, 13933473152, 13941866368,
-13950253696, 13958643584, 13967032192, 13975417216, 13983807616,
-13992197504, 14000582272, 14008973696, 14017363072, 14025752192,
-14034137984, 14042528384, 14050918016, 14059301504, 14067691648,
-14076083584, 14084470144, 14092852352, 14101249664, 14109635968,
-14118024832, 14126407552, 14134804352, 14143188608, 14151577984,
-14159968384, 14168357248, 14176741504, 14185127296, 14193521024,
-14201911424, 14210301824, 14218685056, 14227067264, 14235467392,
-14243855488, 14252243072, 14260630144, 14269021568, 14277409408,
-14285799296, 14294187904, 14302571392, 14310961792, 14319353728,
-14327738752, 14336130944, 14344518784, 14352906368, 14361296512,
-14369685376, 14378071424, 14386462592, 14394848128, 14403230848,
-14411627392, 14420013952, 14428402304, 14436793472, 14445181568,
-14453569664, 14461959808, 14470347904, 14478737024, 14487122816,
-14495511424, 14503901824, 14512291712, 14520677504, 14529064832,
-14537456768, 14545845632, 14554234496, 14562618496, 14571011456,
-14579398784, 14587789184, 14596172672, 14604564608, 14612953984,
-14621341312, 14629724288, 14638120832, 14646503296, 14654897536,
-14663284864, 14671675264, 14680061056, 14688447616, 14696835968,
-14705228416, 14713616768, 14722003328, 14730392192, 14738784128,
-14747172736, 14755561088, 14763947648, 14772336512, 14780725376,
-14789110144, 14797499776, 14805892736, 14814276992, 14822670208,
-14831056256, 14839444352, 14847836032, 14856222848, 14864612992,
-14872997504, 14881388672, 14889775744, 14898165376, 14906553472,
-14914944896, 14923329664, 14931721856, 14940109696, 14948497024,
-14956887424, 14965276544, 14973663616, 14982053248, 14990439808,
-14998830976, 15007216768, 15015605888, 15023995264, 15032385152,
-15040768384, 15049154944, 15057549184, 15065939072, 15074328448,
-15082715008, 15091104128, 15099493504, 15107879296, 15116269184,
-15124659584, 15133042304, 15141431936, 15149824384, 15158214272,
-15166602368, 15174991232, 15183378304, 15191760512, 15200154496,
-15208542592, 15216931712, 15225323392, 15233708416, 15242098048,
-15250489216, 15258875264, 15267265408, 15275654528, 15284043136,
-15292431488, 15300819584, 15309208192, 15317596544, 15325986176,
-15334374784, 15342763648, 15351151744, 15359540608, 15367929728,
-15376318336, 15384706432, 15393092992, 15401481856, 15409869952,
-15418258816, 15426649984, 15435037568, 15443425664, 15451815296,
-15460203392, 15468589184, 15476979328, 15485369216, 15493755776,
-15502146944, 15510534272, 15518924416, 15527311232, 15535699072,
-15544089472, 15552478336, 15560866688, 15569254528, 15577642624,
-15586031488, 15594419072, 15602809472, 15611199104, 15619586432,
-15627975296, 15636364928, 15644753792, 15653141888, 15661529216,
-15669918848, 15678305152, 15686696576, 15695083136, 15703474048,
-15711861632, 15720251264, 15728636288, 15737027456, 15745417088,
-15753804928, 15762194048, 15770582656, 15778971008, 15787358336,
-15795747712, 15804132224, 15812523392, 15820909696, 15829300096,
-15837691264, 15846071936, 15854466944, 15862855808, 15871244672,
-15879634816, 15888020608, 15896409728, 15904799104, 15913185152,
-15921577088, 15929966464, 15938354816, 15946743424, 15955129472,
-15963519872, 15971907968, 15980296064, 15988684928, 15997073024,
-16005460864, 16013851264, 16022241152, 16030629248, 16039012736,
-16047406976, 16055794816, 16064181376, 16072571264, 16080957824,
-16089346688, 16097737856, 16106125184, 16114514816, 16122904192,
-16131292544, 16139678848, 16148066944, 16156453504, 16164839552,
-16173236096, 16181623424, 16190012032, 16198401152, 16206790528,
-16215177344, 16223567744, 16231956352, 16240344704, 16248731008,
-16257117824, 16265504384, 16273898624, 16282281856, 16290668672,
-16299064192, 16307449216, 16315842176, 16324230016, 16332613504,
-16341006464, 16349394304, 16357783168, 16366172288, 16374561664,
-16382951296, 16391337856, 16399726208, 16408116352, 16416505472,
-16424892032, 16433282176, 16441668224, 16450058624, 16458448768,
-16466836864, 16475224448, 16483613056, 16492001408, 16500391808,
-16508779648, 16517166976, 16525555328, 16533944192, 16542330752,
-16550719616, 16559110528, 16567497088, 16575888512, 16584274816,
-16592665472, 16601051008, 16609442944, 16617832064, 16626218624,
-16634607488, 16642996096, 16651385728, 16659773824, 16668163712,
-16676552576, 16684938112, 16693328768, 16701718144, 16710095488,
-16718492288, 16726883968, 16735272832, 16743661184, 16752049792,
-16760436608, 16768827008, 16777214336, 16785599104, 16793992832,
-16802381696, 16810768768, 16819151744, 16827542656, 16835934848,
-16844323712, 16852711552, 16861101952, 16869489536, 16877876864,
-16886265728, 16894653056, 16903044736, 16911431296, 16919821696,
-16928207488, 16936592768, 16944987776, 16953375616, 16961763968,
-16970152832, 16978540928, 16986929536, 16995319168, 17003704448,
-17012096896, 17020481152, 17028870784, 17037262208, 17045649536,
-17054039936, 17062426496, 17070814336, 17079205504, 17087592064,
-17095978112, 17104369024, 17112759424, 17121147776, 17129536384,
-17137926016, 17146314368, 17154700928, 17163089792, 17171480192,
-17179864192, 17188256896, 17196644992, 17205033856, 17213423488,
-17221811072, 17230198912, 17238588032, 17246976896, 17255360384,
-17263754624, 17272143232, 17280530048, 17288918912, 17297309312,
-17305696384, 17314085504, 17322475136, 17330863744, 17339252096,
-17347640192, 17356026496, 17364413824, 17372796544, 17381190016,
-17389583488, 17397972608, 17406360704, 17414748544, 17423135872,
-17431527296, 17439915904, 17448303232, 17456691584, 17465081728,
-17473468288, 17481857408, 17490247552, 17498635904, 17507022464,
-17515409024, 17523801728, 17532189824, 17540577664, 17548966016,
-17557353344, 17565741184, 17574131584, 17582519168, 17590907008,
-17599296128, 17607687808, 17616076672, 17624455808, 17632852352,
-17641238656, 17649630848, 17658018944, 17666403968, 17674794112,
-17683178368, 17691573376, 17699962496, 17708350592, 17716739968,
-17725126528, 17733517184, 17741898112, 17750293888, 17758673024,
-17767070336, 17775458432, 17783848832, 17792236928, 17800625536,
-17809012352, 17817402752, 17825785984, 17834178944, 17842563968,
-17850955648, 17859344512, 17867732864, 17876119424, 17884511872,
-17892900224, 17901287296, 17909677696, 17918058112, 17926451072,
-17934843776, 17943230848, 17951609216, 17960008576, 17968397696,
-17976784256, 17985175424, 17993564032, 18001952128, 18010339712,
-18018728576, 18027116672, 18035503232, 18043894144, 18052283264,
-18060672128, 18069056384, 18077449856, 18085837184, 18094225792,
-18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
-18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
-18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
-18228444544, 18236833408, 18245220736]
-
-cache_sizes = [
-16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
-17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088,
-18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208,
-19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968,
-20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216,
-21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104,
-22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096,
-23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112,
-24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488,
-25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096,
-25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472,
-26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744,
-27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504,
-28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752,
-29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976,
-30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248,
-31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392,
-32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768,
-33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992,
-34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984,
-35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976,
-36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656,
-36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904,
-37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672,
-38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632,
-39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032,
-40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304,
-41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912,
-42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696,
-43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432,
-44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448,
-45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208,
-46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328,
-47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936,
-47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312,
-48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712,
-49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472,
-50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848,
-51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968,
-52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576,
-53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744,
-54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248,
-55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856,
-56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488,
-57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632,
-58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984,
-58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512,
-59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968,
-60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752,
-61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512,
-62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656,
-63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392,
-64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792,
-65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296,
-66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672,
-67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304,
-68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912,
-69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184,
-69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816,
-70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168,
-71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568,
-72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944,
-73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832,
-74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544,
-75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072,
-76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832,
-77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336,
-78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664,
-79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472,
-80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848,
-81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304,
-81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984,
-82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464,
-83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608,
-84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496,
-85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112,
-86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632,
-87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264,
-88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384,
-89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376,
-90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776,
-91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384,
-92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912,
-92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136,
-93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896,
-94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016,
-95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544,
-96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536,
-97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168,
-98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928,
-99352384, 99482816, 99614272, 99745472, 99876416, 100007104,
-100138048, 100267072, 100401088, 100529984, 100662592, 100791872,
-100925248, 101056064, 101187392, 101317952, 101449408, 101580608,
-101711296, 101841728, 101973824, 102104896, 102235712, 102366016,
-102498112, 102628672, 102760384, 102890432, 103021888, 103153472,
-103284032, 103415744, 103545152, 103677248, 103808576, 103939648,
-104070976, 104201792, 104332736, 104462528, 104594752, 104725952,
-104854592, 104988608, 105118912, 105247808, 105381184, 105511232,
-105643072, 105774784, 105903296, 106037056, 106167872, 106298944,
-106429504, 106561472, 106691392, 106822592, 106954304, 107085376,
-107216576, 107346368, 107478464, 107609792, 107739712, 107872192,
-108003136, 108131392, 108265408, 108396224, 108527168, 108657344,
-108789568, 108920384, 109049792, 109182272, 109312576, 109444928,
-109572928, 109706944, 109837888, 109969088, 110099648, 110230976,
-110362432, 110492992, 110624704, 110755264, 110886208, 111017408,
-111148864, 111279296, 111410752, 111541952, 111673024, 111803456,
-111933632, 112066496, 112196416, 112328512, 112457792, 112590784,
-112715968, 112852672, 112983616, 113114944, 113244224, 113376448,
-113505472, 113639104, 113770304, 113901376, 114031552, 114163264,
-114294592, 114425536, 114556864, 114687424, 114818624, 114948544,
-115080512, 115212224, 115343296, 115473472, 115605184, 115736128,
-115867072, 115997248, 116128576, 116260288, 116391488, 116522944,
-116652992, 116784704, 116915648, 117046208, 117178304, 117308608,
-117440192, 117569728, 117701824, 117833024, 117964096, 118094656,
-118225984, 118357312, 118489024, 118617536, 118749632, 118882112,
-119012416, 119144384, 119275328, 119406016, 119537344, 119668672,
-119798464, 119928896, 120061376, 120192832, 120321728, 120454336,
-120584512, 120716608, 120848192, 120979136, 121109056, 121241408,
-121372352, 121502912, 121634752, 121764416, 121895744, 122027072,
-122157632, 122289088, 122421184, 122550592, 122682944, 122813888,
-122945344, 123075776, 123207488, 123338048, 123468736, 123600704,
-123731264, 123861952, 123993664, 124124608, 124256192, 124386368,
-124518208, 124649024, 124778048, 124911296, 125041088, 125173696,
-125303744, 125432896, 125566912, 125696576, 125829056, 125958592,
-126090304, 126221248, 126352832, 126483776, 126615232, 126746432,
-126876608, 127008704, 127139392, 127270336, 127401152, 127532224,
-127663552, 127794752, 127925696, 128055232, 128188096, 128319424,
-128449856, 128581312, 128712256, 128843584, 128973632, 129103808,
-129236288, 129365696, 129498944, 129629888, 129760832, 129892288,
-130023104, 130154048, 130283968, 130416448, 130547008, 130678336,
-130807616, 130939456, 131071552, 131202112, 131331776, 131464384,
-131594048, 131727296, 131858368, 131987392, 132120256, 132250816,
-132382528, 132513728, 132644672, 132774976, 132905792, 133038016,
-133168832, 133299392, 133429312, 133562048, 133692992, 133823296,
-133954624, 134086336, 134217152, 134348608, 134479808, 134607296,
-134741056, 134872384, 135002944, 135134144, 135265472, 135396544,
-135527872, 135659072, 135787712, 135921472, 136052416, 136182848,
-136313792, 136444864, 136576448, 136707904, 136837952, 136970048,
-137099584, 137232064, 137363392, 137494208, 137625536, 137755712,
-137887424, 138018368, 138149824, 138280256, 138411584, 138539584,
-138672832, 138804928, 138936128, 139066688, 139196864, 139328704,
-139460032, 139590208, 139721024, 139852864, 139984576, 140115776,
-140245696, 140376512, 140508352, 140640064, 140769856, 140902336,
-141032768, 141162688, 141294016, 141426496, 141556544, 141687488,
-141819584, 141949888, 142080448, 142212544, 142342336, 142474432,
-142606144, 142736192, 142868288, 142997824, 143129408, 143258944,
-143392448, 143523136, 143653696, 143785024, 143916992, 144045632,
-144177856, 144309184, 144440768, 144570688, 144701888, 144832448,
-144965056, 145096384, 145227584, 145358656, 145489856, 145620928,
-145751488, 145883072, 146011456, 146144704, 146275264, 146407232,
-146538176, 146668736, 146800448, 146931392, 147062336, 147193664,
-147324224, 147455936, 147586624, 147717056, 147848768, 147979456,
-148110784, 148242368, 148373312, 148503232, 148635584, 148766144,
-148897088, 149028416, 149159488, 149290688, 149420224, 149551552,
-149683136, 149814976, 149943616, 150076352, 150208064, 150338624,
-150470464, 150600256, 150732224, 150862784, 150993088, 151125952,
-151254976, 151388096, 151519168, 151649728, 151778752, 151911104,
-152042944, 152174144, 152304704, 152435648, 152567488, 152698816,
-152828992, 152960576, 153091648, 153222976, 153353792, 153484096,
-153616192, 153747008, 153878336, 154008256, 154139968, 154270912,
-154402624, 154533824, 154663616, 154795712, 154926272, 155057984,
-155188928, 155319872, 155450816, 155580608, 155712064, 155843392,
-155971136, 156106688, 156237376, 156367424, 156499264, 156630976,
-156761536, 156892352, 157024064, 157155008, 157284416, 157415872,
-157545536, 157677248, 157810496, 157938112, 158071744, 158203328,
-158334656, 158464832, 158596288, 158727616, 158858048, 158988992,
-159121216, 159252416, 159381568, 159513152, 159645632, 159776192,
-159906496, 160038464, 160169536, 160300352, 160430656, 160563008,
-160693952, 160822208, 160956352, 161086784, 161217344, 161349184,
-161480512, 161611456, 161742272, 161873216, 162002752, 162135872,
-162266432, 162397888, 162529216, 162660032, 162790976, 162922048,
-163052096, 163184576, 163314752, 163446592, 163577408, 163707968,
-163839296, 163969984, 164100928, 164233024, 164364224, 164494912,
-164625856, 164756672, 164887616, 165019072, 165150016, 165280064,
-165412672, 165543104, 165674944, 165805888, 165936832, 166067648,
-166198336, 166330048, 166461248, 166591552, 166722496, 166854208,
-166985408, 167116736, 167246656, 167378368, 167508416, 167641024,
-167771584, 167903168, 168034112, 168164032, 168295744, 168427456,
-168557632, 168688448, 168819136, 168951616, 169082176, 169213504,
-169344832, 169475648, 169605952, 169738048, 169866304, 169999552,
-170131264, 170262464, 170393536, 170524352, 170655424, 170782016,
-170917696, 171048896, 171179072, 171310784, 171439936, 171573184,
-171702976, 171835072, 171966272, 172097216, 172228288, 172359232,
-172489664, 172621376, 172747712, 172883264, 173014208, 173144512,
-173275072, 173407424, 173539136, 173669696, 173800768, 173931712,
-174063424, 174193472, 174325696, 174455744, 174586816, 174718912,
-174849728, 174977728, 175109696, 175242688, 175374272, 175504832,
-175636288, 175765696, 175898432, 176028992, 176159936, 176291264,
-176422592, 176552512, 176684864, 176815424, 176946496, 177076544,
-177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
-177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
-178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
-179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
-180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
-181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
-181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
-182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
-183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
-184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
-185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
-185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
-186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
-187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
-188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
-189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
-189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
-190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
-191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
-192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
-192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
-193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
-194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
-195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
-196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
-196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
-197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
-198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
-199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
-200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
-200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
-201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
-202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
-203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
-203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
-204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
-205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
-206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
-207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
-207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
-208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
-209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
-210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
-211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
-211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
-212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
-213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
-214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
-214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
-215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
-216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
-217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
-218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
-218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
-219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
-220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
-221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
-222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
-222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
-223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
-224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
-225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
-225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
-226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
-227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
-228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
-229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
-229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
-230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
-231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
-232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
-233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
-233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
-234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
-235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
-236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
-236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
-237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
-238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
-239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
-240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
-240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
-241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
-242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
-243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
-244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
-244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
-245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
-246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
-247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
-247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
-248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
-249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
-250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
-251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
-251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
-252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
-253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
-254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
-255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
-255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
-256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
-257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
-258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
-258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
-259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
-260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
-261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
-262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
-262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
-263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
-264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
-265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
-266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
-266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
-267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
-268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
-269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
-270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
-270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
-271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
-272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
-273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
-273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
-274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
-275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
-276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
-277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
-277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
-278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
-279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
-280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
-281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
-281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
-282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
-283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
-284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
-284950208, 285081536]
-```
diff --git "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" "b/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
deleted file mode 100644
index a1c787e6b1c..00000000000
--- "a/public/content/translations/pt-br/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Algoritmos de mineração
-description: Os algoritmos usados para mineração Ethereum
-lang: pt-br
----
-
-
-A prova de trabalho não está mais subjacente ao mecanismo de consenso do Ethereum, o que significa que a mineração foi desativada. Em vez disso, o Ethereum é garantido por validadores que apostam em ETH. Você pode começar a fazer o staking do seu ETH hoje. Leia mais sobre A Fusão (The MErge), prova de participação e participação (stake). Esta página é apenas de interesse histórico.
-
-
-A mineração Ethereum usou um algoritmo conhecido como Ethash. A ideia fundamental do algoritmo é que um minerador tente encontrar uma entrada de nonce usando a computação de força bruta, para que o hash resultante seja menor que um limite determinado pela dificuldade calculada. Esse nível de dificuldade pode ser ajustado dinamicamente, permitindo que a produção de blocos ocorra em intervalos regulares.
-
-## Pré-Requisitos {#prerequisites}
-
-Para entender melhor esta página, recomendamos que você leia primeiro sobre o [consenso da prova de trabalho](/developers/docs/consensus-mechanisms/pow) e a [mineração](/developers/docs /consensus-mechanisms/pow/mining).
-
-## Dagger Hashimoto {#dagger-hashimoto}
-
-Dagger Hashimoto foi um algoritmo de pesquisa precursor para mineração Ethereum que Ethash substituiu. Era uma fusão de dois algoritmos diferentes: Dagger e Hashimoto. Foi apenas uma implementação de pesquisa e foi substituída pelo Ethash no momento em que a rede principal do Ethereum foi lançada.
-
-[Dagger](http://www.hashcash.org/papers/dagger.html) envolve a geração de um [Grafo Acíclico Direcionado](https://en.wikipedia.org/wiki/Directed_acyclic_graph), cujas fatias aleatórias do hash são feitas juntas. O princípio central é que cada nonce requer apenas uma pequena porção de uma grande árvore de dados total. Recomputar a subárvore para cada nonce é proibitivo para a mineração – daí a necessidade de armazenar a árvore – mas tudo bem para uma única verificação de valor do nonce. O Dagger foi projetado para ser uma alternativa aos algoritmos existentes como o Scrypt, que fazem uso intenso de memória, mas que são difíceis de verificar conforme a utilização de memória aumenta para níveis genuinamente seguros. No entanto, Dagger era vulnerável à aceleração de hardware de memória compartilhada e caiu em favor de outras vias de pesquisa.
-
-[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) é um algoritmo que adiciona resistência ASIC ao ser vinculado à E/S (ou seja, leituras de memória são o fator limitante no processo de mineração). A teoria é que a RAM está mais disponível do que a computação; bilhões de dólares em pesquisas já investigaram a otimização de RAM para diferentes casos de uso, o que geralmente envolvem padrões de acesso quase aleatórios (daí “memória de acesso aleatório”). Como resultado, é provável que a memória RAM existente esteja moderadamente próxima do ideal para avaliar o algoritmo. Hashimoto usa a blockchain como fonte de dados, satisfazendo simultaneamente (1) e (3) acima.
-
-Dagger-Hashimoto usou versões modificadas dos algoritmos Dagger e Hashimoto. A diferença entre Dagger Hashimoto e Hashimoto é que, ao invés de usar a blockchain como fonte de dados, o Dagger Hashimoto usa um conjunto de dados gerados de forma personalizada, que atualiza com base nos dados do bloco a cada N blocos. O conjunto de dados é gerado usando o algoritmo Dagger, permitindo calcular com eficiência um subconjunto específico para cada nonce para o algoritmo de verificação de cliente leve. A diferença entre Dagger Hashimoto e Dagger é que, ao contrário do Dagger original, o conjunto de dados usado para consultar o bloco é semipermanente, sendo atualizado apenas em intervalos ocasionais (por exemplo, uma vez por semana). Isso significa que a porção do esforço de geração do conjunto de dados é próxima de zero, de modo que os argumentos de Sergio Lerner a respeito das acelerações de memória compartilhada tornam-se insignificantes.
-
-Mais sobre [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto).
-
-## Ethash {#ethash}
-
-Ethash foi o algoritmo de mineração, que na verdade foi usado na rede principal Ethereum real, sob a agora obsoleta arquitetura de prova de trabalho. Ethash foi efetivamente um novo nome dado a uma versão específica do Dagger-Hashimoto depois que o algoritmo foi significativamente atualizado, enquanto ainda herdava os princípios fundamentais de seu antecessor. A Rede principal do Ethereum só utilizou o Ethash. Dagger Hashimoto era uma versão de pesquisa e desenvolvimento do algoritmo de mineração que foi substituído antes do início da mineração na Rede principal do Ethereum.
-
-[Mais sobre Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
deleted file mode 100644
index 6771c99c3c5..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
+++ /dev/null
@@ -1,207 +0,0 @@
----
-title: Bibliotecas de API no Backend
-description: Uma introdução as API's do Ethereum que permitem interações de seu App com a Blockchain.
-lang: pt-br
----
-
-Para um aplicativo de software interagir com a blockchain Ethereum (ou seja, leia os dados da blockchain e/ou envie transações para a rede), ele deve se conectar a um nó do Ethereum.
-
-Para este proposito, todos os clientes do Ethereum implementam a especificação [SON-RPC](/developers/docs/apis/json-rpc/), para haver um conjunto uniforme de [métodos](/developers/docs/apis/json-rpc/#json-rpc-methods) nos quais os aplicativos podem confiar.
-
-Se você quiser usar uma linguagem de programação específica para se conectar com um nó Ethereum, existem várias bibliotecas de conveniência dentro do ecossistema que tornam isso muito mais fácil. Com essas bibliotecas, os desenvolvedores podem escrever intuitivamente métodos on-line para iniciar requisições JSON RPC (por debaixo dos panos) que interajam com a Ethereum.
-
-## Pré-requisitos {#prerequisites}
-
-Pode ser útil para entender a [stack da Ethereum](/developers/docs/ethereum-stack/) e [clientes Ethereum](/developers/docs/nodes-and-clients/).
-
-## Por que usar uma biblioteca? {#why-use-a-library}
-
-Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um nó Ethereum. Eles também fornecem funções de utilidade (por exemplo, Convertendo ETH para Gwei) para que como desenvolvedor você possa passar menos tempo lidando com as complexidades de clientes da Ethereum e mais tempo focado na funcionalidade única do seu aplicativo.
-
-## Bibliotecas disponíveis {#available-libraries}
-
-### Serviços de nós e infraestrutura {#infrastructure-and-node-services}
-
-**Alchemy -** **_Plataforma de Desenvolvimento Ethereum._**
-
-- [alchemy.com](https://www.alchemy.com/)
-- [Documentação](https://docs.alchemy.com/)
-- [GitHub](https://github.com/alchemyplatform)
-- [Discord](https://discord.com/invite/alchemyplatform)
-
-**Tudo sobre Nós - ** **_Nós-como-um-serviço._**
-
-- [Tudo Sobre Node.com](https://www.allthatnode.com/)
-- [Documentação](https://docs.allthatnode.com)
-- [Discord](https://discord.gg/GmcdVEUbJM)
-
-**Blast, da Bware Labs -****_ APIs descentralizadas para a Ethereum Mainnet ant Testnets._**
-
-- [blastapi.io](https://blastapi.io/)
-- [Documentação](https://docs.blastapi.io)
-- [Discord](https://discord.gg/bwarelabs)
-
-**BlockPi -** **_Fornece serviços RPC mais eficientes e mais rápidos_**
-
-- [blockpi.io](https://blockpi.io/)
-- [Documentação](https://docs.blockpi.io/)
-- [GitHub](https://github.com/BlockPILabs)
-- [Discord](https://discord.com/invite/xTvGVrGVZv)
-
-**Gateway Cloudflare de Ethereum.**
-
-- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
-
-**Etherscan - Explorador de blocos e APIs de transações**
-- [Documentação](https://docs.etherscan.io/)
-
-**GetBlock-** **_Blockchain-as-a-service para desenvolvimento Web3_**
-
-- [GetBlock.io](https://getblock.io/)
-- [Documentação](https://getblock.io/docs/)
-
-**Infura -** **_A API da Ethereum como serviço._**
-
-- [infura.io](https://infura.io)
-- [Documentação](https://docs.infura.io/api)
-- [GitHub](https://github.com/INFURA)
-
-**RPC Node - _Custo efetivo EVM fornecedor JSON-RPC_**
-
-- [noderpc.xyz](https://www.noderpc.xyz/)
-- [Documentação](https://docs.noderpc.xyz/node-rpc)
-
-**NOWNodes - _Nós Completos e Exploradores de Blocos._**
-
-- [NOWNodes.io](https://nownodes.io/)
-- [Documentação](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro)
-
-**QuickNode -** **_Infraestrutura Blockchain como Serviço._**
-
-- [quicknode.com](https://quicknode.com)
-- [Documentação](https://www.quicknode.com/docs/welcome)
-- [Discord](https://discord.gg/quicknode)
-
-**Rivet -** **_Ethereum e Ethereum Classic APIs como serviço, desenvolvido por software de código aberto._**
-
-- [rivet.cloud](https://rivet.cloud)
-- [Documentação](https://rivet.cloud/docs/)
-- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment)
-
-**Zmok -** **_Nós Ethereum orientados a velocidade como JSON-RPC/WebSockets API._**
-
-- [zmok.io](https://zmok.io/)
-- [GitHub](https://github.com/zmok-io)
-- [Documentação](https://docs.zmok.io/)
-- [Discord](https://discord.gg/fAHeh3ka6s)
-
-### Ferramentas de desenvolvimento {#development-tools}
-
-**ethers-kt -** **_Biblioteca assíncrona de alto desempenho em Kotlin/Java/Android para blockchains baseadas em EVM._**
-
-- [GitHub](https://github.com/Kr1ptal/ethers-kt)
-- [Exemplos](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
-- [Discord](https://discord.gg/rx35NzQGSb)
-
-**Nethereum -** **_Uma biblioteca de integração .NET de código aberto para blockchain._**
-
-- [GitHub](https://github.com/Nethereum/Nethereum)
-- [Documentação](http://docs.nethereum.com/en/latest/)
-- [Discord](https://discord.com/invite/jQPrR58FxX)
-
-**Python Tooling -** **_Variedade de bibliotecas para interação com a Ethereum via Python._**
-
-- [py.ethereum.org](https://python.ethereum.org/)
-- [web3.py GitHub](https://github.com/ethereum/web3.py)
-- [web3.py Chat](https://gitter.im/ethereum/web3.py)
-
-**QuikNode -** **_A plataforma definitiva de desenvolvimento de blockchains_**
-
-- [Tatum](https://tatum.io/)
-- [GitHub](https://github.com/tatumio/)
-- [Documentação](https://docs.tatum.io/)
-- [Discord](https://discord.gg/EDmW3kjTC9)
-
-**web3j -** **_Uma biblioteca de integração para Ethereum em Java/Android/Kotlin/Scala._**
-
-- [GitHub](https://github.com/web3j/web3j)
-- [Documentação](https://docs.web3j.io/)
-- [Gitter](https://gitter.im/web3j/web3j)
-
-### Serviços blockchain {#blockchain-services}
-
-**BlockCypher -** **_APIs Web Ethereum._**
-
-- [blockcypher.com](https://www.blockcypher.com/)
-- [Documentação](https://www.blockcypher.com/dev/ethereum/)
-
-**Chainbase -** **_Infraestrutura de dados web3 tudo-em-um para Ethereum._**
-
-- [chainbase.com](https://chainbase.com/)
-- [Documentação](https://docs.chainbase.com/)
-- [Discord](https://discord.gg/Wx6qpqz4AF)
-
-**Chainstack -** **_Nós Ethereum compartilhados e dedicados como serviço._**
-
-- [chainstack.com](https://chainstack.com)
-- [Documentação](https://docs.chainbase.com/docs)
-- [Referência da API Ethereum](https://docs.chainstack.com/reference/ethereum-getting-started)
-
-**Nó da Nuvem da Coinbase -** **_API de infraestrutura Blockchain._**
-
-- [Nó da Nuvem da Coinbase](https://www.coinbase.com/cloud)
-- [Documentação](https://docs.cloud.coinbase.com/)
-
-**DataHub por Figment -** **_Serviços de API Web3 API com rede principal Ethereum e rede de testes._**
-
-- [DataHub](https://www.figment.io/)
-- [Documentação](https://docs.figment.io/)
-
-**Moralis -** **_Provedor de API para EVM para uso corporativo._**
-
-- [moralis.io](https://moralis.io)
-- [Documentação](https://docs.moralis.io/)
-- [GitHub](https://github.com/MoralisWeb3)
-- [Discord](https://moralis.io/joindiscord/)
-- [Fórum](https://forum.moralis.io/)
-
-**NFTPort -** **_Dados Ethereum e APIs Mint._**
-
-- [nftport.xyz](https://www.nftport.xyz/)
-- [Documentação](https://docs.nftport.xyz/)
-- [GitHub](https://github.com/nftport/)
-- [Discord](https://discord.com/invite/K8nNrEgqhE)
-
-**Tokenview -** **_A plataforma geral de APIs blockchain multi-cripto._**
-
-- [services.tokenview.io](https://services.tokenview.io/)
-- [Documentação](https://services.tokenview.io/docs?type=api)
-- [GitHub](https://github.com/Tokenview)
-
-**Watchdata -** **_Fornecer acesso API simples e confiável à blockchain Ethereum._**
-
-- [Watchdata](https://watchdata.io/)
-- [Documentação](https://docs.watchdata.io/)
-- [Discord](https://discord.com/invite/TZRJbZ6bdn)
-
-**Covalent -** **_APIs de blockchain enriquecidas para mais de 200 redes._**
-
-- [covalenthq.com](https://www.covalenthq.com/)
-- [Documentação](https://www.covalenthq.com/docs/api/)
-- [GitHub](https://github.com/covalenthq)
-- [Discord](https://www.covalenthq.com/discord/)
-
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [ Nós e clientes](/developers/docs/nodes-and-clients/)
-- [Estruturas de desenvolvimento](/developers/docs/frameworks/)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Configure Web3js para usar a blockchain Ethereum em Javascript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _ – Instruções para configurar web3.js no seu projeto._
-- [Chamando um contrato inteligente do JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _ – Usando o token do DAI, veja como os contratos de chamadas funcionam usando JavaScript._
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
deleted file mode 100644
index eb7cc7b210a..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
+++ /dev/null
@@ -1,295 +0,0 @@
----
-title: Bibliotecas de API JavaScript
-description: Uma introdução às bibliotecas de cliente JavaScript que permitem que você interaja com a cadeia de blocos de seu aplicativo.
-lang: pt-br
----
-
-Para que um aplicativo web interaja com a cadeia de blocos Ethereum (ou seja, leia os dados da blockchain e/ou envie transações para a rede), ele deve se conectar a um nó Ethereum.
-
-Para esse propósito, cada cliente Ethereum implementa a especificação [JSON-RPC](/developers/docs/apis/json-rpc/), então há um conjunto uniforme de [métodos](/developers/docs/apis/json-rpc/#json-rpc-methods) com os quais os aplicativos podem conta.
-
-Se você quiser usar JavaScript para se conectar a um nó Ethereum, é possível usar o JavaScript vanilla, mas existem várias bibliotecas convenientes dentro do ecossistema que tornam isso muito mais fácil. Com essas bibliotecas, os desenvolvedores podem escrever intuitivamente métodos on-line para iniciar requisições JSON RPC (por debaixo dos panos) que interajam com a Ethereum.
-
-Observe que, desde [A Fusão](/roadmap/merge/) (The Merge), duas partes conectadas do software Ethereum — um cliente de execução e um cliente de consenso — são necessárias para executar um nó. Certifique-se de que seu nó inclui tanto o cliente de execução quanto o consensual. Se o seu nó não estiver na sua máquina local (por exemplo, seu nó está sendo executado em uma instância da AWS) atualize os endereços IP no tutorial adequadamente. Para obter mais informações, veja nossa página no [executando um nó](/developers/docs/nodes-and-clients/run-a-node/).
-
-## Pré-requisitos {#prerequisites}
-
-Além de entender o JavaScript, pode ser útil entender a [pilha de Ethereum](/developers/docs/ethereum-stack/) e[ clientes Ethereum](/developers/docs/nodes-and-clients/).
-
-## Por que usar uma biblioteca? {#why-use-a-library}
-
-Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um nó Ethereum. Eles também fornecem funções de utilidade (por exemplo, Convertendo ETH para Gwei) para que como desenvolvedor, você possa passar menos tempo lidando com as complexidades de clientes da Ethereum e mais tempo focado na funcionalidade única do seu aplicativo.
-
-## Recursos da biblioteca {#library-features}
-
-### Conectar aos nós da Ethereum {#connect-to-ethereum-nodes}
-
-Usando provedores, essas bibliotecas permitem que você se conecte à Ethereum e leia os seus dados, seja por JSON-RPC, INFURA, Etherscan, Alquimia ou MetaMask.
-
-**Exemplo de Ethers**
-
-```js
-// Um BrowserProvider envolve um provedor Web3 padrão, que é
-// o que o MetaMask injeta como window.ethereum em cada página
-const provider = new ethers.BrowserProvider(window.ethereum)
-
-// O plugin MetaMask também permite assinar transações para
-// enviar ether e pagar para alterar o estado dentro da blockchain.
-// Para isso, precisamos do signatário da conta...
-const signer = provider.getSigner()
-```
-
-**Exemplo de Web3js**
-
-```js
-var web3 = new Web3("http://localhost:8545")
-// ou
-var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"))
-
-// mudar provedor
-web3. etProvider("ws://localhost:8546")
-// ou
-web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546"))
-
-// Usando o provedor IPC em node.js
-var net = require("net")
-var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // caminho do mac os
-// ou
-var web3 = new Web3(
- new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net)
-) // Caminho mac os
-// no windows o caminho é: "\\\\.\\pipe\\geth.ipc"
-// no linux o caminho é: "/users/myuser/.ethereum/geth.ipc"
-```
-
-Uma vez configurado, você poderá consultar a blockchain para:
-
-- numero de blocos
-- estimativas de gás
-- eventos de contratos inteligentes
-- id da rede
-- e mais...
-
-### Funcionalidade de carteira {#wallet-functionality}
-
-Essas bibliotecas oferecem a funcionalidade de criar carteiras, gerenciar chaves e assinar transações.
-
-Veja alguns exemplos de Ethers
-
-```js
-// Cria uma instância de carteira de um mnemonic...
-mnemonic =
- "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol"
-walletMnemonic = Wallet.fromPhrase(mnemonic)
-
-// ...ou a partir de uma chave privada
-walletPrivateKey = new Wallet(walletMnemonic.privateKey)
-
-walletMnemonic.address === walletPrivateKey.address
-// true
-
-// O endereço como uma Promise conforme a API Signer
-walletMnemonic.getAddress()
-// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' }
-
-// O endereço de uma Wallet também está disponível de forma síncrona
-walletMnemonic.address
-// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1'
-
-// Os componentes criptográficos internos
-walletMnemonic.privateKey
-// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db'
-walletMnemonic.publicKey
-// '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64'
-
-// A frase mnemônica da wallet
-walletMnemonic.mnemonic
-// {
-// locale: 'en',
-// path: 'm/44\'/60\'/0\'/0/0',
-// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol'
-// }
-
-// Nota: Uma wallet criada com uma chave privada não
-// possui uma frase mnemônica (a derivação a impede)
-walletPrivateKey.mnemonic
-// null
-
-// Assinando uma mensagem
-walletMnemonic.signMessage("Hello World")
-// { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' }
-
-tx = {
- to: "0x8ba1f109551bD432803012645Ac136ddd64DBA72",
- value: utils.parseEther("1.0"),
-}
-
-// Assinando uma transação
-walletMnemonic.signTransaction(tx)
-// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' }
-
-// O método connect retorna uma nova instância da
-// Wallet conectada a um provedor
-wallet = walletMnemonic.connect(provider)
-
-// Consultando a rede
-wallet.getBalance()
-// { Promise: { BigNumber: "42" } }
-wallet.getTransactionCount()
-// { Promise: 0 }
-
-// Enviando ether
-wallet.sendTransaction(tx)
-```
-
-[Leia a documentação completa](https://docs.ethers.io/v5/api/signer/#Wallet)
-
-Uma vez configurado você será capaz de:
-
-- criar contas
-- enviar transações
-- assinar transações
-- e mais...
-
-### Interaja com funções de contrato inteligentes {#interact-with-smart-contract-functions}
-
-As bibliotecas de clientes Javascript permitem que sua aplicação chame funções de contratos inteligentes lendo a Interface Binária da Aplicação (en: ABI, pt: IBA) de um contrato compilado.
-
-O ABI essencialmente explica as funções do contrato em um formato JSON e permite que você use-o como um objeto JavaScript normal.
-
-Então, o seguinte contrato de Solidity:
-
-```solidity
-contract Test {
- uint a;
- address d = 0x12345678901234567890123456789012;
-
- function Test(uint testInt) { a = testInt;}
-
- event Event(uint indexed b, bytes32 c);
-
- event Event2(uint indexed b, bytes32 c);
-
- function foo(uint b, bytes32 c) returns(address) {
- Event(b, c);
- return d;
- }
-}
-```
-
-Resultaria no seguinte JSON:
-
-```json
-[{
- "type":"constructor",
- "payable":false,
- "stateMutability":"nonpayable"
- "inputs":[{"name":"testInt","type":"uint256"}],
- },{
- "type":"function",
- "name":"foo",
- "constant":false,
- "payable":false,
- "stateMutability":"nonpayable",
- "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}],
- "outputs":[{"name":"","type":"address"}]
- },{
- "type":"event",
- "name":"Event",
- "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}],
- "anonymous":false
- },{
- "type":"event",
- "name":"Event2",
- "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}],
- "anonymous":false
-}]
-```
-
-Isso significa que você pode:
-
-- Enviar uma transação para o contrato inteligente e executar seu método
-- Estimar o gás que um método de execução consumirá quando executado na EVM
-- Implantar um contrato
-- E mais...
-
-### Funções utilitárias {#utility-functions}
-
-Funções utilitárias lhe dão atalhos úteis que facilitam um pouco a construção com a Ethereum.
-
-Os valores ETH estão em Wei por padrão. 1 ETH = 1.000.000.000.000.000.000 WEI – isso significa que você está lidando com muitos números! `web3.utils.toWei` converte ether para Wei pra você.
-
-E em ethers fica assim:
-
-```js
-// Obtenha o saldo de uma conta (por endereço ou nome ENS)
-balance = await provider.getBalance("ethers.eth")
-// { BigNumber: "2337132817842795605" }
-
-// Muitas vezes você precisará formatar a saída para o usuário
-// que preferem ver valores no ether (em vez de wei)
-ethers.utils.formatEther(balance)
-// '2.337132817842795605'
-```
-
-- [Funções utilitárias da Web3js](https://docs.web3js.org/api/web3-utils)
-- [Funções utilitárias da EthersJs](https://docs.ethers.io/v5/api/utils/)
-
-## Bibliotecas disponíveis {#available-libraries}
-
-**Web3.js -** **_API para Ethereum em JavaScript._**
-
-- [Documentação](https://docs.web3js.org/)
-- [GitHub](https://github.com/ethereum/web3.js/)
-
-**Ethers.js -** **_Implementação completa de uma carteira Ethereum e utilidades em JavaScript e TypeScript._**
-
-- [Documentação](https://docs.ethers.io/)
-- [GitHub](https://github.com/ethers-io/ethers.js/)
-
-**The Graph -** **_Um protocolo para indexação de dados de Ethereum e IPFS e sua consulta usando GraphQL._**
-
-- [The Graph](https://thegraph.com/)
-- [Graph Explorer](https://thegraph.com/explorer/)
-- [Documentação](https://thegraph.com/docs/)
-- [GitHub](https://github.com/graphprotocol/)
-- [Discord](https://thegraph.com/discord)
-
-**light.js -** **_Uma biblioteca em alto nível reativa em JS otimizada para clientes leves._**
-
-- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js)
-
-**Web3-wrapper -** **_Alternativa ao Web3.js em Typescript._**
-
-- [Documentação](https://0x.org/docs/web3-wrapper#introduction)
-- [GitHub](https://github.com/0xProject/0x-monorepo/tree/development/packages/web3-wrapper)
-
-**Alchemyweb3 -** **_Wrapper em torno de Web3.js com tentativas automáticas e apis aprimoradas._**
-
-- [Documentação](https://docs.alchemy.com/reference/api-overview)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
-
-**Alchemy NFT API -** **_API para buscar dados NFT, incluindo propriedade, atributos de metadados e muito mais._**
-
-- [Documentação](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
-
-**viem -** **_Interface TypeScript para Ethereum._**
-
-- [Documentação](https://viem.sh)
-- [GitHub](https://github.com/wagmi-dev/viem)
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [ Nós e clientes](/developers/docs/nodes-and-clients/)
-- [Estruturas de desenvolvimento](/developers/docs/frameworks/)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Configure Web3js para usar a blockchain Ethereum em Javascript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _ – Instruções para configurar web3.js no seu projeto._
-- [Chamando um contrato inteligente do JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _ – Usando o token do DAI, veja como os contratos de chamadas funcionam usando JavaScript._
-- [Enviando transações usando web3 e Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _ – Passo a passo para enviar transações pelo back-end._
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
deleted file mode 100644
index 9808f73bb1f..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
+++ /dev/null
@@ -1,1771 +0,0 @@
----
-title: API JSON-RPC
-description: Um protocolo de chamada de procedimento remoto (RPC) leve e sem Estado para clientes Ethereum.
-lang: pt-br
----
-
-Para que um aplicativo de software interaja com a blockchain Ethereum - lendo os dados da blockchain ou enviando transações para a rede - ele deve se conectar na Ethereum.
-
-Para esse fim, todos os [clientes Ethereum](/developers/docs/nodes-and-clients/#execution-clients) implementam uma [especificação JSON-RPC](https://github.com/ethereum/execution-apis) para que exista um conjunto uniforme de métodos nos quais os aplicativos podem confiar, independentemente do nó específico ou da implementação do cliente.
-
-[JSON-RPC](https://www.jsonrpc.org/specification) é um protocolo de chamada de procedimento remoto (RPC) leve e sem estado. Ele define várias estruturas de dados e as regras em torno de seu processamento. É agnóstico de transporte no sentido de que os conceitos podem ser usados dentro do mesmo processo, sobre sockets, HTTP ou em vários ambientes de passagem de mensagens. Usa o formato de dados JSON (RFC 4627).
-
-## Implementações do cliente {#client-implementations}
-
-Cada cliente Ethereum pode utilizar linguagens de programação diferentes ao implementar a especificação JSON-RPC. Consulte a [documentação individual do cliente](/developers/docs/nodes-and-clients/#execution-clients) para mais detalhes relacionados a linguagens de programação específicas. Recomendamos verificar a documentação de cada cliente para as informações mais recentes de suporte à API.
-
-## Bibliotecas de Conveniência {#convenience-libraries}
-
-Embora você possa optar por interagir diretamente com clientes da Ethereum usando a API JSON-RPC, muitas vezes existem opções mais fáceis para desenvolvedores de dapps. Muitas [bibliotecas de](/developers/docs/apis/javascript/#available-libraries) e [de backend API](/developers/docs/apis/backend/#available-libraries) existem para fornecer wrappers além de API JSON-RPC. Com essas bibliotecas, os desenvolvedores podem escrever intuitivamente métodos de uma linha para inicializar requisições JSON RPC (sob os capôs) que interagem com a Ethereum.
-
-## APIs de cliente de consenso {#consensus-clients}
-
-Esta página trata principalmente da API JSON-RPC usada pelos clientes de execução Ethereum. No entanto, os clientes de consenso também têm uma API RPC que permite aos usuários consultar informações sobre o nó, solicitar blocos Beacon, estado do Beacon, e outras informações relacionadas ao consenso diretamente de um nó. Essa API está documentada na [página da Web da API Beacon](https://ethereum.github.io/beacon-APIs/#/).
-
-Uma API interna também é usada para comunicação entre clientes dentro de um nó - ou seja, permite que o cliente de consenso e o cliente de execução troquem dados. Ela é chamada de “API Engine” e suas especificações estão disponíveis no [Github](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md).
-
-## Especificação do cliente de execução {#spec}
-
-[Leia a especificação completa da API JSON-RPC no GitHub](https://github.com/ethereum/execution-apis). Esta API está documentada na [página da Web da API de execução](https://ethereum.github.io/execution-apis/api-documentation/) e inclui um Inspetor para testar todos os métodos disponíveis.
-
-## Convenções {#conventions}
-
-### Codificação de valor hexadecimal {#hex-encoding}
-
-Dois tipos de dados-chave são passados pelo JSON: arrays (matrizes) e quantidade de bytes não formatados. Ambos são passados com uma codificação hexadecimal, mas com diferentes requisitos de formatação.
-
-#### Quantidades {#quantities-encoding}
-
-Ao codificar quantidades (inteiros, números): codifique como hexadecimal, prefixe com "0x", a representação mais compacta (pequena exceção: zero deve ser representado como "0x0").
-
-Veja aqui alguns exemplos:
-
-- 0x41 (65 em decimal)
-- 0x400 (1024 em decimal)
-- ERRADO: 0x (deve sempre ter pelo menos um dígito - zero é "0x0")
-- ERRADO: 0x0400 (sem zeros à esquerda permitidos)
-- ERRADO: ff (deve ser prefixado 0x)
-
-### Dados não formatados {#unformatted-data-encoding}
-
-Ao codificar dados não formatados (arrays de bytes, endereços de contas, hashes, matrizes de bytecodes): codifique como hexadecimal, prefixe com "0x", dois dígitos hexadecimais por byte.
-
-Aqui estão alguns exemplos:
-
-- 0x41 (tamanho 1, "A")
-- 0x004200 (tamanho 3, "0B0")
-- 0x (tamanho 0, "")
-- ERRADO: 0xf0f0f (deve ser um número par de dígitos)
-- ERRADO: 004200 (deve ser prefixado 0x)
-
-### O parâmetro de bloco padrão {#default-block}
-
-Os métodos a seguir têm um parâmetro de bloco padrão extra:
-
-- [eth_getBalance](#eth_getbalance)
-- [eth_getCode](#eth_getcode)
-- [eth_getTransactionCount](#eth_gettransactioncount)
-- [eth_getStorageAt](#eth_getstorageat)
-- [eth_call](#eth_call)
-
-Quando são feitas requisições que atuam no estado da Ethereum, o último parâmetro de bloco padrão determina a altura do bloco.
-
-As seguintes opções são possíveis para o parâmetro defaultBlock:
-
-- `String HEX` - um número de bloco inteiro
-- `String "earliest"` para o bloco mais antigo/de início
-- `String "latest"` - para o último bloco proposto
-- `String "safe"` – para o último bloco de cabeçalho seguro
-- `String "finalized"` – para o último bloco finalizado
-- `String "pendente"` – para o estado/transações pendentes
-
-## Exemplos
-
-Nesta página, fornecemos exemplos de como usar endpoints de API JSON_RPC individuais usando a ferramenta de linha de comando [curl](https://curl.se). Esses exemplos de endpoints individuais são encontrados abaixo na seção [Exemplos Curl](#curl-examples). Mais abaixo na página, também fornecemos um [exemplo de ponta a ponta](#usage-example) para compilar e implantar um contrato inteligente usando um nó Geth, a API JSON_RPC e curl.
-
-## Exemplos Curl {#curl-examples}
-
-Exemplos de uso da API JSON_RPC fazendo pedidos [curl](https://curl.se) para um nó Ethereum são fornecidos abaixo. Cada exemplo inclui uma descrição do endpoint específico, seus parâmetros, tipo de retorno e um exemplo funcional de como ele deve ser usado.
-
-Os pedidos curl podem retornar uma mensagem de erro relacionada ao tipo de conteúdo. Isso ocorre porque a opção `--data` define o tipo de conteúdo como `application/x-www-form-urlencoded`. Se o seu nó reclamar sobre isso, defina manualmente o cabeçalho colocando `-H "Content-Type: application/json"` no início da chamada. Os exemplos também não incluem a URL/IP & combinação de porta que deve ser o último argumento dado para curl (por exemplo, `127.0.0.1:8545`). Uma solicitação de curl completa, incluindo esses dados adicionais, tem o seguinte formato:
-
-```shell
-curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
-```
-
-## Gossip, Estado, Histórico {#gossip-state-history}
-
-Alguns dos métodos JSON-RPC principais exigem dados da rede Ethereum, se enquadram perfeitamente em três categorias principais: _Gossip, Estado e Histórico_. Use os links nestas seções para pular para cada método ou use a tabela de conteúdos para explorar toda a lista de métodos.
-
-### Métodos Gossip {#gossip-methods}
-
-> Esses métodos rastreiam o cabeçalho da cadeia. É assim que as transações se deslocam pela rede, encontram o caminho para os blocos e como os clientes descobrem novos blocos.
-
-- [eth_blockNumber](#eth_blocknumber)
-- [eth_sendRawTransaction](#eth_sendrawtransaction)
-
-### Métodos de Estado {#state_methods}
-
-> Métodos que relatam o estado atual de todos os dados armazenados. O "estado" é como um grande pedaço compartilhado de RAM e inclui saldos de contas, dados de contratos e estimativas de gás.
-
-- [eth_getBalance](#eth_getbalance)
-- [eth_getStorageAt](#eth_getstorageat)
-- [eth_getTransactionCount](#eth_gettransactioncount)
-- [eth_getCode](#eth_getcode)
-- [eth_call](#eth_call)
-- [eth_estimateGas](#eth_estimategas)
-
-### Métodos de Histórico {#history_methods}
-
-> Busca o histórico de registros de cada bloco até à gênesis (início). Isso é como um arquivo grande que apenas insere e inclui todos os cabeçalhos de bloco, corpos de bloco, blocos de tio e recibos de transação.
-
-- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash)
-- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber)
-- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash)
-- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber)
-- [eth_getBlockByHash](#eth_getblockbyhash)
-- [eth_getBlockByNumber](#eth_getblockbynumber)
-- [eth_getTransactionByHash](#eth_gettransactionbyhash)
-- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex)
-- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex)
-- [eth_getTransactionReceipt](#eth_gettransactionreceipt)
-- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex)
-- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex)
-
-## Área livre da API JSON-RPC
-
-Você pode usar a [ferramenta de playground](https://ethereum-json-rpc.com) para descobrir e testar os métodos da API. Ele também mostra quais métodos e redes são suportados por vários provedores de nós.
-
-## Métodos de API JSON-RPC {#json-rpc-methods}
-
-### web3_clientVersion {#web3_clientversion}
-
-Retorna a versão atual do cliente.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`String` - A versão atual do cliente
-
-**Exemplo**
-
-```js
-// Solicitação
-curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
-// Resultado
-{
- "id":67,
- "jsonrpc":"2.0",
- "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1"
-}
-```
-
-### web3_sha3 {#web3_sha3}
-
-Retorna Keccak-256 (_não_ o SHA3-256 padronizado) dos dados fornecidos.
-
-**Parâmetros**
-
-1. `DADOS` - Os dados a serem convertidos em um hash SHA3
-
-```js
-params: ["0x68656c6c6f20776f726c64"]
-```
-
-**Retorna**
-
-`DATA` - O resultado SHA3 da string fornecida.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
-// Result
-{
- "id":64,
- "jsonrpc": "2.0",
- "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad"
-}
-```
-
-### net_version {#net_version}
-
-Retorna a id da rede atual.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`String` - A id da rede atual.
-
-A lista completa das IDs da rede atual está disponível em [chainlist.org](https://chainlist.org). Alguns exemplos comuns são:
-
-- `1`: Ethereum Mainnet
-- `5`: Goerli testnet
-- `11155111`: Sepolia testnet
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc": "2.0",
- "result": "3"
-}
-```
-
-### net_listening {#net_listening}
-
-Retorna `true` se o cliente estiver escutando ativamente as conexões de rede.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`Boolean` - `true` quando escuta, do contrário `false`.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc":"2.0",
- "result":true
-}
-```
-
-### net_peerCount {#net_peercount}
-
-Retorna o número de pares atualmente conectados ao cliente.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`QUANTITY` - número inteiro do número de pares conectados.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
-// Result
-{
- "id":74,
- "jsonrpc": "2.0",
- "result": "0x2" // 2
-}
-```
-
-### eth_protocolVersion {#eth_protocolversion}
-
-Retorna a versão atual do protocolo Ethereum. Note que este método [não está disponível no Geth](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924).
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`String` - A versão atual do protocolo Ethereum
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc": "2.0",
- "result": "54"
-}
-```
-
-### eth_syncing {#eth_syncing}
-
-Retorna um objeto com dados sobre o status da sincronização ou `false`.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-Os dados de retorno precisos variam entre as implementações do cliente. Todos os clientes retornam `False` quando o nó não está sincronizando, e todos os clientes retornam os seguintes campos.
-
-`Object|Boolean`, um objeto com dados de status da sincronização ou `FALSE`, quando não sincronizado:
-
-- `startingBlock`: `QUANTITY` — O bloco no qual a importação começou (só será reiniciado após a sincronização atingir seu cabeçalho)
-- `currentBlock`: `QUANTITY` — O bloco atual, o mesmo que eth_blockNumber
-- `highestBlock`: `QUANTITY` — O bloco mais alto estimado
-
-No entanto, os clientes individuais também podem fornecer dados adicionais. Por exemplo, Geth retorna o seguinte:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "currentBlock": "0x3cf522",
- "healedBytecodeBytes": "0x0",
- "healedBytecodes": "0x0",
- "healedTrienodes": "0x0",
- "healingBytecode": "0x0",
- "healingTrienodes": "0x0",
- "highestBlock": "0x3e0e41",
- "startingBlock": "0x3cbed5",
- "syncedAccountBytes": "0x0",
- "syncedAccounts": "0x0",
- "syncedBytecodeBytes": "0x0",
- "syncedBytecodes": "0x0",
- "syncedStorage": "0x0",
- "syncedStorageBytes": "0x0"
- }
-}
-```
-
-Enquanto Besu retorna:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 51,
- "result": {
- "startingBlock": "0x0",
- "currentBlock": "0x1518",
- "highestBlock": "0x9567a3",
- "pulledStates": "0x203ca",
- "knownStates": "0x200636"
- }
-}
-```
-
-Consulte a documentação do seu cliente específico para obter mais detalhes.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": {
- startingBlock: '0x384',
- currentBlock: '0x386',
- highestBlock: '0x454'
- }
-}
-// Or when not syncing
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": false
-}
-```
-
-### eth_coinbase {#eth_coinbase}
-
-Retorna o endereço de coinbase do cliente.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`DATA`, 20 bytes - O endereço atual da coinbase.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
-// Result
-{
- "id":64,
- "jsonrpc": "2.0",
- "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1"
-}
-```
-
-### eth_chainId {#eth_chainId}
-
-Retorna a ID da cadeia usada para assinar transações protegidas contra reprodução.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`chainId`, valor hexadecimal como uma cadeia de caracteres representando o inteiro da ID da cadeia atual.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc": "2.0",
- "result": "0x1"
-}
-```
-
-### eth_mining {#eth_mining}
-
-Retorna `true` se o cliente estiver ativamente minerando novos blocos. Isso só pode retornar `true` para redes de prova de trabalho e pode não estar disponível em alguns clientes desde [The Merge](/roadmap/merge/).
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`Boolean` — retorna `true` do cliente que está minerando, caso contrário, `false`.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
-//
-{
- "id":71,
- "jsonrpc": "2.0",
- "result": true
-}
-```
-
-### eth_hashrate {#eth_hashrate}
-
-Retorna o número de hashes por segundo do nó que está minerando. Isso só pode retornar `true` para redes de prova de trabalho e pode não estar disponível em alguns clientes desde [The Merge](/roadmap/merge/).
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`QUANTITY` — número de hashes por segundo.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
-// Result
-{
- "id":71,
- "jsonrpc": "2.0",
- "result": "0x38a"
-}
-```
-
-### eth_gasPrice {#eth_gasprice}
-
-Retorna uma estimativa do preço atual por gás em wei. Por exemplo, o cliente Besu examina os últimos 100 blocos e retorna o preço unitário médio do gás por padrão.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`QUANTITY` — Número inteiro do preço atual do gás em Wei.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
-// Result
-{
- "id":73,
- "jsonrpc": "2.0",
- "result": "0x1dfd14000" // 8049999872 Wei
-}
-```
-
-### eth_accounts {#eth_accounts}
-
-Retorna uma lista de endereços de propriedade do cliente.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`Matriz de DADOS`, 20 Bytes — endereços de propriedade do cliente.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"]
-}
-```
-
-### eth_blockNumber {#eth_blocknumber}
-
-Retorna o número do bloco mais recente.
-
-**Parâmetros**
-
-Nenhum
-
-**Retorna**
-
-`QUANTITY` — Inteiro do número do bloco atual no qual o cliente está.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
-// Result
-{
- "id":83,
- "jsonrpc": "2.0",
- "result": "0x4b7" // 1207
-}
-```
-
-### eth_getBalance {#eth_getbalance}
-
-Retorna o saldo da conta do endereço fornecido.
-
-**Parâmetros**
-
-1. `DATA`, 20 Bytes - Endereço para verificar o saldo.
-2. `QUANTITY|TAG` - número de bloco inteiro ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, consulte o [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
-```
-
-**Retorna**
-
-`QUANTITY` — Inteiro do saldo atual em Wei.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x0234c8a3397aab58" // 158972490234375000
-}
-```
-
-### eth_getStorageAt {#eth_getstorageat}
-
-Retorna o valor de uma posição de armazenamento em um determinado endereço.
-
-**Parâmetros**
-
-1. `DATA`, 20 Bytes - Endereço do armazenamento.
-2. `QUANTITY` - Número inteiro da posição no armazenamento.
-3. `QUANTITY|TAG` - número de bloco inteiro ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, veja o [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block)
-
-**Retorna**
-
-`DATA` — O valor nessa posição de armazenamento.
-
-**Exemplo** O cálculo da posição correta depende do armazenamento a ser recuperado. Considere o seguinte contrato implementado em `0x295a70b2de5e3953354a6a8344e616ed314d7251` pelo endereço `0x391694e7e0b0cce554cb130d723a9d27458f9298`.
-
-```
-contract Storage {
- uint pos0;
- mapping(address => uint) pos1;
- function Storage() {
- pos0 = 1234;
- pos1[msg.sender] = 5678;
- }
-}
-```
-
-Recuperar o valor da pos0 é simples:
-
-```js
-curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
-{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
-```
-
-Recuperar um elemento do mapa é mais difícil. A posição de um elemento no mapa é calculada com:
-
-```js
-keccak(LeftPad32(chave, 0), LeftPad32(posição do mapa, 0))
-```
-
-Isso significa que, para recuperar o armazenamento na pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] precisamos calcular a posição com:
-
-```js
-keccak(
- decodeHex(
- "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" +
- "0000000000000000000000000000000000000000000000000000000000000001"
- )
-)
-```
-
-O console geth fornecido com a biblioteca Web3 pode ser usado para fazer o cálculo:
-
-```js
-> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
-undefined
-> web3.sha3(key, {"encoding": "hex"})
-"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
-```
-
-Agora, para buscar o armazenamento:
-
-```js
-curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
-{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
-```
-
-### eth_getTransactionCount {#eth_gettransactioncount}
-
-Retorna o número de transações _enviadas_ a partir de um endereço.
-
-**Parâmetros**
-
-1. `DATA`, 20 Bytes - Endereço.
-2. `QUANTITY|TAG` - número de bloco inteiro ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, consulte o [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-params: [
- "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
- "latest", // state at the latest block
-]
-```
-
-**Retorna**
-
-`QUANTITY` — Inteiro do número de transações enviadas a partir desse endereço.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash}
-
-Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido.
-
-**Parâmetros**
-
-1. `DATA`, 32 bytes - Hash de um bloco
-
-```js
-parâmetros: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
-```
-
-**Retorna**
-
-`QUANTITY` — Inteiro do número de transações nesse bloco.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x8b" // 139
-}
-```
-
-### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber}
-
-Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido.
-
-**Parâmetros**
-
-1. `QUANTITY|TAG` - inteiro de um número de bloco, ou a string `"earliest"`, `"latest"`, `"pending"`, `"safe"` ou `"finalized"`, como no [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block).
-
-```js
-parâmetros: [
- "0x13738ca", // 20396234
-]
-```
-
-**Retorna**
-
-`QUANTITY` — Inteiro do número de transações nesse bloco.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x8b" // 139
-}
-```
-
-### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash}
-
-Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido.
-
-**Parâmetros**
-
-1. `DADOS`, 32 bytes - hash de um bloco
-
-```js
-parâmetros: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
-```
-
-**Retorna**
-
-`QUANTITY` — Inteiro do número de transações nesse bloco.
-
-**Exemplo**
-
-```js
-/ Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber}
-
-Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido.
-
-**Parâmetros**
-
-1. `QUANTITY|TAG` - inteiro de um número de bloco, ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, veja o [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-params: [
- "0xe8", // 232
-]
-```
-
-**Retorna**
-
-`QUANTITY` — Inteiro do número de transações nesse bloco.
-
-**Exemplo**
-
-```js
-/ Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x0" // 0
-}
-```
-
-### eth_getCode {#eth_getcode}
-
-Retorna o código em um endereço fornecido.
-
-**Parâmetros**
-
-1. `DATA`, 20 Bytes - Endereço
-2. `QUANTITY|TAG` - número de bloco inteiro ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, consulte o [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-parâmetros: [
- "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
- "0x5daf3b", // 6139707
-]
-```
-
-**Retorna**
-
-`DATA` — O código do endereço fornecido.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029"
-}
-```
-
-### eth_sign {#eth_sign}
-
-O método de assinatura calcula uma assinatura específica do Ethereum com: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
-
-Ao adicionar um prefixo à mensagem, a assinatura calculada é reconhecível como uma assinatura específica do Ethereum. Isso evita o uso indevido por parte de um dapp malicioso, que pode assinar dados arbitrários (por exemplo, de transação) e usar a assinatura para usar a identidade da vítima.
-
-Observação: o endereço de assinatura deve estar desbloqueado.
-
-**Parâmetros**
-
-1. `DADOS`, 20 Bytes - endereço
-2. `DATA`, N Bytes - Mensagem para assinar
-
-**Retorna**
-
-`DATA`: assinatura
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
-}
-```
-
-### eth_signTransaction {#eth_signtransaction}
-
-Assina uma transação que pode ser enviada à rede posteriormente usando [eth_sendRawTransaction](#eth_sendrawtransaction).
-
-**Parâmetros**
-
-1. `Objeto` - O objeto da transação
-
-- `tipo`:
-- `from`: `DATA`, 20 Bytes — Endereço de onde a transação é enviada.
-- `to`: `DATA`, 20 Bytes — (opcional ao criar um novo contrato) O endereço para o qual a transação é direcionada.
-- `gas`: `QUANTITY` — (opcional, padrão: 90000) Inteiro do gás fornecido para a execução da transação. Retornará o gás não utilizado.
-- `gasPrice`: `QUANTITY` — (opcional, padrão: a ser determinado) Inteiro do gasPrice usado para cada gás pago, em Wei.
-- `valor`: `QUANTITY` — (opcional) Inteiro do valor enviado com esta transação, em Wei.
-- `data`: `DATA` — Código compilado de um contrato OU do hash da assinatura do método invocado e parâmetros codificados.
-- `nonce`: `QUANTITY` — (opcional) Inteiro de um nonce. Isso permite substituir suas próprias transações pendentes que usam o mesmo nonce.
-
-**Retorna**
-
-`DATA`, O objeto de transação codificado em RLP assinado pela conta especificada.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
-// Result
-{
- "id": 1,
- "jsonrpc": "2.0",
- "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
-}
-```
-
-### eth_sendTransaction {#eth_sendtransaction}
-
-Cria uma nova transação de chamada de mensagem ou uma criação de contrato, se o campo de dados contiver código, e o assina usando a conta especificada `em`.
-
-**Parâmetros**
-
-1. `Object` - O objeto da transação
-
-- `from`: `DATA`, 20 Bytes — Endereço de onde a transação é enviada.
-- `to`: `DATA`, 20 Bytes — (opcional ao criar um novo contrato) O endereço para o qual a transação é direcionada.
-- `gas`: `QUANTITY` — (opcional, padrão: 90000) Inteiro do gás fornecido para a execução da transação. Retornará o gás não utilizado.
-- `gasPrice`: `QUANTITY` — (opcional, padrão: a ser determinado) Inteiro do gasPrice usado para cada gás pago.
-- `valor`: `QUANTITY` — (opcional) Inteiro do valor enviado com esta transação.
-- `input`: `DATA` - O código compilado de um contrato OU o hash da assinatura do método invocado e dos parâmetros codificados.
-- `nonce`: `QUANTITY` — (opcional) Inteiro de um nonce. Isso permite substituir suas próprias transações pendentes que usam o mesmo nonce.
-
-```js
-params: [
- {
- from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155",
- to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
- gas: "0x76c0", // 30400
- gasPrice: "0x9184e72a000", // 10000000000000
- value: "0x9184e72a", // 2441406250
- input:
- "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
- },
-]
-```
-
-**Retorna**
-
-`DATA`, 32 Bytes — O hash da transação ou o hash zero se a transação ainda não estiver disponível.
-
-Use [eth_getTransactionReceipt](#eth_gettransactionreceipt) para obter o endereço do contrato, depois que a transação foi proposta em um bloco, quando você criou um contrato.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
-}
-```
-
-### eth_sendRawTransaction {#eth_sendrawtransaction}
-
-Cria uma nova transação de chamada de mensagem ou um contrato para transações assinadas.
-
-**Parâmetros**
-
-1. `DATA`, O objeto de transação assinada.
-
-```js
-params: [
- "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
-]
-```
-
-**Retorna**
-
-`DATA`, 32 Bytes — O hash da transação ou o hash zero se a transação ainda não estiver disponível.
-
-Use [eth_getTransactionReceipt](#eth_gettransactionreceipt) para obter o endereço do contrato, depois que a transação foi proposta em um bloco, quando você criou um contrato.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
-}
-```
-
-### eth_call {#eth_call}
-
-Executa uma nova chamada de mensagem imediatamente sem criar uma transação na blockchain. Frequentemente usado para executar funções de contrato inteligente somente leitura, por exemplo, o `balanceOf` para um contrato ERC-20.
-
-**Parâmetros**
-
-1. `Object` - O objeto de chamada de transação
-
-- `from`: `DATA`, 20 Bytes — (opcional) O endereço a partir do qual a transação é enviada.
-- `to`: `DATA`, 20 Bytes — O endereço para o qual a transação é direcionada.
-- `gas`: `QUANTITY` — (opcional) Inteiro do gás fornecido para a execução da transação. eth_call consome zero gás, mas este parâmetro pode ser necessário para algumas execuções.
-- `gasPrice`: `QUANTITY` — (opcional) Inteiro do gasPrice usado para cada gás pago
-- `valor`: `QUANTITY` — (opcional) Inteiro do valor enviado com esta transação
-- `input`: `DATA` - (opcional) Hash da assinatura do método e parâmetros codificados. Para obter mais detalhes, consulte o [Contrato Ethereum ABI na documentação do Solidity](https://docs.soliditylang.org/en/latest/abi-spec.html).
-
-2. `QUANTITY|TAG` - número de bloco inteiro ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, consulte o [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block)
-
-**Retorna**
-
-`DATA` — O valor de retorno do contrato executado.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x"
-}
-```
-
-### eth_estimateGas {#eth_estimategas}
-
-Gera e retorna uma estimativa de quanto gás é necessário para permitir que a transação seja concluída. A transação não será adicionada à blockchain. Observe que a estimativa pode ser significativamente maior do que a quantidade de gás realmente usada pela transação, por vários motivos, incluindo a mecânica do EVM e o desempenho do nó.
-
-**Parâmetros**
-
-Veja os parâmetros do [eth_call](#eth_call), embora todas as propriedades sejam opcionais. Se nenhum limite de gás for especificado, o geth usa o limite de gás do bloco pendente como um limite superior. Consequentemente, a estimativa retornada poderá não ser suficiente para executar a chamada/transação quando a quantidade de gás for maior que o limite de gás do bloco pendente.
-
-**Retorna**
-
-`QUANTITY` — A quantidade de gás usada.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x5208" // 21000
-}
-```
-
-### eth_getBlockByHash {#eth_getblockbyhash}
-
-Retorna informações sobre um bloco por hash.
-
-**Parâmetros**
-
-1. `DATA`, 32 Bytes - Hash de um bloco.
-2. `Boolean` - Se `true` retorna os objetos de transação completos, se `false` apenas os hashes das transações.
-
-```js
-params: [
- "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
- false,
-]
-```
-
-**Retorna**
-
-`Object` — Um objeto de bloco, ou `null` quando nenhum bloco foi encontrado:
-
-- `number`: `QUANTITY` — O número do bloco. `null` quando o bloco está pendente.
-- `hash`: `DATA`, 32 Bytes — Hash do bloco. `null` quando o bloco está pendente.
-- `parentHash`: `DATA`, 32 Bytes — Hash do bloco pai.
-- `nonce`: `DATA`, 8 Bytes — Hash da prova de trabalho gerada. `null` quando o bloco está pendente.
-- `sha3Uncles`: `DATA`, 32 Bytes — SHA3 dos dados tios no bloco.
-- `logsBloom`: `DATA`, 256 Bytes — O filtro bloom para os logs do bloco. `null` quando o bloco está pendente.
-- `transactionsRoot`: `DATA`, 32 Bytes — A raiz da árvore de transação do bloco.
-- `stateRoot`: `DATA`, 32 Bytes — A raiz da árvore do estado final do bloco.
-- `receiptsRoot`: `DATA`, 32 Bytes — A raiz da árvore de itens recebidos do bloco.
-- `miner`: `DATA`, 20 Bytes — O endereço do beneficiário a quem as recompensas de mineração foram dadas.
-- `dificuldade`: `QUANTITY` — Inteiro da dificuldade para este bloco.
-- `totalDifficulty`: `QUANTITY` — Inteiro da dificuldade total da cadeia até este bloco.
-- `extraData`: `DATA` — O campo “dados extras” deste bloco.
-- `size`: `QUANTITY` — Inteiro do tamanho deste bloco em bytes.
-- `gasLimit`: `QUANTITY` — O gás máximo permitido neste bloco.
-- `gasUsed`: `QUANTITY` — O total de gás usado por todas as transações neste bloco.
-- `timestamp`: `QUANTITY` — O carimbo de data/hora unix no momento em que o bloco foi agrupado.
-- `transactions`: `Array` — Matriz de objetos de transação ou hashes de transação de 32 bytes, dependendo do último parâmetro fornecido.
-- `uncles`: `Array` — Matriz de hashes tio.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
-// Result
-{
-{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
- "difficulty": "0x4ea3f27bc",
- "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
- "gasLimit": "0x1388",
- "gasUsed": "0x0",
- "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
- "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171",
- "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843",
- "nonce": "0x689056015818adbe",
- "number": "0x1b4",
- "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54",
- "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
- "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
- "size": "0x220",
- "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d",
- "timestamp": "0x55ba467c",
- "totalDifficulty": "0x78ed983323d",
- "transactions": [
- ],
- "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
- "uncles": [
- ]
-}
-}
-```
-
-### eth_getBlockByNumber {#eth_getblockbynumber}
-
-Retorna informações sobre um bloco por número de bloco.
-
-**Parâmetros**
-
-1. `QUANTITY|TAG` - inteiro de um número de bloco, ou a string `"earliest"`, `"latest"`, `"pending"`, `"safe"` ou `"finalized"`, como no [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block).
-2. `Boolean` - Se `true` retorna os objetos de transação completos, se `false` apenas os hashes das transações.
-
-```js
-params: [
- "0x1b4", // 436
- true,
-]
-```
-
-**Retorno** Consulte [eth_getBlockByHash](#eth_getblockbyhash)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
-```
-
-Veja o resultado [eth_getBlockByHash](#eth_getblockbyhash)
-
-### eth_getTransactionByHash {#eth_gettransactionbyhash}
-
-Retorna as informações sobre uma transação solicitada pelo hash de transação.
-
-**Parâmetros**
-
-1. `DATA`, 32 Bytes - hash de uma transação
-
-```js
-params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
-```
-
-**Retorna**
-
-`Object` — Um objeto de transação ou `null` quando nenhuma transação foi encontrada:
-
-- `blockHash`: `DATA`, 32 Bytes — Hash do bloco onde esta transação estava localizada. `null` quando está pendente.
-- `blockNumber`: `QUANTITY` — Número do bloco onde esta transação estava localizada. `null` quando está pendente.
-- `from`: `DATA`, 20 Bytes — Endereço do remetente.
-- `gás`: `QUANTITY` — Gás fornecido pelo remetente.
-- `gasPrice`: `QUANTITY` — Preço do gás fornecido pelo remetente em Wei.
-- `hash`: `DATA`, 32 Bytes — Hash da transação.
-- `input`: `DATA` — Os dados enviados com a transação.
-- `nonce`: `QUANTITY` — O número de transações feitas pelo remetente antes desta.
-- `to`: `DATA`, 20 Bytes — Endereço do destinatário. `null` quando for uma transação de criação de contrato.
-- `transactionIndex`: `QUANTITY` — Inteiro da posição do índice de transações no bloco. `null` quando está pendente.
-- `valor`: `QUANTITY` — Valor transferido em Wei.
-- `v`: `QUANTITY` — ID de recuperação ECDSA
-- `r`: `QUANTITY` — Assinatura ECDSA r
-- `s`: `QUANTITY` — Assinatura ECDSA s
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
-// Result
-{
- "jsonrpc":"2.0",
- "id":1,
- "result":{
- "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
- "blockNumber":"0x5daf3b", // 6139707
- "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d",
- "gas":"0xc350", // 50000
- "gasPrice":"0x4a817c800", // 20000000000
- "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b",
- "input":"0x68656c6c6f21",
- "nonce":"0x15", // 21
- "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb",
- "transactionIndex":"0x41", // 65
- "value":"0xf3dbb76162000", // 4290000000000000
- "v":"0x25", // 37
- "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea",
- "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c"
- }
-}
-```
-
-### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex}
-
-Retorna informações sobre uma transação por hash de bloco e a posição do índice de transação.
-
-**Parâmetros**
-
-1. `DATA`, 32 Bytes - Hash de um bloco.
-2. `QUANTITY` - Inteiro da posição do índice da transação.
-
-```js
-parâmetros:[
- "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
- "0x0", // 0
-]
-```
-
-**Retorna** Consulte [eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
-```
-
-Resultado veja [eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
-
-Retorna informações sobre uma transação pelo número do bloco e posição do índice da transação.
-
-**Parâmetros**
-
-1. `QUANTITY|TAG` - um número de bloco ou a string `"earliest"`, `"latest"`, `"pending"`, `"safe"` ou `"finalized"`, como no [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - A posição do índice da transação.
-
-```js
-params: [
- "0x9c47cf", // 10241999
- "0x24", // 36
-]
-```
-
-**Retorna** Consulte [eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
-```
-
-Resultado veja [eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-### eth_getTransactionReceipt {#eth_gettransactionreceipt}
-
-Retorna o recebimento de uma transação pelo hash de transação.
-
-**Observe** que o recibo não está disponível para transações pendentes.
-
-**Parâmetros**
-
-1. `DADOS`, 32 bytes - hash de um bloco
-
-```js
-params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
-```
-
-**Retorna** `Object` — Um objeto de recebimento de transação, ou `null` quando nenhum recebimento foi encontrado:
-
-- `transactionHash`: `DATA`, 32 Bytes — Hash da transação.
-- `transactionIndex`: `QUANTITY` — Inteiro da posição do índice de transações no bloco.
-- `blockHash`: `DATA`, 32 Bytes — Hash do bloco onde esta transação estava localizada.
-- `blockNumber`: `QUANTITY` — Número do bloco onde esta transação estava localizada.
-- `from`: `DATA`, 20 Bytes — Endereço do remetente.
-- `to`: `DATA`, 20 Bytes — Endereço do destinatário. null quando for uma transação de criação de contrato.
-- `cumulativeGasUsed` : `QUANTITY` — A quantidade total de gás utilizada quando esta transação foi executada no bloco.
-- `effectiveGasPrice` : `QUANTITY` — A soma da taxa base e gorjeta pagas por unidade de gás.
-- `gasUsed`: `QUANTITY` — A quantidade de gás usada apenas por esta transação específica.
-- `contractAddress`: `DATA`, 20 Bytes — O endereço do contrato criado, se a transação era uma criação do contrato, caso contrário `null`.
-- `logs`: `Array` — Matriz de objetos de log gerados por esta transação.
-- `logsBloom`: `DATA`, 256 Bytes — Filtro Bloom para clientes leves para recuperar rapidamente os logs relacionados.
-- `type`: `QUANTITY` — Inteiro do tipo de transação, `0x0` para transações herdadas, `0x1` para tipos de lista de acesso, `0x2` para taxas dinâmicas.
-
-Ele também retorna _seja_ :
-
-- `root` : `DATA` 32 bytes de stateRoot pós-transação (anterior à atualização Byzantium)
-- `status`: `QUANTITY` seja `1` (êxito) ou `0` (falha)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
-// Result
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "blockHash":
- "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
- "blockNumber": "0xeff35f",
- "contractAddress": null, // string of the address if it was created
- "cumulativeGasUsed": "0xa12515",
- "effectiveGasPrice": "0x5a9c688d4",
- "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
- "gasUsed": "0xb4c8",
- "logs": [{
- // logs as returned by getFilterLogs, etc.
- }],
- "logsBloom": "0x00...0", // 256 byte bloom filter
- "status": "0x1",
- "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
- "transactionHash":
- "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5",
- "transactionIndex": "0x66",
- "type": "0x2"
- }
-}
-```
-
-### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-
-Retorna informações sobre o tio de um bloco por hash e a posição do índice de um tio.
-
-**Parâmetros**
-
-1. `DATA`, 32 Bytes - O hash de um bloco.
-2. `QUANTITY` - A posição do índice tio.
-
-```js
-parâmetros:[
- "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
- "0x0", // 0
-]
-```
-
-**Retorno** Consulte [eth_getBlockByHash](#eth_getblockbyhash)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
-```
-
-Veja o resultado [eth_getBlockByHash](#eth_getblockbyhash)
-
-**Observação**: um tio (bloco) não contém transações individuais.
-
-### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-
-Retorna informações sobre um tio de um bloco por número e posição do índice tio.
-
-**Parâmetros**
-
-1. `QUANTITY|TAG` - um número de bloco ou a string `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, como no [parâmetro de bloco padrão](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - A posição do índice tio.
-
-```js
-parâmetros: [
- "0x29c", // 668
- "0x0", // 0
-]
-```
-
-**Retorno** Consulte [eth_getBlockByHash](#eth_getblockbyhash)
-
-**Observação**: um tio (bloco) não contém transações individuais.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
-```
-
-Veja o resultado [eth_getBlockByHash](#eth_getblockbyhash)
-
-### eth_newFilter {#eth_newfilter}
-
-Cria um objeto de filtro, com base nas opções de filtro, para notificar quando o estado é alterado (logs). Para verificar se o estado mudou, chame [eth_getFilterChanges](#eth_getfilterchanges).
-
-**Observação sobre a especificação de filtros de tópicos:** Os tópicos são dependentes da ordem. Uma transação com um log com tópicos [A, B] será combinada pelos seguintes filtros de tópicos:
-
-- `[]` “qualquer coisa”
-- `[A]` “A na primeira posição (e qualquer coisa depois)”
-- `[null, B]` “qualquer coisa na primeira posição E B na segunda posição (e qualquer coisa depois)”
-- `[A, B]` “A na primeira posição E B na segunda posição (e qualquer coisa depois)”
-- `[[A, B], [A, B]]` “(A OU B) na primeira posição E (A OU B) na segunda posição (e qualquer coisa depois)”
-- **Parâmetros**
-
-1. `Object` - As opções de filtro:
-
-- `fromBlock`: `QUANTITY|TAG` - (opcional, padrão: `"latest"`) Número de bloco inteiro ou `"latest"` para o último bloco proposto, `"safe"` para o último bloco seguro, `"finalized"` para o último bloco finalizado ou `"pending"`, `"earliest"` para transações que ainda não estão em um bloco.
-- `toBlock`: `QUANTITY|TAG` - (opcional, padrão: `"latest"`) Número de bloco inteiro, ou `"latest"` para o último bloco proposto, `"safe"` para o último bloco seguro, `"finalized"` para o último bloco finalizado, ou `"pending"`, `"earliest"` para transações que ainda não estão em um bloco.
-- `endereço`: `DATA|Array`, 20 Bytes - (opcional) Endereço do contrato ou uma lista de endereços dos quais os logs devem se originar.
-- `topics`: `Array of DATA`, - (opcional) Array de tópicos de `DATA` de 32 Bytes. Os tópicos são dependentes da ordem. Cada tópico também pode ser uma matriz de DADOS com opções "ou".
-
-```js
-params: [
- {
- fromBlock: "0x1",
- toBlock: "0x2",
- address: "0x8888f1f195afa192cfee860698584c030f4c9db1",
- topics: [
- "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
- null,
- [
- "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
- "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc",
- ],
- ],
- },
-]
-```
-
-**Retorna** `QUANTITY` — Uma ID de filtro.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_newBlockFilter {#eth_newblockfilter}
-
-Cria um filtro no nó para notificar quando um novo bloco chega. Para verificar se o estado mudou, chame [eth_getFilterChanges](#eth_getfilterchanges).
-
-**Parâmetros** None (Nenhum)
-
-**Retorna** `QUANTITY` — Uma ID de filtro.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-
-Cria um filtro no nó para notificar quando chegam novas transações pendentes. Para verificar se o estado mudou, chame [eth_getFilterChanges](#eth_getfilterchanges).
-
-**Parâmetros** None (Nenhum)
-
-**Retorna** `QUANTITY` — Uma ID de filtro.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_uninstallFilter {#eth_uninstallfilter}
-
-Desinstala um filtro com a ID fornecida. Deve ser sempre chamado quando o relógio não for mais necessário. Além disso, filtra o tempo limite quando não são solicitados com [eth_getFilterChanges](#eth_getfilterchanges) por um período de tempo.
-
-**Parâmetros**
-
-1. `QUANTITY` - A ID do filtro.
-
-```js
-params: [
- "0xb", // 11
-]
-```
-
-**Retorna** `Boolean` — `true` se o filtro foi desinstalado com sucesso, caso contrário `false`.
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": true
-}
-```
-
-### eth_getFilterChanges {#eth_getfilterchanges}
-
-Método de sondagem para um filtro, que retorna uma matriz de logs que ocorreram desde a última sondagem.
-
-**Parâmetros**
-
-1. `QUANTITY` - A ID do filtro.
-
-```js
-params: [
- "0x16", // 22
-]
-```
-
-**Retorna** `Array` — Matriz de objetos de log ou uma matriz vazia se nada mudou desde a última sondagem.
-
-- Para filtros criados com `eth_newBlockFilter`, o retorno são hashes de bloco (`DATA`, 32 Bytes), por exemplo, `["0x3454645634534..."]`.
-- Para filtros criados com `eth_newPendingTransactionFilter`, o retorno são hashes de transação (`DATA`, 32 Bytes), por exemplo, `["0x6345343454645..."]`.
-- Para filtros criados com `eth_newFilter`, os logs são objetos com os seguintes parâmetros:
- - `removed`: `TAG` — `true` quando o log foi removido devido a uma reorganização da cadeia. `false` se for um log válido.
- - `logIndex`: `QUANTITY` — Inteiro da posição do índice de log no bloco. `null` quando o log estiver pendente.
- - `transactionIndex`: `QUANTITY` — Inteiro a partir do qual o log de posição do índice foi criado. `null` quando o log estiver pendente.
- - `transactionHash`: `DATA`, 32 Bytes — Hash das transações a partir das quais este log foi criado. `null` quando o log estiver pendente.
- - `blockHash`: `DATA`, 32 Bytes — Hash do bloco onde este log estava localizado. `null` quando está pendente. `null` quando o log estiver pendente.
- - `blockNumber`: `QUANTITY` — O número do bloco onde este log estava localizado. `null` quando está pendente. `null` quando o log estiver pendente.
- - `endereço`: `DADOS`, 20 Bytes — Endereço de origem deste log.
- - `data`: `DATA` - contém zero ou mais argumentos não indexados de 32 bytes do log.
- - `topics`: `Array of DATA` — Matriz de 0 a 4 32 Bytes `DATA` de argumentos de log indexados. (No _Solidity_: O primeiro tópico é o _hash_ da assinatura do evento (por exemplo, ` Deposit(address,bytes32,uint256)`), exceto se você declarou o evento com o especificador `anonymous`.)
-- **Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc":"2.0",
- "result": [{
- "logIndex": "0x1", // 1
- "blockNumber":"0x1b4", // 436
- "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
- "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
- "transactionIndex": "0x0", // 0
- "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
- "data":"0x0000000000000000000000000000000000000000000000000000000000000000",
- "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
- },{
- ...
- }]
-}
-```
-
-### eth_getFilterLogs {#eth_getfilterlogs}
-
-Retorna uma matriz de todos os logs correspondentes ao filtro com a ID fornecida.
-
-**Parâmetros**
-
-1. `QUANTITY` - A ID do filtro.
-
-```js
-params: [
- "0x16", // 22
-]
-```
-
-**Retorna** Consulte [eth_getFilterChanges](#eth_getfilterchanges)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
-```
-
-Resultado veja [eth_getFilterChanges](#eth_getfilterchanges)
-
-### eth_getLogs {#eth_getlogs}
-
-Retorna uma matriz de todos os logs que correspondem a um determinado objeto de filtro.
-
-**Parâmetros**
-
-1. `Object` - As opções de filtro:
-
-- `fromBlock`: `QUANTITY|TAG` - (opcional, padrão: `"latest"`) Número de bloco inteiro ou `"latest"` para o último bloco proposto, `"safe"` para o último bloco seguro, `"finalized"` para o último bloco finalizado ou `"pending"`, `"earliest"` para transações que ainda não estão em um bloco.
-- `toBlock`: `QUANTITY|TAG` - (opcional, padrão: `"latest"`) Número de bloco inteiro, ou `"latest"` para o último bloco proposto, `"safe"` para o último bloco seguro, `"finalized"` para o último bloco finalizado, ou `"pending"`, `"earliest"` para transações que ainda não estão em um bloco.
-- `endereço`: `DATA|Array`, 20 Bytes - (opcional) Endereço do contrato ou uma lista de endereços dos quais os logs devem se originar.
-- `topics`: `Array of DATA`, - (opcional) Array de tópicos de `DATA` de 32 Bytes. Os tópicos são dependentes da ordem. Cada tópico também pode ser uma matriz de DADOS com opções "ou".
-- `blockhash`: `DATA`, 32 Bytes — (opcional, **futuro**) Com a adição do EIP-234, `blockHash` será uma nova opção de filtro, que restringe os logs retornados ao bloco único com o hash de 32 bytes `blockHash`. Usar `blockHash` é equivalente a `fromBlock` = `toBlock` = o número do bloco com hash `blockHash`. Se `blockHash` estiver presente nos critérios de filtro, nem `fromBlock`, nem `toBlock` serão permitidos.
-
-```js
-params: [
- {
- topics: [
- "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
- ],
- },
-]
-```
-
-**Retorna** Consulte [eth_getFilterChanges](#eth_getfilterchanges)
-
-**Exemplo**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
-```
-
-Resultado veja [eth_getFilterChanges](#eth_getfilterchanges)
-
-## Exemplos de uso {#usage-example}
-
-### Implementando um contrato usando JSON_RPC {#deploying-contract}
-
-Esta seção inclui uma demonstração de como implantar um contrato usando apenas a interface RPC. Existem rotas alternativas para a implantação de contratos nos quais essa complexidade é abstraída, por exemplo, usando bibliotecas criadas sobre a interface RPC, como [web3.js](https://web3js.readthedocs.io/) e [web3.py](https://github.com/ethereum/web3.py). Essas abstrações são geralmente mais fáceis de entender e menos propensas a erros, mas ainda é útil entender o que está acontecendo internamente, ou seja, sem que o usuário perceba.
-
-Veja a seguir um contrato inteligente simples chamado `Multiply7` que será implantado usando a interface JSON-RPC em um nó Ethereum. Este tutorial pressupõe que o leitor já esteja executando um nó Geth. Mais informações sobre nós e clientes estão disponíveis [aqui](/developers/docs/nodes-and-clients/run-a-node). Consulte a documentação específica de cada [cliente](/developers/docs/nodes-and-clients/) para ver como iniciar o JSON-RPC HTTP para clientes não Geth. A maioria dos clientes atende por padrão no `localhost:8545`.
-
-```javascript
-contract Multiply7 {
- event Print(uint);
- function multiply(uint input) returns (uint) {
- Print(input * 7);
- return input * 7;
- }
-}
-```
-
-A primeira coisa a fazer é verificar se a interface HTTP RPC está habilitada. Isso significa que fornecemos ao Geth o sinalizador `--http` na inicialização. Neste exemplo, usamos o nó Geth em uma cadeia de desenvolvimento privada. Usando essa abordagem, não precisamos de ether na rede real.
-
-```bash
-geth --http --dev console 2>>geth.log
-```
-
-Isso iniciará a interface HTTP RPC em `http://localhost:8545`.
-
-Podemos verificar se a interface está funcionando recuperando o endereço e o saldo da Coinbase usando [curl](https://curl.se). Observe que os dados nesses exemplos serão diferentes no seu nó local. Se você quiser tentar esses comandos, substitua os parâmetros de solicitação na segunda solicitação curl pelo resultado retornado da primeira.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_coinbase", "id":1}' -H "Content-Type: application/json" localhost:8545
-{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
-
-curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
-{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"}
-```
-
-Como os números são codificados em hexa, o saldo é retornado em Wei como uma cadeia de caracteres hexadecimal. Se quisermos ter o saldo em ether como um número, podemos usar a Web3 do console Geth.
-
-```javascript
-web3.fromWei("0x1639e49bba16280000", "ether")
-// "410"
-```
-
-Agora que já temos alguns ethers em nossa cadeia de desenvolvimento privada, podemos implantar o contrato. O primeiro passo é compilar o contrato Multiply7 em byte code, que pode ser enviado para a EVM. Para instalar o solc, o compilador do Solidity, confira a [documentação do Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Você pode usar uma versão do `solc` mais antiga que corresponda [à versão do compilador usada em nosso exemplo](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
-
-O próximo passo é compilar o contrato Multiply7 em byte code, que pode ser enviado para a EVM.
-
-```bash
-echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
-
-======= :Multiply7 =======
-Binary:
-6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
-```
-
-Agora que temos o código compilado, precisamos determinar o quanto a sua implantação custará em gás. A interface RPC tem um método `eth_estimateGas`, que nos dará uma estimativa.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
-{"jsonrpc":"2.0","id":5,"result":"0x1c31e"}
-```
-
-Finalmente, implante o contrato.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545
-{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
-```
-
-A transação é aceita pelo nó e um hash de transação é retornado. Esse hash pode ser usado para rastrear a transação. O próximo passo é determinar o endereço onde nosso contrato está implantado. Cada transação executada criará uma confirmação de recebimento. Essa confirmação de recebimento contém várias informações sobre a transação, como em qual bloco a transação foi incluída e quanto gás foi usado pela EVM. Se uma transação criar um contrato, ela também conterá o endereço do contrato. Podemos recuperar a confirmação de recebimento com o método RPC `eth_getTransactionReceipt`.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
-{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
-```
-
-Nosso contrato foi criado em `0x4d03d617d700cf81935d7f797f4e2ae719648262`. Um resultado nulo em vez de um recibo significa que a transação ainda não foi incluída em um bloco. Espere um momento e verifique se o termo de consentimento do cliente está ativo e tente novamente.
-
-#### Interagindo com contratos inteligentes {#interacting-with-smart-contract}
-
-Neste exemplo, enviaremos uma transação usando `eth_sendTransaction` para o método `multiply` do contrato.
-
-`eth_sendTransaction` requer vários argumentos, especificamente `from`, `to` e `data`. `From` é o endereço público de nossa conta, e `to` é o endereço do contrato. O argumento `data` contém um conteúdo que define qual método deve ser chamado e com quais argumentos. É aqui que a [ABI (application binary interface ou interface binária do aplicativo)](https://docs.soliditylang.org/en/latest/abi-spec.html) entra em ação. A ABI é um arquivo JSON que estabelece como definir e codificar dados para a EVM.
-
-Os bytes do conteúdo definem qual método no contrato é chamado. Esses são os primeiros 4 bytes do hash Keccak sobre o nome da função e seus tipos de argumento, com codificação hexadecimal. A função multiplicar aceita um uint, que é um alias de uint256. Isso nos deixa com:
-
-```javascript
-web3.sha3("multiply(uint256)").substring(0, 10)
-// "0xc6888fa1"
-```
-
-O próximo passo é codificar os argumentos. Existe apenas um uint256, por exemplo, o valor 6. A ABI tem uma seção que especifica como codificar os tipos uint256.
-
-`int: enc(X)` é a codificação Big Endian do complemento de dois de X, preenchida no lado superior (esquerdo) com 0xff para X negativo e com zero > bytes para X positivo, de modo que o tamanho seja um múltiplo de 32 bytes.
-
-Isso codifica em `0000000000000000000000000000000000000000000000000000000000000006`.
-
-Combinando o seletor de função e o argumento codificado, nossos dados serão `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
-
-Isso agora pode ser enviado para o nó:
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545
-{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"}
-```
-
-Como uma transação foi enviada, um hash de transação foi retornado. A recuperação do recibo:
-
-```javascript
-{
- blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
- blockNumber: 268,
- contractAddress: null,
- cumulativeGasUsed: 22631,
- gasUsed: 22631,
- logs: [{
- address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d",
- blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
- blockNumber: 268,
- data: "0x000000000000000000000000000000000000000000000000000000000000002a",
- logIndex: 0,
- topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"],
- transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
- transactionIndex: 0
- }],
- transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
- transactionIndex: 0
-}
-```
-
-O recibo contém um log. Esse log foi gerado pela EVM na execução da transação e incluído no recibo. A função `multiply` mostra que o evento `Print` foi gerado com a entrada 7 vezes. Como o argumento do evento `Print` era um uint256, podemos decodificá-lo conforme as regras da ABI, o que nos deixará com a decimal 42 esperada. Além dos dados, vale ressaltar que os tópicos podem ser usados para determinar qual evento criou o log:
-
-```javascript
-web3.sha3("Print(uint256)")
-// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"
-```
-
-Esta foi apenas uma breve introdução a algumas das tarefas mais comuns, demonstrando o uso direto do JSON-RPC.
-
-## Tópicos relacionados {#related-topics}
-
-- [Especificações do JSON-RPC](http://www.jsonrpc.org/specification)
-- [ Nós e clientes](/developers/docs/nodes-and-clients/)
-- [APIs JavaScript](/developers/docs/apis/javascript/)
-- [APIs de back-end](/developers/docs/apis/backend/)
-- [Clientes de execução](/developers/docs/nodes-and-clients/#execution-clients)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
deleted file mode 100644
index ff37c15595b..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: Exploradores de bloco
-description: Uma introdução aos exploradores de bloco, seu portal no mundo dos dados da blockchain, onde você pode consultar informações sobre transações, contas, contratos e mais.
-lang: pt-br
-sidebarDepth: 3
----
-
-Exploradores de blocos são o seu portal para os dados do Ethereum. Você pode usá-los para ver dados em tempo real sobre blocos, transações, validadores, contas e outras atividades em cadeia.
-
-## Pré-requisitos {#prerequisites}
-
-Você deve entender os conceitos básicos do Ethereum; para que você possa entender o sentido dos dados que um explorador de blocos lhe dá. Comece com [uma introdução ao Ethereum](/developers/docs/intro-to-ethereum/).
-
-## Serviços {#services}
-
-- [Etherscan](https://etherscan.io/) -_Também disponível em chinês, coreano, russo e japonês_
-- [3xpl](https://3xpl.com/ethereum)
-- [Beaconcha.in](https://beaconcha.in/)
-- [Blockchair](https://blockchair.com/ethereum) -_ Também disponível em espanhol, francês, italiano, holandês, português, russo, chinês e persa_
-- [Blockscout](https://eth.blockscout.com/)
-- [Chainlens](https://www.chainlens.com/)
-- [Explorador de Blocos DexGuru](https://ethereum.dex.guru/)
-- [Etherchain](https://www.etherchain.org/)
-- [Ethernow](https://www.ethernow.xyz/)
-- [Ethplorer](https://ethplorer.io/) -_ Também disponível em chinês, espanhol, francês, turco, russo, coreano e vietnamita_
-- [EthVM](https://www.ethvm.com/)
-- [OKLink](https://www.oklink.com/eth)
-- [Rantom](https://rantom.app/)
-
-## Ferramentas de Código aberto {#open-source-tools}
-
-- [Otterscan](https://otterscan.io/)
-- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan)
-
-## Dados {#data}
-
-Ethereum é transparente por concepção, então tudo é verificável. Os exploradores de bloco fornecem uma interface para obter essas informações. E isso é tanto para a rede principal Ethereum; quanto para as redes de teste, caso você precise desse dado. Os dados são divididos em dados de execução e dados de consenso. Os dados de execução referem-se às transações executadas em um bloco específico. Os dados de consenso referem-se aos blocos em si e aos validadores que os propuseram.
-
-Aqui está um resumo dos tipos de dados que você pode obter de um explorador de blocos.
-
-### Dados de execução {#execution-data}
-
-Novos blocos são adicionados à Ethereum a cada 12 segundos (a menos que um proponente de bloco perca a sua vez), então um fluxo quase constante de dados é adicionado aos exploradores de blocos. Os blocos contêm muitos dados importantes que você pode achar úteis:
-
-**Dados padrões**
-
-- Altura do bloco - O número do bloco e o comprimento da blockchain (em blocos) na criação do bloco atual
-- Timestamp - A hora em que um bloco foi proposto
-- Transações - O número de transações incluídas no bloco
-- Destinatário da taxa - O endereço que recebeu gorjetas de taxas de gás das transações
-- Recompensa do bloco - A quantidade de ETH concedida ao validador que propôs o bloco
-- Tamanho - O tamanho dos dados dentro do bloco (medido em bytes)
-- Gás utilizado - O total de unidades de gás utilizadas pelas transações no bloco
-- Limite de Gás - Os limites totais de gás definidos pelas transações no bloco
-- Taxa base por gás - O multiplicador mínimo necessário para que uma transação seja incluída em um bloco
-- Taxas queimadas - Quanto ETH é queimado no bloco
-- Dados extras - Quaisquer dados extras que o construtor tenha incluído no bloco
-
-**Dados avançados**
-
-- Hash - O hash criptográfico que representa o cabeçalho do bloco (o identificador único do bloco)
-- Hash pai - O hash do bloco que veio antes do bloco atual
-- StateRoot - O hash raiz da árvore de Merkle, que armazena todo o estado do sistema
-
-### Gás {#gas}
-
-Os exploradores de blocos não apenas fornecerão dados sobre o uso de gás em transações e bloqueios, mas alguns fornecerão informações sobre os preços atuais do gás na rede. Isso ajudará você a entender o uso da rede, enviar transações seguras e não gastar muito com gás. Procure APIs que podem ajudá-lo a inserir essas informações na interface do seu produto. Os dados específicos do gás cobrem:
-
-- Unidades estimadas de gás necessárias para uma transação segura, mas lenta (+ preço e duração estimados)
-- Unidades estimadas de gás necessárias para uma transação média (+ preço e duração estimados)
-- Unidades estimadas de gás necessárias para uma transação rápida (+ preço e duração estimados)
-- Tempo médio de confirmação com base no preço do gás
-- Contratos que consomem gás - em outras palavras, produtos populares que estão sendo muito usados na rede
-- Contas que estão gastando gás - em outras palavras, usuários frequentes da rede
-
-### Transações {#transactions}
-
-Os exploradores de blocos se tornaram um lugar comum para as pessoas acompanharem o andamento de suas transações. Isso ocorre porque o nível de detalhe que você pode obter fornece uma certeza extra. Os dados de transação incluem:
-
-**Dados padrão**
-
-- Hash da transação - Um hash gerado quando a transação é enviada
-- Status - Uma indicação de se a transação está pendente, falhou ou foi concluída
-- Bloco - O bloco em que a transação foi incluída
-- Timestamp - A hora em que uma transação foi incluída em um bloco proposto por um validador
-- De - O endereço da conta que enviou a transação
-- Para - O endereço do destinatário ou o contrato inteligente com que a transação interagem
-- Tokens transferidos - Uma lista de tokens que foram transferidos como parte da transação
-- Valor - O valor total de ETH que está sendo transferido
-- Taxa de transação - O valor pago ao validador para processar a transação (calculado pelo preço do gás\*gás usado)
-
-**Dados avançados**
-
-- Limite de gás - O número máximo de unidades de gás que esta transação pode consumir
-- Gás usado - A quantidade real de unidades de gás que a transação consumiu
-- Preço do gás - O preço estabelecido por unidade de gás
-- Nonce - O número da transação para o endereço `de` (tenha em mente que isso começa em 0, então um nonce de `100` seria na verdade a 101 transação enviada por esta conta
-- Dados de entrada - Quaisquer informações extras necessárias pela transação
-
-### Contas {#accounts}
-
-Há muitos dados que você pode acessar sobre uma conta. É por isso que muitas vezes é recomendado usar várias contas para que seus ativos e valor não possam ser facilmente rastreados. Existem também algumas soluções que estão a ser desenvolvidas para tornar as transações e as atividades de contabilidade mais privadas. Mas aqui estão os dados que estão disponíveis para contas:
-
-**Contas de usuários**
-
-- Endereço da conta - O endereço público para o qual você pode usar para enviar fundos
-- Saldo ETH - A quantidade de ETH associada a essa conta
-- Valor total de ETH - O valor do ETH
-- Tokens - Os tokens associados à conta e seu valor
-- Histórico de transações - Uma lista de todas as transações em que esta conta foi o remetente ou o destinatário
-
-**Contratos inteligentes**
-
-As contas de contrato inteligentes possuem todos os dados que uma conta de usuário terá, mas alguns exploradores de blocos também exibirão algumas informações de código. Os exemplos incluem:
-
-- Criador de contrato - O endereço que implantou o contrato na rede principal
-- Transação de criação - A transação que incluiu a implantação para a conta principal
-- Código fonte - O código Solidity ou Vyper do contrato inteligente
-- Contrato ABI - Interface Binária do contrato da aplicação, as chamadas são feitas e os dados recebidos
-- Código de criação do contrato - O bytecode compilado do contrato inteligente, criado quando você compila um contrato inteligente escrito em Solidity ou Vyper etc.
-- Eventos de contrato - Um histórico dos métodos chamados no contrato inteligente, basicamente uma maneira de ver como o contrato está sendo usado e com que frequência
-
-### Tokens {#tokens}
-
-Tokens são um tipo de contrato, então eles terão dados semelhantes a um contrato inteligente. Mas como eles têm valor e podem ser trocados, eles têm pontos de dados adicionais:
-
-- Tipo - Se eles forem um padrão ERC-20, ERC-721 ou outro padrão de token
-- Preço - Se eles forem um ERC-20, terão um valor de mercado atual
-- Capitalização de mercado - Se forem ERC-20, terão uma capitalização de mercado (calculada por preço\*oferta total)
-- Oferta total - O número de tokens em circulação
-- Holders - O número de endereços que possuem o token
-- Transferências - O número de vezes que o token foi transferido entre contas
-- Histórico de transações - Um histórico de todas as transações, incluindo o token
-- Endereço do contrato - O endereço do token que foi implantado na rede principal
-- Números decimais - tokens ERC-20 são divisíveis e têm casas decimais
-
-### Rede {#network}
-
-Alguns dados do bloco estão preocupados com a funcionalidade da Ethereum de forma mais holística.
-
-- Total de transações - O número de transações desde a criação da Ethereum
-- Transações por segundo - O número de transações processáveis em um segundo
-- Preço ETH - As avaliações atuais de 1 ETTH
-- Fornecimento total de ETH – Número de ETH em circulação – lembre-se de que o novo ETH é criado com a criação de cada bloco sob a forma de recompensas por bloco
-- Capitalização de mercado - Cálculo do preço \ * oferta
-
-## Dados de camada de consenso {#consensus-layer-data}
-
-### Época {#epoch}
-
-Por razões de segurança, comitês aleatórios de validadores são criados no final de cada período (a cada 6,4 minutos). Os dados de época incluem:
-
-- Número de época
-- Status finalizado – Se o período foi finalizado (Sim/Não)
-- Tempo – O tempo em que a época terminou
-- Atestações - O número de atestações na época (votos para blocos dentro de espaços)
-- Depósitos – O número de depósitos de ETH incluídos na época (os validadores devem fazer participações de ETH para se tornarem validadores)
-- Remoções - Número de penalidades dadas aos proponentes de blocos ou atestadores
-- Participação na votação – A quantidade de participações de ETH usadas para atestar blocos
-- Validadores – Número de validadores ativos para a época
-- Saldo médio de validador – Saldo médio para validadores ativos
-- Espaços – Número de espaços incluídos na época (espaços incluem um bloco válido)
-
-### Espaço {#slot}
-
-Espaços são oportunidades para criação de blocos, os dados disponíveis para cada espaço incluem:
-
-- Época – A época em que o espaço é válido
-- Número do espaço
-- Status – O status do espaço (proposto/perdido)
-- Tempo - o carimbo de data/hora do espaço
-- Proponente – O validador que propôs o bloco para o espaço
-- Raiz do bloco - A raiz da árvore de hash do BeaconBlock
-- Raiz principal – O hash do bloco que veio antes
-- Raiz do estado - A raiz da árvore de hash do BeaconState
-- Assinatura
-- Randao revelado
-- Graffiti - Um proponente de blocos pode incluir uma mensagem de 32 bytes em sua proposta de bloco
-- Dados de execução
- - Hash do bloco
- - Contagem de depósitos
- - Raiz de depósito
-- Atestações - Número de atestações para o bloco neste espaço
-- Depósitos - O número de depósitos durante este espaço
-- Saídas voluntárias - O número de validadores que saiu durante o espaço
-- Remoções - Número de penalidades dadas aos proponentes de blocos ou atestores
-- Votos - Os validadores que votaram no bloco neste espaço
-
-### Blocos {#blocks-1}
-
-Proof-of-stake divide o tempo em slots e épocas. Isso significa novos dados!
-
-- Proponente - O validador que foi escolhido algoritmicamente para propor o novo bloco
-- Época - A época em que o bloco foi proposto
-- Espaço - O espaço em que o bloco foi proposto
-- Atestações - O número de atestado incluído no espaço — atestações são como votos que indicam que o bloco está pronto para ir para a Beacon Chain
-
-### Validadores {#validators}
-
-Os validadores são responsáveis por propor blocos e atestá-los dentro dos espaços.
-
-- Número do validador - Número único que representa o validador
-- Saldo atual - O saldo do validador incluindo recompensas
-- Saldo efetivo - O saldo do validador que é usado para staking
-- Receita - As recompensas ou penalidades recebidas pelo validador
-- Status - se o validador está on-line e ativo ou não
-- Atestação de eficácia - O tempo médio necessário para que as atestações do validador sejam incluídas na cadeia
-- Elegibilidade para ativação - Data (e época) em que o validador se tornou disponível para validar
-- Ativo desde - Data (e época) em que o validador se tornou ativo
-- Blocos propostos - O bloco que o validador propôs
-- Atestações - as atestações que o validador forneceu
-- Depósitos - O endereço de origem, hash da transação, número do bloco, data e hora, valor e status do depósito de aposta feito pelo validador
-
-### Atestações {#attestations}
-
-As atestações são votos a favor da inclusão de blocos na cadeia. Seus dados estão relacionados a um registro de atestação e dos validadores que atestaram
-
-- Espaço - O espaço em que a atestação ocorreu
-- Índice do comitê - O índice do comitê em determinado espaço
-- Bits de agregação - Representa o certificado agregado de todos os validadores participantes na atestação
-- Validadores - Os validadores que forneceram as atestações
-- Raíz do bloco Beacon - Aponta para o bloco que os validadores estão atestando
-- Fonte - Pontos para a última época justificada
-- Alvo - Pontos para o último limite de época
-- Assinatura
-
-### Rede {#network-1}
-
-Os dados de nível superior da camada consensual incluem os seguintes:
-
-- Época atual
-- Espaço atual
-- Validadores ativos - Número de validadores ativos
-- Validadores pendentes - Número de validadores à espera de serem ativados
-- Participação de ETH - Valor da participação de ETH na rede
-- Saldo médio - Saldo médio de ETH de validadores
-
-## Exploradores de bloco {#block-explorers}
-
-- [Etherscan](https://etherscan.io/) - um explorador de bloco que você pode usar para buscar dados da rede principal Ethereum e rede de testes Goerli
-- [3xpl](https://3xpl.com/ethereum) - um explorador Ethereum de código aberto e sem anúncios que permite o download de seus conjuntos de dados
-- [Beaconcha.in](https://beaconcha.in/) - um explorador de bloco de código aberto para Ethereum Mainnet e Goerli Testnet
-- [Blockchair](https://blockchair.com/ethereum) - o explorador Ethereum mais privado. Também para classificação e filtragem de dados (mempool)
-- [Etherchain](https://www.etherchain.org/) - um explorador de blocos para a rede principal Ethereum
-- [Ethplorer](https://ethplorer.io/) - um explorador de blocos com foco nos tokens da rede principal Ethereum e rede de testes Kovan
-- [Rantom](https://rantom.app/) - Um DeFi amigável de código aberto & Visualizador de transação NFT para visões detalhadas
-- [Ethernow](https://www.ethernow.xyz/) - um explorador de transações em tempo real que permite que você veja a camada pré-cadeia da Ethereum Mainnet
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que ajudou você? Edite esta página e adicione-o!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Transações](/developers/docs/transactions/)
-- [Contas](/developers/docs/accounts/)
-- [Redes](/developers/docs/networks/)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
deleted file mode 100644
index ae542185af4..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Dados e Estatísticas
-description: Como obter dados e análises on-chain para uso em dapps
-lang: pt-br
----
-
-## Introdução {#Introduction}
-
-À medida que a utilização da rede continua a aumentar, irá existir uma quantidade crescente de informações valiosas nos dados on-chain. À medida que o volume de dados aumenta rapidamente, calcular e agregar essas informações para relatar ou dirigir um dapp pode se tornar uma dura empreitada de tempo e processo.
-
-A alavancagem dos prestadores de dados existentes pode acelerar o desenvolvimento, produzir resultados mais precisos e reduzir os esforços contínuos de manutenção. Isso permitirá que uma equipe se concentre na funcionalidade central que seu projeto está tentando fornecer.
-
-## Pré-requisitos {#prerequisites}
-
-Você deve entender o conceito básico de [Exploradores de Bloco](/developers/docs/data-and-analytics/block-explorers/) para entender melhor usá-los no contexto da análise de dados. Além disso, familiarize-se com o conceito de um [índice](/glossary/#index) para entender os benefícios que eles adicionam a uma concepção do sistema.
-
-Em termos de fundamentos arquitetônicos, entendendo o que uma [API](https://www.wikipedia.org/wiki/API) e [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) são, mesmo em teoria.
-
-## Exploradores de bloco {#block-explorers}
-
-Muitos [Block Explorers](/developers/docs/data-and-analytics/block-explorers/) oferecem gateways [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) que fornecerão aos desenvolvedores visibilidade de dados em tempo real sobre blocos, transações, validadores, contas e outras atividades na cadeia.
-
-Desenvolvedores podem então processar e transformar esses dados para dar aos seus usuários percepções e interações exclusivas com a [blockchain](/glossary/#blockchain). Por exemplo, [Etherscan](https://etherscan.io) fornece dados de execução e consenso para cada slot de 12s.
-
-## The Graph {#the-graph}
-
-A [rede Graph Network](https://thegraph.com/) é um protocolo descentralizado de indexação para a organização de dados blockchain. Em vez de construir e gerenciar lojas de dados off-chain e centralizadas para agregação de dados on-chain com The Graph, os desenvolvedores podem construir aplicativos sem servidor que são executados inteiramente na infraestrutura pública.
-
-Usando o [GraphQL](https://graphql.org/), os desenvolvedores podem consultar qualquer uma das APIs abertas selecionadas, conhecidas como subgráficos, para adquirir as informações necessárias para impulsionar seu dapp. Ao consultar esses subgráficos indexados, relatórios e dapps, não apenas obtêm benefícios de desempenho e escalabilidade, como também a precisão incorporada fornecida pelo consenso da rede. Como novas melhorias e/ou subgráficos são adicionados à rede, seus projetos podem iterar rapidamente para tirar proveito dessas melhorias.
-
-## Diversidade dos clientes
-
-A [diversidade do cliente](/developers/docs/nodes-and-clients/client-diversity/) é importante para a saúde geral da rede Ethereum porque fornece resiliência a bugs e explorações. Agora existem vários painéis de diversidade do cliente, incluindo [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) e [Ethernodes](https://ethernodes.org/).
-
-## Dune Analytics {#dune-analytics}
-
-O [Dune Analytics](https://dune.com/) pré-processa dados da blockchain em tabelas de banco de dados relacional (PostgreSQL e DatabricksSQL), que permite aos usuários consultar dados da blockchain usando SQL e criem painéis com base nos resultados da consulta. Os dados on-chain são organizados em 4 tabelas brutas: `blocos`, `transações`, (evento) `registros` e (chamada) `traços`. Contratos e protocolos populares foram decodificados e cada um tem seu próprio conjunto de tabelas de eventos e chamadas. Essas tabelas de eventos e chamadas são processadas e organizadas em abstração de tabelas por tipo de protocolo, por exemplo, dex, lending, stablecoins etc.
-
-## Rede de Subconsulta {#subquery-network}
-
-[SubQuery](https://subquery.network/) é um indexador de dados líder que fornece aos desenvolvedores APIs rápidas, confiáveis, descentralizadas e personalizadas para seus projetos web3. A SubQuery capacita desenvolvedores de mais de 165+ ecossistemas (incluindo Ethereum) com dados indexados ricos para criar experiências intuitivas e imersivas para seus usuários. A Rede SubQuery alimenta seus aplicativos imbatíveis com uma infraestrutura resiliente e descentralizada. Utilize o kit de ferramentas para desenvolvedores de blockchain da SubQuery para construir as aplicações web3 do futuro, sem precisar gastar tempo construindo um backend personalizado para atividades de processamento de dados.
-
-Para começar, visite o [guia rápido de Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) para começar a indexar dados da blockchain Ethereum em minutos em um ambiente local Docker para testes antes de ir ao vivo em um [serviço gerenciado da SubQuery](https://managedservice.subquery.network/) ou na [rede descentralizada da SubQuery](https://app.subquery.network/dashboard).
-
-## Ethernow - Programa de dados Mempool {#ethernow}
-[Blocknative](https://www.blocknative.com/) fornece acesso aberto ao seu [arquivo de dados de mempool](https://www.ethernow.xyz/mempool-data-archive) histórico do Ethereum. Isso permite pesquisadores e bons projetos comunitários explorar a camada pré-chain da Ethereum Mainnet. O conjunto de dados é ativamente mantido e representa o registro histórico mais abrangente dos eventos de transações de mempool dentro do ecossistema Ethereum. Saiba mais em [Ethernow](https://www.ethernow.xyz/).
-
-## Leitura Adicional {#further-reading}
-
-- [Visão geral da rede de gráficos](https://thegraph.com/docs/en/about/network/)
-- [Área de consulta de gráficos](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current)
-- [Exemplos de código de API em EtherScan](https://etherscan.io/apis#contracts)
-- [Explorador de Beacon Chain Beaconcha.in](https://beaconcha.in)
-- [Fundamentos do Dune](https://docs.dune.com/#dune-basics)
-- [Guia Rápido de Início da SubQuery para Ethereum](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
deleted file mode 100644
index 6e09c96f537..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: Redes de desenvolvimento
-description: Uma visão geral das redes de desenvolvimento e ferramentas disponíveis para ajudar a construir aplicativos Ethereum.
-lang: pt-br
----
-
-Quando fizer um aplicativo Ethereum com contratos inteligentes, você poderá rodar ele em uma rede local para ver como funciona antes de implementar.
-
-Assim como é possível executar um servidor local do seu computador para desenvolvimento web, você pode usar uma rede de desenvolvimento para criar uma instância local de cadeia de blocos para testar seu dapp. Essas redes de desenvolvimento da Ethereum fornecem recursos que permitem uma iteração muito mais rápida do que uma rede de testes pública (por exemplo, você não precisa lidar com a aquisição de ETH de uma faucet de rede de testes).
-
-## Pré-requisitos {#prerequisites}
-
-Você precisa entender conceitos [básicos da pilha de Ethereum](/developers/docs/ethereum-stack/) e [das redes de Ethereum](/developers/docs/networks/) antes de mergulhar nas redes de desenvolvimento.
-
-## O que é uma rede de desenvolvimento? {#what-is-a-development-network}
-
-Redes de desenvolvimento são essencialmente clientes Ethereum (implementações da Ethereum) concebidas especificamente para desenvolvimento local.
-
-**Por quê não executar somente um nó Ethereum localmente?**
-
-Você _poderia_ [executar um nó](/developers/docs/nodes-and-clients/#running-your-own-node), mas como as redes de desenvolvimento são criadas especificamente para o desenvolvimento, elas geralmente vêm com recursos convenientes, como:
-
-- Semeando deterministicamente sua blockchain local com dados (por exemplo, contas com saldo ETH)
-- Produzir instantaneamente blocos com cada transação que receber, em ordem e sem atraso
-- Funcionalidade de depuração e registro aprimorado
-
-## Ferramentas disponíveis {#available-projects}
-
-**Nota**: [A maioria dos frameworks desenvolvidos](/developers/docs/frameworks/) incluem uma rede de desenvolvimento integrada. Recomendamos começar com um framework para [configurar seu ambiente de desenvolvimento local](/developers/local-environment/).
-
-### Ganache {#ganache}
-
-Crie uma blockchain Ethereum pessoal que você possa usar para testes, executar comandos e inspecionar seu estado, enquanto controla como a cadeia irá operar.
-
-Ganache fornece tanto um aplicativo de desktop (Ganache UI), como uma linha de comando (`ganache-cli`). Isso é uma parte da suíte de ferramentas Truffle.
-
-- [Website](https://www.trufflesuite.com/ganache)
-- [GitHub](https://github.com/trufflesuite/ganache)
-- [Documentação](https://www.trufflesuite.com/docs/ganache/overview)
-
-### Rede Hardhat {#hardhat-network}
-
-Uma rede local Ethereum concebida para desenvolvedores. Isso permite que você implante seus contratos, execute os testes e depure seu código.
-
-A rede Hardhat vem integrada com Hardhat, um ambiente de desenvolvimento para profissionais.
-
-- [Website](https://hardhat.org/)
-- [GitHub](https://github.com/nomiclabs/hardhat)
-
-### Beacon Chains Locais {#local-beacon-chains}
-
-Alguns clientes de consenso têm ferramentas integradas para ativar as cadeias Beacon locais para fins de teste. Instruções para Lighthouse, Nimbus e Lodestar estão disponíveis:
-
-- [Testnet local usando Lodestar](https://chainsafe.github.io/lodestar/usage/local/)
-- [Testnet local usando Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
-- [Testnet local usando Nimbus](https://github.com/status-im/nimbus-eth1/blob/master/fluffy/docs/local_testnet.md)
-
-### Cadeias de teste públicas do Ethereum {#public-beacon-testchains}
-
-Existem também duas implementações públicas de testes da Ethereum: Goerli e Sepolia. A rede de testes recomendada com apoio em longo prazo é Goerli, sobre a qual qualquer pessoa tem liberdade para validar. Sepolia é uma cadeia mais nova e menor que também deve ser mantida em um futuro previsível, com um conjunto de validadores autorizados (o que significa que não há acesso geral a novos validadores nesta rede de teste). Espera-se que a cadeia de Ropsten seja descontinuada no quarto trimestre de 2022, e espera-se que a cadeia de Rinkeby seja descontinuada no segundo ou terceiro trimestre de 2023.
-
-- [Plataforma de lançamento de staking Goerli](https://goerli.launchpad.ethereum.org/)
-- [Anúncio de descontinuação da Ropsten, Rinkeby & Kiln](https://blog.ethereum.org/2022/06/21/testnet-deprecation)
-
-### Pacote Kurtosis do Ethereum {#kurtosis}
-
-Kurtosis é um sistema de construção para ambientes de teste em vários contêineres, que permite aos desenvolvedores gerar localmente instâncias reproduzíveis de redes blockchain.
-
-O pacote Ethereum Kurtosis pode ser usado para instanciar rapidamente uma rede de teste Ethereum parametrizável, altamente dimensionável e privada no Docker ou no Kubernetes. O pacote é compatível com todos os principais clientes da camada de execução (EL) e da camada de consenso (CL). A Kurtosis lida com todos os mapeamentos de portas locais e conexões de serviço para uma rede representativa a ser usada em fluxos de trabalho de validação e teste relacionados à infraestrutura principal da Ethereum.
-
-- [Pacote de rede Ethereum](https://github.com/kurtosis-tech/ethereum-package)
-- [Website](https://www.kurtosis.com/)
-- [GitHub](https://github.com/kurtosis-tech/kurtosis)
-- [Documentação](https://docs.kurtosis.com/)
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Estruturas de desenvolvimento](/developers/docs/frameworks/)
-- [Configure um ambiente de desenvolvimento](/developers/local-environment/)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
deleted file mode 100644
index 6d06607dc29..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Introdução à pilha de Ethereum
-description: Um passo a passo de diferentes camadas de pilha de Ethereum e como elas se encaixam.
-lang: pt-br
----
-
-Como qualquer pilha de software, a "pilha de Ethereum" completa varia de projeto a projeto dependendo do seu objetivo de negócios.
-
-Entretanto, existem tecnologias centrais da Ethereum que ajudam a fornecer um modelo mental sobre como aplicativos de software interagem com a cadeia de blocos Ethereum. Compreender as camadas da pilha ajudará você a entender as diferentes maneiras como o Ethereum pode ser integrado nos projetos de software.
-
-## Nível 1: Máquina Virtual Ethereum {#ethereum-virtual-machine}
-
-A [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) é o ambiente de execução para contratos inteligentes na Ethereum. Todos os contratos inteligentes e alterações de estado na blockchain Ethereum são executados por [transações](/developers/docs/transactions/). A EVM controla todo o processamento de transações na rede Ethereum.
-
-Como em qualquer máquina virtual, a EVM cria um nível de abstração entre o código de execução e a máquina de execução (um nó Ethereum). Atualmente, a EVM está executando em milhares de nós distribuídos pelo mundo.
-
-Por trás das cortinas, a EVM utiliza um conjunto de instruções opcode para executar tarefas específicas. Esses opcodes (140 exclusivos) permitem que a EVM seja [Turing-complete](https://en.wikipedia.org/wiki/Turing_completeness), o que significa que a EVM é capaz de computar praticamente qualquer coisa, com recursos suficientes.
-
-Como um desenvolvedor dapp, você não precisa saber muito sobre a EVM que não existe e isso alimenta de forma confiável todos os aplicativos na Ethereum sem interrupções.
-
-## Nível 2: Contratos Inteligentes {#smart-contracts}
-
-[Contratos inteligentes](/developers/docs/smart-contracts/) são os programas executáveis que funcionam na blockchain Ethereum.
-
-Os contratos inteligentes são escritos usando [linguagens de programação](/developers/docs/smart-contracts/languages/) que compilam para bytecode EVM (instruções de máquina de baixo nível chamadas códigos de operação).
-
-Não só os contratos inteligentes servem como bibliotecas de código aberto, eles são essencialmente serviços de API abertos que rodam 24/7 e não podem ser derrubados. Os contratos inteligentes fornecem funções públicas com as quais os aplicativos ([dapps](/developers/docs/dapps/)) podem interagir sem precisar de permissão. Qualquer aplicativo pode se integrar com contratos inteligentes implantados para compor funcionalidade, como adicionar [feeds de dados](/developers/docs/oracles/) ou suportar trocas de token. Qualquer um pode implantar novos contratos inteligentes para a Ethereum, a fim de adicionar funcionalidade personalizada para atender às necessidades do aplicativo.
-
-Como um desenvolvedor dapp, você só precisará escrever contratos inteligentes se desejar adicionar funcionalidade personalizada na blockchain Ethereum. Você pode encontrar que pode alcançar a maior parte ou todas as necessidades do seu projeto simplesmente integrando com contratos inteligentes existentes, por exemplo, se você deseja apoiar pagamentos em stablecoins ou habilitar o câmbio descentralizado de tokens.
-
-## Nível 3: Nós Ethereum {#ethereum-nodes}
-
-Para um aplicativo interagir com a blockchain Ethereum, ele deve se conectar a um [nó Ethereum](/developers/docs/nodes-and-clients/). Conectar-se a um nó permite que você leia dados da blockchain (cadeia de blocos) e/ou envie transações para a rede.
-
-Os nós Ethereum são computadores executando um software - um cliente Ethereum. Um cliente é uma implementação da Ethereum que verifica todas as transações em cada bloco, mantendo a rede segura e os dados precisos. **Os nós Ethereum são a blockchain (cadeia de blocos) Ethereum**. Eles armazenam coletivamente o estado da blockchain Ethereum e alcançam consenso sobre transações para alterar o estado da blockchain.
-
-Conectando seu aplicativo a um nó Ethereum (via [JSON-RPC API](/developers/docs/apis/json-rpc/)), sua aplicação é capaz de ler dados da blockchain (como os saldos das contas de usuários) bem como transmitir novas transações para a rede (como a transferência do ETH entre as contas de usuários ou a execução de funções de contratos inteligentes).
-
-## Nível 4: API de Cliente Ethereum {#ethereum-client-apis}
-
-Muitas bibliotecas de conveniência (desenvolvidas e mantidas pela comunidade de código aberto da Ethereum) permitem que seus aplicativos de usuário finais se conectem e se comuniquem com a blockchain Ethereum.
-
-Se seu aplicativo voltado para o usuário for um aplicativo web, você pode optar por `instalar o npm` uma [API JavaScript](/developers/docs/apis/javascript/) diretamente no seu frontend. Ou talvez você escolha implementar esta funcionalidade do lado do servidor usando uma API [Python](/developers/docs/programming-languages/python/) ou [Java](/developers/docs/programming-languages/java/).
-
-Embora essas APIs não sejam uma parte necessária da pilha, elas abstraem muito da complexidade de interagir diretamente com um nó Ethereum. Eles também fornecem funções de utilidade (por exemplo, Convertendo ETH para Gwei) para que como desenvolvedor você possa passar menos tempo lidando com as complexidades de clientes da Ethereum e mais tempo focado na funcionalidade única do seu aplicativo.
-
-## Nível 5: Aplicativos para o usuário final {#end-user-applications}
-
-No nível superior da pilha estão as aplicações voltadas para o usuário. Esses são os aplicativos padrão que você regularmente usa e constrói hoje: principalmente web e mobile apps.
-
-A forma como você desenvolve essas interfaces de usuário permanece essencialmente inalterada. Frequentemente, os usuários não precisam saber que o aplicativo que estão usando é construído usando uma cadeia de blocos.
-
-## Pronto para escolher sua pilha? {#ready-to-choose-your-stack}
-
-Confira o nosso guia para [configurar um ambiente de desenvolvimento local](/developers/local-environment/) para o seu aplicativo Ethereum.
-
-## Leitura adicional {#further-reading}
-
-- [A Arquitetura de uma aplicação Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-
-_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione!_
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
deleted file mode 100644
index 9a4b6a0bbfd..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: Frameworks de Desenvolvimento de Dapp
-description: Explore as vantagens de frameworks e compare as opções disponíveis.
-lang: pt-br
----
-
-## Introdução aos frameworks {#introduction-to-frameworks}
-
-Criar um aplicativo completo requer diferentes peças de tecnologia. Os frameworks de software incluem muitos dos recursos necessários ou fornecem sistemas de plugins fáceis para escolher as ferramentas que você deseja.
-
-Esses frameworks vêm com muitas funcionalidades prontas para usar, como:
-
-- Recursos para ativar uma instância local do blockchain.
-- Utilitários para compilar e testar seus contratos inteligentes.
-- Complementos de desenvolvimento de cliente para criar seu aplicativo do usuário dentro do mesmo projeto/repositório.
-- Configuração para se conectar a redes Ethereum e implantar contratos, seja para uma instância em execução local ou uma das redes públicas da Ethereum.
-- Distribuição descentralizada de aplicativos - integrações com opções de armazenamento como o IPFS.
-
-## Pré-requisitos {#prerequisites}
-
-Antes de mergulhar em frameworks, recomendamos que você primeiro leia a nossa introdução aos [dapps](/developers/docs/dapps/) e a [pilha de Ethereum](/developers/docs/ethereum-stack/).
-
-## Frameworks disponíveis {#available-frameworks}
-
-**Foundry** - **_Foundry é um kit de ferramentas incrivelmente rápido, portátil e modular para desenvolvimento de aplicações Ethereum_**
-
-- [Instalar Foundry](https://book.getfoundry.sh/)
-- [Livro do Foundry](https://book.getfoundry.sh/)
-- [Bate-papo da comunidade Foundry no Telegram](https://t.me/foundry_support)
-- [Junção Incrível](https://github.com/crisgarner/awesome-foundry)
-
-**Hardhat -** **_Ambiente de desenvolvimento da Ethereum para profissionais._**
-
-- [hardhat.org](https://hardhat.org)
-- [GitHub](https://github.com/nomiclabs/hardhat)
-
-**Macaco -** **_A ferramenta de desenvolvimento de contratos inteligentes para Pythonistas, Cientistas de Dados e Profissionais de Segurança._**
-
-- [Documentação](https://docs.apeworx.io/ape/stable/)
-- [GitHub](https://github.com/ApeWorX/ape)
-
-**Web3j -** **_Uma plataforma para desenvolver aplicativos blockchain na JVM._**
-
-- [Página inicial](https://www.web3labs.com/web3j-sdk)
-- [Documentação](https://docs.web3j.io)
-- [GitHub](https://github.com/web3j/web3j)
-
-**ethers-kt -** **_Biblioteca assíncrona de alto desempenho em Kotlin/Java/Android para blockchains baseadas em EVM._**
-
-- [GitHub](https://github.com/Kr1ptal/ethers-kt)
-- [Exemplos](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
-- [Discord](https://discord.gg/rx35NzQGSb)
-
-**Create Eth App -** **_Crie aplicativos com a tecnologia Ethereum com apenas um comando. Vem com uma ampla oferta de estruturas de interface do usuário e modelos DeFi para escolher._**
-
-- [GitHub](https://github.com/paulrberg/create-eth-app)
-- [Modelos](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
-
-**Scaffold-Eth -** **_Ethers.js + Hardhat + React componentes e hooks para web3: tudo o que você precisa para começar a construir aplicativos descentralizados fornecidos por contratos inteligentes._**
-
-- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
-
-**Tenderly -** **_Plataforma de desenvolvimento web3 que permite aos desenvolvedores de blockchain construir, testar, depurar, monitorar e operar contratos inteligentes e melhora a UX do dapp._**
-
-- [Website](https://tenderly.co/)
-- [Documentação](https://docs.tenderly.co/ethereum-development-practices)
-
-**The Graph -** **_The Graph para consultar dados de blockchain com eficiência._**
-
-- [Website](https://thegraph.com/)
-- [Tutorial](/developers/tutorials/the-graph-fixing-web3-data-querying/)
-
-**Alchemy -** **_Plataforma de Desenvolvimento Ethereum._**
-
-- [alchemy.com](https://www.alchemy.com/)
-- [GitHub](https://github.com/alchemyplatform)
-- [Discord](https://discord.com/invite/alchemyplatform)
-
-**NodeReal -** **_Plataforma de Desenvolvimento Ethereum._**
-
-- [Nodereal.io](https://nodereal.io/)
-- [GitHub](https://github.com/node-real)
-- [Discord](https://discord.gg/V5k5gsuE)
-
-**thirdweb SDK -** **_Crie aplicações web3 que podem interagir com seus contratos inteligentes usando nossos poderosos SDKs e CLI._**
-
-- [Documentação](https://portal.thirdweb.com/sdk/)
-- [GitHub](https://github.com/thirdweb-dev/)
-
-**Chainstack -** **_Plataforma de desenvolvimento Web3 (Ethereum e outros)._**
-
-- [chainstack.com](https://www.chainstack.com/)
-- [GitHub](https://github.com/chainstack)
-- [Discord](https://discord.gg/BSb5zfp9AT)
-
-**Crossmint-****_A plataforma web3 de desenvolvimento a nível empresarial, que permite a construção de NFT nas principais cadeias de chains EVM (entre outras)._**
-
-- [Website](https://www.crossmint.com)
-- [Documentação](https://docs.crossmint.com)
-- [Discord](https://discord.com/invite/crossmint)
-
-**Brownie -** **_Ambiente de desenvolvimento e framework de testes em Python._**
-
-- [Documentação](https://eth-brownie.readthedocs.io/en/latest/)
-- [GitHub](https://github.com/eth-brownie/brownie)
-- **Brownie está em manutenção**
-
-**Truffle -****_Um ambiente de desenvolvimento, teste de framework, compilação e outras ferramentas._**
-
-- [trufflesuite.com](https://www.trufflesuite.com/)
-- [GitHub](https://github.com/trufflesuite/truffle)
-- **O desenvolvimento da truffle terminou** - [leia](https://twitter.com/trufflesuite/status/1704946902393860589?t=NlIWeLTbBSAaJmS5uUAhSA&s=19) mais sobre
-
-**OpenZeppelin SDK -** **_O Ultimate Smart Contract Toolkit: Um conjunto de ferramentas para ajudar você a desenvolver, compilar, atualizar, implantar e interagir com contratos inteligentes._**
-
-- [OpenZeppelin SDK](https://openzeppelin.com/sdk/)
-- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk)
-- [Fórum da Comunidade](https://forum.openzeppelin.com/c/support/17)
-- **O desenvolvimento SDK OpenZeppelin terminou**
-
-**Catapulta -****_É uma ferramenta de contrato inteligente em várias cadeias, melhora a verificação em exploradores de blocos, monitora os contratos inteligentes e compartilha relatórios de implementação desse contratos plug-n-play para projetos Foundry e Hardhat
-
-- [Website](https://catapulta.sh/)
-- [Documentação](https://catapulta.sh/docs)
-- [GitHub](https://github.com/catapulta-sh)
-
-**Covalent -** **_APIs de blockchain enriquecidas para mais de 200 redes._**
-
-- [covalenthq.com](https://www.covalenthq.com/)
-- [Documentação](https://www.covalenthq.com/docs/api/)
-- [GitHub](https://github.com/covalenthq)
-- [Discord](https://www.covalenthq.com/discord/)
-
-**Wake -** **_Tudo em um Framework Python completo para testes de contratos, fuzzing, implantação, varredura de vulnerabilidades e navegação de código._**
-
-- [Página inicial](https://getwake.io/)
-- [Documentação](https://ackeeblockchain.com/wake/docs/latest/)
-- [GitHub](https://github.com/Ackee-Blockchain/wake)
-- [Código X Extensão](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Configure um ambiente de desenvolvimento](/developers/local-environment/)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
deleted file mode 100644
index 8399350f636..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Ambientes de Desenvolvimento Integrado (IDEs)
-description:
-lang: pt-br
----
-
-Quando se trata de desenvolver um [ambiente de trabalho integrado (IDE)](https://pt.wikipedia.org/wiki/Ambiente_de_desenvolvimento_integrado) programar em Ethereum é similar a programar qualquer outro projeto de software. Há muitas opções para escolher, então simplesmente escolha o IDE ou editor de código que melhor se adapta a suas preferências. A melhor escolha para o seu desenvolvimento em Ethereum provavelmente vai ser o IDE que você já usa para o desenvolvimento tradicional de softwares.
-
-## IDEs baseados na Web {#web-based-ides}
-
-Se você quer brincar com o código antes de [configurar um ambiente de desenvolvimento local](/developers/local-environment/), esses aplicativos na web são personalizados para o desenvolvimento de contratos inteligentes em Ethereum.
-
-**[Remix](https://remix.ethereum.org/)** - **_IDE baseada na Web com análise estática integrada e uma máquina virtual de blockchain de teste_**
-
-- [Documentação](https://remix-ide.readthedocs.io/en/latest/#)
-- [Gitter](https://gitter.im/ethereum/remix)
-
-**[ChainIDE](https://chainide.com/)** - **_Uma IDE multicadeia baseada na nuvem_**
-
-- [Documentação](https://chainide.gitbook.io/chainide-english-1/)
-- [Fórum de ajuda](https://forum.chainide.com/)
-
-**[Replit (Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_Um ambiente de desenvolvimento personalizável para Ethereum com hot reloading, verificação de erros e suporte a rede de testes de primeira classe_**
-
-- [Documentação](https://docs.replit.com/)
-
-**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_Um ambiente de prototipagem rápida onde você pode escrever, executar e depurar contratos inteligentes no navegador usando Solidity e JavaScript_**
-
-**[EthFiddle](https://ethfiddle.com/)** - **_IDE baseada na Web que permite escrever, compilar e depurar seu contrato inteligente_**
-
-- [Gitter](https://gitter.im/loomnetwork/ethfiddle)
-
-## Aplicativos IDEs {#desktop-ides}
-
-A maioria dos IDEs estabelecidos possuem plugins integrados para melhorar a experiência de desenvolvimento em Ethereum. No mínimo, eles fornecem destaque de sintaxe para [linguagens de contrato inteligentes](/developers/docs/smart-contracts/languages/).
-
-**Visual Studio Code -** **_IDE profissional multiplataforma com suporte oficial da Ethereum._**
-
-- [Visual Studio Code](https://code.visualstudio.com/)
-- [Bancada de trabalho para Azure Blockchain](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-azure-blockchain.azure-blockchain-workbench?tab=Overview)
-- [Amostras de código](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
-- [GitHub](https://github.com/microsoft/vscode)
-
-**Atom -** **_Um editor de texto de código aberto para o século XXI_**
-
-- [Atom](https://atom.io/)
-- [GitHub](https://github.com/atom)
-- [Pacotes Ethereum](https://atom.io/packages/search?utf8=%E2%9C%93&q=keyword%3Aethereum&commit=Search)
-
-**IDEs de JetBrains (IntelliJ IDEA etc.) -** **_Ferramentas essenciais para desenvolvedores de software e equipes_**
-
-- [JetBrains](https://www.jetbrains.com/)
-- [GitHub](https://github.com/JetBrains)
-- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
-
-**Remix Desktop -** **_Experimente o Remix IDE na sua máquina local_**
-
-- [Baixar](https://github.com/ethereum/remix-desktop/releases)
-- [GitHub](https://github.com/ethereum/remix-desktop)
-
-## Plugins e extensões {#plugins-extensions}
-
-- [Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Linguagem Ethereum Solidity para Visual Studio Code
-- [Solidity + Hardhat para VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Suporte Solidity e Hardhat oferecido pela equipe Hardhat
-- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Formatador de código que faz uso do Prettier
-
-## Leitura adicional {#further-reading}
-
-- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- Lista de IDEs para o Ethereum da Alchemy_
-
-_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
deleted file mode 100644
index 4ec6d3202ef..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Ethereum para desenvolvedores Dart
-description: Aprenda a desenvolver para Ethereum usando a linguagem Dart
-lang: pt-br
-incomplete: true
----
-
-## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-## Tutoriais {#tutorials}
-
-- [Flutter and Blockchain – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) leva você através de todos os passos para iniciar:
- 1. Instalando o [Truffle development suite](https://www.trufflesuite.com/)
- 2. Escrevendo um contrato inteligente em [Solidity](https://soliditylang.org/)
- 3. Escrevendo uma interface de usuário no Dart
-- [Construir um dapp para dispositivos móveis com Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) é muito mais curto, o que pode ser melhor
-- Se você preferir aprender assistindo um video, você pode assistir [Construindo seu Primeiro Blockchain Flutter App](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), o que leva quase uma hora
-- Se você é impaciente, talvez prefira o [Building a Blockchain Decentralized-app with Flutter and Dart on Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s), que leva apenas vinte minutos
-- [Integrando MetaMask no aplicativo Flutter com Web3Modal de WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - este video curto mostra as etapas de integração do MetaMask dentro do aplicativo Flutter com a biblioteca da WalletConnect [Web3Modal](https://pub.dev/packages/web3modal_flutter)
-- [Flutter Dapp Simple Wallet](https://youtu.be/JMfIBpuAhKA) e [Primeiro Flutter DApp - Solidity, Truffle, Ganache](https://youtu.be/bHw2gQZxJ_s) - esses vídeos mostram como fazer Dapps simples no Flutter usando Truffle e Ganache
-- Curso Bootcamp para Desenvolvedores de Blockchain Móvel com Solidity e Flutter - playlist de cursos para desenvolvedores de blockchain móvel full stack
-
-
-
-## Trabalhando com clientes Ethereum {#working-with-ethereum-clients}
-
-Você pode usar Ethereum para criar aplicativos descentralizados (ou "dapps") que utilizam os benefícios da tecnologia de criptomoedas e cadeia de blocos. Atualmente existem pelo menos duas bibliotecas para o dart usar [JSON-RPC API](/developers/docs/apis/json-rpc/) para o Ethereum.
-
-1. [Web3dart de simonbutler.eu](https://pub.dev/packages/web3dart)
-1. [Ethereum 5.0.0 de darticulate.com](https://pub.dev/packages/ethereum)
-
-Existem também bibliotecas adicionais que permitem que você manipule endereços específicos de Ethereum, ou que permitem que você recupere os preços de várias criptomoedas. [Veja a lista completa aqui](https://pub.dev/dart/packages?q=ethereum).
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
deleted file mode 100644
index 4d0abe5f506..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: Ethereum para desenvolvedores Delphi
-description: Aprenda a desenvolver para o Ethereum usando a linguagem de programação Delphi
-lang: pt-br
-incomplete: true
----
-
-
-
-Aprenda a desenvolver para o Ethereum usando a linguagem de programação Delphi
-
-
-
-Utilize Ethereum para criar aplicações descentralizadas ("dapps") que utilizam os benefícios das criptomoedas e tecnologias de cadeia de blocos. Esses dapps podem ser muito confiáveis, o que significa que uma vez que eles são implantados na rede Ethereum, sempre serão executados como programados. Eles podem controlar ativos digitais a fim de criar novos tipos de aplicações financeiras. Eles podem ser descentralizados, o que significa que nenhuma entidade ou pessoa os controla sendo portanto praticamente impossíves de serem censurados.
-
-Crie aplicações descentralizadas sobre a Ethereum e interaja com contratos inteligentes usando a linguagem de programação Delphi!
-
-## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
-
-**Dê o seus primeiros passos para integrar Delphi com a Ethereum**
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/).
-
-- [Cadeia de blocos explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entendendo os contratos inteligentes](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro contrato inteligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implantar em Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## Referências e Links para Iniciantes {#beginner-references-and-links}
-
-**Apresentando a biblioteca Delphereum**
-
-- [O que é Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md)
-- [Conectando Delphi a uma blockchain local (na memória)](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
-- [Conectando Delphi à rede principal Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
-- [Conectando Delphi com Contratos Inteligentes](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
-
-**Deseja ignorar a configuração por enquanto e pular direto para as amostras?**
-
-- [Um Contrato Inteligente em 3 minutos e Dilphi - Parte 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
-- [Um Contrato Inteligente Delphi em 3 minutos - Parte 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
-
-## Artigos intermediários {#intermediate-articles}
-
-- [Gerando uma mensagem Ethereum assinada em Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
-- [Transferindo o ether com Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
-- [Transferindo tokens ERC-20 com Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
-
-## Padrões de uso avançado {#advanced-use-patterns}
-
-- [Delphi e nomes de serviço Ethereum (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
-- [QuikNode, Ethereum e Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
-- [Delphi e Dark Forest do Ethereum](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
-- [Trocar um token por outro em Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
-
-Procurando por mais recursos? Confira [ethereum.org/developers](/developers/).
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
deleted file mode 100644
index 70bd887d3e5..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Ethereum para desenvolvedores .NET
-description: Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em .NET
-lang: pt-br
-incomplete: true
----
-
-Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em .NET
-
-Utilize Ethereum para criar aplicações descentralizadas ("dapps") que utilizam os benefícios das criptomoedas e tecnologias de cadeia de blocos. Esses dapps podem ser muito confiáveis, o que significa que uma vez que eles são implantados na rede Ethereum, sempre serão executados como programados. Eles podem controlar ativos digitais a fim de criar novos tipos de aplicações financeiras. Eles podem ser descentralizados, o que significa que nenhuma entidade ou pessoa os controla sendo portanto praticamente impossíves de serem censurados.
-
-Crie aplicativos descentralizados sobre a Ethereum e interaja com contratos inteligentes usando ferramentas e linguagens da pilha de tecnologias da Microsoft - suportando C#, # Visual Basic .NET, F#, em ferramentas como VSCode e Visual Studio, através do .NET Framework/.NET Core/.NET Standard. Implemente uma cadeia de blocos Ethereum no Azure usando a cadeia de blocos Microsoft Azure em minutos. Traga o amor ao .NET para a Ethereum!
-
-## Começando com contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
-
-**Dê seus primeiros passos para integrar o .NET com a Ethereum**
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/).
-
-- [Cadeia de blocos explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entendendo os contratos inteligentes](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro contrato inteligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implantar Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## Referências e links para iniciantes {#beginner-references-and-links}
-
-**Introduzindo a biblioteca Nethereum e o VS Code Solidity**
-
-- [Nethereum, primeiros passos](https://docs.nethereum.com/en/latest/getting-started/)
-- [Instalar VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
-- [Fluxo de trabalho de um desenvolvedor .NET para criar e chamar Contratos Inteligentes Ethereum](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
-- [Integração de contratos inteligentes com o Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
-- [Contratos Inteligentes entre o .NET e a Ethereum Blockchain com a Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), também em [├](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
-- [Nethereum - Uma biblioteca de integração .NET de código aberto para cadeia de blocos](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
-- [Escrevendo transações Ethereum para a base de dados SQL usando Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
-- [Veja o como é fácil implantar contratos inteligentes Ethereum usando C# e VirtualStudio](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
-
-**Deseja ignorar a configuração por enquanto e pular direto para as amostras?**
-
-- [Playground](http://playground.nethereum.com/) - Interaja com a Ethereum e aprenda como usar a Nethereum através do seu navegador.
- - Consultar Saldo da Conta [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
- - Consultar Saldo de contrato inteligente ERC20 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
- - Transfira ether para uma conta [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
- - ... E mais!
-
-## Artigos intermediários {#intermediate-articles}
-
-- [Nethereum Workbook/Lista de amostras](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
-- [Implantar seus próprios Testchains de Desenvolvimento](https://github.com/Nethereum/Testchains)
-- [Plugin Codegen VSCode para Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
-- [Unity e Ethereum: Porquê e Como](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
-- [Crie ASP.NET Core Web API para dapps Ethereum](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
-- [Usando a Nethereum Web3 para implementar um sistema de rastreamento de cadeia de suprimentos](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
-- [Nethereum Block Processing](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), com [C# Playground sample](http://playground.nethereum.com/csharp/id/1025)
-- [Nethereum Websocket Streaming](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
-- [Kaleido e Nethereum](https://kaleido.io/kaleido-and-nethereum/)
-- [Quórum e Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
-
-## Padrões de uso avançados {#advanced-use-patterns}
-
-- [Azure Key Vault e Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
-- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
-- [Arquitetura de backend do Ujo Nethereum](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
-
-## Projetos.NET, ferramentas e outras coisas divertidas {#dot-net-projects-tools-and-other-fun-stuff}
-
-- [Nethereum Playground](http://playground.nethereum.com/) - _Compile, crie e execute trechos de código Nethereum no navegador_
-- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Gerador de código Nethereum com UI em Blazor_
-- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _Um explorador de blockchain leve e uma carteira simples em .NET Wasm SPA_
-- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _Um mecanismo de regras de negócio (para a plataforma .NET e para a plataforma Ethereum) que é inerentemente orientado a metadados_
-- [Nethermind](https://github.com/NethermindEth/nethermind) - _Um cliente .NET Core Ethereum para Linux, Windows, MacOS_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _funções de utilidade para trabalhar com bases de código relacionadas com a Ethereum_
-- [TestChains](https://github.com/Nethereum/TestChains) - _Devchains .NET pré-configuradas para respostas rápidas (PoA)_
-
-Procurando por mais recursos? Confira [ethereum.org/developers](/developers/).
-
-## Colaboradores comunitários .NET {#dot-net-community-contributors}
-
-Na Nethereum, nós geralmente nos encontramos no [Gitter](https://gitter.im/Nethereum/Nethereum) onde todos são bem vindos para fazer e responder perguntas, obter ajuda ou simplesmente relaxar. Sinta-se à vontade para fazer uma PR ou abrir uma questão no [repositório da Nethereum no Github](https://github.com/Nethereum), ou apenas para navegar pelos vários projetos paralelos e exemplos que temos. Você também pode nos encontrar em [Discord](https://discord.gg/jQPrR58FxX)!
-
-Se você é novo no Nethermind e precisa de ajuda para começar, junte-se ao nosso [Discord](http://discord.gg/PaCMRFdvWT). Os nossos desenvolvedores estão prontos para responder às suas perguntas. Para PRs ou problemas, confira o [repositório do Github da Nethermind](https://github.com/NethermindEth/nethermind).
-
-## Outras listas agregadas {#other-aggregated-lists}
-
-[Site Oficial Nethereum](https://nethereum.com/)
-[Site Oficial Nethermind](https://nethermind.io/)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
deleted file mode 100644
index 8520bf272b9..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: Ethereum para desenvolvedores Go
-description: Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseados no Go
-lang: pt-br
-incomplete: true
----
-
-Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseados no Go
-
-Use Ethereum para criar aplicativos descentralizados (ou "dapps"). Esses dapps podem ser muito confiáveis, o que significa que uma vez que eles são implantados na rede Ethereum, sempre serão executados como programados. São descentralizados, o que significa que funcionam em uma rede peer-to-peer e não há um único ponto de fracasso. Nenhuma entidade ou pessoa os controla e é praticamente impossível censurar. Podem controlar os activos digitais para criar novos tipos de aplicações financeiras.
-
-## Começando com contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**Dê os seus primeiros passos para integrar o Go com a Ethereum**
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/).
-
-- [Cadeia de blocos explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entendendo os contratos inteligentes](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro contrato inteligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implantar em Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-- [Tutorial do contrato](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
-
-## Artigos e livros para iniciantes {#beginner-articles-and-books}
-
-- [Escolhendo um Cliente Ethereum](https://www.trufflesuite.com/docs/truffle/reference/choosing-an-ethereum-client)
-- [Introdução ao Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
-- [Use Golang para conectar à Ethereum](https://www.youtube.com/watch?v=-7uChuO_VzM)
-- [Implantar Contratos Inteligentes Ethereum Usando Golang](https://www.youtube.com/watch?v=pytGqQmDslE)
-- [Um Guia de Passos Para Testar e Implantar Contratos Inteligentes Ethereum em Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
-- [eBook: Ethereum Development with Go](https://goethereumbook.org/) - _Desenvolvendo aplicativos Ethereum com Go_
-
-## Artigos e documentos de nível Intermediário {#intermediate-articles-and-docs}
-
-- [Documentação Ethereum em Go](https://geth.ethereum.org/docs/) - _A documentação da implementação oficial da Ethereum em Go_
-- [Guia do programador Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _Guia ilustrado, incluindo a árvore de estado, comprovações múltiplas e processamento de transações_
-- [Erigon e Ethereum sem estado](https://youtu.be/3-Mn7OckSus?t=394) - _Conferência da Comunidade Ethereum 2020 (EthCC 3)_
-- [Erigon: Otimizando clientes Ethereum](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_
-- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
-- [Criando um dapp em Go com Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
-- [Trabalhe com uma rede privada Ethereum com Golang e Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
-- [Testes unitários de contratos Solidity na Ethereum com Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
-- [Referência rápida para usar Geth como biblioteca](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
-
-## Padrões de uso avançados {#advanced-use-patterns}
-
-- [O Backend Simulado do GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
-- [Aplicativos Blockchain-as-a-Service usando Ethereum e Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
-- [Armazenamento de dados distribuídos IPFS e Swarm em aplicações blockchain da Ethereum](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
-- [Clientes Móveis: Bibliotecas e Nós Ethereum Inproc](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
-- [Dapps nativos: Go bindings a contratos Ethereum](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
-
-## Projetos e Ferramentas para Go {#go-projects-and-tools}
-
-- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Implementação Oficial do protocolo da Ethereum_
-- [Go Ethereum Code Analysis](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Revisão e analise do código-fonte do Go Ethereum_
-- [Erigon](https://github.com/ledgerwatch/erigon) - _Derivado mais rápido do Go Ethereum, com foco em nós de arquivo_
-- [Golem](https://github.com/golemfactory/golem) - _Golem está criando um mercado global para computação distribuída_
-- [Quorum](https://github.com/jpmorganchase/quorum) - _Uma implementação permissionada da Ethereum com suporte a privacidade de dados_
-- [Prysm](https://github.com/prysmaticlabs/prysm) - _Implementação em Go da Ethereum 'Serenity' 2.0_
-- [Eth Tweet](https://github.com/yep/eth-tweet) - _Twitter descentralizado: Um serviço de microblogging executado no blockchain da Ethereum_
-- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Implementação e extensão da especificação de Plasma minimamente Viável_
-- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Um pool de mineração da Ethereum de código aberto_
-- [Ethereum HD Wallet](https://github.com/miguelmota/go-ethereum-hdwallet) - _Derivações de carteiras Ethereum em Go_
-- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Suporte para muitos tipos de redes Ethereum_
-- [Geth Light Cliente](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Implementação do Geth do Subprotocolo Light Ethereum_
-- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _Uma implementação simples de carteira Ethereum e utilitários em Golang_
-- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _Acesso eficiente a dados blockchain via SDK Go para mais de 200 blockchains_
-
-Procurando por mais recursos? Confira [ethereum.org/developers](/developers/)
-
-## Colaboradores da Comunidade Go {#go-community-contributors}
-
-- [Geth Discord](https://discordapp.com/invite/nthXNEv)
-- [Geth Gist](https://gitter.im/ethereum/go-ethereum)
-- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereum channel](https://gophers.slack.com/messages/C9HP1S9V2)
-- [StackExchange - Ethereum](https://ethereum.stackexchange.com/)
-- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
-- [Ethereum Gitter](https://gitter.im/ethereum/home)
-- [Gitter cliente de Geth](https://gitter.im/ethereum/light-client)
-
-## Outras listas agregadas {#other-aggregated-lists}
-
-- [Incrível Ethereum](https://github.com/btomashvili/awesome-ethereum)
-- [Consensys: uma lista definitiva de ferramentas para desenvolvedores da Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) ➜ [fonte GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
deleted file mode 100644
index d7c56bd6858..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Linguagens de programação
-description:
-lang: pt-br
----
-
-Um erro comum é que os desenvolvedores devem escrever [contratos inteligentes](/developers/docs/smart-contracts/) Para desenvolver na Ethereum. Isso é falso. Uma das belezas da rede e comunidade Ethereum é que você pode [participar](/community/)com apenas uma linguagem de programação.
-
-Ethereum e sua comunidade abraçam código aberto. Você pode encontrar projetos da comunidade - implementação em cliente, APIs, frameworks de desenvolvimento, ferramentas de teste - em uma ampla variedade de linguagens.
-
-## Escolha sua linguagem {#data}
-
-Selecione a sua linguagem de programação preferida para encontrar projetos, recursos e comunidades virtuais:
-
-- [Ethereum para desenvolvedores Dart](/developers/docs/programming-languages/dart/)
-- [Ethereum para desenvolvedores Delphi](/developers/docs/programming-languages/delphi/)
-- [Ethereum para desenvolvedores .NET](/developers/docs/programming-languages/dot-net/)
-- [Ethereum para desenvolvedores Go](/developers/docs/programming-languages/golang/)
-- [Ethereum para desenvolvedores Java](/developers/docs/programming-languages/java/)
-- [Ethereum para desenvolvedores JavaScript](/developers/docs/programming-languages/javascript/)
-- [Ethereum para desenvolvedores Python](/developers/docs/programming-languages/python/)
-- [Ethereum para desenvolvedores Ruby](/developers/docs/programming-languages/ruby/)
-- [Ethereum para desenvolvedores Rust](/developers/docs/programming-languages/rust/)
-
-### E se minha linguagem não for suportada {#other-lang}
-
-Se você deseja vincular a recursos ou apontar para uma comunidade virtual para uma linguagem de programação adicional, você pode solicitar uma nova página, [abrindo um problema](https://github.com/ethereum/ethereum-org-website/issues/new/choose).
-
-Se você quiser apenas escrever código para interface com a blockchain usando uma linguagem atualmente não compatível você pode usar a [interface JSON-RPC](/developers/docs/apis/json-rpc/) para se conectar à rede Ethereum. Qualquer linguagem de programação que pode usar TCP/IP pode usar essa interface.
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
deleted file mode 100644
index e607f84a79d..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Ethereum para desenvolvedores Java
-description: Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Java
-lang: pt-br
-incomplete: true
----
-
-Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Java
-
-Utilize Ethereum para criar aplicações descentralizadas ("dapps") que utilizam os benefícios das criptomoedas e tecnologias de cadeia de blocos. Esses dapps podem ser muito confiáveis, o que significa que uma vez que eles são implantados na rede Ethereum, sempre serão executados como programados. Eles podem controlar ativos digitais a fim de criar novos tipos de aplicações financeiras. Eles podem ser descentralizados, o que significa que nenhuma entidade ou pessoa os controla, sendo portanto praticamente impossíves de serem censurados.
-
-## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**Dê seus primeiros passos para integrar Java com Ethereum **
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers.](/developers/)
-
-- [Cadeia de blocos explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entender os Smart Contracts](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro Smart Contract](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implementar Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## Trabalhando com clientes Ethereum {#working-with-ethereum-clients}
-
-Aprenda como usar [Web3J](https://github.com/web3j/web3j)e Besu Hiperregistro, dois principais clientes Java Ethereum
-
-- [Conectando a um cliente Ethereum com Java, Eclipse e Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
-- [Gerenciando uma conta Ethereum com Java e Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
-- [Gerar um wrapper Java a partir do seu Smart Contract](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
-- [Interagindo com um Smart Contract Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
-- [Monitorando Eventos de Smart Contracts Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
-- [Usando Besu (Pantheon), o Cliente Ethereum Java com Linux](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
-- [Executando um Nó de Hyperledger Besu (Pantheon) em testes de integração com Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
-- [Dicas Web3j](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c)
-
-Aprenda a usar [ethers-kt](https://github.com/Kr1ptal/ethers-kt), uma biblioteca Kotlin assíncrona e de alto desempenho para interagir com blockchains baseadas em EVM. Destinada às plataformas JVM e Android.
-- [Transferir tokens ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
-- [Troca UniswapV2 com escuta de eventos](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
-- [Rastreador de saldo ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
-
-## Artigos intermediários {#intermediate-articles}
-
-- [Gerenciando o armazenamento em um aplicativo Java com IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
-- [Gerenciando tokens ERC20 em Java com Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
-- [Gerentes de Transações Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
-
-## Padrões de uso avançados {#advanced-use-patterns}
-
-- [Usando o Eventeum para construir um cache de dados de Smart Contract em Java](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
-
-## Projetos e ferramentas em Java {#java-projects-and-tools}
-
-- [Hyperledger Besu (Pantheon) (Cliente Ethereum)](https://docs.pantheon.pegasys.tech/en/stable/)
-- [Web3J (Biblioteca para Interagir com Clientes Ethereum)](https://github.com/web3j/web3j)
-- [ethers-kt (Biblioteca Kotlin/Java/Android assíncrona e de alto desempenho para blockchains baseadas em EVM.)](https://github.com/Kr1ptal/ethers-kt)
-- [Evento (Monitorador de eventos)](https://github.com/ConsenSys/eventeum)
-- [Mahuta (Ferramenta de Desenvolvedor IPFS)](https://github.com/ConsenSys/mahuta)
-
-Procurando por mais recursos? Leia [ethereum.org/developers.](/developers/)
-
-## Colaboradores da comunidade Java {#java-community-contributors}
-
-- [IO Builders](https://io.builders)
-- [Kauri](https://kauri.io)
-- [Besu HL chat](https://chat.hyperledger.org/channel/besu)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
deleted file mode 100644
index 3fe8201fb9c..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Ethereum para desenvolvedores JavaScript
-description: Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em JavaScript.
-lang: pt-br
----
-
-O JavaScript está entre as linguagens mais populares no ecossistema Ethereum. De fato, existe uma [equipe](https://github.com/ethereumjs) dedicada a levar o máximo da Ethereum ao JavaScript possível.
-
-Existem oportunidades para escrever JavaScript (ou algo parecido) em [todos os níveis de pilhas](/developers/docs/ethereum-stack/).
-
-## Interagir com Ethereum {#interact-with-ethereum}
-
-### Bibliotecas de API JavaScript {#javascript-api-libraries}
-
-Se você deseja escrever JavaScript para consultar a blockchain, enviar transações e muito mais, a maneira mais conveniente para fazer isso é usando uma [biblioteca de API JavaScript](/developers/docs/apis/javascript/). Estas APIs permitem que os desenvolvedores interajam facilmente com os [nós da rede Ethereum](/developers/docs/nodes-and-clients/).
-
-Você pode usar essas bibliotecas para interagir com contratos inteligentes na Ethereum, assim é possível construir um dapp onde você só usa JavaScript para interagir com contratos preexistentes.
-
-**Confira**
-
-- [Web3.js](https://web3js.readthedocs.io/)
-- [Ethers.js](https://docs.ethers.io/)_— Implementação completa de uma carteira Ethereum e utilidades em JavaScript e TypeScript._
-- [viem](https://viem.sh) – uma interface TypeScript para Ethereum que fornece primitivas sem estado de baixo nível para interagir com Ethereum.
-
-### Smart Contracts {#smart-contracts}
-
-Se você for um desenvolvedor JavaScript que deseja escrever seu próprio contrato inteligente, você pode querer se familiarizar com [Solidity](https://solidity.readthedocs.io). Esta é a linguagem de contrato inteligente mais popular e é sintaticamente semelhante ao JavaScript, o que pode torná-la mais fácil de aprender.
-
-Mais nos [contratos inteligentes](/developers/docs/smart-contracts/).
-
-## Entender o protocolo {#understand-the-protocol}
-
-### A Máquina Virtual da Ethereum {#the-ethereum-virtual-machine}
-
-Há uma implementação JavaScript da [máquina virtual da Ethereum](/developers/docs/evm/). Apoia as regras de fork (bifurcação) mais recentes. As regras de bifurcação referem-se a alterações feitas na EVM como resultado de melhorias planejadas.
-
-Divide-se em vários pacotes de JavaScript que você pode conferir para entender melhor:
-
-- Contas
-- Blocos
-- A blockchain em si
-- Transações
-- E mais...
-
-Isso ajudará você a entender coisas como "qual é a estrutura de dados de uma conta?".
-
-Se você prefere ler código, esse JavaScript poderia ser uma ótima alternativa à leitura em nossa documentação.
-
-**Confira o monorepo**
-[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm)
-
-### Nós e clientes {#nodes-and-clients}
-
-Um cliente Ethereumjs está em desenvolvimento ativo que permite você explorar como os clientes Ethereum funcionam em um idioma que você entende; JavaScript!
-
-Ele costumava estar hospedado em um [`repositório`](https://github.com/ethereumjs/ethereumjs-client) autônomo, no entanto, foi posteriormente incorporado ao monorepo EthereumVM como um pacote.
-
-**Confira o monorepo**
-[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
-
-## Outros projetos {#other-projects}
-
-Há também muitas outras coisas acontecendo na terra da Ethereum JavaScript, incluindo:
-
-- bibliotecas de utilitários de carteira.
-- ferramentas para gerar, importar e exportar chaves da Ethereum.
-- uma implementação da `merkle-patricia-tree` – uma estrutura de dados delineada no papel amarelo da Ethereum.
-
-Explore o que mais lhe interessa no [repositório EthereumJS](https://github.com/ethereumjs)
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
deleted file mode 100644
index 2bcc327f4e6..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: Ethereum para Desenvolvedores Python
-description: Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Python
-lang: pt-br
-incomplete: true
----
-
-Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Python
-
-Utilize Ethereum para criar aplicações descentralizadas ("dapps") que utilizam os benefícios das criptomoedas e tecnologias de cadeia de blocos. Esses dapps podem ser muito confiáveis, o que significa que uma vez que eles são implantados na rede Ethereum, sempre serão executados como programados. Eles podem controlar ativos digitais a fim de criar novos tipos de aplicações financeiras. Eles podem ser descentralizados, o que significa que nenhuma entidade ou pessoa os controla sendo, portanto, praticamente impossíveis de serem censurados.
-
-## Começando com contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**Dê seus primeiros passos para integrar Python com Ethereum**
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/).
-
-- [Cadeia de blocos explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entendendo contratos inteligentes](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro contrato inteligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implantar em Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## Artigos para Iniciantes {#beginner-articles}
-
-- [Um (Python) Guia do desenvolvedor para Ethereum](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
-- [O estado do Python no relatório de 2023 da blockchain](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
-- [Uma Introdução aos Smart Contracts com Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
-- [Instale seu próprio Token ERC20 com Python e Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
-- [Como desenvolver um contrato Ethereum utilizando Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
-- [Intro para Web3.py · Ethereum para desenvolvedores Python](https://www.dappuniversity.com/articles/web3-py-intro)
-- [Como chamar uma função do Smart Contract utilizando Python e web3.py](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
-
-## Artigos intermediários {#intermediate-articles}
-
-- [Desenvolvimento de Dapp para programadores Python](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
-- [Criando uma Interface Python Ethereum: Parte 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
-- [Contratos Inteligentes Ethereum em Python: um guia (mais ou menos) abrangente](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
-- [Usando Brownie e Python para implantar Contratos Inteligentes](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
-- [Criando NFTs no OpenSea com Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
-
-## Padrões de uso avançados {#advanced-use-patterns}
-
-- [Compilando, implantando e chamando Contratos Inteligentes Ethereum utilizando Python](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
-- [Analisando Smart Contracts em Solidity usando Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
-- [Tutorial de blockchain Fintech: emprestar e pedir emprestado com Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
-
-## Projetos e ferramentas em Python {#python-projects-and-tools}
-
-### Ativo: {#active}
-
-- [Web3.py](https://github.com/ethereum/web3.py) - _Biblioteca em Python para interagir com Ethereum_
-- [Vyper](https://github.com/ethereum/vyper/) - _Linguagem de Smart Contract em Python para a Máquina Virtual Ethereum_
-- [Ape](https://github.com/ApeWorX/ape) - _A ferramenta de desenvolvimento de contrato inteligente (smart contract) para Pythonistas, Cientistas de Dados e Profissionais de Segurança_
-- [py-evm](https://github.com/ethereum/py-evm) - _Implementação de uma Máquina Virtual Ethereum_
-- [eth-tester](https://github.com/ethereum/eth-tester) - _ferramentas para testar aplicativos baseados na Ethereum_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _funções de utilidade para trabalhar com bases de código relacionadas com a Ethereum_
-- [py-solc-x](https://pypi.org/project/py-solc-x/) - _wrapper em Python em cima do compilador solc solidity com suporte à versão 0.5.x_
-- [pymaker](https://github.com/makerdao/pymaker) - _API em Python para contratos Maker_
-- [siwe](https://github.com/spruceid/siwe-py) - _Registre-se com Ethereum (siwe) para Python_
-- [Web3 DeFi para integrações Ethereum](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _Um pacote Python com integrações prontas para ERC-20, Uniswap e outros projetos populares_
-- [Wake](https://getwake.io) - _Framework Python completo para teste de contratos, fuzzing, implantação, varredura de vulnerabilidades e navegação de código (servidor de linguagem - [Ferramentas para Solidez](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
-
-### Arquivado / Não mais mantido: {#archived--no-longer-maintained}
-
-- [Trinity](https://github.com/ethereum/trinity) - _cliente Ethereum Python_
-- [Mamba](https://github.com/arjunaskykok/mamba) - _Framework para escrever, compilar e implantar contratos inteligentes escritos em linguagem Vyper_
-- [Brownie](https://github.com/eth-brownie/brownie) - _Framework em Python para implantar, testar e interagir com contratos inteligentes Ethereum_
-- [pydevp2p](https://github.com/ethereum/pydevp2p) - _Implementação de uma pilha P2P Ethereum_
-- [py-wasm](https://github.com/ethereum/py-wasm) - _implementação em Python de um intérprete de montagem web_
-
-Procurando por mais recursos? Confira [ethereum.org/developers](/developers/).
-
-## Projetos usando as ferramentas Python {#projects-using-python-tooling}
-
-Os seguintes projetos baseados na Ethereum usam ferramentas mencionadas nesta página. Os repositórios de código aberto relacionados servem como uma boa referência para exemplos de código e melhores práticas.
-
-- [Yearn Finance](https://yearn.finance/) e [Repositório de Contratos Vault](https://github.com/yearn/yearn-vaults)
-- [Repositório de contratos inteligentes Curve](https://curve.fi/) e [Curve](https://github.com/curvefi/curve-contract)
-- [BadgerDAO](https://badger.com/) e [contratos inteligentes usando ferramentas Brownie](https://github.com/Badger-Finance/badger-system)
-- [Sushi](https://sushi.com/) usa [Python na gestão e implantação dos seus contratos adquiridos](https://github.com/sushiswap/sushi-vesting-protocols)
-- [Alpha Finance](https://alphafinance.io/), da Alpha Homora fame, usa [Brownie para testar e implantar contratos inteligentes](https://github.com/AlphaFinanceLab/alpha-staking-contract)
-
-## Comunidade de discussão Python {#python-community-contributors}
-
-- [Comunidade Discord Python Ethereum](https://discord.gg/9zk7snTfWe) Para discussões sobre Web3.py e outros frameworks Python
-- [Vyper Discord](https://discord.gg/SdvKC79cJk) Para discussão sobre programação de contrato inteligente com Vyper
-
-## Demais listas agregadas {#other-aggregated-lists}
-
-A wiki Vyper tem uma [Lista incrível de recursos para Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)
\ No newline at end of file
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
deleted file mode 100644
index adaaa635747..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Ethereum para desenvolvedores Ruby
-description: Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseados em Ruby.
-lang: pt-br
-incomplete: false
----
-
-Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseados em Ruby.
-
-Utilize Ethereum para criar aplicações descentralizadas ("dapps") que utilizam os benefícios das criptomoedas e tecnologias de cadeia de blocos. Esses dapps podem ser confiáveis, o que significa que, uma vez implantados na Ethereum, eles sempre serão executados conforme programado. Eles podem controlar ativos digitais para criar novos tipos de aplicações financeiros. Eles podem ser descentralizados, o que significa que nenhuma entidade ou pessoa os controla sendo, portanto, praticamente impossíveis de serem censurados.
-
-## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**Dê seus primeiros passos para integrar Ruby com Ethereum**
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/).
-
-- [Cadeia de blocos explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entendendo os contratos inteligentes](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro contrato inteligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implantar Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## Artigos para Iniciantes {#beginner-articles}
-
-- [Finalmente entendendo as contas Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
-- [Finalmente autenticando usuários Rails com MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
-- [Entrar com Ethereum - Biblioteca Ruby e Exemplos Rails de Lançamento](https://blog.spruceid.com/sign-in-with-ethereum-ruby-library-release-and-rails-examples/)
-- [Como se conectar à rede Ethereum usando Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
-- [Como gerar um novo endereço Ethereum em Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
-
-## Artigos intermediários {#intermediate-articles}
-
-- [Aplicativo Blockchain com Ruby](https://www.nopio.com/blog/blockchain-app-ruby/)
-- [Use o Ruby, conectado à Ethereum, para executar o Smart Contract](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
-
-## Projetos e ferramentas Ruby {#ruby-projects-and-tools}
-
-### Ativos {#active}
-
-- [eth.rb](https://github.com/q9f/eth.rb) - _Biblioteca Ruby e cliente RPC para lidar com contas, mensagens e transações Ethereum_
-- [keccak.rb](https://github.com/q9f/keccak.rb) - _O hash Keccak (SHA3) usado pela Ethereum_
-- [siwe-ruby](https://github.com/spruceid/siwe-ruby) - _Implementação Ruby de Login com Ethereum_
-- [siwe_rails](https://github.com/spruceid/siwe_rails) - _Gem do Rails que adiciona rotas de login local da SIWE_
-- [siwe-rails-examples](https://github.com/spruceid/siwe-rails-examples) - _Exemplo SIWE usando Ruby on Rails com controlador_
-- [omniauth-siwe](https://github.com/spruceid/omniauth-siwe) - _Estratégia OmniAuth para login com Ethereum (SIWE)_
-- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _Estratégia OmniAuth para autenticação via propriedade NFT_
-- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _Modelo Ethereum on Rails que permite conectar MetaMask para Ruby on Rails_
-
-### Arquivado/Não mais mantido {#archived--no-longer-maintained}
-
-- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _Chamando métodos RPC do nó Ethereum com Ruby_
-- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _Biblioteca Ruby para gerar endereços ETH de uma carteira Determinística Hierárquica de acordo com o padrão BIP32 _
-- [etherlite](https://github.com/budacom/etherlite) - _Integração Ethereum para Ruby on Rails_
-- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _Cliente Ruby Ethereum usando a interface JSON-RPC para enviar transações, criando e interagindo com contratos, assim como um kit de ferramentas útil para trabalhar com nó Ethereum_
-- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _Implementa a estratégia de provedor Ethereum para OmniAuth_
-
-Procurando por mais recursos? Confira a [A casa do nosso desenvolvedor](/developers/).
-
-## Colaboradores da comunidade Ruby {#ruby-community-contributors}
-
-O [Ethereum Ruby Telegram group](https://t.me/ruby_eth) hospeda uma comunidade em rápido crescimento e é o recurso dedicado para discussões sobre qualquer um dos projetos acima e tópicos relacionados.
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
deleted file mode 100644
index b3d2de85834..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Ethereum para desenvolvedores Rust
-description: Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Rust
-lang: pt-br
-incomplete: true
----
-
-Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Rust
-
-Utilize Ethereum para criar aplicações descentralizadas ("dapps") que utilizam os benefícios das criptomoedas e tecnologias de cadeia de blocos. Esses dapps podem ser muito confiáveis, o que significa que uma vez que eles são implantados na rede Ethereum, sempre serão executados como programados. Eles podem controlar ativos digitais a fim de criar novos tipos de aplicações financeiras. Eles podem ser descentralizados, o que significa que nenhuma entidade ou pessoa os controla sendo portanto praticamente impossíves de serem censurados.
-
-## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**Dê seus primeiros passos para integrar Rust com Ethereum**
-
-Precisa de uma introdução geral? Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/).
-
-- [Blockchain Explicada](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Entendendo os Smart Contracts](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Escreva seu primeiro Smart Contract](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Aprenda como Compilar e Implantar em Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## Artigos para Iniciantes {#beginner-articles}
-
-- [Escolhendo um Cliente Ethereum](https://www.trufflesuite.com/docs/truffle/reference/choosing-an-ethereum-client)
-- [O cliente Rust Ethereum](https://openethereum.github.io/) /***Note que o OpenEthereum [foi descontinuado](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) e não está mais sendo mantido.** Use-o com cuidado e de preferência mude para outra implementação do cliente.
-- [Enviando uma transação para Ethereum usando Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
-- [Um tutorial passo a passo sobre como criar contratos em Rust Wasm para Kovan](https://github.com/paritytech/pwasm-tutorial)
-
-## Artigos para intermediários {#intermediate-articles}
-
-## Padrões de utilização avançada {#advanced-use-patterns}
-
-- [pwasm_ethereum: biblioteca externa para interagir com uma rede análoga a Ethereum](https://github.com/openethereum/pwasm-ethereum)
-- [Construa um bate-papo descentralizado utilizando JavaScript e Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
-- [Construa um aplicativo descentralizado de tarefas utilizando Vue.js & Rust](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
-
-- [Construir uma blockchain no Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
-
-## Projetos e ferramentas em Rust {#rust-projects-and-tools}
-
-- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) — _Coleção de externos para interagir com uma rede análoga ao Ethereum._
-- [Lighthouse](https://github.com/sigp/lighthouse) — _Cliente rápido da camada de consenso do Ethereum_
-- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) — _Proposta de reformulação da camada de execução de contrato inteligente do Ethereum usando um subconjunto determinístico do WebAssembly_
-- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _referência da API OASIS_
-- [Solaris](https://github.com/paritytech/sol-rs) — _Agente de teste unitário dos contratos inteligentes no Solidity usando o EVM nativo do cliente Parity._
-- [SputnikVM](https://github.com/rust-blockchain/evm) — _Implementação da Máquina Virtual do Ethereum no Rust_
-- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _smart contract Wavelet em Rust_
-- [Foundry](https://github.com/foundry-rs/foundry) - _Kit de ferramentas para desenvolvimento de aplicações Ethereum_
-- [Alloy](https://alloy.rs) - _Bibliotecas de alto desempenho, bem testadas e documentadas para interagir com Ethereum e outras cadeias baseadas em EVM._
-- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Biblioteca Ethereum e implementação de carteira_
-- [SewUp](https://github.com/second-state/SewUp) — _Uma biblioteca para ajudar você a construir seu contrato Webassembly do Ethereum com o Rust e desenvolvê-lo em um back-end comum_
-- [Substreams](https://github.com/streamingfast/substreams) - _Tecnologia de indexação de dados paralelizada em blockchain_
-- [Reth](https://github.com/paradigmxyz/reth) - Reth (abreviação de Rust Ethereum) é uma nova implementação de nó completo do Ethereum
-- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Uma coleção selecionada de projetos no ecossistema Ethereum escritos em Rust_
-
-Procurando por mais recursos? Leia [ethereum.org/developers.](/developers/)
-
-## Colaboradores da comunidade Rust {#rust-community-contributors}
-
-- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby)
-- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby)
-- [Parity Gitter](https://gitter.im/paritytech/parity)
-- [Enigma](https://discord.gg/SJK32GY)
diff --git "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" "b/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
deleted file mode 100644
index 76a65b7186e..00000000000
--- "a/public/content/translations/pt-br/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
+++ /dev/null
@@ -1,217 +0,0 @@
----
-title: Armazenamento Descentralizado
-description: Visão geral do que é o armazenamento descentralizado e as ferramentas disponíveis para integrar a um dapp.
-lang: pt-br
----
-
-Ao contrário de um servidor localizado centralmente operado por uma única empresa ou organização, os sistemas de armazenamento descentralizado consistem em uma rede ponto a ponto de usuários operadores que mantêm uma parte dos dados gerais, criando um sistema resiliente de armazenamento e compartilhamento de arquivos. Elas podem estar em um aplicativo baseado em blockchain ou qualquer rede baseada em peer-to-peer.
-
-A Ethereum em si pode ser usada como um sistema de armazenamento descentralizado, e é quando se trata de codificar o armazenamento em todos os contratos inteligentes. No entanto, quando se trata de grandes quantidades de dados, para as quais a Ethereum não foi concebida. A corrente está crescendo constantemente, mas no momento da escrita, a cadeia Ethereum é de cerca de 500GB - 1TB ([dependendo do cliente](https://etherscan.io/chartsync/chaindefault)), e cada nó da rede precisa ser capaz de armazenar todos os dados. Se a cadeia fosse expandir para grandes quantidades de dados (diga 5TBs) não seria viável que todos os nós continuassem a rodar. Além disso, o custo de implantar essa quantidade de dados para a rede principal seria proibitivamente caro devido às taxas de [gás](/developers/docs/gas).
-
-Devido a essas restrições, precisamos de uma cadeia ou metodologia diferente para armazenar grandes quantidades de dados de forma descentralizada.
-
-Ao analisar as opções de armazenamento descentralizado (dStorage), existem algumas coisas que o usuário deve ter em mente.
-
-- Mecanismo de persistência/estrutura de incentivo
-- Execução de retenção de dados
-- Descentralizada
-- Consenso
-
-## Mecanismo de persistência / estrutura de incentivo {#persistence-mechanism}
-
-### Baseado em blockchain {#blockchain-based}
-
-Para que uma peça de dados se mantenha para sempre, precisamos utilizar um mecanismo de persistência. Por exemplo, na Ethereum, o mecanismo de persistência é que toda a cadeia precisa ser contabilizada ao executar um nó. Novos dados são empilhados no final da cadeia, continuando a crescer - exigindo que cada nó replique todos os dados embutidos.
-
-Conhecemos isto como persistência **baseada em blockchain**.
-
-O problema com persistência baseada em blockchain é que a cadeia pode ficar muito grande para manter e armazenar todos os dados viáveis (por exemplo, [muitas fontes](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) estimam que a Internet precisa de mais de 40 Zetabytes de capacidade de armazenamento).
-
-A blockchain (cadeia de blocos) também deve ter algum tipo de estrutura de incentivo. Para persistência baseada em blockchain, há um pagamento feito ao validador. Quando os dados são adicionados à cadeia, os validadores são pagos para adicionar os dados.
-
-Plataformas com persistência baseada em blockchain (cadeia de blocos):
-
-- Ethereum
-- [Arweave](https://www.arweave.org/)
-
-### Baseado em contratos {#contract-based}
-
-A persistência **baseada em contrato** tem a intuição de que os dados não podem ser replicados por todos os nós e mantidos para sempre, senão que, ao invés disso, devem ser mantidos com acordos de contrato. Trata-se de acordos celebrados com vários nós que prometeram a conservação de dados por um período de tempo. Devem ser reembolsados ou renovados sempre que se esgotem para manter os dados persistentes.
-
-Na maioria dos casos, em vez de armazenar todos os dados on-chain, o hash de onde os dados estão localizados em uma cadeia é armazenado. Dessa forma, a cadeia inteira não precisará escalar para guardar todos os dados.
-
-Plataformas com persistência baseada em blockchain (cadeia de blocos):
-
-- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/)
-- [Skynet](https://siasky.net/)
-- [Storj](https://storj.io/)
-- [0Chain](https://0chain.net/)
-- [Rede Crust](https://crust.network)
-- [Swarm](https://www.ethswarm.org/)
-- [4EVERLAND](https://www.4everland.org/)
-
-### Considerações finais {#additional-consideration}
-
-IPFS é um sistema distribuído para armazenamento e acesso a arquivos, sites, aplicações e dados. Ele não tem um esquema baseado em incentivos, mas pode ser usado com qualquer uma das soluções acima baseadas em contratos de incentivos para persistências de longo prazo. Outra maneira de persistir dados no IPFS é trabalhar com um serviço fixo, que permita "fixar" seus dados para você. Você pode até mesmo rodar seu próprio nó IPFS e contribuir para a rede para persistir seus dados ou os de outra pessoa de forma gratuita!
-
-- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/)
-- [Pinata](https://www.pinata.cloud/) _(serviço de fixação IPFS)_
-- [web3.storage](https://web3.storage/) _(serviço de fixação IPFS/Filecoin)_
-- [Infura](https://infura.io/product/ipfs) _(serviço de fixação IPFS)_
-- [Verificação IPFS](https://ipfs-scan.io) _(explorador de fixação de IPFS)_
-- [4EVERLAND](https://www.4everland.org/)_ (Serviço de fixação IPFS) _
-- [Filebase](https://filebase.com) _(Serviço de Fixação IPFS)_
-- [Spheron Network](https://spheron.network/) _(serviço de pinagem IPFS/Filecoin)_
-
-SWARM é uma tecnologia descentralizada de armazenamento e distribuição de dados com um sistema de incentivo ao armazenamento e um oráculo de preços de aluguel de armazenamento.
-
-## Retenção de dados {#data-retention}
-
-A fim de conservar dados, os sistemas devem dispor de algum tipo de mecanismo para garantir a conservação dos dados.
-
-### Mecanismo de desafio {#challenge-mechanism}
-
-Uma das maneiras mais populares de garantir que os dados sejam mantidos, é usar algum tipo de desafio criptográfico emitido aos nós para ter certeza que eles ainda possuem os dados. Uma pessoa simples é olhar para a comprovação de acesso da Arweave. Eles lançam um desafio aos nós para ver se eles têm os dados tanto no bloco mais recente quanto em um bloco aleatório no passado. Se o nó não conseguir dar a resposta, ele será penalizado.
-
-Tipos de dStorage com um mecanismo de desafio:
-
-- 0Chain
-- Skynet
-- Arweave
-- Filecoin
-- Rede Crust
-- 4EVERLAND
-
-### Descentralização {#decentrality}
-
-Não há ótimas ferramentas para medir o nível de descentralização das plataformas, mas, em geral, você vai querer usar ferramentas que não têm nenhuma forma de KYC para fornecer evidências que não estão centralizadas.
-
-Ferramentas descentralizadas sem KYC:
-
-- 0Chain (implementação de uma edição não-KYC)
-- Skynet
-- Arweave
-- Filecoin
-- IPFS
-- Ethereum
-- Rede Crust
-- 4EVERLAND
-
-### Consenso {#consensus}
-
-A maioria dessas ferramentas tem sua própria versão de um [mecanismo de consenso](/developers/docs/consensus-mechanisms/) mas, geralmente, elas são baseadas em [**proof-of-work (prova de trabalho)**](/developers/docs/consensus-mechanisms/pow/) ou [**proof-of-stake (prova de participação, PoS)**](/developers/docs/consensus-mechanisms/pos/).
-
-Baseado em prova de trabalho (proof-of-work):
-
-- Skynet
-- Arweave
-
-Baseado em prova de participação (proof-of-stake):
-
-- Ethereum
-- Filecoin
-- 0Chain
-- Rede Crust
-
-## Ferramentas relacionadas {#related-tools}
-
-**IPFS - _InterPlanetary File System é um sistema descentralizado de armazenamento e referenciamento de arquivos para a Ethereum._**
-
-- [Ipfs.io](https://ipfs.io/)
-- [Documentação](https://docs.ipfs.io/)
-- [GitHub](https://github.com/ipfs/ipfs)
-
-**Storj DCS - _Armazenamento descentralizado e compatível com a S3-Cloud para desenvolvedores._**
-
-- [Storj.io](https://storj.io/)
-- [Documentação](https://docs.storj.io/)
-- [GitHub](https://github.com/storj/storj)
-
-**Skynet - _O Skynet é uma cadeia descentralizada de PoW dedicada a uma web descentralizada._**
-
-- [Skynet.net](https://siasky.net/)
-- [Documentação](https://siasky.net/docs/)
-- [GitHub](https://github.com/SkynetLabs/)
-
-**Filecoin - _Filecoin foi criado pela mesma equipe por trás do IPFS. É uma camada de incentivo no topo dos ideais IPFS._**
-
-- [Filecoin.io](https://filecoin.io/)
-- [Documentação](https://docs.filecoin.io/)
-- [GitHub](https://github.com/filecoin-project/)
-
-**Arweave - _Arweave é uma plataforma de dStorage para armazenar dados._**
-
-- [Arweave.org](https://www.arweave.org/)
-- [Documentação](https://docs.arweave.org/info/)
-- [Arweave](https://github.com/ArweaveTeam/arweave/)
-
-**0chain - _0Chain é uma plataforma de prova de participação dStorage com fragmentação e blobbers._**
-
-- [0Chain.net](https://0chain.net/)
-- [Documentação](https://docs.0chain.net/0chain/)
-- [GitHub](https://github.com/0chain/)
-
-**Rede Croust - _Crust é uma plataforma de dStorage no topo do IPFS._**
-
-- [Crust.network](https://crust.network)
-- [Documentação](https://wiki.crust.network)
-- [GitHub](https://github.com/crustio)
-
-**Swarm - _Uma plataforma de armazenamento distribuída e serviço de distribuição de conteúdo para a pilha Ethereum web3._**
-
-- [EthSwarm.org](https://www.ethswarm.org/)
-- [Documentação](https://docs.ethswarm.org/docs/)
-- [GitHub](https://github.com/ethersphere/)
-
-**OrbitDB - _Um banco de dados descentralizado peer-to-peer no topo do IPFS._**
-
-- [OrbitDB.org](https://orbitdb.org/)
-- [Documentação](https://github.com/orbitdb/field-manual/)
-- [GitHub](https://github.com/orbitdb/orbit-db/)
-
-**Aleph.im - _Projeto na nuvem descentralizado (banco de dados, armazenamento de arquivos, computação e DID). Uma combinação única de tecnologia off-chain e peer-to-peer. IPFS e compatibilidade multicadeia._**
-
-- [Aleph.im](https://aleph.im/)
-- [Documentação](https://aleph.im/#/developers/)
-- [GitHub](https://github.com/aleph-im/)
-
-**Ceramic - _Armazenamento de banco de dados IPFS controlado pelo usuário para aplicativos ricos em dados e envolventes._**
-
-- [Ceramic.network](https://ceramic.network/)
-- [Documentação](https://developers.ceramic.network/learn/welcome/)
-- [GitHub](https://github.com/ceramicnetwork/js-ceramic/)
-
-**Filebase - _Armazenamento descentralizado compatível com S3 e serviço de fixação IPFS com redundância geográfica. Todos os arquivos carregados para o IPFS através do Filebase são automaticamente fixados na infraestrutura do Filebase com replicação 3x em todo o mundo._**
-
-- [Filebase.com](https://filebase.com/)
-- [Documentação](https://docs.filebase.com/)
-- [GitHub](https://github.com/filebase)
-
-**4EVERLAND - _Plataforma web 3.0 de computação em nuvem que integra armazenamento, computação e capacidades de núcleo em rede, é compatível com o S3 e fornece armazenamento de dados síncrono em redes de armazenamento descentralizadas, como IPFS e Arweave. s_**
-
-- [4everland.org](https://www.4everland.org/)
-- [Documentação](https://docs.4everland.org/)
-- [GitHub](https://github.com/4everland)
-
-**Kaleido - _Uma plataforma blockchain como serviço com nós IPFS ao clique de um botão_**
-
-- [Kaleido](https://kaleido.io/)
-- [Documentação](https://docs.kaleido.io/kaleido-services/ipfs/)
-- [GitHub](https://github.com/kaleido-io)
-
-**Spheron Network - _Spheron é uma plataforma como serviço (PaaS) projetada para dApps que buscam lançar suas aplicações em infraestrutura descentralizada com o melhor desempenho. Oferece computação, armazenamento descentralizado, CDN e hospedagem web prontos para uso._**
-
-- [spheron.network](https://spheron.network/)
-- [Documentação](https://docs.spheron.network/)
-- [GitHub](https://github.com/spheronFdn)
-
-## Leitura adicional {#further-reading}
-
-- [O que é armazenamento descentralizado?](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
-- [Cinco Mitos Comuns sobre o Armazenamento Descentralizado](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
-
-_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione-o!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Estruturas de desenvolvimento](/developers/docs/frameworks/)
diff --git a/public/content/translations/pt-br/19) Learn Pages 2/glossary/index.md b/public/content/translations/pt-br/19) Learn Pages 2/glossary/index.md
deleted file mode 100644
index 67e80a08e7f..00000000000
--- a/public/content/translations/pt-br/19) Learn Pages 2/glossary/index.md
+++ /dev/null
@@ -1,499 +0,0 @@
----
-title: Glossário do Ethereum
-description: Um glossário incompleto de termos técnicos e não técnicos relacionados ao Ethereum
-lang: pt-br
----
-
-# Glossário {#ethereum-glossary}
-
-## \# {#section-numbers}
-
-
-
-
-
-## A {#section-a}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## B {#section-b}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## C {#section-c}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## D {#section-d}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## E {#section-e}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## F {#section-f}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## G {#section-g}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## H {#section-h}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## I {#section-i}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## K {#section-k}
-
-
-
-
-
-
-
-
-
-
-
-## L {#section-l}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## M {#section-m}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## N {#section-n}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## O {#section-o}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## P {#section-p}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## R {#section-r}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## S {#section-s}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## T {#section-t}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## V {#section-v}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## W {#section-w}
-
-
-
-
-
-
-
-
-
-## Z {#section-z}
-
-
-
-
-
-
-
-
-
-## Fontes {#sources}
-
-_Fornecido parcialmente pela [Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) por [Andreas M. Antonopoulos, Gavin Wood](https://ethereumbook.info) sob licença da CC-BY-SA_
-
-
-
-## Contribua para esta página {#contribute-to-this-page}
-
-Faltou algum termo? Algo parece estar errado? Ajude-nos a melhorar esta página contribuindo com este glossário no GitHub!
-
-[Saiba mais sobre como contribuir](/contributing/adding-glossary-terms)
diff --git a/public/content/translations/pt-br/19) Learn Pages 2/history/index.md b/public/content/translations/pt-br/19) Learn Pages 2/history/index.md
deleted file mode 100644
index 07d99d917f8..00000000000
--- a/public/content/translations/pt-br/19) Learn Pages 2/history/index.md
+++ /dev/null
@@ -1,622 +0,0 @@
----
-title: Histórico e bifurcações do Ethereum
-description: Uma história da blockchain Ethereum, incluindo marcos importantes, versões e bifurcações.
-lang: pt-br
-sidebarDepth: 1
----
-
-# A história do Ethereum {#the-history-of-ethereum}
-
-Uma linha do tempo dos principais marcos, bifurcações e atualizações da blockchain Ethereum.
-
-
-
-Bifurcações ocorrem quando grandes atualizações ou alterações técnicas precisam ser feitas na rede, que geralmente são decorrentes de [Propostas de Melhoria do Ethereum (EIPs)] (/ eips /) e alteram as "regras" do protocolo.
-
-Quando é necessário atualizar um software tradicional, com controle centralizado, a empresa apenas publica uma nova versão para o usuário final. Blockchains funcionam de maneira diferente porque não há propriedade centralizada. Os clientes da Ethereum devem atualizar seu software para implementar as novas regras do fork. Além disso, os criadores de bloco (mineradores em um mundo com prova de trabalho, validadores em um mundo com prova de participação) e nós devem criar blocos e validá-los conforme as novas regras. Mais sobre mecanismo de consenso
-
-Essas mudanças nas regras podem criar uma divisão temporária na rede. Novos blocos podem ser produzidos conforme as novas regras ou as antigas. Geralmente, as bifurcações são acordadas antes do tempo, para que os clientes adotem as mudanças de uníssono e para que a bifurcação com as melhorias se torne a cadeia principal. No entanto, em casos raros, desacordos sobre as bifurcações podem causar uma divisão permanente na rede. A mais notável é a criação do Ethereum Classic com a bifurcação DAO.
-
-
-
-
-
-O software subjacente ao Ethereum é composto de duas metades, conhecidas como [camada de execução](/glossary/#execution-layer) e [camada de consenso](/glossary/#consensus-layer).
-
-**Nomenclatura para a melhoria da camada de execução**
-
-Desde 2021, as melhorias para a **camada de execução** são nomeadas de acordo com os nomes das cidades de [locais Devcon anteriores](https://devcon.org/en/past-events/) em ordem cronológica:
-
-| Nome da melhoria | Ano Devcon | Número do Devcon | Data da melhoria |
-| ------------ | ----------- | ------------- | ------------ |
-| Berlim | 2015 | 0 | 15 de abril de 2021 |
-| Londres | 2016 | Eu | 5 de agosto de 2021 |
-| Xangai | 2017 | II | 12 de abril de 2023 |
-| **Cancún** | 2018 | III | 13 de março de 2024 |
-| _Praga_ | 2019 | IV | A definir |
-| _Osaka_ | 2020 | V | A definir |
-| _Bogotá_ | 2022 | VI | A definir |
-| _Bangkok_ | 2024 | VII | A definir |
-
-**Nomenclatura para a melhoria da camada de consenso**
-
-Desde o lançamento da [Beacon Chain](/glossary/#beacon-chain), as melhorias para a **camada de consenso** são nomeadas em homenagem a estrelas celestiais começando com letras que seguem em ordem alfabética:
-
-| Nome da melhoria | Data da melhoria |
-| ----------------------------------------------------------- | ------------ |
-| Início da Beacon Chain | 1 de dez. de 2020 |
-| [Altair](https://en.wikipedia.org/wiki/Altair) | 27 de out. de 2021 |
-| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix) |6 de set. de 2022 |
-| [Capella](https://en.wikipedia.org/wiki/Capella) | 12 de abril de 2023 |
-| [**Deneb**](https://en.wikipedia.org/wiki/Deneb) | 13 de março de 2024 |
-| [_Electra_]() |A definir |
-**Nomenclatura combinada**
-
-As melhorias nas camadas de execução ede consenso foram inicialmente lançadas em momentos diferentes, mas depois de [A Fusão](/planejamento/fusão/) em 2022, elas foram implantadas simultaneamente. Como tal, surgiram termos coloquiais para simplificar as referências a estas melhorias usando um único termo conjunto. Isso começou com a melhoria _Shanghai-Capella_, comumente chamada de "**Capella"**, e continua com a melhoria _Cancun-Deneb_, que pode ser chamada de "**Dencun**."
-
-| Melhoria na camada de execução | Melhoria na camadade consenso | Nome abreviado |
-| ----------------- | ----------------- | ---------- |
-| Xangai | Capella | "Shapella" |
-| Cancún | Deneb | "Dencun" |
-
-
-
-Vá direto para informações sobre algumas das atualizações anteriores particularmente importantes: [The Beacon Chain](/roadmap/beacon-chain/), [The Merge](/roadmap/merge/) e [EIP-1559](#london)
-
-Procurando por futuras melhorias de protocolo? [Saiba mais sobre as próximas atualizações no roteiro do Ethereum](/roadmap/).
-
-
-
-## 2024 {#2024}
-
-### Cancun-Deneb ("Dencun") {#dencun}
-
-
-
-#### Resumo da melhoria Cancún {#cancun-summary}
-
-A melhoria contém um conjunto de aperfeiçoamentos na execução _ do Ethereum_ para melhorar o dimensionamento, em conjunto com as melhorias na camada de consenso (Denega).
-
-Notavelmente, isso inclui o EIP-4844, conhecido como **Proto-Danksharding**, que diminui significativamente o custo de armazenamento de dados para rollups de camada 2. Isto é conseguido por meio da introdução de "blobs" de dados que permitem que os rollups publiquem dados na rede principal por um curto período de tempo. Isso resulta em taxas de transação significativamente mais baixas para usuários de rollups da camada 2.
-
-
-
-
-
-
-
-- [Rollups de camada 2](/layer-2/)
-- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding)
-- [Danksharding](/roadmap/danksharding/)
-- [Leia a especificação da melhoria Cancún](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
-
-#### Resumo da melhoria Deneb {#deneb-summary}
-
-A melhoria Deneb contém aperfeiçoamentos no _consenso_ que visa alcançar melhor dimensionamento. Esta melhoria vem em conjunto com as melhorias Cancún na camada de execução para habilitar o Proto-Danksharding (EIP-4844), juntamente com outras melhorias para a Beacon Chain.
-
-Mensagens de saída voluntária pré-geradas e assinadas não expiram mais, proporcionando assim mais controle aos usuários que estão colocando seus fundos em stake com um operador de nó terceirizado. Com essa mensagem de saída assinada, os investidores podem delegar o operador de nó enquanto ainda podem sacar seus fundos e sair com segurança em qualquer momento, sem ser necessário pedir permissão para alguém.
-
-EIP-7514 impõe uma limitação na emissão de ETH ao restringir a taxa de 'churn', permitindo que apenas oito (8) validadores possam entrar na rede por época. Como a emissão de ETH é proporcional ao total de ETH em stake, limitar o número de validadores que ingressam restringe a _taxa de crescimento_ do ETH recém-emitido, enquanto também reduz os requisitos de hardware para os operadores de nós, promovendo a descentralização.
-
-
-
-
EIP-7045 - Aumentar o slot máximo de inclusão de atestação
-
EIP-7514 - Adicionar limite máximo de churn por época
-
-
-
-
-- [Leia as especificações da melhoria Deneb](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
-- [Cancun-Deneb ("Dencun"): perguntas frequentes](/roadmap/dencun/)
-
-
-
-## 2023 {#2023}
-
-### Shanghai-Capella ("Shapella") {#shapella}
-
-
-
-#### Resumo da melhoria Shanghai {#shanghai-summary}
-
-A atualização Shanghai trouxe saques de stake para a camada de execução. Em conjunto com a atualização Capella, isso permitiu que os blocos aceitassem operações de saque, o que permite que os stakers saquem seu ETH da Beacon Chain para a camada de execução.
-
-
-
-
-
-
-
-- [Leia a especificação de atualização Shangai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
-
-#### Resumo da melhoria Capella {#capella-summary}
-
-A atualização Capella foi a terceira maior atualização para a camada de consenso (Beacon Chain) e permitiu saques de stake. Capella ocorreu em sincronia com a atualização da camada de execução, Shanghai, e ativou a funcionalidade de saque de stake.
-
-Essa atualização da camada de consenso trouxe a capacidade para os stakers que não forneceram credenciais de saque com seu depósito inicial de fazê-lo, permitindo assim os saques.
-
-A atualização também forneceu a funcionalidade de varredura automática de contas, que processa continuamente as contas do validador para todos os pagamentos de recompensas disponíveis ou saques totais.
-
-- [Mais sobre saques de staking](/staking/withdrawals/).
-- [Leia a especificação da atualização Capella](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/)
-
-
-
-## 2022 {#2022}
-
-### Paris (A Fusão) {#paris}
-
-
-
-#### Resumo {#paris-summary}
-
-A atualização Paris foi desencadeada pela cadeia de blocos de prova de trabalho com uma [dificuldade total final](/glossary/#terminal-total-difficulty) de 58750000000000000000000. Isso aconteceu no bloco 15537393, em 15 de setembro de 2022, iniciando a atualização Paris para o próximo bloco. Paris foi a transição para o [The Merge](/roadmap/merge/) — seu maior recurso era desativar o algoritmo de mineração da [prova de trabalho](/developers/docs/consensus-mechanisms/pow) e a lógica de consenso associada e ativar a [prova de participação](/developers/docs/consensus-mechanisms/pos) no lugar dela. Paris em si foi uma atualização para os [clientes de execução](/developers/docs/nodes-and-clients/#execution-clients) (equivalente à Bellatrix na camada de consenso) que permitiu que eles recebessem instruções de seus [clientes de consenso](/developers/docs/nodes-and-clients/#consensus-clients) conectados. Isso exigiu um novo conjunto de métodos internos da API, coletivamente conhecido como [API do mecanismo](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md), a ser ativado. Esta foi, indiscutivelmente, a atualização mais significativa na história do Ethereum desde o [Homestead](#homestead)!
-
-- [Leia a especificação de atualização Paris](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md)
-
-
-
-
-
EIP-3675 – Consenso da melhoria para a prova de participação
-
EIP-4399 – Substituir o opcode DIFFICULTY por PREVRANDAO
-
-
-
-
----
-
-### Bellatrix {#bellatrix}
-
-
-
-#### Resumo {#bellatrix-summary}
-
-A atualização Bellatrix foi a segunda atualização agendada para a [Beacon Chain](/roadmap/beacon-chain), preparando a cadeia para o [The Merge](/roadmap/merge/). Ela traz penalidades ao validador para seus valores totais por inatividade e ofensas sancionáveis. Bellatrix também inclui uma atualização nas regras de escolha de bifurcações para preparar a cadeia para o The Merge e a transição do último bloco de prova de trabalho para o primeiro bloco de prova de participação. Isso inclui informar os clientes de consenso sobre a [dificuldade total do terminal](/glossary/#terminal-total-difficulty) de 58750000000000000000000.
-
-- [Leia a especificação da atualização Bellatrix](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix)
-
----
-
-### Gray Glacier {#gray-glacier}
-
-
-
-#### Resumo {#gray-glacier-summary}
-
-A atualização Gray Glacier atrasou a [bomba de dificuldade](/glossary/#difficulty-bomb) por 3 meses. Esta é a única mudança introduzida nessa atualização, e é parecida com a natureza das atualizações [Arrow Glacier](#arrow-glacier) e [Muir Glacier](#muir-glacier). Mudanças semelhantes foram realizadas nas atualizações de rede [Byzantium](#byzantium), [Constantinople](#constantinople) e [London](#london).
-
-- [Blog da EF – Comunicado da atualização Gray Glacier](https://blog.ethereum.org/2022/06/16/gray-glacier-announcement/)
-
-
-
-
-
EIP-5133 – atrasa a bomba de dificuldade até setembro de 2022
-
-
-
-
-
-
-## 2021 {#2021}
-
-### Arrow Glacier {#arrow-glacier}
-
-
-
-#### Resumo {#arrow-glacier-summary}
-
-A implementação de rede Arrow Glacier atrasou a [bomba de dificuldade](/glossary/#difficulty-bomb) por vários meses. Essa é a única mudança introduzida nesta implementação, e é de natureza similar à atualização [Muir Glacier](#muir-glacier). Mudanças semelhantes foram realizadas nas implementações de rede [Byzantium](#byzantium), [Constantinople](#constantinople) e [London](#london).
-
-- [Blog da EF – Comunicado da atualização Arrow Glacier](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/)
-- [Ethereum Cat Herders – Atualização Ethereum Arrow Glacier](https://medium.com/ethereum-cat-herders/ethereum-arrow-glacier-upgrade-e8d20fa4c002)
-
-
-
-
-
EIP-4345 – atrasa a bomba de dificuldade até junho de 2022
-
-
-
-
----
-
-### Altair {#altair}
-
-
-
-#### Resumo {#altair-summary}
-
-A Altair foi a primeira implementação programada para a [Beacon Chain](/roadmap/beacon-chain). Foi adicionado suporte para “comitês de sincronização”, permitindo clientes leves, aumentando a inatividade do validador e removendo penalidades à medida que o desenvolvimento avançava para o The Merge.
-
-- [Leia a especificação de melhoria da Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
-
-#### Fato engraçado! {#altair-fun-fact}
-
-Altair foi a primeira grande atualização de rede que teve um tempo exato de implantação. Todas as atualizações anteriores eram baseadas em um número de bloco declarado na cadeia de prova de trabalho, na qual o tempo de mineração de cada bloco varia. A Beacon Chain não requer resolver a prova de trabalho, em vez disso, ela funciona segundo um sistema de tempo em épocas, composto de 32 “intervalos” de 12 segundos cada, durante os quais os validadores podem propor blocos. É por isso que sabíamos exatamente quando atingiríamos a época 74.240 e a data de lançamento da Altair!
-
-- [Tempo do bloco](/developers/docs/blocks/#block-time)
-
----
-
-### London {#london}
-
-
-
-#### Resumo {#london-summary}
-
-A atualização London introduziu a [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), que reformou o mercado de taxas de transação, além de implementar mudanças na forma como os reembolsos de gás são realizados e no cronograma da [Ice Age](/glossary/#ice-age).
-
-#### O que foi a melhoria London / EIP-1559? {#eip-1559}
-
-Antes da melhoria London, o Ethereum tinha blocos de tamanho fixo. Em momentos de alta demanda de rede, esses blocos operaram em capacidade máxima. Como resultado, os usuários muitas vezes tiveram que esperar a redução da demanda para serem incluídos em um bloco, o que levou a uma má experiência do usuário. A atualização London introduziu blocos de tamanho variável ao Ethereum.
-
-A forma como as taxas de transação na rede Ethereum são calculadas foram alteradas com a [melhoria London](/history/#london) de agosto de 2021. Antes da melhoria London, as taxas eram calculadas sem separar as taxas `base` e `priority`, como segue:
-
-Digamos que Alice tenha que pagar a Roberto 1 ETH. Na transação, o limite de gás é de 21.000 unidades e o preço do gás é de 200 gwei.
-
-A taxa total teria sido: `Unidades de gás (limite) * Preço do gás por unidade` ou seja, `21.000 * 200 = 4.200.000 gwei` ou 0,0042 ETH
-
-A implementação da [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) na melhoria London tornou o mecanismo de taxa de transação mais complexo, mas deixou as taxas de gás mais previsíveis, resultando em um mercado de taxas de transação mais eficiente. Os usuários podem enviar transações com um `maxFeePerGas` correspondente ao quanto estão dispostos a pagar para a transação ser executada, sabendo que não pagarão mais do que o preço de mercado do gás (`baseFeePerGas`), e não receberão nenhum extra, exceto a gorjeta, de reembolso.
-
-Este vídeo explica o EIP-1559 e os benefícios que oferece: [EIP-1559 Explicado](https://www.youtube.com/watch?v=MGemhK9t44Q)
-
-- [Você é um desenvolvedor de dapp? Certifique-se de atualizar suas bibliotecas e ferramentas.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md)
-- [Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/)
-- [Leia a explicação do Ethereum Cat Herder](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41)
-
-
-
-
-
EIP-1559 – melhora o mercado de taxas de transação
EIP-3529 - reduz reembolsos de gás para operações EVM
-
EIP-3541 - impede a implantação de contratos que começam com 0xEF
-
EIP-3554 – atrasa a Era Glacial até dezembro de 2021
-
-
-
-
----
-
-### Berlin {#berlin}
-
-
-
-#### Resumo {#berlin-summary}
-
-A atualização Berlim otimizou o custo de gás para certas ações de EVM e aumenta o suporte para vários tipos de transação.
-
-- [Leia o anúncio da Fundação Ethereum](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/)
-- [Leia a explicação do Ethereum Cat Herder](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80)
-
-
-
-
-
-
-
-
-
-## 2020 {#2020}
-
-### Origem da Beacon Chain {#beacon-chain-genesis}
-
-
-
-#### Resumo {#beacon-chain-genesis-summary}
-
-A [Beacon Chain](/roadmap/beacon-chain/) precisava de 16.384 depósitos de 32 ETH em stake (participação) para ser transferida com segurança. Isso aconteceu em 27 de novembro, ou seja, a Beacon Chain começou a produzir blocos em 1 de dezembro de 2020. Este é um primeiro passo importante para alcançar a [Visão Ethereum](/roadmap/vision/).
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21/)
-
-
- A Beacon Chain
-
-
----
-
-### Contrato de depósito de participação implantado {#staking-deposit-contract}
-
-
-
-#### Resumo {#deposit-contract-summary}
-
-O contrato de depósito fixo introduziu [staking](/glossary/#staking) (participação) no ecossistema Ethereum. Embora fosse um contrato da [Mainnet](/glossary/#mainnet), ela teve um impacto direto na linha do tempo para o lançamento da [Beacon Chain](/roadmap/beacon-chain/), uma importante [atualização do Ethereum](/roadmap/).
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/)
-
-
- Participação
-
-
----
-
-### Muir Glacier {#muir-glacier}
-
-
-
-#### Resumo {#muir-glacier-summary}
-
-O fork (bifurcação) Muir Glacier introduziu um atraso na [bomba de dificuldade](/glossary/#difficulty-bomb). O aumento da dificuldade dos blocos do mecanismo de consenso da [prova de trabalho](/developers/docs/consensus-mechanisms/pow/) ameaçava degradar a usabilidade do Ethereum, aumentando os tempos de espera para o envio de transações e usando dapps.
-
-- [Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/)
-- [Leia a explicação do Ethereum Cat Herder](https://medium.com/ethereum-cat-herders/ethereum-muir-glacier-upgrade-89b8cea5a210)
-
-
-
-
-
EIP-2384 – atrasa a bomba de dificuldade por mais 4.000,000 blocos, ou cerca de 611 dias.
-
-
-
-
-
-
-## 2019 {#2019}
-
-### Istambul {#istanbul}
-
-
-
-#### Resumo {#istanbul-summary}
-
-O fork (bifurcação) Istanbul:
-
-- Otimizado o custo de [gás](/glossary/#gas) de certas ações no [EVM](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
-- Melhoria na resiliência a ataques de negação de serviço.
-- Criou soluções de [escalonamento da Camada 2](/developers/docs/scaling/#layer-2-scaling)com soluções baseadas em SNARKs e STARKs de melhor desempenho.
-- Interoperação entre Ethereum e Zcash habilitada.
-- Contratos permitidos para introduzir funções mais criativas.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/)
-
-
-
-
-
EIP-152 – permite que o Ethereum funcione com moedas que preservam a privacidade, como Zcash.
-
EIP-1108 – criptografia mais barata para melhorar custos de gás.
-
EIP-1344 – protege o Ethereum contra ataques de replay ao adicionar o opcodeCHAINID.
-
EIP-1884 – otimizando os preços de gás dos opcodes com base no consumo.
EIP-2200 – outras alterações de preço de gás de opcodes.
-
-
-
-
----
-
-### Constantinopla {#constantinople}
-
-
-
-#### Resumo {#constantinople-summary}
-
-O fork (bifurcação) Constantinople:
-
-- Redução das recompensas de [mineração](/developers/docs/consensus-mechanisms/pow/mining/) de blocos de 3 para 2 ETH.
-- Assegurou que a blockchain não se bloqueasse antes de que a [prova de participação fosse implementada](#beacon-chain-genesis).
-- Otimizado o custo de [gás](/glossary/#gas) de certas ações no [EVM](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
-- Agora apresenta a capacidade de interagir com endereços que ainda não foram criados.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/)
-
-
-
-
-
EIP-145 – otimiza o custo de certas ações on-chain.
-
EIP-1014 – permite que você interaja com endereços que ainda não foram criados.
-
EIP-1052 – otimiza o custo de certas ações on-chain.
-
EIP-1234 – garante que a blockchain não trave antes da prova de participação e reduz a recompensa pela mineração de blocos de 3 para 2 ETH.
-
-
-
-
-
-
-## 2017 {#2017}
-
-### Byzantium {#byzantium}
-
-
-
-#### Resumo {#byzantium-summary}
-
-O fork (bifurcação) Byzantium:
-
-- Reduziu as recompensas de [mineração](/developers/docs/consensus-mechanisms/pow/mining/) de bloco de 5 para 3 ETH.
-- A [bomba de dificuldade](/glossary/#difficulty-bomb) foi atrasada por um ano.
-- Adicionada a capacidade de fazer chamadas sem alteração de estado para outros contratos.
-- Adicionados alguns métodos de criptografia para permitir o [escalonamento da Camada 2](/developers/docs/scaling/#layer-2-scaling).
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/)
-
-
-
-
-
-
-
-
-
-## 2016 {#2016}
-
-### Spurious Dragon {#spurious-dragon}
-
-
-
-#### Resumo {#spurious-dragon-summary}
-
-O fork (bifurcação) Spurious Dragon foi a segunda resposta aos ataques de negação de serviço (DoS) na rede (setembro / outubro de 2016), incluindo:
-
-- ajustar preços do código de operação para evitar ataques futuros à rede.
-- permitindo "desinchar" do estado da cadeia de blocos.
-- adicionando proteção contra ataques de repetição.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/)
-
-
-
-
-
EIP-155 – impede que transações de uma cadeia Ethereum sejam retransmitidas em uma cadeia alternativa, por exemplo, uma transação da rede de testes sendo reproduzida na cadeia principal do Ethereum.
-
EIP-160 – ajusta os preços do opcode EXP – torna mais difícil para desacelerar a rede por meio de operações de contrato computacionalmente caras.
-
EIP-161 – permite a remoção de contas vazias adicionadas por meio de ataques DOS.
-
EIP-170 – muda o tamanho máximo do código que um contrato na blockchain pode ter – para 24576 bytes.
-
-
-
-
----
-
-### Tangerine Whistle {#tangerine-whistle}
-
-
-
-#### Resumo {#tangerine-whistle-summary}
-
-O fork (bifurcação) Whistle Tangerine foi a primeira resposta aos ataques de negação de serviço (DoS) na rede (setembro / outubro de 2016), incluindo:
-
-- resolução de problemas urgentes de integridade da rede relacionados a códigos de operação com preços reduzidos.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/)
-
-
-
-
-
EIP-150 – aumenta os custos de gás de opcodes que podem ser usados em ataques de spam.
-
EIP-158 – reduz o tamanho do estado removendo um grande número de contas vazias que foram colocadas no estado, a um custo muito baixo devido a falhas nas versões anteriores do protocolo Ethereum.
-
-
-
-
----
-
-### Bifurcação DAO {#dao-fork}
-
-
-
-#### Resumo {#dao-fork-summary}
-
-O fork (bifurcação) DAO foi em resposta ao [ataque DAO de 2016](https://www.coindesk.com/learn/understanding-the-dao-attack/), duranto o qual um contrato inseguro de [DAO](/glossary/#dao) foi esvaziado em mais de 3 milhões de ETH durante um hackeio. O fork (bifurcação) moveu os fundos do contrato defeituoso para um [novo contrato](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) com uma única função: fazer saque. Qualquer pessoa que tenha perdido fundos poderia sacar 1 ETH para cada 100 tokens DAO em suas carteiras.
-
-Esse curso de ação foi votado pela comunidade Ethereum. Qualquer titular de ETH pôde votar por meio de uma transação em [uma plataforma de votação](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). A decisão de fazer a bifurcação ultrapassou 85% dos votos.
-
-Alguns mineradores recusaram a bifurcação porque o incidente da DAO não era um defeito do protocolo. Eles começaram a formar a [Ethereum Classic](https://ethereumclassic.org/).
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2016/07/20/hard-fork-completed/)
-
----
-
-### Homestead {#homestead}
-
-
-
-#### Resumo {#homestead-summary}
-
-O fork (bifurcação) Homestead que olhou para o futuro. Incluiu várias alterações no protocolo e uma alteração na rede que deu ao Ethereum a capacidade de fazer mais atualizações na rede.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2016/02/29/homestead-release/)
-
-
-
-
-
EIP-2 – faz edições no processo de criação do contrato.
EIP-8 – apresenta os requisitos de compatibilidade futura do devp2p
-
-
-
-
-
-
-## 2015 {#2015}
-
-### Frontier thawing {#frontier-thawing}
-
-
-
-#### Resumo {#frontier-thawing-summary}
-
-O fork (bifurcação) Frontier Thawing aumentou o limite de [gás](/glossary/#gas) de 5.000 por [bloco](/glossary/#block) e definiu o preço padrão do gás para 51 [gwei](/glossary/#gwei). Isso é permitido para transações – as transações requerem 21.000 em gás. A bomba de dificuldade [](/glossary/#difficulty-bomb) foi introduzida para garantir uma futura bifurcação fixa para a [prova de participação](/glossary/#pos).
-
-- [Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2015/08/04/the-thawing-frontier/)
-- [Leia a atualização do protocolo Ethereum 1](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/)
-
----
-
-### Frontier {#frontier}
-
-
-
-#### Resumo {#frontier-summary}
-
-Frontier era a implementação mais simples do projeto Ethereum. Ela veio após a fase de testes bem-sucedida da Olympic. Ela era destinada a usuários técnicos, especificamente a desenvolvedores. [Blocos](/glossary/#block) tiveram um limite de [gás](/glossary/#gas) de 5.000. Esse período de “escavação” permitiu que os mineradores iniciassem as suas operações e que os primeiros adotantes instalassem os seus clientes sem “pressa”.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare/)
-
-
-
-## 2014 {#2014}
-
-### Venda de Ether {#ether-sale}
-
-
-
-O Ether permaneceu à venda oficialmente por 42 dias. Era possível comprá-lo com BTC.
-
-[Leia o comunicado da Ethereum Foundation](https://blog.ethereum.org/2014/07/22/launching-the-ether-sale/)
-
----
-
-### Lançamento do Yellow Paper {#yellowpaper}
-
-
-
-O Yellow Paper, de autoria do Dr. Gavin Wood, é uma definição técnica do protocolo Ethereum.
-
-[Ver o Yellow Paper](https://github.com/ethereum/yellowpaper)
-
-
-
-## 2013 {#2013}
-
-### Lançamento do Whitepaper {#whitepaper}
-
-
-
-Este artigo introdutório foi originalmente publicado em 2013 por Vitalik Buterin, fundador da Ethereum, antes do lançamento do projeto em 2015.
-
-
- Whitepaper
-
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
deleted file mode 100644
index d62a36f7c01..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
+++ /dev/null
@@ -1,656 +0,0 @@
----
-title: Anatomia dos contratos inteligentes
-description: Uma análise aprofundada na anatomia de um contrato inteligente - funções, dados e variáveis.
-lang: pt-br
----
-
-Um contrato inteligente (smart contract) é um programa executado em um endereço na Ethereum. Eles são compostos por dados e funções que podem ser executadas ao receber uma transação. Veja aqui uma visão geral do que compõe um contrato inteligente.
-
-## Pré-requisitos {#prerequisites}
-
-Não deixe de ler sobre [contratos inteligentes](/developers/docs/smart-contracts/). Este documento presume que você já está familiarizado com linguagens de programação como JavaScript ou Python.
-
-## Dados {#data}
-
-Quaisquer dados de contrato devem ser atribuídos a um local: seja para `armazenamento` ou `memória`. É caro modificar o armazenamento em um contrato inteligente, então você precisa considerar onde seus dados devem estar no ar.
-
-### Armazenamento {#storage}
-
-Dados persistentes são referidos como armazenamento e são representados por variáveis de estado. Esses valores são armazenados permanentemente na blockchain. É necessário declarar o tipo para que o contrato possa manter um registro de quanto espaço na blockchain será necessário quando ele compilar.
-
-```solidity
-// Exemplo Solidity
-contract SimpleStorage {
- uint storedData; // State variable
- // ...
-}
-```
-
-```python
-# Exemplo Vyper
-storedData: int128
-```
-
-Se você já programou linguagens orientadas a objetos, provavelmente você estará familiarizado com a maioria dos tipos. Entretanto, `address` (endereço) deve ser novo para você se você for novo no desenvolvimento com Ethereum.
-
-Um tipo `address` pode conter um endereço Ethereum que equivale a 20 bytes ou 160 bits. Ele retorna em hexadecimal com um 0 à frente.
-
-Outros tipos incluem:
-
-- booleano
-- inteiro
-- números de ponto fixo
-- arrays de bytes de tamanho fixo
-- arrays de bytes de tamanho dinâmico
-- Literais racionais e inteiros
-- Literais de strings
-- Literais hexadecimais
-- Enumeradores
-
-Para mais explicação, dê uma olhada na documentação:
-
-- [Veja tipos de Vyper](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types)
-- [Veja tipos de Solidity](https://solidity.readthedocs.io/en/latest/types.html#value-types)
-
-### Memória {#memory}
-
-Valores que são armazenados apenas para a duração da execução da função de contratos são chamadas de variáveis de memória. Como estes não são armazenados permanentemente na blockchain, são muito mais baratos de usar.
-
-Saiba mais sobre como a EVM armazena dados (Storage, Memória e Stack) em [Solidity docs](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack).
-
-### Variáveis de ambiente {#environment-variables}
-
-Além das variáveis definidas no seu contrato, existem algumas variáveis globais especiais. Elas são usadas principalmente para fornecer informações sobre a blockchain (cadeia de blocos) ou transação atual.
-
-Exemplos:
-
-| **Prop** | **Variável de estado** | **Descrição** |
-| ----------------- | ---------------------- | ------------------------------------- |
-| `block.timestamp` | uint256 | Data/hora de início do bloco atual |
-| `msg.sender` | endereço | Remetente da mensagem (chamada atual) |
-
-## Funções {#functions}
-
-Da forma mais simplista, funções podem obter informação ou um conjunto de informações em resposta a entrada de transações.
-
-Existem dois tipos de chamadas de função:
-
-- `internal` - estas não criam uma chamada EVM
- - Funções internas e variáveis de estado só podem ser acessadas internamente (ou seja, de dentro do contrato atual ou de contratos derivados do mesmo)
-- `external` - estas criam uma chamada EVM
- - Funções externas fazem parte da interface do contrato, o que significa que elas podem ser chamadas a partir de outros contratos e através de transações. Uma função externa `f` não pode ser chamada internamente (ou seja, `f()` não funciona, mas `this.f()` funciona).
-
-Também podem ser `públicas` ou `privadas`
-
-- `funções públicas` podem ser chamadas internamente a partir de dentro do contrato ou externamente por meio de mensagens
-- `funções privadas` são visíveis apenas para o contrato no qual elas estão definidas e não nos contratos derivados
-
-Tanto funções quanto variáveis de estado podem ser tornadas públicas ou privadas
-
-Aqui está uma função para atualizar uma variável de estado em um contrato:
-
-```solidity
-// Exemplo de Solidity
-function update_name(string value) public {
- dapp_name = value;
-}
-```
-
-- O parâmetro `valor` do tipo `string` é passado para a função: `update_name`
-- É declarado `público`, o que significa que qualquer um pode acessá-lo
-- Não é declarada a `visão`, então ela pode modificar o estado do contrato
-
-### Ver funções {#view-functions}
-
-Essas funções prometem não modificar o estado dos dados do contrato. Exemplos comuns são funções "obter" – você pode usar isso para receber o saldo de um usuário, por exemplo.
-
-```solidity
-// Exemplo
-function balanceOf(address _owner) public view return (uint256 _balance) {
- return ownerPizzaCount[_owner];
-}
-```
-
-```python
-dappName: public(string)
-
-@view
-@public
-def readName() -> string:
- return dappName
-```
-
-O que é considerado como modificar estado:
-
-1. Escrevendo variáveis de estado.
-2. [Emitir eventos](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events).
-3. [Criação de outros contratos](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts).
-4. Usando `autodestruct`.
-5. Enviando ether por chamadas.
-6. Chamar qualquer função não marcada como`view`ou`puro`.
-7. Usando chamadas de baixo nível.
-8. Usando montagem em linha que contém certos códigos.
-
-### Funções de "construtor" {#constructor-functions}
-
-`construtor` funções são executadas apenas uma vez quando o contrato é implantado pela primeira vez. Como o `construtor` em muitas linguagens de programação baseadas em classe, essas funções geralmente inicializam variáveis de estado para seus valores especificados.
-
-```solidity
-// Exemplo Solidity
-// Inicializa os dados do contrato, definindo o `owner`
-// como endereço do criador do contrato.
-constructor() public {
- // Todos os contratos inteligentes dependem de transações externas para acionar suas funções.
- // `msg` é uma variável global que inclui dados relevantes sobre a transação em questão,
- // como o endereço do remetente e o valor ETH incluído na transação.
- // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
- owner = msg.sender;
-}
-```
-
-```python
-# Exemplo Vyper
-
-@external
-def __init__(_beneficiary: endereço, _bidding_time: uint256):
- mesmo. eneficiário = _beneficiário
- self.auctionStart = block.timestamp
- self.auctionEnd = self.auctionStart + _bidding_time
-```
-
-### Funções integradas {#built-in-functions}
-
-Além das variáveis definidas no seu contrato, existem algumas variáveis globais especiais. O exemplo mais óbvio é:
-
-- `address.send()` – Solidity
-- `Enviar(endereço)` – Vyper
-
-Estes permitem contratos para enviar ETH para outras contas.
-
-## Como escrever funções {#writing-functions}
-
-Sua função precisa:
-
-- variável e tipo de parâmetro (se aceitar parâmetros)
-- declaração de interno/externo
-- declaração de puro/visualização/pagável
-- tipo de retorno (se ele retornar um valor)
-
-```solidity
-pragma solidity >=0.4.0 <=0.6.0;
-
-contract ExampleDapp {
- string dapp_name; // state variable
-
- // Called when the contract is deployed and initializes the value
- constructor() public {
- dapp_name = "My Example dapp";
- }
-
- // Get Function
- function read_name() public view returns(string) {
- return dapp_name;
- }
-
- // Set Function
- function update_name(string value) public {
- dapp_name = value;
- }
-}
-```
-
-Um contrato completo pode parecer algo assim. Aqui a função `construtor` fornece um valor inicial para a variável `dapp_name`.
-
-## Eventos e registros {#events-and-logs}
-
-Os eventos permitem que seu contrato inteligente se comunique com seu front-end ou outros aplicativos que se inscrevem para recebê-los. Uma vez que uma transação é validada e adicionada a um bloco, os contratos inteligentes podem emitir eventos e registrar informações, que o front-end pode processar e utilizar.
-
-## Exemplos anotados {#annotated-examples}
-
-Estes são alguns exemplos escritos em Solidity. Se você quiser brincar com o código, pode interagir com eles no [Remix](http://remix.ethereum.org).
-
-### Hello World {#hello-world}
-
-```solidity
-// Especifica a versão do Solidity usando a versão semântica.
-// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
-pragma solidity ^0.5.10;
-
-// Define um contrato chamado `HelloWorld`.
-// Um contrato é uma coleção de funções e dados (seu estado).
-// Uma vez implantado, um contrato reside em um endereço específico na blockchain Ethereum.
-// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
-contract HelloWorld {
-
- // Declita uma variável `message` de tipo `string`.
- // Variáveis de estado são variáveis cujos valores são permanentemente armazenados no armazenamento do contrato.
- // A palavra-chave 'público' torna variáveis acessíveis fora de um contrato
- // e cria uma função que outros contratos ou clientes podem chamar para acessar o valor.
- mensagem pública de cadeia;
-
- // Semelhante a muitas linguagens de objeto, baseadas em classes, um construtor é
- // uma função especial que é executada somente após a criação do contrato.
- // Os construtores são usados para inicializar os dados do contrato.
- // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/contracts. tml#constructors
- constructor(string memory initMessage) public {
- // Aceita um argumento de string `initMessage` e define o valor
- // na variável de armazenamento `message` do contrato).
- message = initMessage;
- }
-
- // Uma função pública que aceita um argumento de string
- // e atualiza a variável de armazenamento `message`.
- function update(string memory newMessage) public {
- message = newMessage;
- }
-}
-```
-
-### Token {#token}
-
-```solidity
-pragma solidity ^0.5.10;
-
-contract Token {
- // Um "endereço" é comparável a um endereço de e-mail - é usado para comparar uma conta no Ethereum.
- // Endereços podem representar uma conta de contrato inteligente ou uma conta externa (usuário).
- // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/types.html#address
- address public owner;
-
- // Um `mapping` é essencialmente uma estrutura de dados de tabela de hash.
- // Este `mapeamento` atribui um inteiro não assinado (o saldo do token) a um endereço (o titular do token).
- // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types
- mapping (address => uint) public balances;
-
- // Eventos permitem registro de atividade no blockchain.
- // Clientes Ethereum podem ouvir eventos para reagir às alterações do estado do contrato.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events
- event Transfer(address from, address to, uint amount);
-
- // Initializes the contract's data, setting the `owner`
- // to the address of the contract creator.
- constructor() public {
- // Todos os contratos inteligentes dependem de transações externas para acionar suas funções.
- // `msg` é uma variável global que inclui dados relevantes sobre a transação em questão,
- // como o endereço do remetente e o valor ETH incluído na transação.
- // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
- owner = msg.sender;
- }
-
- // Cria uma quantidade de novos tokens e os envia para um endereço.
- function mint(address receiver, uint amount) public {
- // `require` é uma estrutura de controle usada para aplicar certas condições.
- // Se um comando `require` for avaliado como `false`, uma exceção é acionada,
- // que reverte todas as alterações feitas ao estado durante a chamada atual.
- // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/control-structures. tml#error-handling-assert-require-revert-and-exceptions
-
- // Somente o proprietário do contrato pode chamar esta função
- require(msg. remetente == dono, "Você não é o dono. );
-
- // Reforça uma quantidade máxima de tokens
- require(amount < 1e60, "Emissão máxima excedida");
-
- // Aumenta o saldo de `receiver` em `amount`
- saldos[receiver] += amount;
- }
-
- // Envia uma quantidade de tokens existentes de qualquer chamada para um endereço.
- function transfer(address receiver, uint amount) public {
- // O remetente deve ter tokens suficientes para enviar
- require(amount <= balances[msg.sender], "Insufficient balance.");
-
- // Ajusta os saldos do token dos dois endereços
- balances[msg.sender] -= quantidade;
- balances[receiver] += quantidade;
-
- // Emite um evendo definido anteriormente
- emite Transfer(msg.sender, receiver, amount);
- }
-}
-```
-
-### Ativo digital único {#unique-digital-asset}
-
-```solidity
-pragma solidity ^0.5.10.
-// Neste caso, uma série de contratos auxiliares de OpenZeppelin.
-// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files
-
-import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol";
-import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver. ol";
-import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol";
-import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol";
-
-// A palavra-chave `is` é usada para herdar funções e palavras-chave de contratos externos.
-// Neste caso, o `CryptoPizza` herda dos contratos `IERC721` e `ERC165`.
-// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance
-contract CryptoPizza is IERC721, ERC165 {
- // Usa a biblioteca OpenZeppelin para executar operações aritméticas de forma segura.
- // Saiba mais: https://docs.openzeppelin.com/contracts/2. /api/math#SafeMath
- usando SafeMath para uint256;
-
- // Variáveis de estado constantes em Solidity são semelhantes a outros idiomas
- // mas você deve atribuir a partir de uma expressão que é constante na hora de compilação.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables
- uint256 constant dnaDigits = 10;
- uint256 constant dnaModulus = 10 ** dnaDigits;
- bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;
-
- // Struct types let you define your own type
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs
- struct Pizza {
- string name;
- uint256 dna;
- }
-
- // Creates an empty array of Pizza structs
- Pizza[] public pizzas;
-
- // Mapping from pizza ID to its owner's address
- mapping(uint256 => address) public pizzaToOwner;
-
- // Mapping from owner's address to number of owned token
- mapping(address => uint256) public ownerPizzaCount;
-
- // Mapping from token ID to approved address
- mapping(uint256 => address) pizzaApprovals;
-
- // You can nest mappings, this example maps owner to operator approvals
- mapping(address => mapping(address => bool)) private operatorApprovals;
-
- // Internal function to create a random Pizza from string (name) and DNA
- function _createPizza(string memory _name, uint256 _dna)
- // The `internal` keyword means this function is only visible
- // within this contract and contracts that derive this contract
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters
- internal
- // `isUnique` is a function modifier that checks if the pizza already exists
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers
- isUnique(_name, _dna)
- {
- // Adds Pizza to array of Pizzas and get id
- uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1);
-
- // Checks that Pizza owner is the same as current user
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
-
- // note that address(0) is the zero address,
- // indicating that pizza[id] is not yet allocated to a particular user.
-
- assert(pizzaToOwner[id] == address(0));
-
- // Maps the Pizza to the owner
- pizzaToOwner[id] = msg.sender;
- ownerPizzaCount[msg.sender] = SafeMath.add(
- ownerPizzaCount[msg.sender],
- 1
- );
- }
-
- // Creates a random Pizza from string (name)
- function createRandomPizza(string memory _name) public {
- uint256 randDna = generateRandomDna(_name, msg.sender);
- _createPizza(_name, randDna);
- }
-
- // Generates random DNA from string (name) and address of the owner (creator)
- function generateRandomDna(string memory _str, address _owner)
- public
- // Functions marked as `pure` promise not to read from or modify the state
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions
- pure
- returns (uint256)
- {
- // Generates random uint from string (name) + address (owner)
- uint256 rand = uint256(keccak256(abi.encodePacked(_str))) +
- uint256(_owner);
- rand = rand % dnaModulus;
- return rand;
- }
-
- // Returns array of Pizzas found by owner
- function getPizzasByOwner(address _owner)
- public
- // Functions marked as `view` promise not to modify state
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions
- view
- returns (uint256[] memory)
- {
- // Uses the `memory` storage location to store values only for the
- // lifecycle of this function call.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack
- uint256[] memory result = new uint256[](ownerPizzaCount[_owner]);
- uint256 counter = 0;
- for (uint256 i = 0; i < pizzas.length; i++) {
- if (pizzaToOwner[i] == _owner) {
- result[counter] = i;
- counter++;
- }
- }
- return result;
- }
-
- // Transfers Pizza and ownership to other address
- function transferFrom(address _from, address _to, uint256 _pizzaId) public {
- require(_from != address(0) && _to != address(0), "Invalid address.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- require(_from != _to, "Cannot transfer to the same address.");
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
-
- ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1);
- ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1);
- pizzaToOwner[_pizzaId] = _to;
-
- // Emits event defined in the imported IERC721 contract
- emit Transfer(_from, _to, _pizzaId);
- _clearApproval(_to, _pizzaId);
- }
-
- /**
- * Safely transfers the ownership of a given token ID to another address
- * If the target address is a contract, it must implement `onERC721Received`,
- * which is called upon a safe transfer, and return the magic value
- * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
- * otherwise, the transfer is reverted.
- */
- function safeTransferFrom(address from, address to, uint256 pizzaId)
- public
- {
- // solium-disable-next-line arg-overflow
- this.safeTransferFrom(from, to, pizzaId, "");
- }
-
- /**
- * Safely transfers the ownership of a given token ID to another address
- * If the target address is a contract, it must implement `onERC721Received`,
- * which is called upon a safe transfer, and return the magic value
- * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
- * otherwise, the transfer is reverted.
- */
- function safeTransferFrom(
- address from,
- address to,
- uint256 pizzaId,
- bytes memory _data
- ) public {
- this.transferFrom(from, to, pizzaId);
- require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received.");
- }
-
- /**
- * Internal function to invoke `onERC721Received` on a target address
- * The call is not executed if the target address is not a contract
- */
- function _checkOnERC721Received(
- address from,
- address to,
- uint256 pizzaId,
- bytes memory _data
- ) internal returns (bool) {
- if (!isContract(to)) {
- return true;
- }
-
- bytes4 retval = IERC721Receiver(to).onERC721Received(
- msg.sender,
- from,
- pizzaId,
- _data
- );
- return (retval == _ERC721_RECEIVED);
- }
-
- // Burns a Pizza - destroys Token completely
- // The `external` function modifier means this function is
- // part of the contract interface and other contracts can call it
- function burn(uint256 _pizzaId) external {
- require(msg.sender != address(0), "Invalid address.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
-
- ownerPizzaCount[msg.sender] = SafeMath.sub(
- ownerPizzaCount[msg.sender],
- 1
- );
- pizzaToOwner[_pizzaId] = address(0);
- }
-
- // Returns count of Pizzas by address
- function balanceOf(address _owner) public view returns (uint256 _balance) {
- return ownerPizzaCount[_owner];
- }
-
- // Returns owner of the Pizza found by id
- function ownerOf(uint256 _pizzaId) public view returns (address _owner) {
- address owner = pizzaToOwner[_pizzaId];
- require(owner != address(0), "Invalid Pizza ID.");
- return owner;
- }
-
- // Approves other address to transfer ownership of Pizza
- function approve(address _to, uint256 _pizzaId) public {
- require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner.");
- pizzaApprovals[_pizzaId] = _to;
- emit Approval(msg.sender, _to, _pizzaId);
- }
-
- // Returns approved address for specific Pizza
- function getApproved(uint256 _pizzaId)
- public
- view
- returns (address operator)
- {
- require(_exists(_pizzaId), "Pizza does not exist.");
- return pizzaApprovals[_pizzaId];
- }
-
- /**
- * Private function to clear current approval of a given token ID
- * Reverts if the given address is not indeed the owner of the token
- */
- function _clearApproval(address owner, uint256 _pizzaId) private {
- require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- if (pizzaApprovals[_pizzaId] != address(0)) {
- pizzaApprovals[_pizzaId] = address(0);
- }
- }
-
- /*
- * Sets or unsets the approval of a given operator
- * An operator is allowed to transfer all tokens of the sender on their behalf
- */
- function setApprovalForAll(address to, bool approved) public {
- require(to != msg.sender, "Cannot approve own address");
- operatorApprovals[msg.sender][to] = approved;
- emit ApprovalForAll(msg.sender, to, approved);
- }
-
- // Tells whether an operator is approved by a given owner
- function isApprovedForAll(address owner, address operator)
- public
- view
- returns (bool)
- {
- return operatorApprovals[owner][operator];
- }
-
- // Takes ownership of Pizza - only for approved users
- function takeOwnership(uint256 _pizzaId) public {
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
- address owner = this.ownerOf(_pizzaId);
- this.transferFrom(owner, msg.sender, _pizzaId);
- }
-
- // Checks if Pizza exists
- function _exists(uint256 pizzaId) internal view returns (bool) {
- address owner = pizzaToOwner[pizzaId];
- return owner != address(0);
- }
-
- // Checks if address is owner or is approved to transfer Pizza
- function _isApprovedOrOwner(address spender, uint256 pizzaId)
- internal
- view
- returns (bool)
- {
- address owner = pizzaToOwner[pizzaId];
- // Disable solium check because of
- // https://github.com/duaraghav8/Solium/issues/175
- // solium-disable-next-line operator-whitespace
- return (spender == owner ||
- this.getApproved(pizzaId) == spender ||
- this.isApprovedForAll(owner, spender));
- }
-
- // Check if Pizza is unique and doesn't exist yet
- modifier isUnique(string memory _name, uint256 _dna) {
- bool result = true;
- for (uint256 i = 0; i < pizzas.length; i++) {
- if (
- keccak256(abi.encodePacked(pizzas[i].name)) ==
- keccak256(abi.encodePacked(_name)) &&
- pizzas[i].dna == _dna
- ) {
- result = false;
- }
- }
- require(result, "Pizza with such name already exists.");
- _;
- }
-
- // Returns whether the target address is a contract
- function isContract(address account) internal view returns (bool) {
- uint256 size;
- // Currently there is no better way to check if there is a contract in an address
- // than to check the size of the code at that address.
- // See https://ethereum.stackexchange.com/a/14016/36603
- // for more details about how this works.
- // TODO Check this again before the Serenity release, because all addresses will be
- // contracts then.
- // solium-disable-next-line security/no-inline-assembly
- assembly {
- size := extcodesize(account)
- }
- return size > 0;
- }
-}
-```
-
-## Leitura adicional {#further-reading}
-
-Confira a documentação sobre Solidity e Vyper para ter uma visão geral mais completa dos contratos inteligentes:
-
-- [Solidity](https://solidity.readthedocs.io/)
-- [Vyper](https://vyper.readthedocs.io/)
-
-## Tópicos relacionados {#related-topics}
-
-- [Smart Contracts](/developers/docs/smart-contracts/)
-- [Máquina Virtual Ethereum](/developers/docs/evm/)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Diminuir contratos para enfrentar o limite de tamanho do contrato](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Algumas dicas práticas para reduzir o tamanho de seu contrato inteligente._
-- [Registrando dados de contratos inteligentes com eventos](/developers/tutorials/logging-events-smart-contracts/) _– Uma introdução aos eventos de contratos inteligentes e como você pode usá-los para registrar dados._
-- [Interaja com outros contratos Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Como implantar um contrato inteligente a partir de um contrato existente e interagir com ele._
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
deleted file mode 100644
index 1d9a3f0514e..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
+++ /dev/null
@@ -1,282 +0,0 @@
----
-title: Compilação de contratos inteligentes
-description: Uma explicação do motivo pelo qual você precisa compilar contratos inteligentes e o que a compilação realmente faz.
-lang: pt-br
-incomplete: true
----
-
-Você precisa compilar seu contrato para que seu aplicativo web e a máquina virtual Ethereum (EVM) possam entendê-lo.
-
-## Pré-requisitos {#prerequisites}
-
-Você pode achar útil ler nossa introdução a [contratos inteligentes](/developers/docs/smart-contracts/) e a [máquina virtual Ethereum](/developers/docs/evm/) antes de ler sobre compilação.
-
-## A EVM {#the-evm}
-
-Para a [ EVM](/developers/docs/evm/) poder executar seu contrato, ele precisa estar em ** bytecode**. A compilação transforma isso:
-
-```solidity
-pragma solidity 0.4.24;
-
-contract Saudações {
-
- function greet() public constant returns (string) {
- return "Olá";
- }
-
-}
-```
-
-**nisso**
-
-```
-PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900
-```
-
-Esses são chamados de **opcodes**. Os opcodes da EVM são instruções de baixo nível que a Máquina Virtual Ethereum (EVM) pode executar. Cada opcode representa uma operação específica, como operações aritméticas, operações lógicas, manipulação de dados, controle de fluxo, entre outras.
-
-[Mais sobre opcodes](/developers/docs/evm/opcodes/)
-
-## Aplicativos Web {#web-applications}
-
-O compilador também produzirá a ** Interface Binária de Aplicação (ABI)** de que necessita para que a sua aplicação compreenda o contrato e chame as funções do contrato.
-
-A ABI é um arquivo JSON que descreve o contrato implantado e suas funções de contrato inteligente. Ele faz a ponte entre a web2 e web3
-
-Uma [biblioteca cliente JavaScript](/developers/docs/apis/javascript/) vai ler a **ABI** para que você chame seu contrato inteligente na interface do seu aplicativo da web.
-
-Abaixo está a ABI para o contrato de token ERC-20. Um ERC-20 é um token que você pode negociar no Ethereum.
-
-```json
-[
- {
- "constant": true,
- "inputs": [],
- "name": "name",
- "outputs": [
- {
- "name": "",
- "type": "string"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": false,
- "inputs": [
- {
- "name": "_spender",
- "type": "address"
- },
- {
- "name": "_value",
- "type": "uint256"
- }
- ],
- "name": "approve",
- "outputs": [
- {
- "name": "",
- "type": "bool"
- }
- ],
- "payable": false,
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [],
- "name": "totalSupply",
- "outputs": [
- {
- "name": "",
- "type": "uint256"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": false,
- "inputs": [
- {
- "name": "_from",
- "type": "address"
- },
- {
- "name": "_to",
- "type": "address"
- },
- {
- "name": "_value",
- "type": "uint256"
- }
- ],
- "name": "transferFrom",
- "outputs": [
- {
- "name": "",
- "type": "bool"
- }
- ],
- "payable": false,
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [],
- "name": "decimals",
- "outputs": [
- {
- "name": "",
- "type": "uint8"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [
- {
- "name": "_owner",
- "type": "address"
- }
- ],
- "name": "balanceOf",
- "outputs": [
- {
- "name": "balance",
- "type": "uint256"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [],
- "name": "symbol",
- "outputs": [
- {
- "name": "",
- "type": "string"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": false,
- "inputs": [
- {
- "name": "_to",
- "type": "address"
- },
- {
- "name": "_value",
- "type": "uint256"
- }
- ],
- "name": "transfer",
- "outputs": [
- {
- "name": "",
- "type": "bool"
- }
- ],
- "payable": false,
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [
- {
- "name": "_owner",
- "type": "address"
- },
- {
- "name": "_spender",
- "type": "address"
- }
- ],
- "name": "allowance",
- "outputs": [
- {
- "name": "",
- "type": "uint256"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "payable": true,
- "stateMutability": "payable",
- "type": "fallback"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "name": "owner",
- "type": "address"
- },
- {
- "indexed": true,
- "name": "spender",
- "type": "address"
- },
- {
- "indexed": false,
- "name": "value",
- "type": "uint256"
- }
- ],
- "name": "Approval",
- "type": "event"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "name": "from",
- "type": "address"
- },
- {
- "indexed": true,
- "name": "to",
- "type": "address"
- },
- {
- "indexed": false,
- "name": "value",
- "type": "uint256"
- }
- ],
- "name": "Transfer",
- "type": "event"
- }
-]
-```
-
-## Leitura adicional {#further-reading}
-
-- [ Especificações ABI](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html)_– Solidity_
-
-## Tópicos relacionados {#related-topics}
-
-- [Bibliotecas cliente JavaScript](/developers/docs/apis/javascript/)
-- [Máquina virtual Ethereum](/developers/docs/evm/)
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
deleted file mode 100644
index acc0e90d437..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Implantação de contratos inteligentes
-description:
-lang: pt-br
----
-
-Você precisa implantar o seu contrato inteligente para que ele esteja disponível para os usuários de uma rede Ethereum.
-
-Para implantar um contrato inteligente, você apenas envia uma transação Ethereum que contém o código do contrato inteligente compilado sem especificar os destinatários.
-
-## Pré-Requisitos {#prerequisites}
-
-Você deve entender as [redes Ethereum](/developers/docs/networks/), [transações](/developers/docs/transactions/) e a [anatomia de contratos inteligentes](/developers/docs/smart-contracts/anatomy/) antes de implantar contratos inteligentes.
-
-Implantar um contrato também custa ether (ETH), pois eles são armazenados na blockchain, portanto, você deveria estar familiarizado com [gás e taxas](/developers/docs/gas/) na Ethereum.
-
-Finalmente, você precisará compilar seu contrato antes de implantá-lo, então certifique-se de ter lido sobre [compilação de contratos inteligentes](/developers/docs/smart-contracts/compiling/).
-
-## Como implantar um contrato inteligente {#how-to-deploy-a-smart-contract}
-
-### O que você precisará {#what-youll-need}
-
-- Bytecode do seu contrato - isto é gerado através da [compilação](/developers/docs/smart-contracts/compiling/).
-- Ether para gás – você definirá o seu limite de gás como outras transações, então esteja ciente de que a implantação do contrato precisa de muito mais gás do que uma simples transferência de ETH
-- um script de implantação ou um plugin
-- acesso a um [nó Ethereum](/developers/docs/nodes-and-clients/), executando o seu próprio, conectando a um nó público ou por meio de uma chave de API usando um [serviço de nó](/developers/docs/nodes-and-clients/nodes-as-a-service/)
-
-### Como implantar um contrato inteligente {#steps-to-deploy}
-
-Os passos específicos envolvidos dependerão do framework de desenvolvimento em questão. Por exemplo, confira [a documentação do Hardhat sobre como implementar seu contrato](https://hardhat.org/guides/deploying.html) ou [a documentação do Foundry sobre como implementar e verificar um contrato inteligente](https://book.getfoundry.sh/forge/deploying). Uma vez implementado, seu contrato terá um endereço Ethereum igual qualquer outra [conta](/developers/docs/accounts/) e poderá ser verificado usando [ferramentas de verificação de código-fonte](/developers/docs/smart-contracts/verifying/#source-code-verification-tools).
-
-## Ferramentas relacionadas {#related-tools}
-
-**Remix - _Remix IDE permite desenvolver, implantar e administrar contratos inteligentes para Ethereum como as cadeias de blocos._**
-
-- [Remix](https://remix.ethereum.org)
-
-**Tenderly - _Plataforma de desenvolvimento web3 que fornece blocos de construção para debugar, observar, e para infraestrutura para desenvolvimento, testes, monitoramento e operação de contratos inteligentes_**
-
-- [tenderly.com](https://tenderly.co/)
-- [Documentação](https://docs.tenderly.co/)
-- [GitHub](https://github.com/Tenderly)
-- [Discord](https://discord.gg/eCWjuvt)
-
-**Hardhat - _Um ambiente de desenvolvimento para compilar, implantar, testar e depurar seu software de Ethereum_**
-
-- [hardhat.org](https://hardhat.org/getting-started/)
-- [Documentos na implantação de seus contratos](https://hardhat.org/guides/deploying.html)
-- [GitHub](https://github.com/nomiclabs/hardhat)
-- [Discord](https://discord.com/invite/TETZs2KK4k)
-
-**thirdweb - _Implemente facilmente qualquer contrato em qualquer cadeia compatível com EVM, usando um único comando_**
-
-- [Documentação](https://portal.thirdweb.com/deploy/)
-
-**Crossmint - _Plataforma de desenvolvimento web3 de nível empresarial para implantar contratos inteligentes, habilitar pagamentos com cartão de crédito e entre cadeias, e usar APIs para criar, distribuir, vender, armazenar e editar NFTs._**
-
-- [crossmint.com](https://www.crossmint.com)
-- [Documentação](https://docs.crossmint.com)
-- [Discord](https://discord.com/invite/crossmint)
-- [Blog](https://blog.crossmint.com)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Implementando o seu primeiro contrato inteligente](/developers/tutorials/deploying-your-first-smart-contract/) _– Uma introdução à implementação do seu primeiro contrato inteligente em uma rede de teste da Ethereum._
-- [Hello World | tutorial para contrato inteligente](/developers/tutorials/hello-world-smart-contract/)_ - Um tutorial fácil de seguir para criar & implementar um contrato inteligente básico na Ethereum._
-- [Interaja com outros contratos Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Como implantar um contrato inteligente a partir de um contrato existente e interagir com ele._
-- [Como diminuir o tamanho de seu contrato](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- Como reduzir o tamanho do seu contrato para mantê-lo abaixo do limite e economizar Gas_
-
-## Leia mais {#further-reading}
-
-- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_
-- [Implementando seus contratos com Hardhat](https://hardhat.org/guides/deploying.html) - _Nomic Labs_
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
-
-## Tópicos relacionados {#related-topics}
-
-- [Estruturas de desenvolvimento](/developers/docs/frameworks/)
-- [Executando um nó Ethereum](/developers/docs/nodes-and-clients/run-a-node/)
-- [Nódulos como serviço](/developers/docs/nodes-and-clients/nodes-as-a-service)
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
deleted file mode 100644
index f2b598084f3..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Introdução aos contratos inteligentes
-description: Uma visão geral dos contratos inteligentes, centrada em suas características e limitações únicas.
-lang: pt-br
----
-
-## O que é um contrato inteligente? {#what-is-a-smart-contract}
-
-Um "contrato inteligente" é simplesmente um programa executado na blockchain Ethereum. É uma coleção de código (suas funções) e dados (seu estado) que reside em um endereço específico na blockchain Ethereum.
-
-Os contratos inteligentes são um tipo de [conta Ethereum](/developers/docs/accounts/). Isso significa que eles têm saldo e podem ser alvo de transações. No entanto, eles não são controlados por um usuário, em vez disso, eles são implantados na rede e são executados como programados. Contas de usuários podem então interagir com um contrato inteligente enviando transações que executam uma função definida no contrato inteligente. Os contratos inteligentes podem definir regras, como um contrato regular, e aplicá-los automaticamente através do código. Os contratos inteligentes não podem ser excluídos por padrão, e as interações com eles são irreversíveis.
-
-## Pré-requisitos {#prerequisites}
-
-Se você está apenas começando ou procurando uma introdução menos técnica, recomendamos nossa [introdução aos contratos inteligentes](/smart-contracts/).
-
-Não deixe de ler [contas](/developers/docs/accounts/), [transações](/developers/docs/transactions/) e [máquina virtual Ethereum](/developers/docs/evm/) antes de entrar no mundo dos contratos inteligentes.
-
-## Uma máquina de vendas digitais {#a-digital-vending-machine}
-
-Talvez a melhor metáfora para um contrato inteligente seja uma máquina de venda automática, descrita por [Nick Szabo](https://unenumerated. blogspot. com/). Com as entradas certas, uma saída segura é garantida.
-
-Para obter um snack de uma máquina de venda automática:
-
-```
-dinheiro +seleção de snack = snack dispensado
-```
-
-Esta lógica está programada para a máquina de venda automática.
-
-Um contrato inteligente, como uma máquina de venda automática, tem lógica programada dentro dele. Aqui está um exemplo simples de como essa máquina de venda automática ficaria se fosse um contrato inteligente escrito em Solidity:
-
-```solidity
-pragma solidity 0.8.7;
-
-contract VendingMachine {
-
- // Declarar variáveis de estado do endereço público do proprietário do contrato;
- mapping (address => uint) public cupcakeBalances;
-
- // Quando o contrato 'VendingMachine' é implantado:
- // 1. defina o endereço de implantação como proprietário do contrato
- // 2. defina o saldo de cupcake do contrato inteligente para 100
- constructor() public {
- owner = msg.sender;
- cupcakeBalances[address(this)] = 100;
- }
-
- // Permite que o proprietário aumente o saldo de cupcake no contrato inteligente
- function refill(uint amount) public {
- require(msg.sender == owner, "Only the owner can refill.");
- cupcakeBalances[address(this)] += amount;
- }
-
- // Permite que qualquer pessoa adquira cupcakes
- function purchase(uint amount) public payable {
- require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
- require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase");
- cupcakeBalances[address(this)] -= amount;
- cupcakeBalances[msg.sender] += amount;
- }
-}
-```
-
-De maneira similar a como uma máquina de venda automática elimina a necessidade de um funcionário fornecedor, os contratos inteligentes podem substituir intermediários em muitos setores.
-
-## Sem necessidade de permissão {#permissionless}
-
-Qualquer um pode escrever um contrato inteligente e implantá-lo na rede. Você só precisa aprender a codificar em uma [linguagem de contrato inteligente](/developers/docs/smart-contracts/languages/) e ter ETH suficiente para implantar seu contrato. A implantação de um contrato inteligente é tecnicamente uma transação, portanto, você precisa pagar o [gás](/developers/docs/gas/) da mesma forma que precisa pagar o Gas por uma simples transferência de ETH. No entanto, os custos de gás para implantação de contrato são muito mais altos.
-
-A Ethereum tem linguagens que o desenvolvedor terá facilidade de usar para escrever contratos inteligentes:
-
-- Solidity
-- Vyper
-
-[Mais sobre linguagens](/developers/docs/smart-contracts/languages/)
-
-Contudo, elas devem ser compiladas antes de poderem ser implantadas para que a máquina virtual da Ethereum possa interpretar e armazenar o contrato. [Mais sobre compilação](/developers/docs/smart-contracts/compiling/)
-
-## Componibilidade {#composability}
-
-Os contratos inteligentes são públicos na Ethereum e podem ser considerados como APIs abertas. Isso significa que você pode chamar outros contratos inteligentes em seu próprio contrato inteligente para estender muito o que é possível. Os contratos podem mesmo implantar outros contratos.
-
-Saiba mais sobre a [composição do contrato inteligente](/developers/docs/smart-contracts/composability/).
-
-## Limitações {#limitations}
-
-Os contratos inteligentes sozinhos não podem obter informações sobre eventos do "mundo real", porque não podem recuperar dados de fontes off-chain. Isso significa que eles não podem responder a eventos no mundo real. Isto é, por concepção. A sua concepção é a de que as informações externas podem pôr em causa o consenso, que é importante para a segurança e a descentralização.
-
-No entanto, é importante que aplicações blockchain possam usar dados off-chain. A solução são os [oráculos](/developers/docs/oracles/), que são instrumentos que ingerem dados off-chain e os disponibilizam para contratos inteligentes.
-
-Outra limitação de contratos inteligentes é o tamanho máximo do contrato. Um contrato inteligente pode ser um máximo de 24KB ou ficará sem gás. Isso pode ser contornado usando [O Padrão de Diamante](https://eips.ethereum.org/EIPS/eip-2535).
-
-## Contratos Multisig {#multisig}
-
-Os contratos multisig (com múltiplas assinaturas) são contas de contrato inteligente que exigem várias assinaturas válidas para executar uma transação. Isso é muito útil para evitar pontos únicos de falha para contratos com quantidades substanciais de ether ou outros tokens. Os Multisigs também dividem a responsabilidade pela execução do contrato e gerenciamento das chaves entre vários participantes e evitam que a perda de uma única chave privada leve à perda irreversível de fundos. Por esses motivos, os contratos multisig podem ser usados para governança DAO simples. Multisigs requerem N assinaturas de M possíveis assinaturas aceitáveis (onde N ≤ M e M > 1) para serem executados. `N = 3, M = 5` e `N = 4, M = 7` são utilizados com frequência. Um multisig 4/7 requer quatro das sete assinaturas válidas possíveis. Isso significa que os fundos ainda podem ser recuperados, mesmo que três assinaturas sejam perdidas. Nesse caso, também significa que a maioria dos detentores de chaves deve concordar e assinar para que o contrato seja executado.
-
-## Recursos para contratos inteligentes {#smart-contract-resources}
-
-**OpenZeppelin Contracts -** **_Biblioteca para o desenvolvimento de contratos inteligentes seguros._**
-
-- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/)
-- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
-- [Fórum da Comunidade](https://forum.openzeppelin.com/c/general/16)
-
-## Leitura adicional {#further-reading}
-
-- [Coinbase: O que é um contrato inteligente?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract)
-- [Chainlink: O que é um contrato inteligente?](https://chain.link/education/smart-contracts)
-- [Vídeo: Simplesmente Explicado - Contratos Inteligentes](https://youtu.be/ZE2HxTmxfrI)
-- [Cyfrin Updraft: Plataforma de aprendizado e auditoria Web3](https://updraft.cyfrin.io)
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
deleted file mode 100644
index b378eb20329..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
+++ /dev/null
@@ -1,326 +0,0 @@
----
-title: Linguagens de contratos inteligentes
-description: Uma visão geral e comparação de duas línguagens de contratos inteligentes – Solidity e Vyper.
-lang: pt-br
----
-
-Um grande aspecto sobre a Ethereum é que os contratos inteligentes podem ser programados usando linguagens relativamente amigáveis para o desenvolvedor. Se você tem experiência com Python ou qualquer [linguagem de marcação](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), você pode encontrar uma linguagem com sintaxe familiar.
-
-As duas linguagens mais ativas e mantidas são:
-
-- Solidity
-- Vyper
-
-O Remix IDE oferece um ambiente de desenvolvimento abrangente para a criação e teste de contratos em Solidity e Vyper. [Experimente o Remix IDE no navegador](https://remix.ethereum.org) para começar a codificar.
-
-Desenvolvedores mais experientes também podem querer usar o Yul, uma linguagem intermediária para a [Máquina Virtual Ethereum](/developers/docs/evm/), ou Yul+, uma extensão para Yul.
-
-Se você está curioso e gosta de ajudar a testar novas linguagens que ainda estão em grande desenvolvimento, você pode experimentar com Fe, uma linguagem de contrato inteligente emergente que ainda está na sua infância.
-
-## Pré-requisitos {#prerequisites}
-
-Conhecimento anterior de linguagens de programação, especialmente de JavaScript ou Python, pode ajudá-lo a entender as diferenças nas linguagens de contratos inteligentes. Nós também recomendamos que você entenda os contratos inteligentes como um conceito, antes de se aprofundar nas comparações de linguagem. [Introdução aos contratos inteligentes](/developers/docs/smart-contracts/).
-
-## Solidity {#solidity}
-
-- Linguagem de alto nível orientada para objetos para a implementação de contratos inteligentes.
-- Linguagem de marcações mais profundamente influenciada por C++.
-- Tipada estaticamente (o tipo de variável é conhecido em tempo de compilação).
-- Suporte:
- - Herança (você pode estender outros contratos).
- - Bibliotecas (você pode criar código reutilizável que pode ser chamado de diferentes contratos – como funções estáticas dentro de uma classe estática em outras linguagens de programação orientadas a objetos).
- - Tipos complexos definidos pelo usuário.
-
-### Links importantes {#important-links}
-
-- [Documentação](https://docs.soliditylang.org/en/latest/)
-- [Portal da linguagem Solidity](https://soliditylang.org/)
-- [Solidity como exemplo](https://docs.soliditylang.org/en/latest/solidity-by-example.html)
-- [GitHub](https://github.com/ethereum/solidity/)
-- [Solidity Gitter Chatroom](https://gitter.im/ethereum/solidity) ponte para [Solidity Matrix Chatroom](https://matrix.to/#/#ethereum_solidity:gitter.im)
-- [Dicas](https://reference.auditless.com/cheatsheet)
-- [Blog da Solidity](https://blog.soliditylang.org/)
-- [Solidity Twitter](https://twitter.com/solidity_lang)
-
-### Exemplo de contrato {#example-contract}
-
-```solidity
-// SPDX-License-Identifier: GPL-3.0
-pragma solidity >= 0.7.0;
-
-contract Coin {
- // A palavra-chave "public" torna as variáveis
- // acessíveis a partir de outros contratos
- address public minter;
- mapping (address => uint) public balances;
-
- // Os eventos permitem que os clientes reajam a determinadas
- // alterações de contrato que você declara
- event Sent(address from, address to, uint amount);
-
- // O código constructor só é executado quando o contrato
- // é criado
- constructor() {
- minter = msg.sender;
- }
-
- // Envia uma quantidade de moedas recém criadas para um endereço
- // Só pode ser chamada pelo criador do contrato
- function mint(address receiver, uint amount) public {
- require(msg.sender == minter);
- require(amount < 1e60);
- balances[receiver] += amount;
- }
-
- // Envia uma quantidade de moedas existentes
- // de qualquer solicitador para um endereço
- function send(address receiver, uint amount) public {
- require(amount <= balances[msg.sender], "Saldo insuficiente.");
- balances[msg.sender] -= amount;
- balances[receiver] += amount;
- emit Sent(msg.sender, receiver, amount);
- }
-}
-```
-
-Esse exemplo deve dar a você, uma ideia de como é a sintaxe de um contrato na Solidity. Para uma descrição mais detalhada das funções e variáveis, [consulte a documentação](https://docs.soliditylang.org/en/latest/contracts.html).
-
-## Vyper {#vyper}
-
-- Linguagem de programação Pythonic
-- Digitação sólida
-- Código de compilador pequeno e compreensível
-- Geração de bytecode eficiente
-- Deliberadamente, tem menos recursos do que Solidity, com o objetivo de tornar os contratos mais seguros e mais fáceis de auditar. Vyper não suporta:
- - Modificadores
- - Herança
- - Montagem embutida
- - Sobrecarga de função
- - Sobrecarga do operador
- - Chamada recursiva
- - Repetições com comprimento infinito
- - Pontos fixos binários
-
-Para obter mais informações, [leia a lógica do Vyper](https://vyper.readthedocs.io/en/latest/index.html).
-
-### Links importantes {#important-links-1}
-
-- [Documentação](https://vyper.readthedocs.io)
-- [Vyper como exemplo](https://vyper.readthedocs.io/en/latest/vyper-by-example.html)
-- [Mais Vyper por Exemplo](https://vyper-by-example.org/)
-- [GitHub](https://github.com/vyperlang/vyper)
-- [Chat Discord da comunidade Vyper](https://discord.gg/SdvKC79cJk)
-- [Dicas](https://reference.auditless.com/cheatsheet)
-- [Ferramentas e frameworks de desenvolvimento de contratos inteligentes para Vyper](/developers/docs/programming-languages/python/)
-- [VyperPunk - Aprenda a proteger e hackear contratos inteligentes Vyper](https://github.com/SupremacyTeam/VyperPunk)
-- [VyperExamples - Exemplos de vulnerabilidade Vyper](https://www.vyperexamples.com/reentrancy)
-- [Vyper Hub para desenvolvimento](https://github.com/zcor/vyper-dev)
-- [Exemplos de contratos inteligentes de maiores sucessos Vyper](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts)
-- [Recursos incríveis com curadoria do Vyper](https://github.com/spadebuilders/awesome-vyper)
-
-### Exemplo {#example}
-
-```python
-# Leilão aberto
-
-# Parâmetros do leilão
-# Beneficiário recebe dinheiro do licitante com lance mais alto
-beneficiary: public(address)
-auctionStart: public(uint256)
-auctionEnd: public(uint256)
-
-# Estado atual do leilão
-highestBidder: public(address)
-highestBid: public(uint256)
-
-# Definido como verdadeiro no final, não permite qualquer alteração
-ended: public(bool)
-
-# Acompanha os lances reembolsados para que possamos seguir o padrão de saque
-pendingReturns: public(HashMap[address, uint256])
-
-# Cria um leilão simples com `_bidding_time`
-# segundos de tempo de licitação em nome do
-# endereço do beneficiário `_beneficiary`.
-@external
-def __init__(_beneficiary: address, _bidding_time: uint256):
- self.beneficiary = _beneficiary
- self.auctionStart = block.timestamp
- self.auctionEnd = self.auctionStart + _bidding_time
-
-# Licita no leilão com o valor enviado
-# junto com esta transação.
-# O valor só será devolvido se o
-# leilão não foi ganho.
-@external
-@payable
-def bid():
- # Verifica se o período de licitação acabou.
- assert block.timestamp < self.auctionEnd
- # Verifica se o lance é alto o suficiente
- assert msg.value > self.highestBid
- # Rastreia o reembolso do licitante anterior
- self.pendingReturns[self.highestBidder] += self.highestBid
- # Rastreia o mais recente lance mais alto
- self.highestBidder = msg.sender
- self.highestBid = msg.value
-
-# Retira um lance previamente reembolsado. O padrão de retirada é
-# usado aqui para evitar um problema de segurança. Se os reembolsos fossem diretamente
-# enviados como parte do lance (bid()), um contrato de licitação malicioso poderia bloquear
-# esses reembolsos e, assim, bloquear a entrada de novos lances mais altos.
-@external
-def withdraw():
- pending_amount: uint256 = self.pendingReturns[msg.sender]
- self.pendingReturns[msg.sender] = 0
- send(msg.sender, pending_amount)
-
-# Termina o leilão e envia o lance mais alto
-# para o beneficiário.
-@external
-def endAuction():
- # É uma boa diretriz para estruturar funções que interagem
- # com outros contratos (ou seja, eles chamam funções ou enviam Ether)
- # em três fases:
- # 1. verificando as condições
- # 2. realizando ações (condições potencialmente mutáveis)
- # 3. interagindo com outros contratos
- # Se essas fases forem misturadas, o outro contrato poderia retornar ao
- # contrato atual e modificar o estado ou causar
- # efeitos (pagamento em ether) para serem realizados várias vezes.
- # Se as funções chamadas internamente incluem interações
- # com contratos externos, também devem ser consideradas interações com
- # contratos externos.
-
- # 1. Condições
- # Verifique se o horário de término do leilão foi atingido
- assert block.timestamp >= self.auctionEnd
- # Verifique se esta função já foi chamada
- assert not self.ended
-
- # 2. Efeitos
- self.ended = True
-
- # 3. Interação
- send(self.beneficiary, self.highestBid)
-```
-
-Esse exemplo deve dar-nos uma noção do que é a sintaxe do contrato Vyper. Para uma descrição mais detalhada das funções e variáveis, [consulte a documentação](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction).
-
-## Yul e Yul+ {#yul}
-
-Se você é novo na Ethereum e ainda não fez qualquer codificação com linguagens de contrato inteligentes, recomendamos começar com Solidity ou Vyper. Apenas olhe para Yul ou Yul+ quando estiver familiarizado com as melhores práticas de segurança inteligente do contrato e com as especificações de trabalho com a EVM.
-
-**Yul**
-
-- Linguagem intermediária para Ethereum.
-- Suporta a [EVM](/developers/docs/evm) e [eWASM](https://github.com/ewasm), um WebAssembly com sabor de Ethereum e concebido para ser um denominador comum utilizável de ambas as plataformas.
-- Alvo para fases de otimização de alto nível que podem beneficiar tanto as plataformas EVM como Ewasm de forma igual.
-
-**Yul+**
-
-- Uma extensão de baixo nível altamente eficiente para Yul.
-- Inicialmente concebido para um [optimistic rollup](/developers/docs/scaling/optimistic-rollups/).
-- Yul+ pode ser visto como uma proposta de atualização experimental para Yul, adicionando novos recursos.
-
-### Links Importantes {#important-links-2}
-
-- [Documentação](https://docs.soliditylang.org/en/latest/yul.html)
-- [Documentação Yul+](https://github.com/fuellabs/yulp)
-- [Yul+ Playground](https://yulp.fuel.sh/)
-- [Yul+ Post de Introdução](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f)
-
-### Exemplo de contrato {#example-contract-2}
-
-O exemplo a seguir simples implementa uma função de energia. Ele pode ser compilado usando `solc --strict-assembly --bin input.yul`. O exemplo deve ser armazenado no arquivo input.yul.
-
-```
-{
- function power(base, exponent) -> result
- {
- switch exponent
- case 0 { result := 1 }
- case 1 { result := base }
- default
- {
- result := power(mul(base, base), div(exponent, 2))
- if mod(exponent, 2) { result := mul(base, result) }
- }
- }
- let res := power(calldataload(0), calldataload(32))
- mstore(0, res)
- return(0, 32)
-}
-```
-
-Se você já é bem experiente com contratos inteligentes, uma implementação do ERC20 em Yul pode ser encontrada [aqui](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example).
-
-## Fe {#fe}
-
-- Linguagem estaticamente digitada para a Máquina Virtual Ethereum (EVM).
-- Inspirado por Python e Rust.
-- O objetivo é ser fácil de aprender -- mesmo para desenvolvedores que são novos no ecossistema Ethereum.
-- Fe ainda está em seus estágios iniciais, a linguagem teve sua versão alfa em janeiro de 2021.
-
-### Links importantes {#important-links-3}
-
-- [GitHub](https://github.com/ethereum/fe)
-- [Anúncio da Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/)
-- [Fe 2021 Roadmap](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg)
-- [Chat de Discord Fe](https://discord.com/invite/ywpkAXFjZH)
-- [Fe Twitter](https://twitter.com/official_fe)
-
-### Exemplo de contrato {#example-contract-3}
-
-O seguinte é um contrato simples implementado em Fe.
-
-```
-type BookMsg = bytes[100]
-
-contrate GuestBook:
- pub guest_book: map
-
- event Signed:
- book_msg: BookMsg
-
- pub def sign(book_msg: BookMsg):
- eu mesmo. uest_book[msg.sender] = book_msg
-
- emite Signed(book_msg=book_msg)
-
- pub def get_msg(addr: address) -> BookMsg:
- remeter. uest_book[addr].to_mem()
-
-```
-
-## Como escolher {#how-to-choose}
-
-Como com qualquer outra linguagem de programação, trata-se principalmente de escolher a ferramenta certa para o trabalho certo, assim como preferências pessoais.
-
-Aqui estão algumas coisas a considerar se você ainda não tentou nenhuma das linguagens:
-
-### O que é que há de melhor em Solidity? {#solidity-advantages}
-
-- Se você for um iniciante, há muitos tutoriais e ferramentas de aprendizagem disponíveis. Veja mais sobre isso na seção [Aprenda programando](/developers/learning-tools/).
-- Ótima ferramenta de desenvolvedor disponível.
-- Solidity tem uma grande comunidade de desenvolvedores, o que significa que você provavelmente encontrará respostas para as suas perguntas muito rapidamente.
-
-### O que há de melhor em Vyper? {#vyper-advatages}
-
-- Uma ótima maneira de começar para desenvolvedores de Python que querem escrever contratos inteligentes.
-- O Vyper tem um número menor de características que o torna ótimo para a rápida reprodução de ideias.
-- A Vyper visa ser fácil de controlar e o máximo legível ao ser humano.
-
-### O que é ótimo sobre Yul e Yul+? {#yul-advantages}
-
-- Uma linguagem de baixo nível simples e funcional.
-- Permite aproximar-se muito mais da EVM bruta, o que pode ajudar a otimizar o uso de gás de seus contratos.
-
-## Comparações de linguagens {#language-comparisons}
-
-Para comparações de sintaxe básica, o ciclo de vida do contrato, interfaces, operadores, estruturas de dados, funções, fluxo de controle e mais confira esta [folha de crédito por auditoria](https://reference.auditless.com/cheatsheet/)
-
-## Leitura adicional {#further-reading}
-
-- [Biblioteca de Contratos da Solidity por OpenZeppelin](https://docs.openzeppelin.com/contracts)
-- [Solidity como exemplo](https://solidity-by-example.org)
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
deleted file mode 100644
index 896fd4ed2ef..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: Biblioteca de contratos inteligentes
-description:
-lang: pt-br
----
-
-Você não precisa escrever todos os contratos inteligentes em seu projeto a partir do zero. Há muitas bibliotecas de contratos inteligentes de código aberto disponíveis que fornecem blocos de construção reutilizáveis para o seu projeto que podem evitar que você tenha que reinventar a roda.
-
-## Pré-Requisitos {#prerequisites}
-
-Antes de entrar em bibliotecas de contratos inteligentes, é uma boa ideia ter uma boa compreensão da estrutura de um contrato inteligente. Vá até a [anatomia do contrato inteligente](/developers/docs/smart-contracts/anatomy/) se você ainda não fez isso.
-
-## O que há em uma biblioteca {#whats-in-a-library}
-
-Geralmente, você pode encontrar dois tipos de blocos de construção em bibliotecas de contratos inteligentes: comportamentos reutilizáveis podem ser adicionados aos seus contratos, e a implementação de várias normas.
-
-### Comportamentos {#behaviors}
-
-Ao escrever contratos inteligentes, há uma boa chance de você escrever padrões semelhantes repetidamente, como atribuir um endereço de administrador __ para realizar operações protegidas em um contrato, ou adicionando um botão de emergência _pause_ em caso de um problema inesperado.
-
-As bibliotecas inteligentes de contratos geralmente fornecem implementações reutilizáveis destes comportamentos como [bibliotecas](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) ou via [herança](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) em Solidity.
-
-Como exemplo, a seguir é uma versão simplificada do [`contrato` próprio](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) da [biblioteca de contratos OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts), que concebe um endereço como proprietário de um contrato e fornece um modificador para restringir o acesso a um método apenas para esse proprietário.
-
-```solidity
-contract Ownable {
- address public owner;
-
- constructor() internal {
- owner = msg.sender;
- }
-
- modifier onlyOwner() {
- require(owner == msg.sender, "Ownable: caller is not the owner");
- _;
- }
-}
-```
-
-Para usar um bloco de construção como esse no seu contrato, você precisa primeiro importá-lo, e depois integrá-lo nos seus próprios contratos. Isso permitirá que você use o modificador fornecido pelo contrato base `Ownable` para proteger suas próprias funções.
-
-```solidity
-import ".../Ownable.sol"; // Caminho para a library importada
-
-contract MyContract is Ownable {
- // A seguinte função só pode ser chamada pelo proprietário
- function secured() onlyOwner public {
- msg.sender.transfer(1 ether);
- }
-}
-```
-
-Outro exemplo popular é o [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) ou [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html). Estas são bibliotecas (em oposição aos contratos base) que fornecem as funções aritméticas com verificações de excesso de fluxo, que não são fornecidas pela linguagem. É uma boa prática usar uma dessas bibliotecas em vez de operações aritméticas para proteger seu contrato contra transbordos, que pode ter consequências desastrosas!
-
-### Padrões {#standards}
-
-Para facilitar a [composição e a interoperabilidade](/developers/docs/smart-contracts/composability/), a comunidade Ethereum definiu vários padrões na forma de **ERCs**. Você pode ler mais sobre eles na seção [de padrões](/developers/docs/standards/).
-
-Ao incluir um ERC como parte de seus contratos, É uma boa ideia procurar implementações padrão ao invés de tentar implantar a sua própria. Muitas bibliotecas de contratos inteligentes incluem implementações para os ERC mais populares. Por exemplo, o onipresente [padrão de token fungível lERC20 universal](/developers/tutorials/understand-the-erc-20-token-smart-contract/) pode ser encontrado em [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/) e [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20). Além disso, alguns ERCs também fornecem implementações canônicas como parte do próprio ERC.
-
-Vale a pena mencionar que alguns ERCs não são sozinhos, mas são adições a outros ERCs. Por exemplo, [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) adiciona uma extensão ao ERC20 para melhorar sua usabilidade.
-
-## Como adicionar uma biblioteca {#how-to}
-
-Sempre consulte a documentação da biblioteca que você está incluindo para instruções específicas sobre como incluí-la no seu projeto. Várias bibliotecas de contratos Solidity são empacotadas usando o `npm`, então você pode apenas `npm instale-as`. A maioria das ferramentas para [compilar](/developers/docs/smart-contracts/compiling/) contratos irá analisar os seus `node_modules` para bibliotecas de contratos inteligentes, assim você poderá fazer o seguinte:
-
-```solidity
-// Isto irá carregar a biblioteca @openzeppelin/contracts de seus node_modules
-importe "@openzeppelin/contracts/token/ERC721/ERC721. ol";
-
-contrato MyNFT é ERC721 {
- constructor() ERC721("MyNFT", "MNFT") público { }
-}
-```
-
-Independente do método que você usa, ao incluir uma biblioteca, sempre fique de olho na versão de [linguagem](/developers/docs/smart-contracts/languages/). Por exemplo, não é possível usar uma biblioteca para Solidity 0.6 se você estiver escrevendo seus contratos em Solidity 0.5.
-
-## Quando usar {#when-to-use}
-
-Usar uma biblioteca de contratos inteligente para o seu projeto traz vários benefícios. Em primeiro lugar e acima de tudo, economiza seu tempo fornecendo blocos de construção prontos para usar que você pode incluir no seu sistema, ao invés de ter que programar você mesmo.
-
-A segurança é também um importante ganho. Bibliotecas de contratos inteligentes de código aberto também são frequentemente cuidadosamente controladas. Dado que muitos projectos dependem deles, existe um forte incentivo por parte da comunidade para os manter sob constante revisão. É muito mais comum encontrar erros no código do aplicativo do que em bibliotecas de contratos reutilizáveis. Algumas bibliotecas também são submetidas a [auditorias externas](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) para segurança adicional.
-
-No entanto, o uso de bibliotecas de contratos inteligentes acarreta o risco de incluir código com que você não está familiarizado no seu projeto. É tentador importar um contrato e incluí-lo diretamente no seu projeto, mas sem um bom entendimento do que esse contrato faz, você pode estar inadvertidamente a introduzir um problema no seu sistema devido a um comportamento inesperado. Certifique-se de ler a documentação do código que você está importando, e, em seguida, revise o próprio código antes de torná-lo parte do seu projeto!
-
-Por último, ao decidir se deve incluir uma biblioteca, considere a sua utilização global. Uma comunidade amplamente adoptada tem os benefícios de ter uma comunidade mais vasta e de olhar para ela com mais olhos para as questões. A segurança deve ser seu foco principal ao construir com contratos inteligentes!
-
-## Ferramentas relacionadas {#related-tools}
-
-**OpenZeppelin Contracts -** **_Biblioteca para o desenvolvimento de contratos inteligentes seguros._**
-
-- [Documentação](https://docs.openzeppelin.com/contracts/)
-- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
-- [Fórum da Comunidade](https://forum.openzeppelin.com/c/general/16)
-
-**DappSys -** **_Blocos de código seguros, simples e flexíveis para contratos inteligentes._**
-
-- [Documentação](https://dappsys.readthedocs.io/)
-- [GitHub](https://github.com/dapphub/dappsys)
-
-**HQ20 -** **_Um projeto Solidity com contratos, bibliotecas e exemplos para ajudá-lo a construir aplicações distribuídas completas para o mundo real._**
-
-- [GitHub](https://github.com/HQ20/contracts)
-
-**thirdweb Solidity SDK -** **_Fornece as ferramentas necessárias para criar contratos inteligentes e personalizados com eficiência_**
-
-- [Documentação](https://portal.thirdweb.com/solidity/)
-- [GitHub](https://github.com/thirdweb-dev/contracts)
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Considerações de segurança para os desenvolvedores da Ethereum](/developers/docs/smart-contracts/security/) _– Um tutorial sobre considerações de segurança ao criar contratos inteligentes, incluindo o uso da biblioteca._
-- [Entenda o contrato inteligente de token ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _-Tutorial no padrão ERC20, fornecido por várias bibliotecas._
-
-## Leitura adicional {#further-reading}
-
-_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_
diff --git "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" "b/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
deleted file mode 100644
index 60c7f38b6cb..00000000000
--- "a/public/content/translations/pt-br/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
+++ /dev/null
@@ -1,580 +0,0 @@
----
-title: Segurança de um Contrato Inteligente
-description: Uma visão geral das diretrizes para a construção segura de contratos inteligentes na Ethereum
-lang: pt-br
----
-
-Os contratos inteligentes são extremamente flexíveis e capazes de controlar grandes quantidades de valor e dados, enquanto executam lógica imutável com base no código implantado na blockchain. Isto criou um vibrante ecossistema de aplicações descentralizadas e sem confiança que oferecem muitas vantagens sobre os sistemas legados. Eles também representam oportunidades para os invasores que procuram lucrar explorando vulnerabilidades em contratos inteligentes.
-
-Blockchains públicas, como a Ethereum, complicam ainda mais a questão de proteger contratos inteligentes. O código de contrato implantado _geralmente_ não pode ser alterado para corrigir falhas de segurança, enquanto os ativos roubados de contratos inteligentes são extremamente difíceis de rastrear e, em sua maioria, irrecuperáveis devido à imutabilidade.
-
-Embora os números variem, estima-se que o valor total roubado ou perdido devido a defeitos de segurança em contratos inteligentes é facilmente superior a 1 bilhão de dólares. Isso inclui incidentes de alto perfil, como o [DAO hack](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (com 3,6 milhões de ETH roubados, no valor de mais de US$ 1 bilhão de dólares nos preços de hoje), [ Hack da carteira múltiplas assinaturas da Parity ](https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach) (US$ 30 milhões perdidos para hackers) e o [ Caso da carteira congelada da Parity](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (mais de US$ 300 milhões em ETH bloqueados para sempre).
-
-As questões mencionadas tornam imperativo para os desenvolvedores investirem esforços na construção de contratos inteligentes seguros, sólidos e resistentes. Segurança dos contratos inteligentes é um assunto sério, e todo desenvolvedor deve aprender. Este guia abrangerá considerações de segurança para desenvolvedores de Ethereum e explorará recursos para melhorar a segurança dos contratos inteligentes.
-
-## Pré-requisitos {#prerequisites}
-
-Certifique-se de estar familiarizado com os [fundamentos do desenvolvimento de contratos inteligentes](/developers/docs/smart-contracts/) antes de abordar a segurança.
-
-## Diretrizes para construir contratos inteligentes Ethereum seguros {#smart-contract-security-guidelines}
-
-### 1. Crie controles de acesso adequados {#design-proper-access-controls}
-
-Em contratos inteligentes, funções marcadas `públicas` ou `externas` podem ser chamadas por quaisquer contas externas (EOAs) ou contas de contrato. Especificar a visibilidade pública para funções é necessária se você quiser que outras pessoas interajam com seu contrato. As funções marcadas como `privadas`, no entanto, só podem ser chamadas por funções dentro do contrato inteligente e não por contas externas. Dar a cada participantes da rede o acesso às funções do contrato pode causar problemas, especialmente se isso significar que qualquer pessoa pode realizar operações confidenciais (por exemplo, cunhar novos tokens).
-
-Para evitar o uso não autorizado de funções do contrato inteligente, é necessário implementar controles de acesso seguros. Os mecanismos de controle de acesso restringem a capacidade de usar determinadas funções em um contrato inteligente para entidades aprovadas, como contas responsáveis pelo gerenciamento do contrato. O **padrão de propriedade** e o **controle baseado em funções** são dois padrões úteis para implementar o controle de acesso em contratos inteligentes:
-
-#### Padrão proprietário {#ownable-pattern}
-
-No padrão Proprietário, um endereço é definido como o “dono” do contrato durante o processo de criação do contrato. As funções protegidas são atribuídas a um modificador `OnlyOwner`, que garante que o contrato autentique a identidade do endereço de chamada antes de executar a função. Chamadas para funções protegidas de outros endereços além do proprietário do contrato sempre revertem, impedindo o acesso indesejado.
-
-#### Controle de acesso baseado em funções {#role-based-access-control}
-
-Registrar um único endereço como `Proprietário` em um contrato inteligente apresenta o risco de centralização e representa um único ponto de falha. Se as chaves da conta do proprietário forem comprometidas, os invasores podem invadir o contrato de propriedade. É por isso que usar um padrão de controle de acesso baseado em funções com várias contas administrativas pode ser uma opção melhor.
-
-No controle de acesso baseado em funções, o acesso a funções confidenciais é distribuído entre um conjunto de participantes confiáveis. Por exemplo, uma conta pode ser responsável por cunhar tokens (transformar um ativo digital na blockchain), enquanto outra conta realiza atualizações ou pausa o contrato. Descentralizar o controle de acesso dessa forma elimina pontos únicos de falha e reduz as suposições de confiança para os usuários.
-
-##### Usando carteiras multi-assinatura
-
-Outra abordagem para implementar controle seguro de acesso é usar uma [conta de múltiplas assinaturas](/developers/docs/smart-contracts/#multisig) para gerenciar um contrato. Ao contrário de um EOA (conta de propriedade externa) regular, as contas com várias assinaturas são de propriedade de várias entidades e exigem assinaturas de um número mínimo de contas - digamos 3 de 5 - para executar transações.
-
-O uso de multisig (múltiplas assinaturas) para controle de acesso introduz uma camada extra de segurança, pois as ações no contrato de destino exigem o consentimento de várias partes. Isso é particularmente útil se usar o padrão Proprietário, pois torna mais difícil para um invasor ou malfeitor interno de manipular funções de contrato confidenciais para fins maliciosos.
-
-### 2. Use as instruções require(), assert() e revert() para proteger as operações do contrato {#use-require-assert-revert}
-
-Como mencionado, qualquer pessoa pode chamar funções públicas em seu contrato inteligente uma vez que ele é implantado na blockchain. Como você não pode saber com antecedência como as contas externas (EOA) vão interagir com um contrato, é ideal implementar proteções internas contra operações problemáticas antes da implantação. Você pode aplicar o comportamento correto nos contratos inteligentes usando as instruções `require()`, `assert()` e `revert()` para acionar exceções e reverter mudanças de estado se a execução não satisfazer determinados requisitos.
-
-**`require()`**: `require` são definidas no início das funções e garantem condições predefinidas antes que a função chamada seja executada. Uma instrução `require` pode ser usada para validar entradas do usuário, verificar variáveis de estado ou autenticar a identidade da conta de chamada antes de prosseguir com uma função.
-
-**`assert()`**: `assert()` é usado para detectar erros internos e verificar por violações de "invariáveis" em seu código. Uma invariável é uma asserção lógica sobre o estado de um contrato que deve ser verdadeira para todas as execuções de função. Um exemplo invariável é a oferta total máxima ou saldo de um contrato de token. O uso do `assert()` garante que seu contrato nunca atinja um estado vulnerável e, se isso acontecer, todas as mudanças nas variáveis de estado serão revertidas.
-
-**`revert()`**: `revert()` pode ser usado em uma instrução if-else (se-senão) que aciona uma exceção se a condição exigida não for satisfeita. O modelo de contrato abaixo usa o `revert()` para proteger a execução de funções:
-
-```
-pragma solidity ^0.8.4;
-
-contract VendingMachine {
- address owner;
- error Unauthorized();
- function buy(uint amount) public payable {
- if (amount > msg.value / 2 ether)
- revert("Not enough Ether provided.");
- // Perform the purchase.
- }
- function withdraw() public {
- if (msg.sender != owner)
- revert Unauthorized();
-
- payable(msg.sender).transfer(address(this).balance);
- }
-}
-```
-
-### 3. Teste contratos inteligentes e verifique a corretude do código {#test-smart-contracts-and-verify-code-correctness}
-
-A imutabilidade do código em execução na [Máquina Virtual Ethereum](/developers/docs/evm/) significa que os contratos inteligentes demandam um nível mais alto de avaliação de qualidade durante a fase de desenvolvimento. Testar seu contrato extensivamente e observá-lo para quaisquer resultados inesperados irão melhorar muito a segurança e proteger os seus usuários a longo prazo.
-
-O método habitual é escrever pequenos testes unitários utilizando dados simulados que o contrato deverá receber dos usuários. O [teste unitário](/developers/docs/smart-contracts/testing/#unit-testing) é bom para testar a funcionalidade de determinadas funções e garantir que um contrato inteligente funcione como esperado.
-
-Infelizmente, o teste unitário é minimamente eficaz para melhorar a segurança do contrato inteligente quando usado isoladamente. Um teste unitário pode provar que uma função é executada corretamente para dados simulados (mock), mas os testes unitários são tão eficazes quanto os testes que são escritos. Isso torna difícil detectar casos perdidos de falha e vulnerabilidades que poderiam quebrar a segurança de seu contrato inteligente.
-
-Uma abordagem melhor é combinar testes unitários com testes baseados em propriedades realizados usando [análise estática e dinâmica](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) (do código). A análise estática depende de representações de baixo nível, como [controlar fluxo de controle](https://en.wikipedia.org/wiki/Control-flow_graph) e [árvores de sintaxe abstrata](https:// deepsource.io/glossary/ast/) para analisar estados de programas alcançáveis e caminhos de execução. Enquanto isso, as técnicas de análise dinâmica, como [fuzzing de contrato inteligente](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry), executam o código do contrato com valores de entrada aleatórios para detectar operações que violam as propriedades de segurança.
-
-A [Verificação Formal](/developers/docs/smart-contracts/formal-verification) é outra técnica para verificar propriedades de segurança em contratos inteligentes. Ao contrário dos testes regulares, a verificação formal pode comprovar conclusivamente a ausência de erros em um contrato inteligente. Isso é alcançado criando uma especificação formal que captura as propriedades de segurança desejadas e provando que um modelo formal dos contratos adere a esta especificação.
-
-### 4. Peça uma revisão independente do seu código {#get-independent-code-reviews}
-
-Depois de testar seu contrato, é bom pedir aos outros que verifiquem o código-fonte para quaisquer problemas de segurança. O teste não revelará todas as falhas de um contrato inteligente, mas realizar uma revisão independente aumenta a possibilidade de detectar vulnerabilidades.
-
-#### Auditorias {#audits}
-
-A comissão de uma auditoria de contrato inteligente é uma forma de realizar uma revisão de código independente. Os auditores desempenham um papel importante na garantia de que os contratos inteligentes sejam seguros e livres de falhas de qualidade e erros de concepção.
-
-Com isto em mente, há que evitar tratar as auditorias como uma bala de prata. Auditorias de contratos inteligentes não irão detectar todos os bugs e são concebidas principalmente para fornecer uma rodada adicional de revisões, o qual pode ajudar a detectar problemas perdidos pelos desenvolvedores durante o desenvolvimento e testes iniciais. Você também deve seguir as práticas recomendadas para trabalhar com auditores, como documentar o código apropriadamente e adicionar comentários em linha, para maximizar o benefício de uma auditoria de contrato inteligente.
-
-- [Dicas e sugestões para a auditoria de contratos inteligentes](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_
-- [Aproveite ao máximo sua auditoria](https://inference.ag/blog/2023-08-14-tips/) - _Inferência_
-
-#### Recompensa por bugs {#bug-bounties}
-
-A criação de um programa de recompensas por bugs é outra abordagem para implementar revisões de código externas. Uma recompensa por bugs é uma recompensa financeira dada a indivíduos (geralmente hackers de chapéu branco) que descobrem vulnerabilidades em um aplicativo.
-
-Quando usadas corretamente, as recompensas por bugs dão aos membros da comunidade hacker incentivo para inspecionar seu código em busca de falhas críticas. Um exemplo da vida real é o “bug do dinheiro infinito” que teria deixado um invasor criar uma quantidade ilimitada de Ether no [Optimism](https://www.optimism.io/), um protocolo da [Camada 2](/layer-2/) em execução na Ethereum. Felizmente, um hacker de chapéu branco [descobriu a falha](https://www.saurik.com/optimism.html) e notificou a equipe, [ganhando um grande pagamento no processo](https://cryptoslate.com/ critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/).
-
-Uma estratégia útil é definir o pagamento de um programa de recompensas por bugs proporcionalmente à quantidade de fundos em jogo. Descrita como a “[recompensa por bugs que escala](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)”, essa abordagem fornece incentivos financeiros para que os indivíduos revelem vulnerabilidades de forma responsável em vez de explorá-las.
-
-### 5. Siga as melhores práticas durante o desenvolvimento de contratos inteligentes {#follow-smart-contract-development-best-practices}
-
-A existência de auditorias e recompensas por bugs não dispensa sua responsabilidade de escrever código de alta qualidade. Uma boa segurança em contrato inteligente começa com os seguintes processos de concepção e desenvolvimento adequados:
-
-- Guarde todo o código em um sistema de controle de versão, como git
-
-- Faça todas as modificações de código por meio de solicitações de pull (conhecido como pull request, da sigla PR)
-
-- Garanta que as solicitações de pull (PR) tenham pelo menos um revisor independente - se você estiver trabalhando sozinho(a) em um projeto, considere encontrar outros desenvolvedores e negociar revisões de código
-
-- Use um [ambiente de desenvolvimento](/developers/docs/frameworks/) para testar, compilar e implantar contratos inteligentes
-
-- Execute seu código por meio de ferramentas básicas de análise de código, como [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn), Mythril e Slither. Idealmente, você deve fazer isso antes de cada solicitação de pull ser mesclado (merge) e comparar as diferenças na saída
-
-- Garanta que seu código seja compilado sem erros e que o compilador Solidity não emita alertas
-
-- Documente seu código adequadamente (usando [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)) e descreva detalhes sobre a arquitetura do contrato em linguagem fácil de entender. Isso facilitará para outras pessoas auditarem e revisarem seu código.
-
-### 6. Implemente planos robustos de recuperação de desastres {#implement-disaster-recovery-plans}
-
-Conceber controles de acesso seguros, implementar modificadores de função e outras sugestões podem melhorar a segurança do contrato inteligente, mas não podem excluir a possibilidade de explorações maliciosas. Construir contratos inteligentes seguros requer “preparar-se para falhas” e ter um plano de retorno para responder de forma eficaz a ataques. Um plano de recuperação de desastres adequado incorporará alguns ou todos os seguintes componentes:
-
-#### Atualizações de contrato {#contract-upgrades}
-
-Embora os contratos inteligentes Ethereum sejam imutáveis por padrão, é possível alcançar algum grau de mutabilidade usando padrões de atualização. A atualização de contratos é necessária nos casos em que uma falha crítica torna seu contrato antigo inutilizável e a implantação de uma nova lógica é a opção mais viável.
-
-Os mecanismos de atualização de contrato funcionam de forma diferente, mas o “padrão de proxy” é uma das abordagens mais populares para atualizar contratos inteligentes. [Os padrões de proxy](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) dividem o estado e a lógica de um aplicativo entre _dois_ contratos. O primeiro contrato (chamado de 'contrato de proxy') armazena variáveis de estado (por exemplo, saldos de usuários), enquanto o segundo contrato (chamado de 'contrato lógico') contém o código para executar funções de contrato.
-
-As contas interagem com o contrato de proxy, que despacha todas as chamadas de função para o contrato lógico usando o [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight =delegatecall#delegatecall-callcode-and-libraries) em chamada de baixo nível. Ao contrário de uma chamada de mensagem normal, o `delegatecall()` garante que o código executado no endereço do contrato lógico seja executado no contexto do contrato de chamada. Isso significa que o contrato lógico sempre escreverá no armazenamento do proxy (em vez de em seu próprio armazenamento) e os valores originais de `msg.sender` e `msg.value` são preservados.
-
-Delegar chamadas para o contrato lógico requer armazenar seu endereço no armazenamento do contrato de proxy. Portanto, atualizar a lógica do contrato é apenas uma questão de implantar outro contrato lógico e armazenar o novo endereço no contrato de proxy. Como as chamadas subsequentes para o contrato de proxy são roteadas automaticamente para o novo contrato lógico, você teria “atualizado” o contrato sem realmente modificar o código.
-
-[Mais sobre atualização de contratos](/developers/docs/smart-contracts/upgrading/).
-
-#### Interrupções de emergência {#emergency-stops}
-
-Como mencionado, auditorias e testes extensivos não podem descobrir todos os bugs em um contrato inteligente. Se uma vulnerabilidade aparecer em seu código após a implantação, corrigi-la é impossível, pois você não pode alterar o código em execução no endereço do contrato. Além disso, mecanismos de atualização (por exemplo, padrões de proxy) podem levar tempo para serem implementados (eles geralmente exigem aprovação de diferentes partes), o que só dá aos invasores mais tempo para causar mais danos.
-
-A opção nuclear é implementar uma função de “interrupção de emergência” que bloqueia chamadas para funções vulneráveis em um contrato. As interrupções ou paradas de emergência normalmente compreendem os seguintes componentes:
-
-1. Uma variável global booleana indicando se o contrato inteligente está em um estado interrompido ou não. Esta variável é definida como `false` ao criar o contrato, mas reverterá para `true` assim que o contrato for interrompido.
-
-2. Funções que referenciam a variável booleana em sua execução. Essas funções são acessíveis quando o contrato inteligente não é interrompido e tornam-se inacessíveis quando o recurso da interrupção de emergência é acionado.
-
-3. Uma entidade que tem acesso à função da interrupção de emergência, que define a variável booleana como `true`. Para evitar ações maliciosas, as chamadas para essa função podem ser restritas a um endereço confiável (por exemplo, o proprietário do contrato).
-
-Uma vez que o contrato ative a parada ou interrupção de emergência, determinadas funções não poderão ser chamadas. Isso é alcançado envolvendo funções de seleção em um modificador que faz referência à variável global. Veja abaixo [um exemplo](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) que descreve uma implementação desse padrão em contratos:
-
-```solidity
-// Este código não foi auditado profissionalmente e não faz promessas sobre sua segurança ou correção. Use por sua conta e risco.
-
-contract EmergencyStop {
-
- bool isStopped = false;
-
- modifier stoppedInEmergency {
- require(!isStopped);
- _;
- }
-
- modifier onlyWhenStopped {
- require(isStopped);
- _;
- }
-
- modifier onlyAuthorized {
- // Check for authorization of msg.sender here
- _;
- }
-
- function stopContract() public onlyAuthorized {
- isStopped = true;
- }
-
- function resumeContract() public onlyAuthorized {
- isStopped = false;
- }
-
- function deposit() public payable stoppedInEmergency {
- // Deposit logic happening here
- }
-
- function emergencyWithdraw() public onlyWhenStopped {
- // Emergency withdraw happening here
- }
-}
-```
-
-Este exemplo mostra as características básicas das interrupções de emergência:
-
-- `isStopped` é um booleano avaliado como `false` no início e `true` quando o contrato entra no modo de emergência.
-
-- Os modificadores de função `onlyWhenStopped` e `stoppedInEmergency` verificam a variável `isStopped`. `stoppedInEmergency` é usado para controlar funções que devem ser inacessíveis quando o contrato é vulnerável (por exemplo, `deposit()`). As chamadas para essas funções simplesmente serão revertidas.
-
-`onlyWhenStopped` é usado para funções que devem ser chamadas durante uma emergência (por exemplo, `emergencyWithdraw()`). Essas funções podem ajudar a resolver a situação, daí a sua exclusão da lista de “funções restritas”.
-
-Usar uma funcionalidade de interrupção de emergência fornece um paliativo eficaz para lidar com vulnerabilidades graves em seu contrato inteligente. No entanto, aumenta a necessidade dos usuários confiarem nos desenvolvedores para não ativá-lo por razões egoístas. Para este fim, descentralizar o controle da interrupção de emergência sujeitando-o a um mecanismo de votação on-chain, timelock (bloqueio de tempo para transações) ou aprovação de uma carteira de assinatura múltipla são soluções possíveis.
-
-#### Monitoramento de eventos {#event-monitoring}
-
-[Eventos](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) permitem rastrear chamadas para funções de contrato inteligente e monitorar mudanças em variáveis de estado. É ideal programar seu contrato inteligente para emitir um evento sempre que alguma parte tomar uma ação crítica de segurança (por exemplo, retirar fundos).
-
-Registrar eventos e monitorá-los off-chain fornece informações sobre as operações do contrato e auxilia na descoberta mais rápida de ações maliciosas. Isso significa que sua equipe pode responder mais rapidamente a hacks e tomar medidas para mitigar o impacto sobre os usuários, como pausar funções ou realizar uma atualização.
-
-Você também pode optar por uma ferramenta de monitoramento pronta para uso, que encaminha alertas automaticamente, sempre que alguém interage com seus contratos. Essas ferramentas permitirão que você crie alertas personalizados com base em diferentes gatilhos, como volume de transações, frequência de chamadas de função ou funções específicas envolvidas. Por exemplo, você poderia programar um alerta que chega quando a quantia retirada em uma única transação ultrapassa determinado limite.
-
-### 7. Projete sistemas de governança seguros {#design-secure-governance-systems}
-
-Você pode querer descentralizar sua aplicação, transferindo o controle dos principais contratos inteligentes para os membros da comunidade. Nesse caso, o sistema de contrato inteligente incluirá um módulo de governança - um mecanismo que permite que os membros da comunidade aprovem ações administrativas, por meio de um sistema de governança on-chain. Por exemplo, uma proposta para atualizar um contrato de proxy para uma nova implementação, que pode ser votada pelos detentores do token.
-
-A governança descentralizada pode ser benéfica, especialmente porque alinha os interesses dos desenvolvedores e usuários finais. No entanto, os mecanismos de governança de contratos inteligentes podem apresentar novos riscos se implementados incorretamente. Um cenário plausível é se um invasor adquirir um enorme poder de voto (medido em número de tokens mantidos) ao fazer um [empréstimo imediato](/defi/#flash-loans) e enviar uma proposta maliciosa.
-
-Uma maneira de evitar problemas relacionados à governança on-chain é [usar um timelock](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/). Um timelock impede que um contrato inteligente execute certas ações até que um período específico passe. Outras estratégias incluem atribuir um “peso de voto” a cada token com base em quanto tempo ele foi bloqueado ou medir o poder de voto de um endereço em um período histórico (por exemplo, 2-3 blocos no passado) em vez do bloco atual. Ambos os métodos reduzem a possibilidade de acumular rapidamente o poder de voto para oscilar os votos on-chain.
-
-Mais sobre [como projetar sistemas de governança seguros](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [diferentes mecanismos de votação em DAOs](https://hackernoon.com/governance-is-the-holy-grail-for-daos) e [os vetores comuns de ataque de DAO que usam DeFi](https://dacian.me/dao-governance-defi-attacks) nos links compartilhados.
-
-### 8. Reduza a complexidade do código ao mínimo {#reduce-code-complexity}
-
-Os desenvolvedores de software tradicionais estão familiarizados com o princípio KISS (“Não complique, estúpido!”), o qual aconselha a não introdução complexidade desnecessária na concepção de software. Isso segue o pensamento de longa data, de que “sistemas complexos falham de maneiras complexas” e são mais suscetíveis a erros dispendiosos.
-
-Não complicar é de particular importância ao escrever contratos inteligentes, visto que os contratos inteligentes estão potencialmente controlando grandes quantidades de valor. Uma dica para descomplicar ao escrever contratos inteligentes é reutilizar bibliotecas existentes, como [Contratos OpenZeppelin](https://docs.openzeppelin.com/contracts/4.x/), sempre que possível. Como essas bibliotecas foram extensivamente auditadas e testadas pelos desenvolvedores, usá-las reduz as chances de introduzir bugs ao escrever novas funcionalidades do zero.
-
-Outro conselho comum é escrever funções pequenas e manter contratos modulares, dividindo a lógica do negócio por vários contratos. Não só escrever um código simples reduz a superfície de ataque em um contrato inteligente, também facilita argumentar sobre a exatidão do sistema por inteiro e detectar possíveis erros de concepção mais cedo.
-
-### 9. Defenda-se contra vulnerabilidades comuns de contratos inteligentes {#mitigate-common-smart-contract-vulnerabilities}
-
-#### Reentrância {#reentrancy}
-
-A EVM (Ethereum Virtual Machine) não permite concorrência (paralelismo), o que significa que dois contratos envolvidos em uma chamada de mensagem não podem ser executados simultaneamente. Uma chamada externa pausa a execução e a memória do contrato de chamada até que a chamada retorne, momento em que a execução prossegue normalmente. Esse processo pode ser formalmente descrito como a transferência do [fluxo de controle](https://www.computerhope.com/jargon/c/contflow.htm) para outro contrato.
-
-Embora a maioria seja inofensiva, a transferência de fluxo de controle para contratos não confiáveis pode causar problemas, tais como a reentrância. Um ataque de reentrância ocorre quando um contrato malicioso volta a chamar um contrato vulnerável antes que a invocação da função original ser completa. Este tipo de ataque é melhor explicado com um exemplo.
-
-Considere um contrato inteligente simples ('Vítima') que permite que qualquer pessoa depositar e retirar Ether:
-
-```solidity
-// This contract is vulnerable. Do not use in production
-
-contract Victim {
- mapping (address => uint256) public balances;
-
- function deposit() external payable {
- balances[msg.sender] += msg.value;
- }
-
- function withdraw() external {
- uint256 amount = balances[msg.sender];
- (bool success, ) = msg.sender.call.value(amount)("");
- require(success);
- balances[msg.sender] = 0;
- }
-}
-```
-
-Este contrato expõe uma função `withdraw()` para permitir que os usuários retirem ETH previamente depositados no contrato. Ao processar uma retirada, o contrato realiza as seguintes operações:
-
-1. Verifica o saldo de ETH do usuário
-2. Envia fundos para o endereço de chamada
-3. Redefine seu saldo para 0, evitando saques adicionais do usuário
-
-A função `withdraw()` no contrato `Victim` segue um padrão "verificações-efeitos-interações". Ela _verifica_ se as condições necessárias para a execução são atendidas (ou seja, o usuário tem um saldo ETH positivo) e realiza a _interação_ enviando ETH para o endereço do chamador, antes de aplicar os _efeitos_ da transação (ou seja, reduzir o saldo do usuário).
-
-Se `withdraw()` for chamado de uma conta de propriedade externa (EOA), a função será executada conforme o esperado: `msg.sender.call.value()` envia ETH para o chamador. Contudo, se `msg.sender` é uma conta de contrato inteligente que chama `withdraw()`, o envio de fundos usando `msg.sender.call.value()` também acionará o código armazenado naquele endereço para ser executado.
-
-Imagine que este é o código implantado no endereço do contrato:
-
-```solidity
- contract Attacker {
- function beginAttack() external payable {
- Victim(victim_address).deposit.value(1 ether)();
- Victim(victim_address).withdraw();
- }
-
- function() external payable {
- if (gasleft() > 40000) {
- Victim(victim_address).withdraw();
- }
- }
-}
-```
-
-Este contrato foi concebido para fazer três coisas:
-
-1. Aceite um depósito de outra conta (provavelmente o EOA do atacante)
-2. Deposite 1 ETH no contrato Victim
-3. Retire o 1 ETH armazenado no contrato inteligente
-
-Não há nada de errado aqui, exceto que o `Attacker` tem outra função que chama `withdraw()` em `Victim` novamente se, o gás restante de entrada do `msg.sender.call.value` for superior a 40.000. Isso dá ao `Invasor` a capacidade de reentrar em `Victim` e retirar mais fundos _antes_ da primeira invocação de `withdraw` concluir. O ciclo fica assim:
-
-```solidity
-- EOA do invasor chama `Attacker.beginAttack()` com 1 ETH
-- `Attacker.beginAttack()` deposita 1 ETH em `Victim`
-- `Attacker` chama `withdraw() em `Victim`
-- `Victim` verifica o saldo do `Attacker` (1 ETH)
-- `Victim` envia 1 ETH para o `Attacker` (que aciona a função padrão)
-- `Attacker` chama `Victim.withdraw()` novamente (observe que `Victim` não reduziu o saldo do `Attacker` desde a primeira retirada)
-- `Victim` verifica o saldo do `Attacker` (que ainda é 1 ETH porque não tem aplicado os efeitos da primeira chamada)
-- `Victim` envia 1 ETH para `Attacker` (que aciona a função padrão e permite que `Attacker` entre novamente na função `withdraw`)
-- O processo se repete até que `Attacker` fique sem gás, ponto em que `msg.sender.call.value` retorna sem acionar retiradas adicionais
-- `Victim` finalmente aplica os resultados da primeira transação (e as subsequentes) ao seu estado, então o saldo do `Attacker` é definido para 0 (zero)
-```
-
-O resumo é que, como o saldo do chamador não é definido como 0 até que a execução da função termine, as invocações subsequentes serão bem-sucedidas e permitirão que o chamador retire seu saldo várias vezes. Esse tipo de ataque pode ser usado para drenar um contrato inteligente de seus fundos, como aconteceu no [DAO hack em 2016](https://www.coindesk.com/learn/2016/06/25/understanding-the-dao- attack/). Os ataques de reentrância ainda são um problema crítico para contratos inteligentes hoje, como mostram as[listagens públicas de exploits de reentrância](https://github.com/pcaversaccio/reentrancy-attacks).
-
-##### Como prevenir ataques de reentrância
-
-Uma abordagem para lidar com a reentrância é seguir o [padrão de verificações-efeitos-interações](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern). Este padrão ordena a execução de funções de forma que o código que realiza as verificações necessárias antes de prosseguir com a execução chegar primeiro, seguido pelo código que manipula o estado do contrato, com o código que interage com outros contratos ou EOAs chegando por último.
-
-O padrão verificação-efeito-interação é usado em uma versão revisada do contrato `Victim` mostrado abaixo:
-
-```solidity
-contract NoLongerAVictim {
- function withdraw() external {
- uint256 amount = balances[msg.sender];
- balances[msg.sender] = 0;
- (bool success, ) = msg.sender.call.value(amount)("");
- require(success);
- }
-}
-```
-
-Este contrato realiza uma _verificação_ do saldo do usuário, aplica os _efeitos_ da função `withdraw()` (redefinindo o saldo do usuário para 0, zero), e passa a realizar a _interação_ (enviando ETH para o endereço do usuário). Isso garante que o contrato atualize seu armazenamento antes da chamada externa, eliminando a condição de reentrância que permitiu o primeiro ataque. O contrato `Attacker` ainda poderia chamar de volta para `NoLongerAVictim`, mas como `balances[msg.sender]` foi definido como 0 (zero), retiradas adicionais gerarão um erro.
-
-Outra opção é usar um bloqueio de exclusão mútua (comumente descrito como "mutex") que bloqueia uma porção do estado de um contrato até que a invocação de uma função seja concluída. Isso é implementado usando uma variável booleana que é definida como `true` antes da execução da função e revertida para `false` após a chamada ser finalizada. Como visto no exemplo abaixo, usar um mutex protege uma função contra chamadas recursivas enquanto a invocação original ainda está sendo processada, efetivamente interrompendo a reentrada.
-
-```solidity
-pragma solidity ^0.7.0;
-
-contract MutexPattern {
- bool locked = false;
- mapping(address => uint256) public balances;
-
- modifier noReentrancy() {
- require(!locked, "Blocked from reentrancy.");
- locked = true;
- _;
- locked = false;
- }
- // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again.
- // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier
- function withdraw(uint _amount) public payable noReentrancy returns(bool) {
- require(balances[msg.sender] >= _amount, "No balance to withdraw.");
-
- balances[msg.sender] -= _amount;
- bool (success, ) = msg.sender.call{value: _amount}("");
- require(success);
-
- return true;
- }
-}
-```
-
-Você também pode usar um sistema de [receber pagamentos](https://docs.openzeppelin.com/contracts/4.x/api/security#PullPayment), que exige que os usuários retirem fundos dos contratos inteligentes, em vez de um sistema de "envio de pagamentos" que envia fundos para contas. Isso elimina a possibilidade de acionar código inadvertidamente em endereços desconhecidos (e também pode impedir determinados ataques de negação de serviço).
-
-#### Overflows e underflows em inteiro {#integer-underflows-and-overflows}
-
-Um extravasamento (overflow) de números inteiros ocorre quando os resultados de uma operação aritmética ficam fora do intervalo aceitável de valores, fazendo com que ela "role" para o menor valor representável. Por exemplo, um `uint8` só pode armazenar valores até 2^8-1 = 255. Operações aritméticas que resultam em valores superiores a `255` irão extravasar e redefinir `uint` para `0`, semelhante a como o odômetro em um carro é redefinido para 0 uma vez que atinge a quilometragem máxima (999999).
-
-Os extravasamentos negativos (underflows) de números inteiros acontecem por motivos semelhantes: os resultados de uma operação aritmética ficam abaixo do intervalo aceitável. Digamos que você tentou decrementar `0` em um `uint8`, o resultado simplesmente passaria para o valor máximo representável (`255`).
-
-Tanto overflows quanto underflows de inteiros podem levar a mudanças inesperadas nas variáveis de estado de um contrato e resultar em execução não planejada. Veja abaixo um exemplo mostrando como um invasor pode explorar o extravasamento aritmético em um contrato inteligente para executar uma operação inválida:
-
-```
-pragma solidity ^0.7.6;
-
-// Este contrato foi projetado para atuar como um cofre no tempo.
-// O usuário pode depositar neste contrato, mas não pode retirar por pelo menos uma semana.
-// O usuário também pode estender o tempo de espera além do período estipulado de 1 semana.
-
-/*
-1. Implantar TimeLock
-2. Ataque de Implantação com endereço do TimeLock
-3. Chame Attack.attack enviando 1 ether. Você imediatamente será capaz de
- retirar seu ether.
-
-O que aconteceu?
-O ataque causou o extravasamento do TimeLock.lockTime e foi capaz de retirar
-antes do período de espera de 1 semana.
-*/
-
-contract TimeLock {
- mapping(address => uint) public balances;
- mapping(address => uint) public lockTime;
-
- function deposit() external payable {
- balances[msg.sender] += msg.value;
- lockTime[msg.sender] = block.timestamp + 1 weeks;
- }
-
- function increaseLockTime(uint _secondsToIncrease) public {
- lockTime[msg.sender] += _secondsToIncrease;
- }
-
- function withdraw() public {
- require(balances[msg.sender] > 0, "Insufficient funds");
- require(block.timestamp > lockTime[msg.sender], "Lock time not expired");
-
- uint amount = balances[msg.sender];
- balances[msg.sender] = 0;
-
- (bool sent, ) = msg.sender.call{value: amount}("");
- require(sent, "Failed to send Ether");
- }
-}
-
-contract Attack {
- TimeLock timeLock;
-
- constructor(TimeLock _timeLock) {
- timeLock = TimeLock(_timeLock);
- }
-
- fallback() external payable {}
-
- function attack() public payable {
- timeLock.deposit{value: msg.value}();
- /*
- if t = current lock time then we need to find x such that
- x + t = 2**256 = 0
- so x = -t
- 2**256 = type(uint).max + 1
- so x = type(uint).max + 1 - t
- */
- timeLock.increaseLockTime(
- type(uint).max + 1 - timeLock.lockTime(address(this))
- );
- timeLock.withdraw();
- }
-}
-```
-
-##### Como evitar overflows e underflows de números inteiros
-
-A partir da versão 0.8.0, o compilador Solidity rejeita código que resulta em underflows e overflows de números inteiros. No entanto, contratos compilados com uma versão inferior do compilador devem ou realizar verificações sobre funções que envolvem operações aritméticas ou usar uma biblioteca (e.., [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) que verifica se há underflow/overflow (extravasamentos negativos/extravasamentos).
-
-#### Manipulação de oráculos {#oracle-manipulation}
-
-Os [Oráculos](/developers/docs/oracles/) fornecem informações off-chain (fora da blockchain) e as enviam on-chain (dentro da blockchain) para uso em contratos inteligentes. Com oráculos, você pode conceber contratos inteligentes que interoperam com sistemas off-chain, como mercados de capitais, expandindo muito sua aplicação.
-
-Mas se o oráculo estiver corrompido e enviar informações incorretas on-chain, contratos inteligentes serão executados com base em entradas erradas, o que pode causar problemas. Essa é a base do “problema do oráculo” (paradoxo), que diz respeito à tarefa de garantir que as informações de um oráculo da blockchain sejam precisas, atualizadas e pontuais.
-
-Uma preocupação de segurança relacionada está usando um oráculo on-chain, como uma troca descentralizada, para obter o preço de ponto por um ativo. Plataformas de empréstimos no setor de [finanças descentralizadas (DeFi)](/defi/) frequentemente fazem isso para determinar o valor da garantia de um usuário para determinar quanto eles podem emprestar.
-
-Os preços dos DEX são muitas vezes exatos, em grande parte devido aos árbitros que restauram a paridade nos mercados. Porém, eles estão abertos à manipulação, especialmente se o oráculo on-chain calcular os preços dos ativos com base em padrões históricos de negociação (como geralmente é o caso).
-
-Por exemplo, um invasor pode explodir artificialmente o preço de um ativo fazendo um empréstimo rápido antes de interagir com seu contrato de empréstimo. Consultar o DEX pelo preço do ativo retornaria um valor mais alto do que normal (devido à grande demanda de inclinação do atacante de "ordem de compra" pelo ativo), permitir que emprestem mais do que deveriam. Esses "ataques de empréstimos rápidos" foram utilizados para explorar a dependência de preços nos oráculos de aplicações DeFi, custando protocolos milhões em fundos perdidos.
-
-##### Como evitar manipulação de oráculos
-
-O requisito mínimo para [evitar a manipulação de oráculos](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) é usar uma rede de oráculos descentralizada que consulte informações de várias fontes para evitar pontos únicos de falha. Na maioria dos casos, oráculos descentralizados tem incentivos criptoeconômicos incorporados para incentivar nós oráculos a relatar informações corretas, tornando-os mais seguros do que os oráculos centralizados.
-
-Se você planeja consultar um oráculo on-chain para preços de ativos, considere usar um que implemente um mecanismo de preço médio ponderado por tempo (TWAP). Um [TWAP oracle](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) consulta o preço de um ativo em dois pontos diferentes em tempo (que você pode modificar) e calcula o preço de ponto com base na média obtida. Escolher períodos mais longos protege seu protocolo contra a manipulação de preços uma vez que grandes ordens executadas recentemente não podem afetar os preços dos ativos.
-
-## Recursos de segurança de contrato inteligente para desenvolvedores {#smart-contract-security-resources-for-developers}
-
-### Ferramentas para analisar contratos inteligentes e verificar a exatidão do código {#code-analysis-tools}
-
-- **[Ferramentas de teste e bibliotecas](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _Coleção de ferramentas e bibliotecas padrão do setor para realizar testes unitários, análise estática e análise dinâmica em contratos inteligentes._
-
-- **[Ferramentas de verificação formal](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _Ferramentas para verificar a correção funcional em contratos inteligentes e verificar inconsistências._
-
-- **[Serviços de auditoria de contrato inteligente](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _Lista de organizações que fornecem serviços de auditoria de contrato inteligente para projetos de desenvolvimento Ethereum._
-
-- **[Plataformas de recompensa por bugs](/developers/docs/smart-contracts/testing/#bug-bounty-platforms) ** - _Plataformas para coordenar recompensas por bugs e recompensar a divulgação responsável de vulnerabilidades críticas em contratos inteligentes._
-
-- **[Fork Checker](https://forkchecker.hashex.org/)** – _Uma ferramenta online gratuita para verificar todas as informações disponíveis sobre um contrato bifurcado._
-
-- **[ABI Encoder](https://abi.hashex.org/)** – _Um serviço online para codificar suas funções de contrato e argumentos de construtor do Solidity._
-
-- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Analisador estático da Solidity, que percorre as árvores de sintaxe abstrata (AST) para identificar vulnerabilidades suspeitas e imprimir os problemas em um formato markdown fácil de usar._
-
-### Ferramentas para monitorar contratos inteligentes {#smart-contract-monitoring-tools}
-
-- **[OpenZeppelin Defender Sentinels](https://docs.openzeppelin.com/defender/v1/sentinel)** - *Uma ferramenta para monitorar e responder automaticamente a eventos, funções e parâmetros de transação em seus contratos inteligentes.*
-
-- **[Alerta leve e em tempo real](https://tenderly.co/alerting/)** - _Uma ferramenta para receber notificações em tempo real quando eventos incomuns ou inesperados acontecem em seus contratos inteligentes ou carteiras._
-
-### Ferramentas para administração segura de contratos inteligentes {#smart-contract-administration-tools}
-
-- **[Administrador do OpenZeppelin Defender](https://docs.openzeppelin.com/defender/v1/admin)** - *Interface para gerenciar a administração de contrato inteligente, incluindo controles de acesso, melhorias e pausas.*
-
-- **[Safe](https://safe.global/)** - _Carteira de contrato inteligente em execução na Ethereum, que requer um número mínimo de pessoas para aprovar uma transação antes que ela possa ocorrer (M-de-N)._
-
-- **[Contratos OpenZeppelin](https://docs.openzeppelin.com/contracts/4.x/)** - _Bibliotecas de contrato para implementação de funcionalidades administrativas, incluindo propriedade de contratos, atualizações, controles de acesso, governança, pausabilidade e muito mais._
-
-### Serviços de auditoria de contrato inteligente {#smart-contract-auditing-services}
-
-- **[ConsenSys Diligence](https://consensys.net/diligence/)** - _Serviço de auditoria para contrato inteligente que ajuda projetos em todo o ecossistema blockchain a garantir que seus protocolos estejam prontos para lançamento e criados para proteger os usuários._
-
-- **[CertiK](https://www.certik.com/)** - _Empresa de segurança Blockchain pioneira no uso de tecnologia de verificação formal de ponta em contratos inteligentes e redes blockchain._
-
-- **[Trilha de Bits](https://www.trailofbits.com/)** - _Empresa de cibersegurança que combina pesquisa de segurança com uma mentalidade de um invasor para reduzir riscos e fortalecer o código._
-
-- **[PeckShield](https://peckshield.com/)** - _Empresa de segurança Blockchain que oferece produtos e serviços para segurança, privacidade e usabilidade de todo o ecossistema blockchain._
-
-- **[QuantStamp](https://quantstamp.com/)** - _Serviço de auditoria que facilita o mainstream de adoção da tecnologia blockchain por meio de serviços de avaliação de segurança e risco._
-
-- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _ Empresa de segurança de contrato inteligente que fornece auditorias de segurança para sistemas distribuídos._
-
-- **[Runtime Verification](https://runtimeverification.com/)** - _Empresa de segurança especializada em modelagem formal e verificação de contratos inteligentes._
-
-- **[Hacken](https://hacken.io)** - _Auditor de cibersegurança da Web3 que traz a abordagem de 360 graus à segurança da blockchain._
-
-- **[Nethermind](https://nethermind.io/smart-contracts-audits)** - _Serviços de auditoria Solidity e Cairo que garantem a integridade dos contratos inteligentes e a segurança dos usuários em toda a Ethereum e Starknet._
-
-- **[HashEx](https://hashex.org/)** – _O HashEx se dedica a blockchain e auditoria de contrato inteligente para garantir a segurança de criptomoedas, fornecendo serviços como desenvolvimento de contrato inteligente, teste de penetração e consultoria em blockchain._
-
-- **[Code4rena](https://code4rena.com/)** - _Plataforma de auditoria competitiva que incentiva especialistas em segurança de contratos inteligentes a encontrar vulnerabilidades e ajudar a tornar a web3 mais segura._
-
-- **[CodeHawks](https://codehawks.com/)** - _Plataforma de auditorias competitivas que hospeda competições de auditoria de contratos inteligentes para pesquisadores de segurança._
-
-- **[Cyfrin](https://cyfrin.io)** - _Poderosa empresa de segurança da Web3, desenvolvendo a segurança de criptografia por meio de produtos e serviços de auditoria de contratos inteligentes._
-
-- **[ImmuneBytes](https://www.immunebytes.com//smart-contract-audit/)** - _Empresa de segurança Web3 que oferece auditorias de segurança para sistemas de blockchain por meio de uma equipe de auditores experientes e das melhores ferramentas da categoria._
-
-- **[Oxorio](https://oxor.io/)** - _Auditorias de contratos inteligentes e serviços de segurança de blockchain com experiência em EVM, Solidity, ZK, tecnologia cross-chain para empresas de criptografia e projetos DeFi._
-
-- **[Inferência](https://inference.ag/)** - _Empresa de auditoria de segurança, especializada em auditoria de contratos inteligentes para blockchains baseados em EVM. É graças a seus auditores especializados que eles identificam possíveis problemas e sugerem soluções úteis para corrigi-los antes da implementação._
-
-### Plataformas de recompensa por bugs {#bug-bounty-platforms}
-
-- **[Immunefi](https://immunefi.com/)** - _Plataforma de recompensa por bugs para contratos inteligentes e projetos DeFi, onde os pesquisadores de segurança revisam o código, divulgam vulnerabilidades, recebem pagamentos e tornam a criptografia mais segura._
-
-- **[HackerOne](https://www.hackerone.com/)** - _Coordenação de vulnerabilidades e plataforma de recompensa por bugs que conecta empresas com testadores de penetração e pesquisadores de segurança cibernética._
-
-- **[HackenProof](https://hackenproof.com/)** - _Plataforma especializada de recompensa por bug para projetos cripto (DeFi, Contratos Inteligentes, Wallets, CEX e muito mais), onde os profissionais de segurança fornecem serviços de triagem e os pesquisadores são pagos por relatórios de bug relevantes, verificados._
-
-- **[Sherlock](https://www.sherlock.xyz/)** - _Subscritor em Web3 para segurança de contratos inteligentes, com pagamentos para auditores gerenciados por meio de contratos inteligentes para garantir que bugs relevantes sejam pagos de forma justa._
-
-- **[CodeHawks](https://www.codehawks.com/)** - _Plataforma competitiva de recompensa por bugs em que os auditores participam de concursos e desafios de segurança e, em breve, de suas próprias auditorias privadas._
-
-### Publicações de vulnerabilidades e exploits conhecidos em contratos inteligentes {#common-smart-contract-vulnerabilities-and-exploits}
-
-- **[ConsenSys: Ataques Conhecidos em Contrato Inteligente](https://consensys.github.io/smart-contract-best-practices/attacks/)** - _Explicação fácil das vulnerabilidades de contrato mais significativas, com código de exemplo para a maioria dos casos._
-
-- **[Registro SWC](https://swcregistry.io/)** - _Lista selecionada de Enumerações de Vulnerabilidades Comuns (Common Weakness Enumeration, CWE) que se aplicam a contratos inteligentes da Ethereum._
-
-- **[Rekt](https://rekt.news/)** - _Publicação regularmente atualizada de cripto hacks (roubos) e exploits (ataques) de alto-perfil, juntamente com relatórios post-mortem (após incidente) detalhados._
-
-### Desafios para aprender a segurança de contratos inteligentes {#challenges-for-learning-smart-contract-security}
-
-- **[A Incrível BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - *Lista selecionada de jogos de guerra de segurança na blockchain, desafios e a [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) com competições e descrições de soluções.*
-
-- **[Maldito DeFi Vulnerável](https://www.damnvulnerabledefi.xyz/)** - _Jogo de guerra para aprender a segurança ofensiva de contratos inteligentes DeFi e desenvolver habilidades em caça a bugs e auditoria de segurança._
-
-- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _Jogo de guerra baseado em Web3/Solidity onde cada nível é um contrato inteligente que precisa ser 'hackeado'._
-
-- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _Desafio de hacking de contrato inteligente, ambientado em uma aventura de fantasia. A conclusão bem-sucedida do desafio também dá acesso a um programa privado de recompensa por bugs._
-
-### Melhores práticas para proteger contratos inteligentes {#smart-contract-security-best-practices}
-
-- **[ConsenSys: Melhores Práticas de Segurança em Contratos Inteligentes Ethereum](https://consensys.github.io/smart-contract-best-practices/)** - _Lista abrangente de diretrizes para proteger contratos inteligentes Ethereum._
-
-- **[Nascent: Kit de Ferramentas de Segurança Simples](https://github.com/nascentxyz/simple-security-toolkit)** - _Coleção de guias práticos com foco em segurança e listas de verificação para o desenvolvimento de contratos inteligentes._
-
-- **[Padrões Solidity](https://fravoll.github.io/solidity-patterns/)** - *Compilação útil de padrões segurança e melhores práticas para contratos inteligentes da linguagem de programação Solidity.*
-
-- **[Documentação Solidity: Considerações de Segurança](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _Diretrizes para programar contratos inteligentes seguros com Solidity._
-
-- **[Padrão de Verificação de Segurança de Contrato Inteligente](https://github.com/securing/SCSVS)** - _Lista de verificação de quatorze partes criadas para padronizar a segurança de contratos inteligentes para desenvolvedores, arquitetos, revisores de segurança e fornecedores._
-
-- **[Aprenda sobre segurança e auditoria de contratos inteligentes](https://updraft.cyfrin.io/courses/security) - _Curso definitivo de segurança e auditoria de contratos inteligentes, criado para desenvolvedores de contratos inteligentes que desejam melhorar suas práticas recomendadas de segurança e se tornar pesquisadores de segurança._
-
-### Tutoriais sobre segurança de contratos inteligentes {#tutorials-on-smart-contract-security}
-
-- [Como programar contratos inteligentes seguros](/developers/tutorials/secure-development-workflow/)
-
-- [Como utilizar o Slither para encontrar bugs nos contratos inteligentes](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
-
-- [Como usar o Manticore para encontrar bugs em contratos inteligentes](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
-
-- [Diretrizes de segurança do contrato inteligente](/developers/tutorials/smart-contract-security-guidelines/)
-
-- [Como integrar com segurança seu contrato de token com tokens arbitrários](/developers/tutorials/token-integration-checklist/)
-
-- [Cyfrin Updraft - Curso completo de segurança e auditoria de contratos inteligentes](https://updraft.cyfrin.io/courses/security)
diff --git "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" "b/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
deleted file mode 100644
index b70bc869e56..00000000000
--- "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: Composição de contrato inteligente
-description:
-lang: pt-br
-incomplete: true
----
-
-## Uma breve introdução {#a-brief-introduction}
-
-Os contratos inteligentes são públicos na Ethereum e podem ser considerados como APIs abertas. Você não precisa escrever o seu próprio contrato inteligente para se tornar um desenvolvedor dapp, você só precisa saber como interagir com eles. Por exemplo, você pode usar os contratos inteligentes existentes do [Uniswap](https://uniswap.exchange/swap), uma troca descentralizada, para lidar com toda a lógica de troca de token em seu aplicativo - você não precisa começar do zero. Confira alguns de seus contratos [v2](https://github. com/Uniswap/uniswap-v2-core/tree/master/contracts) e [v3](https://github. com/Uniswap/uniswap-v3-core/tree/main/contracts).
-
-## O que é composabilidade? {#what-is-composability}
-
-Composabilidade é combinar componentes distintos para criar novos sistemas ou saídas. No desenvolvimento de software, a composabilidade significa que os desenvolvedores podem reutilizar os componentes de software existentes para criar novos aplicativos. Uma boa maneira de entender a composabilidade é pensar em elementos componíveis como blocos de Lego. Cada Lego pode ser combinado com outro, permitindo que você construa estruturas complexas combinando diferentes Legos.
-
-Na Ethereum, todo contrato inteligente é uma espécie de Lego – você pode usar contratos inteligentes de outros projetos como blocos de construção para seu projeto. Isso significa que você não precisa perder tempo reinventando a roda ou construindo do zero.
-
-## Como funciona a composabilidade? {#how-does-composability-work}
-
-Os contratos inteligentes Ethereum são como APIs públicas, para que qualquer pessoa possa interagir com o contrato ou integrá-los em dapps para funcionalidade adicional. A composição de contrato inteligente geralmente funciona com três princípios: modularidade, autonomia e descoberta:
-
-**1. Modularidade**: Esta é a capacidade de componentes individuais para executar uma tarefa específica. Na Ethereum, cada contrato inteligente tem um caso de uso específico (como mostrado no exemplo Uniswap).
-
-**2. Autonomia**: Componentes compostos devem ser capazes de operar independentemente. Cada contrato inteligente na Ethereum é autoexecutável e pode funcionar sem depender de outras partes do sistema.
-
-**3. Capacidade de descoberta**: Desenvolvedores não podem chamar contratos externos ou integrar bibliotecas de software em aplicativos, se o primeiro não estiver disponível publicamente. Por concepção, os contratos inteligentes são de código aberto; qualquer um pode chamar um contrato inteligente ou copiar uma base de código.
-
-## Benefícios da composabilidade {#benefits-of-composability}
-
-### Ciclo de desenvolvimento curto {#shorter-development-cycle}
-
-A composabilidade reduz o trabalho que os desenvolvedores têm de fazer ao criar [dapps](/dapps/#what-are-dapps). [Como Naval Ravikant coloca:](https://twitter.com/naval/status/1444366754650656770) "O código aberto significa que todo problema deve ser resolvido uma vez."
-
-Se houver um contrato inteligente que resolva um problema, outros desenvolvedores podem reutilizá-lo, para que não precisem resolver o mesmo problema. Dessa forma, os desenvolvedores podem usar bibliotecas de software existentes e adicionar funcionalidades extras para criar novos dapps.
-
-### Maior inovação {#greater-innovation}
-
-A composabilidade incentiva a inovação e a experimentação porque os desenvolvedores são livres para reusar, modificar, duplicar ou integrar código-fonte aberto para criar os resultados desejados. Como resultado, as equipes de desenvolvimento gastam menos tempo em funcionalidades básicas e podem alocar mais tempo experimentando novos recursos.
-
-### Melhor experiência do usuário {#better-user-experience}
-
-A interoperabilidade entre os componentes do ecossistema Ethereum melhora a experiência do usuário. Os usuários podem acessar maiores funcionalidades quando os dapps integram contratos inteligentes externos do que em um ecossistema fragmentado onde os aplicativos não podem se comunicar.
-
-Usaremos um exemplo de negociação de arbitragem para ilustrar os benefícios da interoperabilidade:
-
-Se um token estiver sendo negociado mais alto na `troca A` do que na `troca B`, você pode aproveitar a diferença de preço para obter lucro. No entanto, você só pode fazer isso se tiver capital suficiente para financiar a transação (ou seja, comprar o token da `troca B` e vendê-lo na `troca A`).
-
-Em um cenário em que você não tem fundos suficientes para cobrir a negociação, um empréstimo rápido pode ser o ideal. Os [empréstimos relâmpagos](/defi/#flash-loans) são altamente técnicos, mas a ideia básica é que você pode emprestar ativos (sem garantias) e devolvê-los dentro de *uma* transação.
-
-Voltando ao nosso exemplo inicial, um trader de arbitragem pode fazer um grande empréstimo relâmpago, comprar tokens da `troca B`, vendê-los na `troca A`, pagar o capital + juros, e manter o lucro, dentro da mesma transação. Essa lógica complexa requer a combinação de chamadas para vários contratos, o que não seria possível se os contratos inteligentes não tivessem interoperabilidade.
-
-## Exemplos de composabilidade na Ethereum {#composability-in-ethereum}
-
-### Trocas de tokens {#token-swaps}
-
-Se você criar um dapp que exige que as transações sejam pagas em ETH, você pode permitir que os usuários paguem em outros tokens ERC-20 integrando a lógica de troca de token. O código converterá automaticamente o token do usuário em ETH antes que o contrato execute a função chamada.
-
-### Governança {#governance}
-
-Construir sistemas de governança sob medida para um [DAO](/dao/) pode ser caro e demorado. Em vez disso, você pode usar um kit de ferramentas de governança de código aberto, como [Aragon Client](https://client.aragon.org/), para inicializar seu DAO e criar rapidamente um framework de governança.
-
-### Gerenciamento de identidade {#identity-management}
-
-Em vez de criar um sistema de autenticação personalizado ou depender de provedores centralizados, você pode integrar ferramentas de identidade descentralizada (DID) para gerenciar a autenticação de usuários. Um exemplo é o [SpruceID](https://www.spruceid.com/), um kit de ferramentas de código aberto que oferece uma funcionalidade "Entrar com Ethereum" que permite aos usuários autenticar identidades com uma carteira Ethereum.
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Comece seu desenvolvimento de front-end dapp com create-eth-app](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– Uma visão geral de como usar o create-eth-app para criar apps com contratos inteligentes populares prontos para uso._
-
-## Leitura adicional {#further-reading}
-
-_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_
-
-- [Composição é Inovação](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/)
-- [Porque a Composabilidade é importante para a Web3](https://hackernoon.com/why-composability-matters-for-web3)
-- [O que é Composabilidade?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.)
diff --git "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" "b/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
deleted file mode 100644
index 7c83c73ed16..00000000000
--- "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
+++ /dev/null
@@ -1,283 +0,0 @@
----
-title: Verificação formal de contratos inteligentes
-description: Uma visão geral da verificação formal de contratos inteligentes na Ethereum
-lang: pt-br
----
-
-[Contratos inteligentes](/developers/docs/smart-contracts/) permitem criar aplicativos descentralizados, sem necessidade de confiança, e robustos, que introduzem novos casos de uso e desbloqueiam valor para os usuários. Como os contratos inteligentes manipulam grandes quantidades de valor, a segurança é uma consideração crítica para desenvolvedores.
-
-A verificação formal é uma das técnicas recomendadas para melhorar [a segurança do contrato inteligente](/developers/docs/smart-contracts/security/). Verificação formal, que usa [métodos formais](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) para especificar, conceber e verificar programas, tem sido usada há anos para garantir a correção de sistemas críticos de hardware e software.
-
-Quando implementada em contratos inteligentes, a verificação formal pode comprovar que a lógica de negócio de um contrato cumpre uma especificação predefinida. Comparado com outros métodos para avaliar a exatidão do código do contrato, como testes, verificação formal dá mais garantias de que um contrato inteligente está funcionalmente correto.
-
-## O que é a verificação formal? {#what-is-formal-verification}
-
-A verificação formal refere-se ao processo de avaliação da exatidão de um sistema no que diz respeito a uma especificação formal. Em termos simples, verificação formal nos permite verificar se o comportamento de um sistema satisfaz algumas exigências (ou seja, ele faz o que queremos).
-
-Comportamentos esperados do sistema (um contrato inteligente, neste caso) são descritos usando modelagem formal, enquanto linguagens de especificação permitem a criação de propriedades formais. Técnicas formais de verificação podem depois verificar se a implementação de um contrato está de acordo com sua especificação e deriva comprovação matemática da exatidão do primeiro. Quando um contrato satisfaz a sua especificação, ele é descrito como "funcionalmente correto", "correto por concepção" ou "correto por elaboração".
-
-### O que é um modelo formal? {#what-is-a-formal-model}
-
-Na ciência da computação, um [modelo formal](https://en.wikipedia.org/wiki/Model_of_computation) é uma descrição matemática de um processo computacional. Programas são abstraídos em funções matemáticas (equações), com o modelo que descreve como as saídas para funções são computadas dada uma entrada.
-
-Modelos formais fornecem um nível de abstração sobre o qual a análise do comportamento de um programa pode ser avaliada. A existência de modelos formais permite a criação de uma _especificação formal_, que descreve as propriedades desejadas do modelo em questão.
-
-Diferentes técnicas são utilizadas para modelagem de contratos inteligentes para verificação formal. Por exemplo, alguns modelos são usados para racionalizar sobre o comportamento de alto nível de um contrato inteligente. Essas técnicas de modelagem aplicam uma visão de caixa preta em contratos inteligentes, visualizando-os como sistemas que aceitam entradas e executam computação com base nessas entradas.
-
-Os modelos mais gerais focam na relação entre contratos inteligentes e agentes externos, como contas de propriedade externa (EOA), contas de contrato e ambiente da blockchain. Esses modelos são úteis para definir propriedades que especificam como um contrato deve se comportar em resposta a determinadas interações do usuário.
-
-Inversamente, outros modelos formais se concentram no comportamento de baixo nível de um contrato inteligente. Embora os modelos mais gerais possam ajudar no raciocínio sobre a funcionalidade de um contrato, eles podem não conseguir capturar detalhes sobre o funcionamento interno da implementação. Modelos de baixo nível aplicam uma visualização de caixa branca para programar a análise e dependem de representações de baixo nível de aplicações de contrato inteligentes, como traços de programas e [gráficos de controle de fluxo](https://en.wikipedia.org/wiki/Control-flow_graph), justificando sobre propriedades relevantes para a execução de um contrato.
-
-Modelos de baixo nível são considerados ideais uma vez que representam a execução real de um contrato inteligente no ambiente de execução da Ethereum (ou seja, a [EVM](/developers/docs/evm/)). Técnicas de modelagem de baixo nível são especialmente úteis para estabelecer propriedades de segurança críticas em contratos inteligentes e para detectar potenciais vulnerabilidades.
-
-### O que é uma especificação formal? {#what-is-a-formal-specification}
-
-Uma especificação é simplesmente um requisito técnico que determinado sistema tem de cumprir. Em programação, as especificações representam ideias gerais sobre a execução de um programa (ou seja, o que o programa deve fazer).
-
-No contexto dos contratos inteligentes, especificações formais se referem a _propriedades_—descrições formais dos requisitos que um contrato deve cumprir. Essas propriedades são descritas como "invariáveis" e representam afirmações lógicas sobre a execução de um contrato que devem permanecer verdadeiras em todas as circunstâncias possíveis, sem quaisquer exceções.
-
-Assim, podemos pensar em uma especificação formal como uma coleção de instruções escritas em uma linguagem formal que descreve a execução pretendida de um contrato inteligente. As especificações cobrem as propriedades de um contrato e definem como o contrato deve se comportar em diferentes circunstâncias. O objetivo da verificação formal é determinar se um contrato inteligente possui essas propriedades (conhecidas como invariáveis ou invariantes) e que essas propriedades não são violadas durante a execução.
-
-As especificações formais são fundamentais no desenvolvimento de implementações seguras de contratos inteligentes. Contratos que falhem em implementar invariáveis ou que tenham suas propriedades sejam violadas durante a execução estão propensos a vulnerabilidades que podem prejudicar a funcionalidade ou causar usos maliciosos.
-
-## Tipos de especificações formais para contratos inteligentes {#formal-specifications-for-smart-contracts}
-
-Especificações formais permitem o raciocínio matemático sobre a exatidão da execução do programa. Como nos modelos formais, as especificações formais podem capturar propriedades de alto nível ou o comportamento de baixo nível de uma implementação de contrato.
-
-Especificações formais são derivadas usando elementos de [lógica de programa](https://en.wikipedia.org/wiki/Logic_programming), que permitem raciocínio formal sobre as propriedades de um programa. Uma lógica do programa tem regras formais que expressam (na linguagem matemática) o comportamento esperado de um programa. Várias lógicas de programa são usadas na criação de especificações formais, incluindo a [lógica de acessibilidade](https://en.wikipedia.org/wiki/Reachability_problem), [lógica temporal](https://en.wikipedia.org/wiki/Temporal_logic), e [lógica Hoare](https://en.wikipedia.org/wiki/Hoare_logic).
-
-Especificações formais para contratos inteligentes podem ser classificadas geralmente como especificações de **alto nível** ou de **baixo nível**. Independentemente da categoria a que pertence uma especificação, ela deve descrever de forma adequada e inequívoca a propriedade do sistema em análise.
-
-### Especificações de alto nível {#high-level-specifications}
-
-Como o nome sugere, uma especificação de alto nível (também chamada de "especificação orientada ao modelo") descreve o comportamento de alto nível de um programa. Especificações de alto nível modelam um contrato inteligente como uma [máquina de estado finito](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM), que pode fazer a transição entre os estados realizando operações, com lógica temporal usada para definir propriedades formais para o modelo FSM.
-
-[Lógicas temporais](https://en.wikipedia.org/wiki/Temporal_logic) são "regras para raciocínio de proposições qualificadas em termos de tempo (por exemplo, "Eu tenho _sempre_ fome" ou "Eu vou _em algum momento_ estar com fome")." Quando aplicadas à verificação formal, as lógicas temporais são usadas para declarar asserções sobre o comportamento correto de sistemas modelados como máquinas de estado. Especificamente, uma lógica temporal descreve os estados futuros em que um contrato inteligente pode estar e como ele transita entre estados.
-
-Especificações de alto nível geralmente capturam duas propriedades temporais críticas para contratos inteligentes: **segurança** e **vivacidade** (liveness). As propriedades de segurança representam a ideia de que “nada de mal jamais acontece” e geralmente expressam invariância. Uma propriedade de segurança pode definir requisitos gerais de software, como liberdade de [impasse](https://www.techtarget.com/whatis/definition/deadlock) ou expressar propriedades específicas de domínio para contratos (por exemplo, invariáveis no controle de acesso para funções, valores admissíveis de variáveis de estado ou condições para transferências de token).
-
-Veja, por exemplo, este requisito de segurança que cobre condições para usar `transfer()` ou `transferFrom()` em contratos de token ERC-20: _ “O saldo de um remetente nunca é inferior à quantidade solicitada de tokens a serem enviados.”_. Essa descrição em linguagem natural de uma invariável de contrato pode ser traduzida em uma especificação formal (matemática), que pode então ser rigorosamente verificada para validade.
-
-Propriedades de vivacidade afirmam que “algo eventualmente bom acontece” e se refere à capacidade do contrato progredir por diferentes estados. Um exemplo de uma propriedade de vivacidade é a “liquidez”, que se refere à capacidade do contrato transferir seus saldos aos usuários por solicitação. Se essa propriedade for violada, os usuários não poderiam retirar os ativos armazenados no contrato, como aconteceu com o [incidente de carteira do Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may- have-frozen-280-worth-of-ether-on-parity-wallet.html).
-
-### Especificações de baixo nível {#low-level-specifications}
-
-As especificações de alto nível tomam como ponto de partida um modelo de estado finito de um contrato e definem as propriedades desejadas deste modelo. Em contraste, as especificações de baixo nível (também chamadas de "especificações orientadas à propriedade") muitas vezes modelam programas (contratos inteligentes) como sistemas que compreendem uma coleção de funções matemáticas e descrevem o comportamento correto desses sistemas.
-
-Em termos simples, as especificações de baixo nível analisam _traços de programa_ e tentam definir propriedades de um contrato inteligente sobre esses traços. Traços se referem a sequências de execuções de funções que alteram o estado de um contrato inteligente; por isso, as especificações de baixo nível ajudam a especificar requisitos para uma execução interna de contrato.
-
-Especificações formais de baixo nível podem ser fornecidas como propriedades do estilo Hoare ou invariáveis em caminhos de execução.
-
-### Propriedades do estilo Hoare {#hoare-style-properties}
-
-[Hore Logic](https://en.wikipedia.org/wiki/Hoare_logic) fornece um conjunto de regras formais para raciocinar sobre a correção de programas, incluindo contratos inteligentes. Uma propriedade de estilo Hoare é representada por um triplo Hoare {_P_}_c_{_Q_}, onde _c_ é um programa e _P_ e _Q_ são predicados no estado do _c_ (ou seja, o programa), formalmente descritos como _precondições_ e _pós-condições_, respectivamente.
-
-Uma precondição é um predicado que descreve as condições necessárias para a execução correta de uma função; os usuários que chamam um contrato devem satisfazer este requisito. Uma pós-condição é um predicado que descreve a condição que uma função estabelece se executada corretamente; os usuários podem esperar que essa condição seja verdadeira após chamar a função. Uma _invariável_ na lógica Hoare é um predicado que é preservado pela execução de uma função (ou seja, não muda).
-
-As especificações do estilo Hoare podem garantir _correção parcial_ ou _correção total_. A implementação de uma função de contrato é "parcialmente correta" se a precondição se confirmar verdadeira antes da função ser executada e, se a execução terminar, a pós-condição também é verdadeira. A prova de correção total é obtida se uma precondição for verdadeira antes da execução da função, a execução é garantida para terminar e, quando isso acontecer, a pós-condição é verdadeira.
-
-Obter a comprovação de correção total é difícil, pois algumas execuções podem atrasar antes de terminar ou nunca terminar nada. Dito isso, a questão de se a execução termina é sem dúvida um ponto discutível, já que o mecanismo de gás da Ethereum evita loops infinitos de programa (a execução termina, ou com sucesso, ou termina devido a um erro de 'falta de gás').
-
-As especificações de contrato inteligente criadas usando a lógica de Hoare terão precondições, pós-condições e invariáveis definidas para a execução de funções e loops em um contrato. Precondições geralmente incluem a possibilidade de entradas erradas para uma função, com pós-condições descrevendo a resposta esperada para essas entradas (por exemplo, lançando uma exceção específica). Dessa maneira, as propriedades do estilo Hoare são eficazes para garantir a correção das implementações de contratos.
-
-Muitas estruturas formais de verificação usam especificações no estilo Hoare para comprovar a correção semântica das funções. Também é possível adicionar propriedades do estilo Hoare (como asserções) diretamente ao código do contrato usando as instruções `require` e `assert` no Solidity.
-
-As instruções `require` expressam uma precondição ou invariável e são frequentemente usadas para validar as entradas do usuário, enquanto `assert` captura uma pós-condição necessária para segurança. Por exemplo, o controle de acesso adequado para funções (um exemplo de uma propriedade de segurança) pode ser alcançado usando `require` como uma verificação de precondição na identidade da conta de chamada. Da mesma forma, uma invariável em valores permitidos de variáveis de estado em um contrato (por exemplo, número total de tokens em circulação) pode ser protegida contra violação usando `assert` para confirmar o estado do contrato após a execução da função.
-
-### Propriedades de nível de traços {#trace-level-properties}
-
-Especificações baseadas em traços descrevem operações que transitam um contrato entre diferentes estados e as relações entre essas operações. Como foi explicado anteriormente, os traços são sequências de operações que alteram o estado de um contrato de uma forma específica.
-
-Essa abordagem depende do modelo de contratos inteligentes como sistemas de transição de estado com alguns estados predefinidos (descritos por variáveis de estado) junto com um conjunto de transições predefinidas (descritas pelas funções de contrato). Além disso, um [gráfico de controle de fluxo ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), que é uma representação gráfica do fluxo de execução de um programa, é frequentemente utilizado para descrever a semântica operacional de um contrato. Aqui, cada traço representado como um caminho no gráfico do fluxo de controle.
-
-Em primeiro lugar, as especificações de nível de traços são usadas para raciocinar sobre padrões de execução interna em contratos inteligentes. Ao criar especificações de nível de traços, afirmamos os caminhos de execução admissíveis (ou seja, transições de estado) para um contrato inteligente. Utilizando técnicas, como a execução simbólica, podemos verificar formalmente que a execução nunca segue um caminho não definido no modelo formal.
-
-Vamos usar um exemplo de um contrato com [DAO](/dao/) que tem algumas funções publicamente acessíveis para descrever propriedades de nível de traços. Aqui, assumimos que o contrato DAO permite aos usuários executar as seguintes operações:
-
-- Depositar fundos
-
-- Votar em uma proposta depois de depositar fundos
-
-- Reivindicar um reembolso se eles não votarem em uma proposta
-
-Exemplo de propriedades de nível de traços poderia ser _"usuários que não depositam fundos não podem votar em uma proposta"_ ou _"usuários que não votarem em uma proposta devem estar sempre aptos a reivindicar um reembolso"_. Ambas as propriedades afirmam sequências preferidas de execução (votação não pode acontecer _antes_ de depositar fundos, e reivindicar um reembolso não pode acontecer _após_ a votação de uma proposta).
-
-## Técnicas para verificação formal de contratos inteligentes {#formal-verification-techniques}
-
-### Verificação de modelo {#model-checking}
-
-A verificação de modelo é uma técnica de verificação formal na qual um algoritmo verifica um modelo formal de um contrato inteligente em relação à sua especificação. No modelo de verificação, os contratos inteligentes são frequentemente representados como sistemas de transição de estado, enquanto as propriedades nos estados de contrato permitidos são definidas usando lógica temporal.
-
-A verificação de modelo requer a criação de uma representação matemática abstrata de um sistema (ou seja, um contrato) e a expressão das propriedades desse sistema usando fórmulas enraizadas na [lógica proposicional](https://www.baeldung.com/cs/propositional-logic). Isto simplifica a tarefa do algoritmo de verificação de modelo, ou seja, comprovar que um modelo matemático cumpre uma dada fórmula lógica.
-
-A verificação de modelo na verificação formal é usada principalmente para avaliar propriedades temporais que descrevem o comportamento de um contrato ao longo do tempo. As propriedades temporais para contratos inteligentes incluem _segurança_ e _vivacidade_, a qual explicamos anteriormente.
-
-Por exemplo, uma propriedade de segurança relacionada ao controle de acesso (exemplo: _Somente o proprietário do contrato pode chamar `selfdestruct`_) pode ser escrita na lógica formal. Depois disso, o algoritmo de verificação de modelos pode verificar se o contrato satisfaz esta especificação formal.
-
-A verificação de modelo usa a exploração do espaço do estado, que envolve construir todos os estados possíveis de um contrato inteligente e tentar encontrar estados acessíveis que resultem em violações de propriedades. No entanto, isso pode levar a um número infinito de estados (conhecido como o "problema da explosão de estado"), por isso, os verificadores de modelos dependem de técnicas de abstração para possibilitar uma análise eficiente de contratos inteligentes.
-
-### Comprovação de teorema {#theorem-proving}
-
-Comprovação de teorema é um método de raciocínio matemático sobre a exatidão de programas, incluindo contratos inteligentes. Ela envolve transformar o modelo do sistema de um contrato e as suas especificações em fórmulas matemáticas (declarações lógicas).
-
-O objetivo da comprovação de teorema é verificar a equivalência lógica entre essas declarações. “Equivalência lógica” (também chamada de “bi-implicação lógica”) é um tipo de relação entre duas declarações, de modo que a primeira declaração é verdadeira, _se e somente se_, a segunda declaração for verdadeira.
-
-A relação necessária (equivalência lógica) entre as declarações sobre o modelo de um contrato e sua propriedade é formulada como uma declaração provável (chamada teorema). Usando um sistema formal de inferência, o comprovador do teorema automatizado pode verificar a validade do teorema. Em outras palavras, um comprovador de teorema pode comprovar de forma conclusiva se o modelo de um contrato inteligente corresponde precisamente às suas especificações.
-
-Enquanto a verificação de modelos de contratos como sistemas de transição com estados finitos, a comprovação de teorema pode lidar com a análise de sistemas de estado infinito. No entanto, isso significa que um comprovador de teorema automatizado nem sempre sabe se um problema lógico é "decidível" ou não.
-
-Como resultado, muitas vezes a assistência humana é necessária para guiar o comprovador do teorema na derivação das provas de correção. O uso do esforço humano na comprovação do teorema torna mais caro usar do que a verificação de modelos, que é totalmente automatizada.
-
-### Execução simbólica {#symbolic-execution}
-
-Execução simbólica é um método de análise de um contrato inteligente que executa funções usando _valores simbólicos_ (por exemplo, `x > 5`) em vez de _valores concretos_ (por exemplo, `x == 5`). Como técnica formal de verificação, a execução simbólica é usada para argumentar formalmente sobre propriedades de traços no código de um contrato.
-
-A execução simbólica representa um traço de execução como uma fórmula matemática sobre valores simbólicos de entrada, também chamados de _predicado de caminho_. Um [SMT solver](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) é usado para verificar se um predicado de caminho é "satisfatório" (ou seja, existe um valor que pode cumprir a fórmula). Se um caminho vulnerável for cumprido, o solucionador SMT gerará um valor concreto que acionará a execução de guias em direção àquele caminho.
-
-Suponha que a função de um contrato inteligente tome como entrada, um valor `uint` (`x`) e reverta quando `x` for maior que `5` e também menor que `10`. Encontrar um valor para `x` que dispara o erro usando um procedimento de teste normal exigiria ser executado por dezenas de casos de teste (ou mais) sem a garantia de realmente encontrar uma entrada de disparo de erro.
-
-Inversamente, uma ferramenta de execução simbólica executaria a função com o valor simbólico: `X > 5 ∧ X < 10` (ou seja, `x` é maior que 5 E `x` é menor que 10). O predicado do caminho associado `x = X > 5 ∧ X < 10` seria dada a um solucionador de SMT para resolver. Se determinado valor satisfaz a fórmula `x = X > 5 ∧ X < 10`, o solucionador SMT irá calculá-lo—por exemplo, o solucionador pode produzir `7` como um valor para `x`.
-
-Como a execução simbólica depende de entradas para um programa, e o conjunto de entradas para explorar todos os estados acessíveis é potencialmente infinito, ela ainda é uma forma de teste. Contudo, como mostrado no exemplo, a execução simbólica é mais eficiente do que os testes regulares para encontrar entradas que desencadeiem violações de propriedade.
-
-Além disso, a execução simbólica produz menos falsos positivos do que outras técnicas baseadas em propriedades (por exemplo, fuzzing) que geram aleatoriamente entradas para uma função. Se um estado de erro for acionado durante a execução simbólica, então é possível gerar um valor concreto que desencadeie o erro e reproduza o problema.
-
-A execução simbólica também pode fornecer algum grau de prova matemática de exatidão. Considere o seguinte exemplo de uma função de contrato com proteção a overflow:
-
-```
-function safe_add(uint x, uint y) returns(uint z){
-
- z = x + y;
- require(z>=x);
- require(z>=y);
-
- return z;
-```
-
-Um traço de execução que resulta em um overflow de número inteiro precisaria satisfazer a fórmula: `z = x + y E (z >= x) E (z=>y) E (z < x OU z < y)` É improvável que uma fórmula como essa seja resolvida, portanto ela serve uma comprovação matemática de que a função `safe_add` nunca sofre overflow.
-
-### Por que usar a verificação formal para contratos inteligentes? {#benefits-of-formal-verification}
-
-#### Necessidade de confiabilidade {#need-for-reliability}
-
-A verificação formal é utilizada para avaliar a exatidão de sistemas críticos em matéria de segurança, cuja falha pode ter consequências devastadoras, como a morte, ferimentos ou a ruína financeira. Contratos inteligentes são aplicações de alto valor que controlam enormes quantidades de valor, e erros simples na concepção podem levar a [perdas irrecuperáveis para usuários](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). Verificar formalmente um contrato antes da implantação pode, no entanto, aumentar as garantias de que ele executará como esperado, uma vez funcionando na blockchain.
-
-A confiabilidade é uma qualidade altamente desejada em qualquer contrato inteligente, especialmente porque o código implantado na Ethereum Virtual Machine (EVM) é tipicamente imutável. Com melhorias pós-lançamento não prontamente acessíveis, a necessidade de garantir a confiabilidade dos contratos torna necessária a verificação formal. A verificação formal é capaz de detectar problemas complicados, como underflows e overflows de inteiros, reentrância, e otimizações de gás fracas, que podem passar por auditores e testadores.
-
-#### Comprovar correção funcional {#prove-functional-correctness}
-
-O teste do programa é o método mais comum de comprovar que um contrato inteligente cumpre alguns requisitos. Isso envolve a execução de um contrato com uma amostra dos dados que se espera que eles lidem e analisar seu comportamento. Se o contrato retorna os resultados esperados para os dados da amostra, então os desenvolvedores têm uma prova objetiva de sua exatidão.
-
-No entanto, esta abordagem não pode comprovar a execução correta para valores de entrada que não fazem parte da amostra. Portanto, testar um contrato pode ajudar a detectar erros (ou seja, se alguns caminhos de código falham em retornar os resultados desejados durante a execução), mas **ele não pode comprovar de forma conclusiva a ausência de bugs**.
-
-Inversamente, verificação formal pode comprovar formalmente que um contrato inteligente cumpre as exigências de uma infinita gama de execuções _sem_ executar nada do contrato. Isso requer a criação de uma especificação formal que descreva precisamente comportamentos de contratos corretos e desenvolva um modelo formal (matemático) do sistema do contrato. Em seguida, podemos seguir um procedimento formal de prova para verificar a consistência entre o modelo do contrato e a sua especificação.
-
-Com a verificação formal, a questão de verificar se a lógica de negócios de um contrato satisfaz os requisitos é uma proposta matemática que pode ser comprovada ou reprovada. Ao comprovar formalmente uma proposição, podemos verificar um número infinito de casos de teste com um número finito de etapas. Desta forma, a verificação formal tem melhores perspectivas de comprovar que um contrato é funcionalmente correto no que se refere a uma especificação.
-
-#### Alvos de verificação ideais {#ideal-verification-targets}
-
-Um alvo de verificação descreve o sistema a ser formalmente verificado. A verificação formal é melhor usada em "sistemas integrados" (pequenos partes simples de software que fazem parte de um sistema maior). Eles também são ideais para domínios especializados que têm poucas regras, já que isso torna mais fácil modificar ferramentas para verificar propriedades específicas de domínio.
-
-Contratos inteligentes, pelo menos em certa medida, preenchem ambos os requisitos. Por exemplo, o tamanho pequeno dos contratos Ethereum os torna acessíveis a uma verificação formal. Da mesma forma, a EVM segue regras simples, o que facilita a especificação e verificação de propriedades semânticas para programas em execução na EVM.
-
-### Ciclo de desenvolvimento mais rápido {#faster-development-cycle}
-
-Técnicas de verificação formais, como verificação de modelo e execução simbólica, geralmente são mais eficientes do que a análise regular do código do contrato inteligente (executado durante testes ou auditorias). Isso é porque a verificação formal depende de valores simbólicos para testar declarações ("e se um usuário tentar retirar _n_ ether?") Ao contrário de testes que usam valores concretos ("e se um usuário tentar retirar 5 ethers?").
-
-Variáveis de entrada simbólica podem cobrir várias classes de valores concretos, assim as abordagens de verificação formal prometem mais cobertura de código em um período de tempo mais curto. Quando usado de forma eficaz, a verificação formal pode acelerar o ciclo de desenvolvimento para desenvolvedores.
-
-A verificação formal também melhora o processo de construção de aplicativos descentralizados (dapps) reduzindo os erros de concepção caros. Atualizar contratos (sempre que possível) para corrigir vulnerabilidades requer extensa reescrita de códigos e mais esforço gasto em desenvolvimento. A verificação formal pode detectar muitos erros em implementações de contratos que podem passar por testadores e auditores anteriores e oferece uma ampla oportunidade para corrigir esses problemas antes de implantar um contrato.
-
-## Desvantagens da verificação formal {#drawbacks-of-formal-verification}
-
-### Custo do trabalho manual {#cost-of-manual-labor}
-
-Verificação formal, especialmente verificação semiautomatizado, na qual um humano guia o comprovador para derivar comprovações de exatidão, requer um trabalho manual considerável. Além disso, a criação de uma especificação formal é uma atividade complexa que exige um elevado nível de competências.
-
-Esses fatores (esforço e habilidade) tornam a verificação formal mais exigente e cara comparada com os métodos normais de avaliação da exatidão nos contratos, como testes e auditorias. No entanto, pagar o custo de uma auditoria completa de verificação é prático, dado o custo de erros em implementações de contratos inteligentes.
-
-### Falsos negativos {#false-negatives}
-
-A verificação formal só pode verificar se a execução do contrato inteligente corresponde à especificação formal. Como tal, é importante garantir que a especificação descreve corretamente os comportamentos esperados de um contrato inteligente.
-
-Se as especificações forem mal escritas, as violações de propriedades - que apontam para execuções vulneráveis - não podem ser detectadas pela auditoria de verificação formal. Neste caso, um desenvolvedor pode assumir erroneamente que o contrato está livre de erros.
-
-### Problemas de desempenho {#performance-issues}
-
-Verificação formal acarreta uma série de problemas de desempenho. Por exemplo, os problemas de explosão de estado e caminho encontrados durante a verificação do modelo e a verificação simbólica, respectivamente, podem afetar os procedimentos de verificação. Além disso, as ferramentas formais de verificação muitas vezes usam solucionadores SMT e outros solucionadores de restrições em sua camada subjacente, e esses solucionadores dependem de procedimentos computacionais intensos.
-
-Além disso, nem sempre é possível que os verificadores de programa determinem se uma propriedade (descrita como uma fórmula lógica) pode ser satisfeita ou não (o "[decidability problem](https://en.wikipedia.org/wiki/Decision_problem)") porque um programa pode nunca terminar. Como tal, pode ser impossível comprovar algumas propriedades de um contrato, mesmo se estiver bem especificado.
-
-## Ferramentas de verificação formal para contratos inteligentes Ethereum {#formal-verification-tools}
-
-### Linguagens de especificação para criação de especificações formais {#specification-languages}
-
-**Act**: _*O Act permite a especificação de atualizações de armazenamento, condições de pré/pós e invariáveis do contrato. Seu conjunto de ferramentas também tem backends capazes de comprovar muitas propriedades via Coq, solucionadores SMT, ou hevm.**
-
-- [GitHub](https://github.com/ethereum/act)
-- [Documentação](https://ethereum.github.io/act/)
-
-**Scribble** - _*Scribble transforma anotações de código na linguagem de especificação Scribble em afirmações concretas que verificam a especificação.**
-
-- [Documentação](https://docs.scribble.codes/)
-
-**Dafny** - _*Dafny é uma linguagem de programação pronta para verificação que depende de anotações de alto nível para argumentar e comprovar a exatidão do código.**
-
-- [GitHub](https://github.com/dafny-lang/dafny)
-
-### Verificadores de programa para checagem de exatidão {#program-verifiers}
-
-**Certora Prover** - _Certora Prover é uma ferramenta de verificação formal automática para verificar a exatidão do código em contratos inteligentes. As especificações são escritas em CVL (Certora Verification Language), com violações de propriedade detectadas usando uma combinação de análise estática e resolução de restrições._
-
-- [Site](https://www.certora.com/)
-- [Documentação](https://docs.certora.com/en/latest/index.html)
-
-**Solidity SMTChecker** - _*Solidity’s SMTChecker é um verificador de modelos integrado com base no SMT (Teorias do Módulo de Satisfiabilidade) e na resolução de Horn. Ele confirma se o código-fonte de um contrato corresponde às especificações durante a compilação e procura estaticamente por violações de propriedades de segurança.**
-
-- [GitHub](https://github.com/ethereum/solidity)
-
-**solc-verify** - _*solc-verify é uma versão estendida do compilador Solidity que pode executar a verificação formal automatizada no código Solidity usando anotações e verificação de programa modular.**
-
-- [GitHub](https://github.com/SRI-CSL/solidity)
-
-**KEVM** - _*KEVM é uma semântica formal da Máquina Virtual Ethereum (EVM) escrita no framework K. KEVM é executável e pode comprovar determinadas declarações relacionadas à propriedade usando a lógica de alcançabilidade.**
-
-- [GitHub](https://github.com/runtimeverification/evm-semantics)
-- [Documentação](https://jellopaper.org/)
-
-### Frameworks lógicos para comprovação de teorema {#theorem-provers}
-
-**Isabelle** - _Isabelle/HOL é um assistente de comprovação que permite que fórmulas matemáticas sejam expressas em uma linguagem formal e fornece ferramentas para comprovar essas fórmulas. A aplicação principal é a formalização de provas matemáticas e, em particular, a verificação formal, que inclui comprovar a exatidão do hardware ou software de computador e comprovar propriedades de linguagens e protocolos de computador._
-
-- [GitHub](https://github.com/isabelle-prover)
-- [Documentação](https://isabelle.in.tum.de/documentation.html)
-
-**Coq** - _Coq é um comprovador de teorema interativo que permite definir programas usando teoremas e interativamente gerar comprovações de correção verificadas por máquina._
-
-- [GitHub](https://github.com/coq/coq)
-- [Documentação](https://coq.github.io/doc/v8.13/refman/index.html)
-
-### Ferramentas de execução simbólica para detectar padrões vulneráveis em contratos inteligentes {#symbolic-execution-tools}
-
-**Manticore** - _*Uma ferramenta para analisar a ferramenta de análise de bytecode EVM com base em execução simbólica*.*
-
-- [GitHub](https://github.com/trailofbits/manticore)
-- [Documentação](https://github.com/trailofbits/manticore/wiki)
-
-**hevm** - _*hevm é um mecanismo de execução simbólico e um verificador de equivalência para bytecode EVM.**
-
-- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm)
-
-**Mythril** - _Uma ferramenta de execução simbólica para detectar vulnerabilidades nos contratos inteligentes da Ethereum_
-
-- [GitHub](https://github.com/ConsenSys/mythril-classic)
-- [Documentação](https://mythril-classic.readthedocs.io/en/develop/)
-
-## Leitura adicional {#further-reading}
-
-- [Como funciona a verificação formal dos contratos inteligentes](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/)
-- [Como a verificação formal pode garantir contratos inteligentes infalíveis](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1)
-- [Uma visão geral dos Projetos de Verificação Formal no Ecossistema Ethereum](https://github.com/leonardoalt/ethereum_formal_verification_overview)
-- [Verificação formal de ponta a ponta do contrato inteligente de depósito Ethereum 2.0](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/)
-- [Verificando formalmente o Contrato Inteligente Mais Popular do Mundo](https://www.zellic.io/blog/formal-verification-weth)
-- [SMTChecker e Verificação Formal](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html)
diff --git "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" "b/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
deleted file mode 100644
index e00ded094e6..00000000000
--- "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
+++ /dev/null
@@ -1,308 +0,0 @@
----
-title: Testes de contratos inteligentes
-description: Uma visão geral das técnicas e considerações para testar contratos inteligentes Ethereum.
-lang: pt-br
----
-
-Blockchains públicas como Ethereum são imutáveis, dificultando alterações de código de contratos inteligentes após sua implementação. Existem [padrões de atualização de contrato](/developers/docs/smart-contracts/upgrading/) para realizar "atualizações virtuais", mas são difíceis de implementar e requer um consenso social. Além disso, uma atualização só pode corrigir um erro _após_ que é descoberto se um invasor descobrir a vulnerabilidade primeiro, seu contrato inteligente corre o risco sofrer um exploit.
-
-Por estas razões, testar contratos inteligentes antes de [implementar](/developers/docs/smart-contracts/deploying/) à rede principal é o requisito mínimo para [segurança](/developers/docs/smart-contracts/security/). Existem muitas técnicas para testar contratos e avaliar a corretude de código; qual escolher depende de suas necessidades. No entanto, um conjunto de testes feito a partir de diferentes ferramentas e abordagens é ideal para pegar pequenas e grandes falhas de segurança no código do contrato.
-
-## Pré-requisitos {#prerequisites}
-
-Esta página explica como testar contratos inteligentes antes de implantar na rede Ethereum. Pressupõe-se que você esteja familiarizado com [contratos inteligentes](/developers/docs/smart-contracts/).
-
-## O que é teste de contrato inteligente? {#what-is-smart-contract-testing}
-
-O teste de contrato inteligente é o processo de verificação de que o código de um contrato inteligente funciona conforme o esperado. Testar é útil para verificar se um contrato inteligente específico atende aos requisitos de confiabilidade, usabilidade e segurança.
-
-Embora as abordagens variem, a maioria dos métodos de teste exige a execução de um contrato inteligente com uma pequena amostra dos dados que se espera manipular. Se o contrato produzir resultados corretos para dados da amostra, presume-se que esteja funcionando corretamente. A maioria das ferramentas de teste fornece recursos para escrever e executar [casos de teste](https://en.m.wikipedia.org/wiki/Test_case) para verificar se a execução de um contrato corresponde aos resultados esperados.
-
-### Por que é importante testar contratos inteligentes? {#importance-of-testing-smart-contracts}
-
-Como os contratos inteligentes geralmente gerenciam ativos financeiros de alto valor, pequenos erros de programação podem e geralmente levam a [perdas massivas para os usuários](https://rekt.news/leaderboard/). Testes rigorosos podem, no entanto, ajudar a descobrir de maneira antecipada erros e problemas no código de um contrato inteligente e corrigi-los antes do lançamento na rede principal.
-
-Embora seja possível atualizar um contrato se um bug for descoberto, as atualizações são complexas e podem [ resultar em erros](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) se tratadas de forma inadequada. A atualização de um contrato vai contra o princípio da imutabilidade e sobrecarrega os usuários com suposições de confiança adicionais. Por outro lado, um plano abrangente para testar seu contrato reduz os riscos de segurança do contrato inteligente e reduz a necessidade de realizar atualizações lógicas complexas após a implantação.
-
-## Métodos para testar contratos inteligentes {#methods-for-testing-smart-contracts}
-
-Os métodos para testar contratos inteligentes no Ethereum se dividem em duas categorias amplas: **teste automatizado** e **teste manual**. Testes automatizados e testes manuais tem seus prós e contras, mas você pode combinar ambos para criar um plano robusto para analisar seus contratos.
-
-### Teste automatizado {#automated-testing}
-
-O teste automatizado usa ferramentas que verificam automaticamente um código de contratos inteligentes em busca de erros na execução. O benefício do teste automatizado vem do uso de [scripts](https://www.techtarget.com/whatis/definition/script?amp=1) para orientar a avaliação das funcionalidades do contrato. Os scripts de testes podem ser programados para serem executados repetidamente com o mínimo de intervenção humana, tornando o teste automatizado mais eficiente do que as abordagens manuais de teste.
-
-O teste automatizado é particularmente útil quando os testes são repetitivos e demorados; difícil de realizar manualmente; suscetíveis a erro humano; ou envolvem a avaliação de funções contratuais críticas. Mas as ferramentas de teste automatizadas podem ter desvantagens - elas podem perder certos bugs e produzir muitos [falsos positivos](https://www.contrastsecurity.com/glossary/false-positive). Portanto, combinar testes automatizados com testes manuais para contratos inteligentes é ideal.
-
-### Teste manual {#manual-testing}
-
-O teste manual é auxiliado por humanos e envolve a execução de cada caso de teste em seu conjunto de testes, um após o outro, ao analisar a corretude de um contrato inteligente. Isso é diferente do teste automatizado, no qual você pode executar simultaneamente vários testes isolados em um contrato e obter um relatório mostrando todos os testes que falharam e os que foram aprovados.
-
-O teste manual pode ser realizado por um único indivíduo seguindo um plano de teste escrito que cobre diferentes cenários de teste. Você também pode ter vários indivíduos ou grupos interagindo com um contrato inteligente durante um período especificado como parte do teste manual. Os testadores compararão o comportamento real do contrato com o comportamento esperado, sinalizando qualquer diferença como um bug.
-
-Um teste manual eficaz requer recursos consideráveis (habilidade, tempo, dinheiro e esforço) e é possível, devido a erro humano, perder certos erros durante a execução dos testes. Mas o teste manual também pode ser benéfico - por exemplo, um testador humano (por exemplo, um auditor) pode usar a intuição para detectar casos extremos que uma ferramenta de teste automatizada perderia.
-
-## Teste automatizado para contratos inteligentes {#automated-testing-for-smart-contracts}
-
-### Teste unitário {#unit-testing-for-smart-contracts}
-
-O teste unitário avalia as funções do contrato separadamente e verifica se cada componente funciona corretamente. Testes unitários bons devem ser simples, rápidos de executar e fornecer uma ideia clara do que deu errado se os testes falharem.
-
-Os testes unitários são úteis para verificar se as funções retornam os valores esperados e se o armazenamento do contrato é atualizado corretamente após a execução da função. Além disso, a execução de testes unitários após fazer alterações em uma base de código de contratos garante que a adição de nova lógica não introduza erros. Abaixo estão algumas diretrizes para executar testes unitários eficazes:
-
-#### Diretrizes para testes unitários de contratos inteligentes {#unit-testing-guidelines}
-
-##### 1. Entenda a lógica de negócios e o fluxo de trabalho de seus contratos
-
-Antes de escrever testes unitários, é bom saber quais funcionalidades um contrato inteligente oferece e como os usuários acessarão e usarão essas funções. Isso é particularmente útil para executar [testes de caminho feliz](https://en.m.wikipedia.org/wiki/Happy_path) que determinam se as funções em um contrato retornam a saída correta para entradas válidas do usuário. Explicaremos esse conceito usando este exemplo (resumido) de [um contrato de leilão](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple- open-auction)
-
-```
-constructor(
- uint biddingTime,
- address payable beneficiaryAddress
- ) {
- beneficiary = beneficiaryAddress;
- auctionEndTime = block.timestamp + biddingTime;
- }
-
-function bid() external payable {
-
- if (block.timestamp > auctionEndTime)
- revert AuctionAlreadyEnded();
-
- if (msg.value <= highestBid)
- revert BidNotHighEnough(highestBid);
-
- if (highestBid != 0) {
- pendingReturns[highestBidder] += highestBid;
- }
- highestBidder = msg.sender;
- highestBid = msg.value;
- emit HighestBidIncreased(msg.sender, msg.value);
- }
-
- function withdraw() external returns (bool) {
- uint amount = pendingReturns[msg.sender];
- if (amount > 0) {
- pendingReturns[msg.sender] = 0;
-
- if (!payable(msg.sender).send(amount)) {
- pendingReturns[msg.sender] = amount;
- return false;
- }
- }
- return true;
- }
-
-function auctionEnd() external {
- if (block.timestamp < auctionEndTime)
- revert AuctionNotYetEnded();
- if (ended)
- revert AuctionEndAlreadyCalled();
-
- ended = true;
- emit AuctionEnded(highestBidder, highestBid);
-
- beneficiary.transfer(highestBid);
- }
-}
-```
-
-Este é um contrato de leilão simples projetado para receber lances durante o período de submissão de ofertas. Se a variável `highestBid` aumentar, o licitante anterior mais alto receberá seu dinheiro; uma vez terminado o período de licitação, o objeto `beneficiary` aciona o contrato para obter seu dinheiro.
-
-Testes unitários para um contrato como este cobriria diferentes funções que um usuário poderia chamar quando interagindo com o contrato. Um exemplo seria um teste unitário que verifica se um usuário pode fazer uma oferta enquanto o leilão está em andamento (ou seja, que as chamadas para `bid()` são bem-sucedidas) ou um que verifica se um usuário pode fazer uma oferta maior do que a atual `highestBid`.
-
-Entendendo o fluxo operacional do contrato também ajuda a escrever testes unitários que checam se a execução atende os requisitos. Por exemplo, o contrato de leilão especifica que os usuários não podem colocar ordens quando o leilão terminou (ou seja, quando `auctionEndTime` é menor que `block.timestamp`). Portanto, o desenvolvedor deve rodar um teste unitário que checa se chamadas para a função `bid()` tiveram sucesso ou falharam quando o leilão terminou (ou seja, quando `auctionEndTime` > `block.timestamp`).
-
-##### 2. Avalie todas as suposições relacionadas à execução do contrato
-
-É importante documentar quaisquer suposições sobre a execução do contrato e escrever testes unitários para verificar a validade destas suposições. Além de oferecer proteção contra execução inesperada, testar afirmações força você a pensar sobre operações que poderiam quebrar o modelo de segurança do contrato inteligente. Uma dica útil é ir além dos "testes do usuário feliz" e escrever testes negativos que checam se a função falha com as entradas erradas.
-
-Muitos frameworks de teste unitário permitem você criar afirmações - simples declarações que declaram o que um contrato pode e não pode fazer - e rodar testes para ver se estas afirmações funcionam durante a execução. Um desenvolvedor trabalhando no contrato de leilão descrito anteriormente poderia fazer as seguintes afirmações sobre o seu comportamento antes de rodar testes negativos:
-
-- Usuários não podem colocar ordens quando o leilão acabou ou não começou.
-
-- O contrato de leilão reverte se a ordem é abaixo do limite aceitável.
-
-- Usuários que falham em vencer o leilão são creditados com seus fundos
-
-**Nota**: Uma outra maneira de testar suposições é escrever testes que disparam [modificadores de função](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) em um contrato, especialmente declarações`require`, `assert`, e `if…else`.
-
-##### 3. Medida de cobertura do código
-
-[Cobertura de código](https://en.m.wikipedia.org/wiki/Code_coverage) é uma métrica de teste que rastreia o número de ramificações, linhas e comandos no seu código executados durante os testes. Testes devem ter boa cobertura de código, caso contrário você pode ter "falsos negativos" que acontecem quando um contrato passa todos os testes, mas vulnerabilidades ainda existem no código. Obtendo alta cobertura de código, entretanto, dá a segurança que todos os comandos/funções em um contrato inteligente foram suficientemente testados por exatidão.
-
-##### 4. Use frameworks de teste bem desenvolvidos
-
-A qualidade das ferramentas usada para rodar testes unitários para o seu contrato inteligente é crucial. Um framework de teste ideal é aquele que é regularmente mantido; fornece recursos úteis (por exemplo, capacidades de log e relatórios); e tem de ter sido extensivamente usado por outros desenvolvedores.
-
-Frameworks de teste unitário para contratos inteligentes em Solidity vêm em diferentes linguagens (geralmente JavaScript, Python e Rust). Veja alguns dos guias abaixo para informações sobre como começar a rodar testes unitários com diferentes frameworks de teste:
-
-- **[Rodando testes unitários com Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
-- **[Rodando testes unitários com Foundry](https://book.getfoundry.sh/forge/writing-tests)**
-- **[Rodando testes unitários com Waffle](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
-- **[Rodando testes unitários com Remix](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
-- **[Rodando testes unitários com Ape](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
-- **[Rodando testes unitários com Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
-- **[Como executar testes unitários com Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
-
-### Teste de Integração {#integration-testing-for-smart-contracts}
-
-Enquanto o teste unitário depura funções de contrato isoladamente, testes integrados avaliam os componentes de um contrato inteligente como um todo. Teste de integração pode detectar defeitos vindos de chamadas entre contratos ou interações entre diferentes funções no mesmo contrato inteligente. Por exemplo, testes de integração podem ajudar a checar se coisas como [herança](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) e injeção de dependência funcionam devidamente.
-
-Teste de integração é útil se o seu contrato adota uma arquitetura modular ou interfaces com outros contratos on-chain durante a execução. Uma maneira de executar testes de integração é [fazer um fork da blockchain](/glossary/#fork) a uma altura específica (usando uma ferramenta como [Forge](https://book.getfoundry.sh/forge/fork-testing) ou [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) e simular interações entre seu contrato e contratos implantados.
-
-O blockchain que sofreu fork irá se comportar similarmente à Mainnet e ter contas com estados e saldos associados. Mas ele age somente como um ambiente de área local de desenvolvimento restrita, significando que você não precisará de ETH real para transações, por exemplo, nem suas modificações irão afetar o protocolo Ethereum real.
-
-### Teste baseado em propriedade {#property-based-testing-for-smart-contracts}
-
-Teste baseado em propriedade é o processo de checar que um contrato inteligente satisfaz algumas propriedades definidas. Propriedades afirmam fatos sobre o comportamento de um contrato esperado continuar verdadeiro em diferentes cenários - um exemplo de propriedade de contrato inteligente poderia ser "Operações aritméticas no contrato nunca sofrem overflow ou underflow."
-
-**Análise estática** e **análise dinâmica** são duas técnicas comuns de execução de teste baseado em propriedade, e ambas podem verificar que o código para um programa (um contrato inteligente no caso) satisfaz algumas propriedades pré-definidas. Algumas ferramentas de teste baseadas em propriedade vem com regras pré-definidas sobre propriedades esperadas de contratos e checam o código contra estas regras, enquanto outras permitem você criar propriedades customizadas para um contrato inteligente.
-
-#### Análise estática {#static-analysis}
-
-Um analisador estático pega como entrada o código-fonte de um contrato inteligente e retorna resultados declarando se o contrato satisfaz a propriedade ou não. Diferente da análise dinâmica, análise estática não envolve executar um contrato para analisá-lo por exatidão. Análise estática gera razões alternativas sobre todos os caminhos possíveis que um contrato inteligente poderia tomar durante a execução (ou seja, examinando a estrutura do código-fonte para determinar o que significaria para a operação do contrato em tempo de execução).
-
-Testes [Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) e [estático](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) são métodos comuns de rodar análise estática em contratos. Ambos requerem analisar representações de baixo nível da execução de um contrato, como [árvores de sintaxe abstrata](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) e [gráficos de controle de fluxo](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) retornados pelo compilador.
-
-Na maioria dos casos, análise estática é útil para detectar problemas de segurança como uso de construtores inseguros, erros de sintaxe, ou violações de padrões de código no código de contratos. Entretanto, analisadores estáticos são conhecidos por geralmente serem instáveis em detectar vulnerabilidades mais profundas, e podem produzir excessivos falsos positivos.
-
-#### Análise dinâmica {#dynamic-analysis}
-
-Análise dinâmica gera entradas simbólicas (por exemplo, em [execução simbólica](https://en.m.wikipedia.org/wiki/Symbolic_execution)) ou entradas concretas (por exemplo, em [fuzzing](https://owasp.org/www-community/Fuzzing)) para funções de contratos inteligentes para ver se qualquer trace de execução violou propriedades específicas. Esta forma de teste baseado em propriedades difere dos testes unitários no tocante a casos de teste cobrem múltiplos cenários e um programa manipula a geração de casos de teste.
-
-[Fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) é um exemplo de análise técnica dinâmica para verificar propriedades arbitrárias em contratos inteligentes. Um fuzzer invoca funções em um contrato alvo com variações randômicas ou mal formadas de um valor de entrada definido. Se um contrato inteligente entra em estado de erro (por exemplo, uma afirmação 'where' falha), o problema é indicado e as entradas que geraram esta execução para o caminho da vulnerabilidade são produzidas em um relatório.
-
-Fuzzing é útil para avaliação de um mecanismo de validação de entrada de contratos inteligentes, já que manipulação imprópria de entradas inesperadas pode resultar em execução não pretendida e produzir efeitos perigosos. Esta forma de teste baseado em propriedade pode ser ideal por muitas razões:
-
-1. **Escrever casos de teste para cobrir muitos cenários é difícil.** Um teste de propriedade somente requer que você defina o comportamento e faixa de dados com a qual testar o comportamento - o programa automaticamente gera casos de teste baseados na propriedade definida.
-
-2. **Sua suíte de testes pode não cobrir suficientemente todos os caminhos possíveis dentro do programa. ** Até com 100% de cobertura, é possível perder alguns casos limítrofes.
-
-3. **Testes unitários provam que um contrato executa corretamente para dados de amostra, mas se o contrato executa corretamente para entradas fora das amostras, permanece desconhecido.** Testes de propriedade executam um contrato alvo com múltiplas variações de uma dado valor de entrada para encontrar traços de execução que causaram falhas de afirmação. Por isso, um teste proprietário fornece mais garantias que um contrato execute corretamente para uma larga classe de dados de entrada.
-
-### Orientações para rodar teste baseado em propriedade para contratos inteligentes {#running-property-based-tests}
-
-Executar testes baseados em propriedade geralmente começa com a definição da propriedade (por exemplo, ausência de [overflows de inteiro](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) ou com coleções de propriedades que você quer verificar em um contrato inteligente. Você pode também precisar definir uma faixa de valores dentro da qual o programa pode gerar dados para entradas de transação quando escrevendo os testes de propriedade.
-
-Uma vez configurado propriamente, a ferramenta de teste de propriedade irá executar as suas funções do contrato inteligente com entradas aleatoriamente geradas. Se houver quaisquer violações de afirmações, você deve receber um relatório com os dados de entrada concretos que violaram a propriedade sendo avaliada. Veja alguns dos guias abaixo para começar com testes baseados em propriedade com diferentes ferramentas:
-
-- **[Análise estática de contratos inteligentes com Slither](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)**
-- **[Análise estática de contratos inteligentes com Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
-- **[Teste baseado em propriedade com Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
-- **[Testando contratos com fuzzing com o Foundry](https://book.getfoundry.sh/forge/fuzz-testing)**
-- **[Testando contratos com fuzzing com o Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
-- **[Testando contratos com fuzzing usando Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
-- **[Execução simbólica de contratos inteligentes com Manticore](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
-- **[Execução simbólica de contratos inteligentes com Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
-
-## Testes manuais para contratos inteligentes {#manual-testing-for-smart-contracts}
-
-Teste manual de contratos inteligentes frequentemente vêm mais tarde no ciclo de desenvolvimento, após rodar testes automatizados. Essa forma de teste avalia o contrato inteligente como um produto totalmente integrado para ver se ele executa conforme especificado nos requisitos técnicos.
-
-### Testando contratos no blockchain local {#testing-on-local-blockchain}
-
-Enquanto testes automatizados realizados em um ambiente local de desenvolvimento podem fornecer informações úteis de depuração, você irá querer saber como seus contrato inteligente se comporta em um ambiente de produção. Entretanto, implantar na cadeia principal do Ethereum incorre em taxas de gas - sem mencionar que você ou seus usuários podem perder dinheiro real se o seu contrato inteligente ainda tem falhas.
-
-Testar seu contrato em um blockchain local (também conhecido como uma [rede de desenvolvimento](/developers/docs/development-networks/)) é uma alternativa recomendada em relação a testar na Mainnet. Um blockchain local é uma cópia do blockchain Ethereum rodando localmente no seu computador que simula o comportamento da camada de execução do Ethereum. Como tal, você pode programar transações para interagir com um contrato sem incorrer em custo significante.
-
-Rodar contratos em blockchain local pode ser útil como forma de teste de integração manual. [Contratos inteligentes são altamente combináveis](/developers/docs/smart-contracts/composability/), permitindo você integrar com protocolos existentes - mais você ainda precisará garantir que interações on-chain assim tão complexas produzam os resultados corretos.
-
-[Mais sobre redes de desenvolvimento.](/developers/docs/development-networks/)
-
-### Testando contratos nas redes de teste {#testing-contracts-on-testnets}
-
-Uma rede de teste ou testnet funciona exatamente como o Ethereum Mainnet, exceto que ela usa Ether (ETH) sem valor no mundo real. Implantar seu contrato em uma [testnet](/developers/docs/networks/#ethereum-testnets) significa que qualquer um pode interagir com ele (por exemplo, via o front-end do dapp) sem colocar fundos em risco.
-
-Esta forma de teste manual é útil para avaliação do fluxo fim-a-fim da sua aplicação do ponto de vista do usuário. Aqui, testadores beta podem também realizar execuções experimentais e reportar qualquer problema com a lógica de negócios do contrato e funcionalidade geral.
-
-Implantar na testnet depois de testar no blockchain local é ideal desde que o primeiro é mais perto do comportamento da Máquina Virtual Ethereum. Portanto, é comum para muitos projetos nativos do Ethereum implantar dapps nas testnets para avaliar a operação dos contratos inteligentes em condições de vida real.
-
-[Mais sobre redes de teste do Ethereum.](/developers/docs/development-networks/#public-beacon-testchains)
-
-## Testes vs. Verificação formal {#testing-vs-formal-verification}
-
-Ao passo que testar ajuda a confirmar se um contrato retorna os resultados esperados para algumas entradas de dados, isso não pode comprovar de forma conclusiva o mesmo para entradas não utilizadas durante os testes. Testar um contrato inteligente, portanto, não pode garantir "correção funcional" (o que significa que não pode mostrar que um programa se comporta conforme necessário para _todos os_ conjuntos de valores de entrada).
-
-Verificação formal é uma abordagem para avaliação da correção do software checando se um modelo formal do programa bate com a especificação formal. Um modelo formal é uma representação matemática abstrata de um programa, enquanto uma especificação formal define as propriedades de um programa (por exemplo, afirmações lógicas sobre a execução do programa).
-
-Pelo fato de propriedades serem escritas em termos matemáticos, é possível verificar que um modelo formal (matemático) do sistema satisfaz uma especificação usando regras lógicas de inferência. Por isso, ferramentas de verificação formal são ditas produzir 'provas matemáticas' da correção de um sistema.
-
-Diferente de testar, verificações formais podem ser usadas para verificar se a execução de um contrato inteligente satisfaz uma especificação formal para _todas_ as execuções (por exemplo, não ter falhas) sem necessitar executá-lo com dados de amostra. Não apenas isto reduz tempo gasto em rodar dezenas de testes unitários, mas é também mais efetivo na caça por vulnerabilidades escondidas. Dito isto, técnicas de verificação formal se baseiam em um espectro dependendo da sua dificuldade de implementação e utilidade.
-
-[Saiba mais sobre verificação formal de contratos inteligentes.](/developers/docs/smart-contracts/formal-verification)
-
-## Testes vs auditorias e recompensas por bugs {#testing-vs-audits-bug-bounties}
-
-Como mencionado, testes rigorosos raramente podem garantir a ausência de bugs em um contrato; abordagens de verificação formal podem fornecer garantias mais fortes da correção, mas atualmente são difíceis de usar e incorrem em custos consideráveis.
-
-Ainda assim, você pode aumentar a possibilidade de encontrar vulnerabilidades de contrato pegando uma revisão independente de código. [Auditorias de contratos inteligentes](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) e [recompensas por bugs](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) são duas maneiras de ter outros analisando os seus contratos.
-
-Auditorias são realizadas por auditores experientes em encontrar casos de falhas de segurança e práticas pobres de desenvolvimento em contratos inteligentes. Uma auditoria irá geralmente incluir testes (e possivelmente verificação formal) assim como revisão manual de todo o código.
-
-Por outro lado, um programa de recompensas por bug geralmente envolve oferta de recompensa financeira para um indivíduo (geralmente descrito como um [whitehat hackers](https://en.wikipedia.org/wiki/White_hat_(computer_security))) que descobre uma vulnerabilidade em um contrato inteligente e divulga-a para os desenvolvedores. As recompensas por bugs são semelhantes às auditorias, uma vez que envolve pedir que outras pessoas ajudem a encontrar defeitos em contratos inteligentes.
-
-A maior diferença é que programas de recompensa por bug são abertos a uma maior comunidade de desenvolvedores/hackers e atraem uma vasta classe de hackers éticos e profissionais de segurança independentes com habilidades únicas e experiência. Isso pode ser uma vantagem em relação às auditorias de contratos inteligentes, que dependem principalmente de equipes que podem possuir conhecimentos especializados limitados ou estreitos.
-
-## Testando ferramentas e bibliotecas {#testing-tools-and-libraries}
-
-### Ferramentas de testes unitários {#unit-testing-tools}
-
-- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Ferramenta de cobertura de código para contratos inteligentes escritos em Solidity._
-
-- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _Framework para desenvolvimento avançado de contratos inteligentes e teste (baseado no ethers.js)_.
-
-- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Ferramenta para testar contratos inteligentes em Solidity. Funciona abaixo do plugin Remix IDE "Solidity Unit Testing" usado para escrever e executar casos de teste para um contrato._
-
-- **[Auxiliar para Teste do OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _Biblioteca de asserções para teste de contrato inteligente Ethereum. Certifique-se de que seus contratos se comportam como esperado!_
-
-- **[Framework de teste de unidade do Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie utiliza Pytest, uma estrutura de teste rica em recursos que permite que você escreva pequenos testes com o mínimo de código, escala bem para grandes projetos e é altamente extensível._
-
-- **[Froundry Testes](https://github.com/foundry-rs/foundry/tree/master/forge)** - _Foundry oferece o Forge, um framework de teste no Ethereum rápido e flexível, capaz de executar testes de unidade simples, verificações de otimização de gás e mutações (fuzzing) em contratos._
-
-- **[Hardhat Testes](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _Framework para testar contratos inteligentes com base no ethers.js, Mocha e Chai._
-
-- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _Desenvolvimento baseado em Python e framework de teste para contratos inteligentes voltados para a Máquina Virtual Ethereum._
-
-- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Framework baseado em Python para teste unitário e fuzzing com fortes capacidades de depuração e suporte a testes cross-chain, utilizando pytest e Anvil para a melhor experiência e desempenho do usuário._
-
-### Ferramentas de teste baseadas em propriedades {#property-based-testing-tools}
-
-#### Ferramentas de análise estática {#static-analysis-tools}
-
-- **[Slither](https://github.com/crytic/slither)** - _Framework com base no Python de análise estática estabelecida no Solidity para encontrar vulnerabilidades, aprimorar a compreensão do código e escrever análises personalizadas para contratos inteligentes._
-
-- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Analisador (linter) para garantir as práticas recomendadas de estilo e segurança para a linguagem de programação de contrato inteligente Solidity._
-
-- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Analisador estático baseado em Rust especificamente projetado para a segurança e o desenvolvimento de contratos inteligentes Web3._
-
-- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _Framework de análise estática baseado em Python com detectores de vulnerabilidades e qualidade de código, impressoras para extrair informações úteis do código e suporte para a criação de submódulos personalizados._
-
-#### Ferramentas de análise dinâmica {#dynamic-analysis-tools}
-
-- **[Echidna](https://github.com/crytic/echidna/)** - _Fuzzer (analisador) de contrato para detectar vulnerabilidades em contratos inteligentes por meio de testes baseados em propriedade._
-
-- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _ Ferramenta de análise automatizada útil para detectar violações de propriedade no código de contrato inteligente._
-
-- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _Framework de execução simbólica dinâmica para análise de bytecode na EVM._
-
-- **[Mithril](https://github.com/ConsenSys/mythril-classic)** - _ Ferramenta para diagnóstico de bytecode na EVM para detectar vulnerabilidades de contrato usando análise de contaminação, análise simbólica e verificação de fluxo de controle._
-
-- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _ Scribble é uma linguagem de especificação e ferramenta de verificação do tempo de execução, que possibilita anotar contratos inteligentes com propriedades, o que permite testar automaticamente os contratos com ferramentas como Diligence Fuzzing ou MythX._
-
-## Tutoriais relacionados {#related-tutorials}
-
-- [Uma visão geral e comparação de diferentes produtos de teste](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
-- [Como usar o Echidna para testar contratos inteligentes](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
-- [Como usar o Manticore para encontrar bugs em contratos inteligentes](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
-- [Como utilizar o Slither para encontrar bugs nos contratos inteligentes](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
-- [Como simular contratos Solidity para teste](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
-- [Como executar testes unitários em Solidity usando Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
-
-## Leitura adicional {#further-reading}
-
-- [Um guia detalhado para testar contratos inteligentes do Ethereum](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
-- [Como testar contratos inteligentes do Ethereum](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
-- [Guia de teste de unidade do MolochDAO para desenvolvedores](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
-- [Como testar contratos inteligentes como um astro do rock](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" "b/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
deleted file mode 100644
index 0ea6b7aca97..00000000000
--- "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: Atualizando contratos inteligentes
-description: Uma visão geral dos padrões de atualização de contratos inteligentes no Ethereum
-lang: pt-br
----
-
-Contratos inteligentes no Ethereum são programas auto-executados que rodam em Máquina Virtual Ethereum (EVM). Estes programas são imutáveis por desenho, o que evita quaisquer atualizações na lógica de negócios uma vez que o contrato é implantado.
-
-Enquanto imutabilidade é necessária para falta de confiança, descentralização, e segurança de contratos inteligentes, ela pode ser um problema em certos casos. Por exemplo, código imutável pode tornar impossível desenvolvedores consertar contratos vulneráveis.
-
-Entretanto, mais pesquisas sobre melhoria de contratos inteligentes tem levado à introdução de vários padrões de atualização. Estes padrões de atualização permitem a desenvolvedores atualizar contratos inteligentes (enquanto preservam a imutabilidade) colocando lógica de negócio em diferentes contratos.
-
-## Pré-requisitos {#prerequisites}
-
-Você deve ter um bom entendimento de [contratos inteligentes](/developers/docs/smart-contracts/), [anatomia de contratos inteligentes](/developers/docs/smart-contracts/anatomy/), e a [Máquina Virtual Ethereum (EVM)](/developers/docs/evm/). Este guia também presume que os leitores entendam de programação de contratos inteligentes.
-
-## O que é uma atualização de contrato inteligente? {#what-is-a-smart-contract-upgrade}
-
-Uma atualização de contrato inteligente envolve mudar a lógica de negócios de um contrato inteligente enquanto preserva o estado do contrato. É importante esclarecer que capacidade de atualização e mutabilidade não são o mesmo, especialmente no contexto de contratos inteligentes.
-
-Você ainda não pode mudar um programa implantado em um endereço na rede Ethereum. Mas você pode alterar o código que é executado quando usuários interagem com um contrato inteligente.
-
-Isto pode ser feito por meio dos seguintes métodos:
-
-1. Criando múltiplas versões de um contrato inteligente e migrando o estado (ou seja, os dados) de um contrato antigo para uma nova instância do contrato.
-
-2. Criando contratos separados para armazenar lógica de negócios e estado.
-
-3. Usando padrões de proxy para delegar chamadas de função de um contrato de proxy imutável para um contrato de lógica modificável.
-
-4. Criando um contrato principal imutável que faz interface e confia em contratos satélites flexíveis para executar funções específicas.
-
-5. Usando o padrão diamante para delegar chamadas de função de um contrato proxy para contratos lógicos.
-
-### Mecanismo de atualização 1: Migração de contrato {#contract-migration}
-
-Migração de contrato é baseada no versionamento - a ideia de criar e gerenciar estados únicos do mesmo software. Migração de contrato envolve implantar uma nova instância de um contrato inteligente existente e transferir o storage e saldos para o novo contrato.
-
-O recém-implantado contrato terá um storage vazio, permitindo você recuperar dados do contrato antigo e escrevê-lo na nova implementação. Depois disso, você precisará atualizar todos os contratos que interagiram com o contrato antigo para refletir o novo endereço.
-
-O último passo na migração do contrato é convencer usuários a mudar para o novo contrato. A nova versão do contrato irá reter saldos de usuários e endereços, que preserva a imutabilidade. Se for um contrato baseado em token, você também precisará contatar a corretora para descartar o contrato antigo e usar o novo contrato.
-
-Migração de contrato é uma medida relativamente direta e segura para atualização de contratos inteligentes sem quebrar interações de usuários. Entretanto, migrar manualmente o storage do usuário e saldos para o novo contrato é demorado e pode incorrer em altos gastos com gas.
-
-[Mais sobre migração de contrato.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
-
-### Mecanismo de atualização 2: Separação de dados {#data-separation}
-
-Um outro método para atualização de contratos inteligentes é separar a lógica de negócios e o armazenamento de dados em contratos separados. Isto significa usuários interagirem com a lógica do contrato, enquanto dados são armazenados na storage do contrato.
-
-O contrato lógico contém o código executado quando usuários interagem com a aplicação. Ele também mantém o endereço de storage do contrato e interage com ele para pegar e configurar os dados.
-
-Enquanto isso, o storage do contrato mantém o estado associado com o contrato inteligente, como saldos de usuários e endereços. Note que o storage do contrato é de propriedade da lógica do contrato e é configurado com o endereço do último na implantação. Isto evita contratos não autorizados de chamar o storage do contrato ou atualizar seus dados.
-
-Por padrão, o storage do contrato é imutável - mas você pode substituir o contrato lógico que ele aponta para uma nova implementação. Isto irá mudar o código que roda na EVM, enquanto mantém o storage o saldos intactos.
-
-Usando este método de atualização requer atualizar o endereço do contrato lógico na storage do contrato. Você tem também que configurar o novo contrato lógico com o endereço do storage do contrato, por razões já explicadas anteriormente.
-
-O padrão de separação de dados é discutivelmente mais fácil de implementar comparado à migração de contrato. Entretanto, você terá de gerenciar múltiplos contratos e implementar esquemas complexos de autorização para proteger contratos inteligentes de atualizações maliciosas.
-
-### Mecanismo de atualização 3: Padrões de proxy {#proxy-patterns}
-
-O padrão de proxy também usa separação de dados para manter lógica de negócio e dados em contratos separados. Entretanto, em um padrão de proxy, o storage do contrato (chamado de proxy) chama o contrato lógico durante a execução do código. Isto é o contrário do método de separação de dados, onde o contrato lógico chama o contrato de storage.
-
-Isto é o que acontece em um padrão proxy:
-
-1. Usuários interagem com o contrato de proxy, que armazena dados, mas não mantém a lógica de negócio.
-
-2. O contrato proxy armazena os endereços do contrato lógico e delega todas as chamadas de função para o contrato lógico (que mantém a lógica de negócio) usando a função `delegatecall`.
-
-3. Depois de a chamada ser direcionada para o contrato lógico, os dados retornados do contrato lógico é recuperado e retornado ao usuário.
-
-Usar padrões de proxy requer um entendimento da função **delegatecall**. Basicamente, `delegatecall` é um opcode que permite um contrato chamar outro contrato, enquanto a execução real do código acontece no contexto do contrato chamado. Uma implicação de usar `delegatecall` em padrões proxy é que o contrato proxy lê e escreve no seu storage e executa lógica armazenada no contrato lógico como se chamando uma função interna.
-
-Da [Documentação Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries):
-
-> _Existe uma variante especial de chamada de mensagem, chamada **delegatecall** que é idêntica à chamada de mensagem, exceto pelo fato de que o código no endereço alvo é executado no contexto (ou seja, no endereço) do contrato chamador e `msg.sender` e `msg.value` não mudam seus valores._ _Isto significa que um contrato pode dinamicamente carregar código de um endereço diferente em tempo de execução. Storage, endereço atual e saldo ainda se referem ao contrado chamador, somente o código é pego do endereço chamado._
-
-O contrato proxy sabe invocar `delegatecall` sempre quando um usuário chama a função, porque ele tem uma funçaõ `fallback` construída dentro dele. Em programação Solidity a [função fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) é executada quando uma chamada de função não encontra funções especificadas em um contrato.
-
-Fazer o padrão proxy trabalhar requer escrever uma função fallback customizada que especifique como o contrato proxy deve manipular chamadas de função que ele não suporta. Neste caso, a função de fallback do proxy é programada para iniciar um delegatecall and re-rotear a requisição do usuário para a implementação atual do contrato lógico.
-
-O contrato proxy é imutável por padrão, mas novos contratos lógicos com lógicas de negócio atualizadas podem ser criados. Fazer a atualização é então uma questão de mudança de endereço do contrato lógico referenciado no contrato proxy.
-
-Ao apontar o contrato proxy para um novo contrato lógico, o código executado quando os usuários chamam a função do contrato proxy é alterado. Isso nos permite atualizar a lógica do contrato sem pedir para os usuários interagirem com o novo contrato.
-
-Padrões proxy são um método popular para atualização de contratos inteligentes porque eles eliminam as dificuldades associadas com migração de contrato. No entanto, os padrões de proxy são mais complicados de usar e podem introduzir falhas críticas, como [conflitos do seletor de funções](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357), se usado indevidamente.
-
-[Mais sobre padrões de proxy](https://blog.openzeppelin.com/proxy-patterns/).
-
-### Mecanismo de atualização 4: Padrão de estratégia {#strategy-pattern}
-
-Esta técnica é influenciada pelo [padrão de estratégia](https://en.wikipedia.org/wiki/Strategy_pattern), que encoraja criar programas de software que fazem interface com outros programas para implementar recursos específicos. Aplicar padrão de estratégia para desenvolvimento Ethereum significaria construir um contrato inteligente que chama funções de outros contratos.
-
-O contrato principal neste caso contém o núcleo da lógica de negócio, mas faz interface com outros contratos inteligentes ("contratos satélites") para executar certas funções. Este contrato principal também armazena o endereço para cada contrato satélite e pode alternar entre diferentes implementações de contrato satélite.
-
-Você pode construir um novo contrato satélite e configurar o contrato principal com o novo endereço. Isto permite você mudar _estratégias_ (ou seja, implementar nova lógica) para um contrato inteligente.
-
-Apesar de similar ao padrão de proxy discutido anteriormente, o padrão de estratégia é diferente porque o contrato principal, com o qual usuários interagem, mantém a lógica de negócios. Usar este padrão te dá a oportunidade de introduzir mudanças limitadas a um contrato inteligente sem afetar a infraestrutura principal.
-
-A principal desvantagem é que este padrão é mais útil para implantar atualizações menores. Além disso, se o contrato for comprometido (por exemplo, via um hack), você não pode usar este método de atualização.
-
-### Mecanismo de atualização 5: Padrão Diamante {#diamond-pattern}
-
-O padrão diamante pode ser considerado uma melhoria do padrão proxy. Padrões diamante diferem dos padrões proxy porque o contrato proxy diamante pode delegar chamadas de função para mais de um contrato lógico.
-
-Os contratos lógicos no padrão diamante são conhecidos como _facets_. Para fazer o padrão diamante funcionar, você precisa criar um mapeamento no contrato proxy que mapeie [funções seletoras](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) para endereços facet diferentes.
-
-Quando um usuário faz uma chamada de função, o contrato proxy checa o mapeamento para encontrar o facet responsável por executar aquela função. Então ele invoca `delegatecall` (usando a função fallback) e redireciona a chamada para o devido contrato lógico.
-
-O padrão de atualização diamante tem algumas desvantagens sobre os padrões tradicionais de atualização proxy:
-
-1. Ele permite você atualizar uma pequena parte do contrato sem alterar todo o código. Usar o padrão proxy para atualizações requer criar um contrato lógico inteiramente novo, mesmo para pequenas atualizações.
-
-2. Todos os contratos inteligentes (incluindo contratos lógicos usados nos padrões proxy) tem 24KB de limite de tamanho, o que pode ser uma limitação - especialmente para contratos complexos que requerem mais funções. O padrão diamante facilita resolver este problema dividindo funções por múltiplos contratos lógicos.
-
-3. Padrões proxy adotam uma abordagem de pegar todos para controle de acesso. Uma entidade com acesso a funções de atualização pode mudar o contrato _inteiro_. Mas o padrão diamante habilita uma abordagem de permissões modulares, onde você pode restringir entidades para atualizar certas funções dentro de um contrato inteligente.
-
-[Mais sobre padrão diamante](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
-
-## Prós e contras da atualização de contratos inteligentes {#pros-and-cons-of-upgrading-smart-contracts}
-
-| Prós | Contras |
-| ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| Uma atualização de contrato inteligente pode tornar mais fácil corrigir vulnerabilidades descobertas na fase pós-implantação. | A atualização de contratos inteligentes nega a ideia de imutabilidade do código, o qual tem implicações sobre descentralização e segurança. |
-| Os desenvolvedores podem usar atualizações lógicas para adicionar novas funcionalidades para aplicações descentralizadas. | Os usuários devem confiar nos desenvolvedores para não modificar contratos inteligentes de forma arbitrária. |
-| As atualizações de contratos inteligentes podem melhorar a segurança para os usuários finais, pois os bugs podem ser corrigidos rapidamente. | A funcionalidade de atualização de programação em contratos inteligentes adiciona outra camada de complexidade e aumenta a possibilidade de falhas críticas. |
-| As atualizações de contrato dá aos desenvolvedores mais liberdade para experimentar diferentes recursos e melhorar os dapps ao longo do tempo. | A oportunidade para atualizar contratos inteligentes pode encorajar os desenvolvedores a lançar projetos mais rapidamente sem fazer a devida diligência durante a fase de desenvolvimento. |
-| | O controle de acesso inseguro ou a centralização em contratos inteligentes podem tornar mais fácil por atores maliciosos a execução de atualizações não autorizadas. |
-
-## Considerações para atualizar contratos inteligentes {#considerations-for-upgrading-smart-contracts}
-
-1. Use mecanismos seguros de controle/autorização de acesso para evitar atualizações não autorizadas de contratos inteligentes, especialmente ao usar padrões de proxy, padrões de estratégia ou separação de dados. Um exemplo é restringir o acesso à função de atualização, de modo que apenas o proprietário do contrato possa chamá-lo.
-
-2. A atualização de contratos inteligentes é uma atividade complexa e requer um alto nível de diligência para impedir a introdução de vulnerabilidades.
-
-3. Reduza as suposições de confiança ao descentralizar o processo de implementação de atualizações. As estratégias possíveis incluem usar um [contrato de carteira multi-sig](/developers/docs/smart-contracts/#multisig), para controlar atualizações ou exigir [membros de um DAO](/dao/) para votar na aprovação da atualização.
-
-4. Esteja ciente dos custos envolvidos na atualização de contratos. Por uma razão que, ao copiar o estado (por exemplo, saldos do usuário) de um contrato antigo para um novo contrato durante a migração do contrato pode exigir mais do que uma transação, o que significa mais taxas de gás.
-
-5. Considere implementar **bloqueios de tempo** para proteger os usuários. Um bloqueio de tempo se refere a um atraso aplicado de mudanças em um sistema. Os bloqueios de tempo podem ser combinados com um sistema de governança multi-sig para controlar as atualizações: se uma ação proposta atingir o limite de aprovação necessária, ela não será executada até que o período de atraso predefinido termine.
-
-Os bloqueios de tempo dão aos usuários algum tempo para sair do sistema, se eles discordarem de uma mudança proposta (por exemplo, atualização lógica ou novos esquemas de taxas). Sem bloqueios de tempo, os usuários precisam confiar nos desenvolvedores para não implementar alterações arbitrárias em um contrato inteligente sem aviso prévio. A desvantagem aqui é que os bloqueios de tempo restringem a capacidade de corrigir vulnerabilidades rapidamente.
-
-## Recursos {#resources}
-
-**Plugins de atualização do OpenZeppelin - _Um conjunto de ferramentas para implantar e proteger contratos inteligentes atualizáveis._**
-
-- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades)
-- [Documentação](https://docs.openzeppelin.com/upgrades)
-
-## Tutoriais {#tutorials}
-
-- [Atualizando seus contratos inteligentes | Tutorial do YouTube](https://www.youtube.com/watch?v=bdXJmWajZRY) por Patrick Collins
-- [Tutorial de migração de contrtos inteligentes Ethereum](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) por Austin Griffith
-- [Usando o padrão de proxy UUPS para atualizar contratos inteligentes](https://blog.logrocket.com/author/praneshas/) por Pranesh A.S
-- [Tutorial Web3: Escreva o contrato inteligente atualizável (proxy) usando OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) por fangjun.eth
-
-## Leitura adicional {#further-reading}
-
-- [O estado das atualizações de contratos inteligentes](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) por Santiago Palladino
-- [Várias maneiras de atualizar um contrato inteligente Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Blog do Crypto Market Pool
-- [Aprenda: Atualizando contratos inteligentes](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - Documentos do OpenZeppelin
-- [Padrões de proxy para capacidade de atualização de contratos Solidity: Proxies Transparentes vs UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) por Naveen Sahu
-- [Como funcionam as atualizações por diamantes](https://dev.to/mudgen/how-diamond-upgrades-work-417j) de Nick Mudge
diff --git "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" "b/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
deleted file mode 100644
index 00797a5c5fa..00000000000
--- "a/public/content/translations/pt-br/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Verificando contratos inteligentes
-description: Uma visão geral da verificação do código-fonte de contratos inteligentes no Ethereum
-lang: pt-br
----
-
-[Contratos inteligentes](/developers/docs/smart-contracts/) são projetados para serem "sem confiança", ou seja, usuários não precisam ter que confiar em terceiros (ex. desenvolvedores e empresas) antes de interagir com um contrato. Como um requisito para a não necessidade de confiança, usuários e outros desenvolvedores precisam ser capazes de verificar o código-fonte de um contrato inteligente. A verificação do código-fonte assegura aos usuários e desenvolvedores que o código do contrato publicado é o mesmo código em execução no endereço do contrato na blockchain Ethereum.
-
-É importante fazer a distinção entre "verificação de código-fonte" e "[verificação formal](/developers/docs/smart-contracts/formal-verification/)". Verificação do código-fonte, que será explicada em detalhes abaixo, refere-se à verificação de que um determinado código-fonte de um contrato inteligente em uma linguagem de alto nível (ex. Solidity) compila com o mesmo bytecode a ser executado no endereço do contrato. Por outro lado, verificação formal descreve a verificação da corretude de um contrato inteligente, assegurando que o contrato se comporta como o esperado. Embora dependa do contexto, a verificação do contrato geralmente se refere à verificação do código-fonte.
-
-## O que é verificação do código-fonte? {#what-is-source-code-verification}
-
-Antes de fazer o deploy de um contrato inteligente na [Máquina Virtual do Ethereum (EVM)](/developers/docs/evm/), desenvolvedores [compilam](/developers/docs/smart-contracts/compiling/) o código-fonte do contrato —instruções [escritas em Solidity](/developers/docs/smart-contracts/languages/) ou outra linguagem de programação de alto nível— para bytecode. Como a EVM não pode interpretar instruções de alto nível, compilar o código-fonte para bytecode (ou seja, de baixo nível, instruções de máquina) é necessário para executar a lógica do contrato na EVM.
-
-A verificação do código-fonte é a comparação entre o código-fonte do contrato inteligente e o bytecode compilado usado durante a criação do contrato para detectar quaisquer diferenças. A verificação de contratos inteligentes é importante visto que o código do contrato anunciado pode diferir do que é executado na blockchain.
-
-A verificação do contrato inteligente permite investigar o que um contrato faz através da linguagem de alto nível em que é escrito, sem ter que ler código de máquina. Funções, valores, e geralmente os nomes de variáveis e comentários permanecem os mesmos do código-fonte original em que é compilado e feito o deploy. Isso torna a leitura do código muito mais fácil. A verificação da origem também incentiva a documentação do código, para que os usuários finais saibam o que um contrato inteligente é projetado para fazer.
-
-### O que é a verificação total? {#full-verification}
-
-Há algumas partes do código-fonte que não afetam o bytecode compilado, como comentários ou nomes de variáveis. Isso significa que dois códigos-fonte com diferentes nomes de variáveis e comentários conseguiriam verificar o mesmo contrato. Com isso, um ator malicioso consegue adicionar comentários enganosos ou dar nomes de variáveis enganosas dentro do código-fonte e obter o contrato verificado com um código-fonte diferente do código-fonte original.
-
-É possível evitar isso anexando dados extras ao bytecode para servir como uma _garantia criptográfica_ da exatidão do código-fonte e como uma _impressão digital_ das informações de compilação. A informação necessária está disponível em [Metadados de contrato Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html), e o hash desse arquivo é adicionado ao bytecode do contrato. Você pode conferi-lo em ação no [playground de metadados](https://playground.sourcify.dev).
-
-O arquivo de metadados contém informações sobre a compilação do contrato incluindo o código-fonte e seus hashes. Significa que, se alguma das configurações de compilação ou até mesmo um byte em um dos arquivos de origem mudar, o arquivo de metadados muda. Consequentemente, o hash do arquivo de metadados, o qual é anexado ao bytecode, também muda. Isso significa que se o bytecode de um contrato + seu hash de metadados correspondem ao determinado código-fonte e as configurações de compilação, nós podemos ter certeza de que é o mesmo código-fonte usando na compilação original, nem mesmo um único byte de diferença.
-
-Esse é tipo de verificação que se aproveita do hash é referenciado como **[verificação total](https://docs.sourcify.dev/docs/full-vs-partial-match/)** (também "verificação perfeita"). Se os hashes de metadados não coincidirem ou não forem considerados na verificação, essa seria uma "correspondência parcial", que atualmente é a maneira mais comum de se verificar contratos. É possível [inserir código malicioso](https://samczsun.com/hiding-in-plain-sight/) que não apareceria no código-fonte verificado sem a verificação total. A maioria dos desenvolvedores não está ciente da verificação completa e não mantém o arquivo de metadados de sua compilação, portanto, a verificação parcial tem sido o método de fato para verificar os contratos até agora.
-
-## Por que a verificação do código-fonte é importante? {#importance-of-source-code-verification}
-
-### Ausência de confiança {#trustlessness}
-
-A ausência da necessidade de confiança é provavelmente a maior premissa para contratos inteligentes e [aplicações descentralizadas (dapps)](/developers/docs/dapps/). Os contratos inteligentes são "imutáveis" e não podem ser alterados; um contrato executará apenas a lógica de negócio definida no código no momento do deploy. Isto significa que os desenvolvedores e empresas não podem manipular o código de um contrato após o deploy no Ethereum.
-
-Para que um contrato inteligente seja ausente de confiança, o código do contrato deve estar disponível para verificação independente. Embora o bytecode compilado de cada contrato inteligente esteja disponível publicamente na blockchain, uma linguagem de baixo nível é difícil de entender — tanto para desenvolvedores quanto para usuários.
-
-Projetos reduzem as suposições de confiança publicando o código-fonte de seus contratos. Mas isso leva a outro problema: é difícil verificar se o código-fonte publicado corresponde ao bytecode do contrato. Nesse cenário, o valor da ausência de confiança é perdido porque os usuários precisam confiar nos desenvolvedores para não mudar a lógica de negócios de um contrato (ex. alterando o bytecode) antes do deploy na blockchain.
-
-As ferramentas de verificação do código-fonte fornecem garantias de que os arquivos do código-fonte do contrato inteligente correspondem ao código de montagem. O resultado é um ecossistema sem necessidade de confiança, no qual os usuários não dependem de confiar em terceiros uma vez que podem verificar o código antes de depositar fundos em um contrato.
-
-### Segurança do usuário {#user-safety}
-
-Em contratos inteligentes, geralmente há muito dinheiro envolvido. Isso pede por altas garantias de segurança e verificação da lógica de um contrato inteligente antes de usá-lo. O problema é que desenvolvedores inescrupulosos podem enganar usuários inserindo código malicioso em um contrato inteligente. Sem a verificação, contratos inteligentes maliciosos podem ter [backdoors](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), controversos mecanismos de controle de acesso, vulnerabilidades exploráveis, e outras coisas que comprometem a segurança dos usuários e que passariam despercebidas.
-
-Publicar os arquivos de código-fonte de um contrato inteligente torna mais fácil para interessados, como auditores, avaliar o contrato quanto a possíveis vetores de ataque. Com várias partes verificando independentemente o contrato inteligente, os usuários têm maiores garantias quanto à sua segurança.
-
-## Como verificar o código-fonte para contratos inteligentes Ethereum {#source-code-verification-for-ethereum-smart-contracts}
-
-[Implantar um contrato inteligente no Ethereum](/developers/docs/smart-contracts/deploying/) requer o envio de uma transação com o payload de dados (bytecode compilado) para um endereço especial. O payload de dados é gerado compilando o código-fonte, além dos [argumentos do construtor](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) da instância do contrato anexado aos dados do payload na transação. A compilação é determinística, o que significa que sempre produz a mesma saída (ou seja, bytecode de contrato), se os mesmos arquivos de origem e configurações de compilação (por exemplo, versão do compilador, otimizador) forem usados.
-
-
-
-A verificação de um contrato inteligente basicamente envolve os seguintes passos:
-
-1. Insira os arquivos de origem e as configurações de compilação em um compilador.
-
-2. O compilador gera o bytecode do contrato
-
-3. Obtenha o bytecode do contrato implantado em um dado endereço
-
-4. Compare o bytecode implantado com o bytecode recompilado. Se os códigos corresponderem, o contrato é verificado com o código-fonte fornecido e as configurações de compilação.
-
-5. Além disso, se os hashes de metadados no final do bytecode corresponderem, será uma correspondência completa.
-
-Note que esta é uma descrição simplista de verificação e há muitas exceções que não funcionariam com isso, como ter [variáveis imutáveis](https://docs.sourcify.dev/docs/immutables/).
-
-## Ferramentas de verificação de código-fonte {#source-code-verification-tools}
-
-O processo tradicional de verificação de contratos pode ser complexo. Isto é porque nós temos ferramentas para verificar o código-fonte para contratos inteligentes implantados no Ethereum. Estas ferramentas automatizam grandes partes da verificação de código-fonte e também selecionam contratos verificados para os benefícios dos usuários.
-
-### Etherscan {#etherscan}
-
-Embora mais conhecido como um [observador da blockchain do Ethereum](/developers/docs/data-and-analytics/block-explorers/), o Etherscan também oferece um [serviço de verificação de código-fonte](https://etherscan.io/verifyContract) para desenvolvedores e usuários de contratos inteligentes.
-
-O Etherscan permite que você recompile o bytecode do contrato a partir do payload de dados original (código-fonte, endereço da biblioteca, configurações do compilador, endereço do contrato, etc.) Se o bytecode recompilado está associado ao bytecode (e aos parâmetros do construtor) do contrato on-chain, então [o contrato é verificado](https://info.etherscan.com/types-of-contract-verification/).
-
-Uma vez verificado, o código-fonte do seu contrato recebe um rótulo "Verificado" e é publicado no Etherscan, para que outros auditem. Ele também é adicionado à seção [Contratos Verificados](https://etherscan.io/contractsVerified/) - um repositório de contratos inteligentes com códigos-fonte verificados.
-
-Etherscan é a ferramenta mais usada para verificação de contratos. No entanto, a verificação de contrato do Etherscan tem uma desvantagem: ele falha ao comparar o **hash de metadados** do bytecode on-chain e o bytecode recompilado. Portanto, as correspondências no Etherscan são correspondências parciais.
-
-[Mais sobre a verificação de contratos no Etherscan](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
-
-### Sourcify {#sourcify}
-
-[Sourcify](https://sourcify.dev/#/verifier) é outra ferramenta para verificação de contratos que é de código aberto e descentralizada. Não é um observador de blocos e apenas verifica contratos em [diferentes redes baseadas em EVM](https://docs.sourcify.dev/docs/chains). Ele atua como uma infraestrutura pública para que outras ferramentas construam sobre ele, e tem como objetivo permitir interações de contrato mais amigáveis a humanos usando o [ABI](/developers/docs/smart-contracts/compiling/#web-applications) e [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) encontrados no arquivo de metadados.
-
-Ao contrário do Etherscan, o Sourcify suporta correspondências completas com o hash de metadados. Os contratos verificados são servidos em seu [repositório público](https://docs.sourcify.dev/docs/repository/) HTTP e [IPFS](https://docs.ipfs. io/concepts/what-is-ipfs/#what-is-ipfs), que é um [armazenamento descentralizado](https://web3.storage/docs/concepts/content-addressing/) endereçado ao conteúdo. Isso permite buscar o arquivo de metadados de um contrato sobre IPFS, pois o hash de metadados incluído é um hash IPFS.
-
-Adicionalmente, também é possível recuperar os arquivos de código-fonte por IPFS, pois os hashes IPFS desses arquivos também são encontrados nos metadados. Um contrato pode ser verificado fornecendo o arquivo de metadados e os arquivos da origem por meio de sua API ou [UI](https://sourcify.dev/#/verifier) ou usando os plugins. A ferramenta de monitoramento Sourcify também escuta as criações de contratos em novos blocos e tenta verificar os contratos se os seus metadados e arquivos de origem são publicados no IPFS.
-
-[Mais sobre a verificação de contratos no Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/).
-
-### Tenderly {#tenderly}
-
-A [plataforma Tenderly](https://tenderly.co/) permite desenvolvedores Web3 criem, testem, monitorem e operem contratos inteligentes. Ao combinar ferramentas de depuração com observabilidade e blocos de construção de infraestrutura, o Tenderly ajuda os desenvolvedores a acelerar o desenvolvimento de contratos inteligentes. Para habilitar totalmente os recursos do Tenderly, os desenvolvedores precisam [realizar a verificação do código-fonte](https://docs.tenderly.co/monitoring/contract-verification) usando vários métodos.
-
-É possível verificar um contrato de forma privada ou pública. Se verificado privadamente, o contrato inteligente ficará visível apenas para você (e outros membros do seu projeto). A verificação de um contrato publicamente o torna visível para todos que usam a plataforma Tenderly.
-
-Você pode verificar seus contratos usando o [Painel](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), [Plugin Tenderly da Hardhat](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) ou [CLI](https:/ /docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli).
-
-Ao verificar contratos através do Painel, você precisa importar o arquivo de origem ou o arquivo de metadados gerado pelo compilador Solidity, o endereço/rede e as configurações do compilador.
-
-O uso do plugin Tenderly da Hardhat permite mais controle sobre o processo de verificação com menos esforço, permitindo escolher entre verificação automática (sem código) e manual (baseado no código).
-
-## Leitura adicional {#further-reading}
-
-- [Verificando o código-fonte do contrato](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/pt-br/21) Whitepaper/whitepaper/index.md b/public/content/translations/pt-br/21) Whitepaper/whitepaper/index.md
deleted file mode 100644
index 5ab6c27d2c5..00000000000
--- a/public/content/translations/pt-br/21) Whitepaper/whitepaper/index.md
+++ /dev/null
@@ -1,517 +0,0 @@
----
-title: Whitepaper sobre o Ethereum
-description: Um documento de introdução ao Ethereum, publicado em 2013 antes de seu lançamento.
-lang: pt-BR
-sidebarDepth: 2
-hideEditButton: true
----
-
-# Whitepaper do Ethereum {#ethereum-whitepaper}
-
-_Este artigo de introdução foi publicado em 2014 por Vitalik Buterin, o fundador da [Ethereum](/what-is-ethereum/), antes do lançamento do projeto em 2015. Vale a pena notar que o Ethereum, como muitos projetos de software de código aberto impulsionados pela comunidade, evoluiu desde a sua criação._
-
-_Apesar de já terem se passado alguns anos desde sua publicação, nós o mantivemos porque ele continua a ser uma referência útil e uma autêntica representação do Ethereum e de sua visão. Para aprender sobre os desenvolvimentos mais recentes do Ethereum e como as mudanças no protocolo são feitas, recomendamos [este manual](/learn/)._
-
-[Pesquisadores e acadêmicos que buscam uma versão histórica ou uma versão canônica do whitepaper [de Dezembro de 2014] devem usar este PDF.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf)
-
-## Uma nova geração de contrato inteligente e plataforma de aplicativos descentralizada {#a-next-generation-smart-contract-and-decentralized-application-platform}
-
-O desenvolvimento do Bitcoin por Satoshi Nakamoto em 2009 tem sido frequentemente aclamado como um desenvolvimento radical em dinheiro e moeda, sendo o primeiro exemplo de um ativo digital que simultaneamente não tem respaldo ou "[valor intrínseco](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" e sem órgão centralizado ou controlador. No entanto, outra parte (talvez mais) importante do experimento é a tecnologia blockchain como ferramenta de consenso distribuído, e esse outro aspecto do bitcoin está recebendo bastante atenção. Outras aplicações da tecnologia blockchain geralmente citadas incluem o uso de ativos digitais em blockchain para representar moedas personalizadas e instrumentos financeiros, ("[moedas coloridas](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)"), a propriedade de um dispositivo físico, ("[propriedade inteligente](https://en.bitcoin.it/wiki/Smart_Property)"), ativos não-fungíveis como nomes de domínio ("[Namecoin](http://namecoin.org)"), bem como usos mais complexos envolvendo ativos digitais controlados diretamente por uma parte de código que implementa regras arbitrárias, ("[contratos inteligentes](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)"), ou até mesmo "[organizações autônomas descentralizadas](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)" (DAOs). O que o Ethereum pretende fornecer é uma blockchain com uma linguagem de programação integrada completa que pode ser usada para criar "contratos" que podem ser usados para codificar funções arbitrárias de transição do estado, permitindo que usuários criem qualquer um dos sistemas descritos acima, bem como muitos outros que ainda não imaginamos, simplesmente escrevendo a lógica em algumas linhas de código.
-
-## Introdução ao bitcoin e conceitos gerais {#introduction-to-bitcoin-and-existing-concepts}
-
-### História {#history}
-
-O conceito de moeda digital descentralizada, bem como aplicativos alternativos, como registros de propriedade, existe há décadas. Os protocolos anônimos de e-cash das décadas de 1980 e 1990, principalmente dependentes de um primitivo criptográfico conhecido como Chaumian blinding, forneciam uma moeda com um alto nível de privacidade, mas os protocolos não conseguiram ganhar força devido à dependência de um intermediário centralizado. Em 1998, o [b-money](http://www.weidai.com/bmoney.txt) de WeiDai foi a primeira proposta a sugerir a ideia de se criar dinheiro usando a resolução de quebra-cabeças computacionais, bem como de consenso descentralizado, mas faltavam detalhes sobre como o consenso descentralizado poderia realmente ser implementado. Em 2005, Hal Finney introduziu um conceito de [provas de trabalho reutilizável](https://nakamotoinstitute.org/finney/rpow/), um sistema que usa ideias do b-money junto com quebra-cabeças de Hashcash computacionalmente difíceis de Adam Back para criar um conceito de criptomoeda, mas mais uma vez ficou aquém do ideal porque usava a computação confiável como backend. Em 2009, uma moeda descentralizada foi implementada pela primeira vez por Satoshi Nakamoto, combinando primitivos estabelecidos para gerenciar a propriedade usando criptografia de chave pública, com um algoritmo de consenso para manter o controle de quem tem moedas conhecido como "prova de trabalho".
-
-O mecanismo por trás da prova de trabalho foi um avanço no espaço porque resolveu simultaneamente dois problemas. Primeiro, ele forneceu um algoritmo de consenso simples e moderadamente eficaz, permitindo que os nós da rede concordassem coletivamente com um conjunto de atualizações canônicas para o estado do livro-razão do Bitcoin. Em segundo lugar, forneceu um mecanismo que não só prevenia ataques cibernéticos como também permitia a livre entrada no processo de consenso, resolvendo o problema político de decidir quem o influencia. Ele faz isso substituindo uma barreira formal à participação, como a exigência de ser registrado como entidade única em uma determinada lista, por uma barreira econômica – o peso de um único nó no processo de votação por consenso é diretamente proporcional ao poder de computação que o nó traz. Desde então, uma abordagem alternativa foi proposta, chamada _prova de participação_, que calcula o peso de um nó como sendo proporcional às posses de moeda e não a recursos computacionais. A discussão dos méritos relativos das duas abordagens está além do escopo deste artigo, mas as duas podem ser usadas para servir como espinha dorsal de uma criptomoeda.
-
-### Bitcoin como um sistema de transição de estado {#bitcoin-as-a-state-transition-system}
-
-
-
-Do ponto de vista técnico, o livro-razão de uma criptomoeda como o Bitcoin pode ser pensado como um sistema de transição de estado, onde há um "estado" que consiste no status de propriedade de todos os bitcoins existentes e uma "função de transição de estado" que assume um estado e uma transação e gera um novo estado que é o resultado. Em um sistema bancário padrão, por exemplo, o estado é um balanço patrimonial, uma transação é um pedido para mover $X de A para B, e a função de transição de estado tira $X da conta de A e aumenta $X na conta de B. Se a conta A tem menos que $X, a função de transição de estado retorna um erro. Portanto, pode-se definir formalmente:
-
-```
-APPLY(S,TX) -> S' or ERROR
-```
-
-No sistema bancário definido acima:
-
-```js
-APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
-```
-
-Mas:
-
-```js
-APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
-```
-
-O estado do "Bitcoin" é a coleção de todas as moedas (tecnicamente, "saídas de transação não gastas" ou UTXO) que foram mineradas e ainda não foram gastas, com cada UTXO tendo uma denominação e um proprietário (definido por um endereço de 20 bytes que é basicamente uma chave pública criptográfica[fn1](#notes)). Uma transação contém uma ou mais entradas, com cada entrada contendo uma referência a um UTXO existente e uma assinatura criptográfica produzida pela chave privada associada ao endereço do proprietário, e uma ou mais saídas, com cada saída contendo um novo UTXO a ser adicionado ao estado.
-
-A função de transição de estado `APPLY(S,TX) -> S'` pode ser definida mais ou menos da seguinte forma:
-
-
-
- Para cada entrada em TX:
-
-
- Se o UTXO referenciado não está no S, retorne um erro.
-
-
- Se a assinatura fornecida não coincide com o proprietário do UTXO, retorne um erro.
-
-
-
-
- Se a soma das denominações de todas as entradas UTXO é menor que a soma das denominações de todas as saídas UTXO, retorne um erro.
-
-
- Retorne S com todas as entradas UTXO removidas e todas as saídas UTXO adicionadas.
-