diff --git a/docs/solutions/integration-issues/sanitizer-test-research.md b/docs/solutions/integration-issues/sanitizer-test-research.md index 26a82cfa776..9eca702fa45 100644 --- a/docs/solutions/integration-issues/sanitizer-test-research.md +++ b/docs/solutions/integration-issues/sanitizer-test-research.md @@ -36,6 +36,10 @@ | 25 | Tilde range notation triggers strikethrough | ko #17166 | `100만~200만 ... 65,536~97,152명` -- two `~` chars parsed as `` by remark-gfm | High -- garbled rendering | | 26 | Bold markers not parsed when adjacent to non-Latin text | ko #17166 | `**단일 슬롯 최종 승인(SSF)**으로` -- MDX emphasis parser requires word boundary after closing `**`; fix converts ONLY non-Latin-adjacent cases to `` HTML tags to preserve josa attachment; lookbehind prevents cross-boundary matching between closing `**` on one line and opening `**` on the next | High -- asterisks render literally | | 27 | Italic markers not parsed when adjacent to non-Latin text | ko #17166 | `_G_가`, `*S*라고` -- same word-boundary issue as bold but for single `*` and `_` italic syntax; fix converts to `` HTML tags; handles both asterisk and underscore variants | High -- asterisks/underscores render literally | +| 28 | Duplicate author frontmatter continuation line | pt-br #17122 | `author: Ori Pomerantz\n Ori Pomerantz` -- Crowdin duplicates the author name on an indented YAML continuation line; parsed value becomes "Ori Pomerantz Ori Pomerantz" | High -- broken frontmatter metadata | +| 29 | Broken markdown link: `}` instead of `]` | pt-br #17122 | `[Mais em staking withdrawals}(/staking/withdrawals/)` -- Crowdin replaces closing `]` with `}`, breaking the link | High -- breaks navigation | +| 30 | TNF ticker transposition for NFT | pt-br #17122 | `TNF` instead of `NFT` -- 37 occurrences across pt-br files; pt-br uses `NFT` (356 occurrences) confirming TNF is a Crowdin error | Medium -- wrong acronym | +| 31 | Translated inline code content with orphaned backticks | pt-br #17122 | EN: `` pass `wallet`, the compiled `` -> PT: `passar a carteira \`, o arquivo` -- Crowdin translates content inside backticks, breaking the code span and leaving orphaned backticks | High -- broken inline code, stray backtick in prose | ## Patterns Already Handled by Sanitizer (Confirmed Working) @@ -43,9 +47,9 @@ These patterns are covered by existing fix functions and should have regression - **Duplicated headings** (`fixDuplicatedHeadings`) — `## Text? Text? {#id}` - **Broken markdown links** (`fixBrokenMarkdownLinks`) — `] (url)` space -- **Escaped bold/italic** (`fixEscapedBoldAndItalic`) — `\*\*text\*\*` +- **Escaped bold/italic** (`fixEscapedBoldAndItalic`) — `\*\*text\*\*`; uses lookbehind to skip `\*` used as multiplication (e.g., `operand\*operand`) - **ASCII guillemets** (`fixAsciiGuillemets`) — `<>` -- **Ticker transpositions** (`fixTickerTranspositions`) — `EHT` → `ETH` +- **Ticker transpositions** (`fixTickerTranspositions`) — `EHT` → `ETH`, `TNF` → `NFT`, `TNFs` → `NFTs`; uses alphanumeric-only boundaries to match adjacent to markdown `_` - **MDX angle brackets** (`escapeMdxAngleBrackets`) — `<5GB` - **Orphaned closing tags** (`removeOrphanedClosingTags`) — trailing `` - **Block component line breaks** (`fixBlockComponentLineBreaks`) @@ -73,6 +77,7 @@ These patterns are covered by existing fix functions and should have regression - **Tilde strikethrough escape** (`escapeTildeStrikethrough`) — `100만~200만` → `100만\~200만` prevents remark-gfm `` (ko PR #17166) - **Bold adjacent non-Latin** (`fixBoldAdjacentNonLatin`) — `**text**가` → `text가` converts ONLY non-Latin-adjacent cases to HTML tags; uses lookbehind to prevent cross-boundary matching (ko PR #17166) - **Italic adjacent non-Latin** (`fixItalicAdjacentNonLatin`) — `*text*가` / `_text_가` → `text가` mirrors bold fix for single `*` and `_` italic syntax (ko PR #17166) +- **Translated inline code warning** (`warnTranslatedInlineCode`) — warns when inline code span count drops significantly OR when orphaned backticks are detected on a line; signals Crowdin translated content inside backticks (pt-br PR #17122) ## Recommendations for Future Sanitizer Iteration diff --git a/public/content/translations/pt-br/about/index.md b/public/content/translations/pt-br/about/index.md index ca51440f2e0..4052187d60d 100644 --- a/public/content/translations/pt-br/about/index.md +++ b/public/content/translations/pt-br/about/index.md @@ -1,6 +1,6 @@ --- title: Quem somos -description: Sobre a equipe, a comunidade e a missão do ethereum.org +description: "Sobre a equipe, a comunidade e a missão do ethereum.org" lang: pt-br --- @@ -10,7 +10,7 @@ ethereum.org é um recurso público de código aberto para a comunidade Ethereum **Ninguém da ethereum.org jamais entrará em contato com você. Não responda.** -## Observação sobre nomes {#a-note-on-names} +## Uma nota sobre nomes {#a-note-on-names} É comum para as pessoas confundir nomes no cenário do Ethereum, o que pode levar a más interpretações sobre como o Ethereum funciona. Aqui está uma rápida explicação para esclarecer as coisas: @@ -20,7 +20,7 @@ Ethereum é uma rede pública, um blockchain e um protocolo de código aberto [Mais sobre o Ethereum](/what-is-ethereum/) -[Mais sobre governança do Ethereum](/governance/) +[Mais sobre a governança do Ethereum](/governance/) ### Ether (ETH) {#ether-or-eth} @@ -28,9 +28,9 @@ Ether (também conhecido pelo seu símbolo ETH) é a moeda nativa transacionada [Mais sobre ETH](/what-is-ether/) -[Mais sobre staking (participação) de ETH](/staking/) +[Mais sobre a participação em ETH](/staking/) -### Fundação Ethereum {#ethereum-foundation} +### Ethereum Foundation {#ethereum-foundation} Uma organização sem fins lucrativos, financiada inicialmente pelo crowdsale de ETH, dedicada ao apoio da rede e do ecossistema Ethereum. @@ -64,7 +64,7 @@ Para alcançar esta missão, nossa equipe se concentra em dois objetivos princip - Aumentar o envolvimento do usuário por meio de recursos como pesquisas, questionários e integrações na web3 - Manter o site leve e com bom desempenho -### 2. Crescer, fortalecer e capacitar nossa comunidade de colaboradores {#community} +### 2. Crescer, fortalecer e capacitar nossa comunidade de contribuidores {#community} - Aumentar o número total de colaboradores do site - Melhorar a retenção de contribuidores por meio de engajamento, reconhecimentos e recompensas @@ -78,52 +78,57 @@ Temos alguns princípios fundamentais que nos ajudam a cumprir a nossa missão. ### 1. O ethereum.org é um portal para o Ethereum 🌏 {#core-principles-1} -Queremos que nossos usuários tenham seus interesses despertados e suas perguntas respondidas. Por isso, o nosso portal precisa combinar informações, “momentos mágicos” e links para os fantásticos recursos já disponíveis para a comunidade. O objetivo do nosso conteúdo é ser um “portal de integração” e não um substituto para os recursos extensivos que já existem. Estamos interessados em apoiar e integrar os recursos criados pela comunidade, dando-lhes mais visibilidade e tornando-os mais acessíveis. [A comunidade do Ethereum](/community/) é o coração disso: não precisamos apenas servir a comunidade, mas trabalhar com os membros dela e incorporar seus comentários. O site não é apenas para a comunidade que temos agora, mas para a comunidade que esperamos nos tornar. Não podemos esquecer que a nossa comunidade é global, com pessoas que falam muitas línguas, provenientes de várias regiões e com várias culturas. +Queremos que nossos usuários tenham seus interesses despertados e suas perguntas respondidas. Por isso, o nosso portal precisa combinar informações, “momentos mágicos” e links para os fantásticos recursos já disponíveis para a comunidade. O objetivo do nosso conteúdo é ser um “portal de integração” e não um substituto para os recursos extensivos que já existem. Estamos interessados em apoiar e integrar os recursos criados pela comunidade, dando-lhes mais visibilidade e tornando-os mais acessíveis. +[A comunidade do Ethereum](/community/) está no centro de tudo: precisamos não apenas servir a comunidade, mas trabalhar com ela e incorporar seu feedback. O site não é apenas para a comunidade que temos agora, mas para a comunidade que esperamos nos tornar. Não podemos esquecer que a nossa comunidade é global, com pessoas que falam muitas línguas, provenientes de várias regiões e com várias culturas. ### 2. O ethereum.org está sempre evoluindo 🛠 {#core-principles-2} -O Ethereum e a comunidade estão sempre evoluindo, logo, o ethereum.org também evoluirá. É por isso que o site tem um design simples e uma estrutura modular. Nós fazemos mudanças iterativas à medida que aprendemos mais sobre como as pessoas usam o site e o que a comunidade espera dele. Nós funcionamos com código aberto e com uma comunidade de colaboradores, por isso, você pode propor alterações ou nos ajudar também. [Saiba como contribuir](/contributing/) +O Ethereum e a comunidade estão sempre evoluindo, logo, o ethereum.org também evoluirá. É por isso que o site tem um design system simples e uma estrutura modular. Nós fazemos mudanças iterativas à medida que aprendemos mais sobre como as pessoas usam o site e o que a comunidade espera dele. +Nós funcionamos com código aberto e com uma comunidade de colaboradores, por isso, você pode propor alterações ou nos ajudar também. +[Saiba mais sobre como contribuir](/contributing/) -### 3. O ethereum.org não é um site de produtos típico 🦄 {#core-principles-3} +### 3. O ethereum.org não é um site de produto típico 🦄 {#core-principles-3} -O universo Ethereum é imenso: ele inclui uma comunidade, uma tecnologia, um conjunto de ideias, ideologias e muito mais. Isso significa que o site precisa lidar com muitas jornadas diferentes de usuários, de "um desenvolvedor que quer uma ferramenta específica" a "um recém-chegado que acabou de comprar algum ETH e não sabe o que é uma carteira". "Qual é o melhor site para uma plataforma de blockchain?" permanece uma questão em aberto. Somos pioneiros. Construir isso requer experimentação. +O universo Ethereum é imenso: ele inclui uma comunidade, uma tecnologia, um conjunto de ideias, ideologias e muito mais. +Isso significa que o site precisa lidar com muitas jornadas diferentes de usuários, de "um desenvolvedor que quer uma ferramenta específica" a "um recém-chegado que acabou de comprar algum ETH e não sabe o que é uma carteira". +"Qual é o melhor site para uma plataforma de blockchain?" permanece uma questão em aberto. Somos pioneiros. Construir isso requer experimentação. -## Roteiro do produto {#roadmap} +## Planejamento do produto {#roadmap} -Para tornar nosso trabalho mais acessível e fomentar mais colaboração comunitária, a equipe base do ethereum.org publica uma visão geral de nossas metas de roteiro trimestrais. +Para tornar nosso trabalho mais acessível e fomentar mais a colaboração da comunidade, a equipe principal do ethereum.org publica uma visão geral das metas do nosso planejamento do [ciclo shape up](https://www.productplan.com/glossary/shape-up-method/). -[Veja nosso roteiro de produtos para o terceiro trimestre de 2024](https://github.com/ethereum/ethereum-org-website/issues/13399) +[Veja nosso planejamento de produto do Ciclo 1 de 2025](https://github.com/ethereum/ethereum-org-website/issues/14726) -**O que você acha disso?** Nós sempre agradecemos o feedback sobre nosso roadmap — se houver algo em que você acha que deveríamos melhorar, por favor nos avise! Agradecemos o envio de ideias e PRs (pull requests) de qualquer pessoa da comunidade. +**O que você acha?** Nós sempre agradecemos o feedback sobre nosso planejamento. Se houver algo em que você acha que deveríamos trabalhar, por favor nos avise! Agradecemos o envio de ideias e PRs (pull requests) de qualquer pessoa da comunidade. -**Quer se envolver?** [Saiba mais sobre como contribuir](/contributing/), [visite-nos no Twitter](https://twitter.com/ethdotorg) ou junte-se às discussões da comunidade em [nosso servidor Discord](https://discord.gg/ethereum-org). +**Quer se envolver?** [Saiba mais sobre como contribuir](/contributing/), [fale conosco no Twitter](https://x.com/ethdotorg) ou junte-se às discussões da comunidade em [nosso servidor do Discord](https://discord.gg/ethereum-org). ## Princípios de design {#design-principles} -Nós usamos um conjunto de [princípios de design](/contributing/design-principles/) para orientar nosso conteúdo e nossas decisões de design no site. +Usamos um conjunto de [princípios de design](/contributing/design-principles/) para guiar nosso conteúdo e decisões de design no site. -## Sistema de design {#design-system} +## Design system {#design-system} -Construímos e lançamos um [sistema de design](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) para enviar funcionalidades mais rapidamente e permitir que os membros da comunidade participem do design aberto do ethereum.org. +Nós criamos e lançamos um [design system](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) para lançar recursos mais rapidamente e permitir que os membros da comunidade participem do design aberto do ethereum.org. -Quer se envolver?[Acompanhe no Figma](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System), [assuntos no GitHub](https://github.com/ethereum/ethereum-org-website/issues/6284) e junte-se à conversa em nosso [canal #design no Discord](https://discord.gg/ethereum-org). +Quer se envolver?[Acompanhe no Figma](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System), a [issue do GitHub](https://github.com/ethereum/ethereum-org-website/issues/6284) e junte-se à conversa em nosso [canal #design no Discord](https://discord.gg/ethereum-org). ## Guia de estilo {#style-guide} -Temos um [guia de estilo](/contributing/style-guide/) para padronizar certos aspectos do conteúdo de escrita para facilitar o processo de contribuição. +Temos um [guia de estilo](/contributing/style-guide/) para padronizar certos aspectos da escrita de conteúdo para tornar o processo de contribuição mais tranquilo. -Certifique-se de ler [nossos princípios](/contributing/design-principles/) e [nosso guia de estilo](/contributing/style-guide/) se você quiser [contribuir para o site](/contributing/). +Certifique-se de ler [nossos princípios](/contributing/design-principles/) e [nosso guia de estilo](/contributing/style-guide/) se você quiser [contribuir com o site](/contributing/). Agradecemos seus comentários sobre nossos princípios de design, sistema de design e guia de estilo. Lembre-se, o site ethereum.org é feito para a comunidade, pela comunidade. ## Licença {#license} -O site ethereum.org é de código aberto e construído sob uma [Licença MIT](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE), a menos que especificado de outra forma. Mais sobre os [termos de uso](/terms-of-use/) do ethereum.org. +O site ethereum.org é de código aberto e foi desenvolvido sob uma [licença MIT](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE), a menos que especificado de outra forma. Mais sobre os [termos de uso](/terms-of-use/) do ethereum.org. -## Vagas de emprego {#open-jobs} +## Vagas abertas {#open-jobs} Embora este site seja de código aberto e qualquer um possa trabalhar nele, temos uma equipe dedicada ao ethereum.org e outros projetos web da Ethereum Foundation. -Publicaremos qualquer vaga de emprego aqui. Se você não encontrar uma vaga aqui para você, acesse [nosso servidor do Discord](https://discord.gg/ethereum-org) e nos conte como gostaria de trabalhar conosco! +Publicaremos qualquer vaga de emprego aqui. Se você não encontrar uma vaga para você aqui, acesse [nosso servidor do Discord](https://discord.gg/ethereum-org) e nos diga como gostaria de trabalhar conosco! -Procurando algo além da equipe do ethereum.org? [Confira outros trabalhos relacionados ao Ethereum](/community/get-involved/#ethereum-jobs/). +Procurando algo além da equipe do ethereum.org? [Confira outras vagas relacionadas ao Ethereum](/community/get-involved/#ethereum-jobs/). diff --git a/public/content/translations/pt-br/ai-agents/index.md b/public/content/translations/pt-br/ai-agents/index.md new file mode 100644 index 00000000000..fe7c1d3b26f --- /dev/null +++ b/public/content/translations/pt-br/ai-agents/index.md @@ -0,0 +1,100 @@ +--- +title: Agentes de IA +metaTitle: Agentes IA | Agentes IA em Ethereum +description: "Uma visão geral de todos os agentes em Ethereum" +lang: pt-br +template: use-cases +emoji: ":robot:" +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: "Pessoas reunidas no índice terminal" +summaryPoint1: "IA que interage com blockchain e operações independentemente" +summaryPoint2: Controla carteiras em cadeia e fundos +summaryPoint3: Contrata humanos ou outros agentes para o trabalho +buttons: + - content: O que são agentes de IA? + toId: "o-que-são-agentes-de-Ia" + - content: Explorar agentes + toId: Agentes-ia-no-ethereum + isSecondary: false +--- + +Imagine navegar no Ethereum com um assistente de IA que estuda tendências de mercado em cadeia 24/7, responde dúvidas, e até realiza transações em seu nome. Bem-vindo ao mundo de Agentes de IA - sistemas inteligentes feitos para facilitar sua vida digital. + +Em Ethereum, estamos vendo inovações de agentes de IA variando de influencers virtuais e criadores de conteúdo autônomos para plataformas de análise de mercado em tempo real, ajudando usuários ao entregar informações, entretenimento, e eficiência operacional. + +## O que são agentes de IA? {#what-are-ai-agents} + +Agentes de IA são programas de software que usam inteligência artificial para realizar tarefas ou tomar suas próprias decisões. Eles aprendem a partir de dados, adaptam-se a mudanças, e lidam com tarefas complexas. Eles operam sem parar e podem detectar oportunidades instantaneamente. + +### Como agentes de IA trabalham com blockchains {#how-ai-agents-work-with-blockchains} + +Na finança tradicional, agentes de IA muitas vezes operam em ambientes centralizados com entrada limitada de dados. Isso atrapalha sua habilidade de aprender ou cuidar de ativos de forma autônoma. + +Em comparação, o ecossistema decentralizado do Ethereum oferece várias vantagens para chaves: + +- Transparência nos dados: Acesso em tempo real à informação de blockchain. +- Real propriedade de ativos: Ativos digitais são controlados totalmente por agentes de IA. +- Funcionalidade em cadeia robusta: Permite agentes de IA fazer transações, interagir com contratos inteligentes, prover liquidez, e colaborar entre protocolos. + +Esses fatores transformam agentes de IA de simples robôs para dinâmicos e auto-melhorados sistemas que oferecem valor significativo entre múltiplos setores: + + + + + + + +## Agentes de IA no Ethereum {#ai-agents-on-ethereum} + +Estamos começando a explorar o potencial máximo dos agentes de IA, e projetos já estão alavancando a sinergia entre IA e blockchain - particularmente em transparência e monetização. + + + +Primeira aparição de Luna como convidada de podcast + + + +## Carteiras controladas por agentes {#agent-controlled-wallets} + +Agentes como Luna ou AIXBT controlam suas próprias carteiras em cadeia ([Carteira de AIXBT](https://clusters.xyz/aixbt), [Carteira de Luna](https://zapper.xyz/account/0x0d177181e3763b20d47dc3a72dd584368bd8bf43)) permitindo que deem dicas e participem em atividades econômicas. + +Durante a campanha social de Luna no X #LunaMuralChallenge, Luna escolheu e recompensou os vencedores via sua carteira base - marcando o primeiro exemplo de uma IA contratando humanos para recompensa em crypto. + + + + +

Bom saber

+

Agentes de IA e ferramentas parecidas ainda estão em fase de desenvolvimento e são experimentais - use com cuidado.

+ + + + +## Controle sua carteira com comandos de chat {#control-your-wallet-using-chat-commands} + +Você pode pular as interfaces complicadas de DeFi e cuidar de suas criptos com simples comandos de chat. + +Essa abordagem intuitiva deixa transações mais rápidas, fáceis, e menos propensas a erros como enviar fundos para o endereço errado ou pagar taxas a mais. + + + +## Agentes de IA vs Robôs de IA {#ai-agents-vs-ai-bots} + +A diferença entre agentes de IA e robôs de IA pode ser confusa às vezes, como ambos realizam ações automatizadas baseadas em entrada. + +- Robôs de IA são como assistentes automatizados - eles seguem instruções específicas e pré-programadas para realizar tarefas de rotina. +- Agentes de IA são mais como companheiros inteligentes - eles aprendem com a experiência, se adaptam a novas informações, e tomam decisões por conta própria. + +| | Agentes de IA | Robôs de IA | +| -------------------------- | --------------------------------------------------------------------------- | -------------------------------------------- | +| **Interações** | Complexo, adaptável, autônomo | Simples, alcance pre-definido, codificado | +| **Aprendizado** | Aprende continuamente, pode testar e se adaptar a dados novos em tempo real | Opera em dados pre-treinados ou regras fixas | +| **Cumprimento de tarefas** | Almeja alcançar objetivos mais amplos | Foca apenas em tarefas específicas | + +## Explore mais {#dive-deeper} + + + +## Você pode construir seu próprio Agente de IA {#you-can-build-your-own-ai-agent} + + \ No newline at end of file diff --git a/public/content/translations/pt-br/bridges/index.md b/public/content/translations/pt-br/bridges/index.md index 6c54e9e32a7..01a21c3812e 100644 --- a/public/content/translations/pt-br/bridges/index.md +++ b/public/content/translations/pt-br/bridges/index.md @@ -1,12 +1,12 @@ --- -title: Introdução às pontes de blockchain -description: Pontes permitem que os usuários movam seus fundos entre blockchains diferentes +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} +# Pontes de blockchain {#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._ +_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._ @@ -18,73 +18,72 @@ 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. +Mas o que você faz se quiser fazer uma troca semelhante para usar uma [cadeia de blocos](/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://portal.arbitrum.io/bridge) que pode transferir ETH da Rede Principal para a 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. +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 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. +No entanto, todas as cadeias de blocos 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). +- [dapps](/glossary/#dapp) para acessar os pontos fortes de várias cadeias de blocos – aumentando, assim, suas capacidades (já que os protocolos agora têm mais espaço de design para 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/) +[Como fazer a ponte de tokens para a camada 2](/guides/how-to-use-a-bridge/) -## Casos de utilização de pontes {#bridge-use-cases} +## Casos de uso da ponte {#bridge-use-cases} Seguem alguns cenários onde você pode usar uma ponte: -### Diminuir as taxas de transação {#transaction-fees} +### Taxas de transação mais baixas {#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} +### Dapps em outras cadeias de blocos {#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. +Se você estiver usando Aave na rede principal do Ethereum para emprestar USDT, mas a taxa de juros que você pode receber por emprestar USDT usando Aave no Polygon é maior. -### Explorar os ecossistemas de blockchain {#explore-ecosystems} +### Explore ecossistemas de cadeia de blocos {#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} +### Possuir criptoativos nativos {#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. +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 em 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](/get-eth/). 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. + Você também pode fazer tudo a acima usando um [exchange centralizado](/get-eth). 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. | +| 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. | Por meio de [contratos inteligentes](/glossary/#smart-contract), pontes sem 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. +- **Com necessidade mínima de confiança**: tendo 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:** afastar-se da segurança dos domínios subjacentes, adicionando verificadores externos ao sistema, o que o torna menos seguro criptoeconomicamente. Para desenvolver uma melhor compreensão das principais diferenças entre as duas abordagens, vamos dar um exemplo: @@ -101,25 +100,25 @@ Muitas soluções de ponte adotam modelos entre esses dois extremos, com graus v -## Usando pontes {#use-bridge} +## Usar pontes {#use-bridge} O uso de pontes permite que você mova seus ativos entre diferentes blockchains. Aqui estão alguns recursos que podem ajudar você a encontrar e usar pontes: -- **[Resumo de pontes L2BEAT](https://l2beat.com/bridges/summary) & [Análise de riscos de pontes do L2BEAT](https://l2beat.com/bridges/summary)**: Uma lista completa de diversas pontes, incluindo detalhes sobre participação de mercado, tipo de ponte e blockchains de destino. O L2BEAT também oferece uma análise de riscos para pontes, ajudando os usuários a tomar decisões informadas ao escolher uma ponte. -- **[Resumo de Pontes da DefiLlama](https://defillama.com/bridges/Ethereum)**: Um resumo dos volumes de pontes nas redes Ethereum. +- **[Resumo de Pontes da L2BEAT](https://l2beat.com/bridges/summary) e [Análise de Risco de Pontes da L2BEAT](https://l2beat.com/bridges/summary)**: um resumo abrangente de várias pontes, incluindo detalhes sobre participação de mercado, tipo de ponte e cadeias de destino. O L2BEAT também oferece uma análise de riscos para pontes, ajudando os usuários a tomar decisões informadas ao escolher uma ponte. +- **[Resumo de Pontes da DefiLlama](https://defillama.com/bridges/Ethereum)**: um resumo dos volumes de pontes nas redes Ethereum. -## Riscos ao usar pontes {#bridge-risk} +## Risco 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 +- **Risco de contrato inteligente —** o risco de um bug no código que pode causar a perda dos fundos do usuário +- **Risco tecnológico —** falha de software, código com bugs, 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 censura —** os operadores de ponte podem, teoricamente, 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: @@ -130,14 +129,17 @@ Os fundos do usuário estão em risco se: - 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/). +Um hack recente foi na ponte Wormhole da Solana, [onde 120 mil wETH (US$ 325 milhões) foram roubados durante o ataque](https://rekt.news/wormhole-rekt/). Muitos dos [maiores 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). +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://debridge.com/learn/blog/10-strategies-for-cross-chain-security/). ## 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_ +- [EIP-5164: Execução entre cadeias](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) - _18 de junho de 2022 - Brendan Asselstine_ +- [Estrutura de Risco de Pontes L2](https://gov.l2beat.com/t/l2bridge-risk-framework/31) - _5 de julho de 2022 - Bartek Kiepuszewski_ +- ["Por que o futuro será multicadeia, mas não será entre cadeias."](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_ +- [Aproveitando a Segurança Compartilhada para Interoperabilidade Segura entre Cadeias: Comitês de Estado Lagrange e Além](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - _12 de junho de 2024 - Emmanuel Awosika_ +- [O Estado das Soluções de Interoperabilidade de Rollups](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - _20 de junho de 2024 - Alex Hook_ + diff --git a/public/content/translations/pt-br/community/code-of-conduct/index.md b/public/content/translations/pt-br/community/code-of-conduct/index.md index 3bd57493bab..5996fce989e 100644 --- a/public/content/translations/pt-br/community/code-of-conduct/index.md +++ b/public/content/translations/pt-br/community/code-of-conduct/index.md @@ -1,10 +1,10 @@ --- -title: Código de Conduta -description: As normas básicas que buscamos nos espaços do ethereum.org. +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 {#conduct-intro} +# Código de conduta {#code-of-conduct} ## Missão {#mission} @@ -23,13 +23,13 @@ A comunidade ethereum.org trabalha para ser: ## O que não somos {#what-we-are-not} -- O site Ethereum Foundation +- O site da 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} +## Código de conduta {#code-of-conduct} ### Compromisso {#pledge} @@ -37,9 +37,9 @@ A participação aberta é fundamental para o ethos do ethereum.org. Somos um si ### 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. +Este Código de Conduta se aplica a todos os espaços do ethereum.org (como GitHub, Discord, Figma, Crowdin, X (antigo Twitter) e outras plataformas on-line), e também se aplica quando a comunidade é representada em espaços públicos do mundo real, como em encontros, conferências e eventos. -### As nossas normas {#our-standards} +### Nossos padrões {#our-standards} Exemplos de comportamentos que colaboram para criar um ambiente positivo incluem: @@ -48,7 +48,7 @@ Exemplos de comportamentos que colaboram para criar um ambiente positivo incluem - 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 +- Incentivar e ampliar novas vozes na comunidade Exemplos de comportamento inaceitável por parte dos participantes incluem: diff --git a/public/content/translations/pt-br/community/events/organizing/index.md b/public/content/translations/pt-br/community/events/organizing/index.md new file mode 100644 index 00000000000..edcbd89c8a2 --- /dev/null +++ b/public/content/translations/pt-br/community/events/organizing/index.md @@ -0,0 +1,221 @@ +--- +title: Organizar um evento de Ethereum +description: Como organizar um evento de Ethereum +lang: pt-br +hideEditButton: true +--- + +# Como organizar um evento de Ethereum {#how-to-organize-an-ethereum-event} + +Criar uma comunidade forte e dinâmica é fundamental para o crescimento do ecossistema Ethereum Esteja você planejando organizar encontros, oficinas ou uma conferência de grande porte, o êxito do evento está diretamente ligado às conexões e ao engajamento de sua rede local Este guia ajudará você a preparar a base para uma comunidade Ethereum ativa e o conduzirá passo a passo pelo processo de organização de uma conferência memorável e impactante. + +## Pergunte a si mesmo: existe uma comunidade Ethereum? {#ask-yourself-is-there-an-ethereum-community} + +Uma conferência Ethereum bem sucedida é baseada em uma comunidade ativa e comprometida. Se você já conta com uma comunidade, você tem vantagem - mas se não tem,a etapa crucial é criar essa base. É crucial diferenciar cena de comunidade: uma cena pode abranger empresas e profissionais atuantes em uma área geográfica, que geralmente trabalham de modo isolado, com colaborações esporádicas — à semelhança do ecossistema Web2 convencional. Uma comunidade, por outro lado, é uma rede de pessoas e organizações que colaboram e se apoiam mutuamente, o que é frequentemente visto em ambientes web3. + +**Seus primeiros passos devem ser:** + +- "Analise o ecossistema local de startups e empresas — a existência de organizações robustas e dinâmicas é frequentemente o fator determinante para a construção de uma comunidade. +- Verifique se já existem encontros na sua área — ethereum.org [página de eventos](https://ethereum.org/community/events/) +- [O site ethereum.org](https://ethereum.org/community/events/) e o discord ethereum.org: para verificar se há eventos de Ethereum, desenvolvedores e colaboradores locais. +- "Confira Luma e Meetup.com — assim você descobre se existem eventos de Ethereum ou web3 perto de você. +- X: Tente encontrar ativistas locais ou pessoais influentes no setor. + +Encontrar a maioria destes elementos é um sinal claro de que as condições para criar uma comunidade existem, mas não significa que necessariamente já existe uma comunidade. O próximo passo envolve o trabalho essencial de organizar, engajar e apoiar esses agentes, abrindo espaço para cooperação e desenvolvimento sustentável. + +### Se não é o caso, como construir {#if-not-how-to-build-it} + +Se você perceber que muitos desses elementos estão faltando, não se preocupe — construir uma comunidade do zero é um processo desafiador, mas profundamente recompensador. Uma comunidade Ethereum forte não nasce do dia para a noite; leva tempo, requer consistência e uma direção clara. Você pode começar assim: + +- **Estabeleça um canal de comunicação** isso pode ser Telegram, Signal, WhatsApp, WeChat ou um servidor no Discord — o que for mais popular onde você estiver — para que as pessoas possam se conectar, tirar dúvidas e compartilhar recursos. +- **Localize seus usuários pioneiros.** Identifique colaboradores motivados pelo ecossistema Ethereum e Web3. Serão os seus principais seguidores e colaboradores. +- **Organize eventos pequenos e constantes.** Comece com encontros informais, grupos de estudo ou oficinas. Consistência é a chave - mesmo que no início o grupo seja pequeno, os eventos regulares geram confiança e ritmo. +- **Tente entrar em contato com empresas locais**, instituições de ensino ou espaços de trabalho cooperativo para fornecerem um espaço gratuitamente. Se você não encontrar palestrantes no seu país, convide palestrantes online, mas reúna as pessoas presencialmente.É crucial manter seu público presente fisicamente em um mesmo local. +- Colabore com comunidades de tecnologia existentes. Se já existirem grupos de desenvolvedores, ecossistemas de empresas ou eventos de blockchain estabelecidos, faça parceria com eles para introduzir tópicos sobre Ethereum e ampliar seu alcance. +- **Compartilhe conteúdo educativo** sobre o potencial da Ethereum. +- **Estenda sua rede a comunidades globais.** Busque conexões com projetos e coletivos renomados da Ethereum ao redor do mundo para suporte técnico, mentoria e oportunidades de colaboração. As comunidades Ethereum ao redor do mundo têm pelo menos uma coisa em comum: todas estão ansiosas para ajudar. +- **Busque captar recursos** — tanto de empresas web3 regionais quanto através de programas de subsídios, como o [ESP.](https://esp.ethereum.foundation/). + +### Se já houver, como manter e fazer crescer {#if-yes-how-to-maintain-and-grow-it} + +Depois de consolidar uma comunidade, o trabalho não termina — pelo contrário, é só o ponto de partida.Manter uma comunidade ativa, engajada e em crescimento exige esforço contínuo e criatividade. Um dos elementos-chave para manter a comunidade envolvida é que você deve experimentar constantemente novos formatos e ideias. + +Confira algumas estratégias para manter sua comunidade Ethereum ativa e engajada: + +- **Diversifique os formatos dos seus eventos:** Não se limite a apenas um tipo de encontro. Varie entre encontros, hackathons rápidos, debates em painel e eventos de conexão. Você pode experimentar organizar dias de trabalho cooperativo ou programas de formação. +- **Diversifique os tópicos:** o Ethereum não é apenas uma tecnologia; também é um conjunto de valores que envolve aspectos jurídicos, de marketing e de negócios. +- **Peça a sua comunidade** por comentários e ideias +- **Conecte-se com diferentes segmentos de público** Adapte conteúdos e eventos a diferentes níveis de experiência — de iniciantes que exploram o Ethereum pela primeira vez a desenvolvedores e empreendedores experientes. + +Ao oferecer diversas oportunidades de aprendizado, colaboração e crescimento, você garante que sua comunidade permaneça ativa e preparada para iniciativas maiores, como a organização de uma conferência. + +## Eventos {#event} + +### Qual é o momento certo para organizar um evento? {#when-is-the-right-time-to-organize-an-event} + +Organizar uma conferência ou evento comunitário Ethereum bem-sucedido exige planejamento e consideração cuidadosos. O momento certo depende de uma variedade de fatores que contribuem para o sucesso geral do evento. + +Você deve considerar a maturidade da comunidade, as condições do mercado, se você tem uma equipe e se há um cenário local (por exemplo, possíveis patrocinadores). + +### KYC - Conheça a sua comunidade {#kyc-know-your-community} + +Uma das etapas mais cruciais na organização de um evento é entender sua comunidade. Assim como o Conheça o Seu Cliente (KYC) nos serviços financeiros, o Conheça Sua Comunidade (KYC) significa dedicar tempo para compreender as necessidades, preferências e características específicas do seu público local. Esse entendimento ajudará você a adaptar a conferência para garantir seu sucesso e relevância. + +É tentador planejar um evento de grande escala imediatamente, mas começar pequeno costuma ser a melhor abordagem. A melhor escolha para você surge quando observa sua comunidade com objetividade e considera fatores que costumam passar despercebidos, por exemplo: se o seu país é um destino turístico conhecido ou o valor da hospedagem. + +No primeiro ano, a maior parte do seu público será a comunidade local, portanto, tudo o que você fizer nesse período ao organizar um evento maior deve atender às necessidades e ao tamanho dessa comunidade. + +### Por onde começar {#where-to-start} + +Quando se trata de organizar uma conferência, os primeiros passos podem muito difíceis. Mas, com um plano e uma estrutura claros, é possível dividir o processo em tarefas gerenciáveis. Vamos analisar cada um deles. + +Começar de forma estruturada ajudará você a manter a organização e reduzir o estresse à medida que avança pelas diferentes etapas de organização do seu evento. Cada decisão que você tomar deve ajudá-lo a criar uma experiência que realmente atenda às necessidades da sua comunidade. + +**O primeiro passo é montar uma equipe de organização com papéis e responsabilidades claros.** + +Outro passo importante antes de começar a elaborar um programa ou contatar patrocinadores é escolher uma data. Embora pareça um passo simples, há alguns fatores importantes que você deve considerar previamente. Alguns deles são: + +- **Evite datas que coincidam com grandes conferências** ou eventos +- **Pense nas condições e contexto loca** (por exemplo, a estação do ano, feriados e outros fatores que podem influenciar o evento.) +- **Considere as condições de mercado ao planejar** +- Reserve tempo suficiente para organizar tudo — pelo menos nove meses. + +### Como montar uma equipe {#how-to-assemble-a-team} + +Selecione pessoas que tenham a mesma visão que você e tragam habilidades que se complementem às suas. Algumas equipes atuam de forma coletiva, e outras têm papéis bem definidos — descubra qual abordagem funciona melhor no seu caso. Comunicação regular e expectativas claras são essenciais. Embora seja tentador depender de plataformas de comunicação para o planejamento de eventos, sugerimos escolher uma plataforma de gerenciamento de tarefas (como Notion, Basecamp, Trello, Asana ou até mesmo o tradicional Google Sheets) para organizar e acompanhar o que precisa ser feito. É crucial ter uma equipe bem estruturada e organizada. + +Embora cada equipe organizadora de Ethereum tenha suas próprias funções, todas incluem pessoas cuidando de logística, finanças, marketing, programação, design e parcerias. + +### O programa: Um elemento-chave para um evento de sucesso {#the-program-a-key-element-of-a-successful-event} + +Quando se trata de organizar uma conferência verdadeiramente valiosa e memorável, **o programa é tudo**. Esta não é uma área em que você pode se dar ao luxo de fazer concessões. Embora os patrocinadores sejam importantes e frequentemente cruciais para financiar o evento, a experiência do público e o valor que ele recebe devem sempre ter prioridade. Uma programação sobrecarregada com conteúdo promocional e apresentações intermináveis de patrocinadores afastará seus participantes e prejudicará a credibilidade do seu evento. + +Cada sessão, painel e workshop deve informar, inspirar e envolver a comunidade. Ouça seu público — entenda seus interesses, necessidades e desafios. Quais tópicos repercutem em suas mentes? Ao mesmo tempo, introduza novas perspectivas e formatos inovadores para manter o programa dinâmico. Equilibre temas já conhecidos e tendências com ideias inovadoras, garantindo uma programação abrangente que cubra diferentes aspectos do ecossistema Ethereum — desde imersões técnicas e sessões de construção de comunidade até discussões sobre políticas e oficinas práticas. Outro ponto importante: o idioma. Apesar de o inglês ser comum em eventos da Ethereum, incluir palestras no idioma local facilita o acesso de desenvolvedores entusiastas da região. + +Ao mesmo tempo, introduza perspectivas frescas e formatos inovadores para manter a programação dinâmica. Isso assegura que consigam reconhecer contribuições relevantes e inteligentes, além de preservar a qualidade do conteúdo. + +### Onde encontrar apoio financeiro {#where-to-find-financial-support} + +Organizar uma conferência de alta qualidade envolve custos significativos — aluguel do local, materiais promocionais, comida e bebidas, produção e inúmeras outras despesas. "É fundamental assegurar financiamento já nas etapas iniciais, garantindo que o evento mantenha o nível profissional e proporcione uma ótima experiência aos participantes.. + +#### Como criar uma apresentação para patrocinadores? {#how-to-create-a-sponsorship-deck} + +Antes de tudo, você precisará de uma apresentação. **Peça orientação a outros organizadores de eventos**, inclusive para compartilharem suas apresentações para patrocinadores e você possa usar como referência na criação dos seus pacotes. Você deve ser realista na hora de definir os valores dos pacotes e foque em cobrir as despesas, não em gerar lucro, principalmente nas primeiras edições. + +**Cada apresentação de patrocínio deve fornecer uma visão geral clara e convincente do evento**, garantindo que potenciais patrocinadores entendam seu escopo, foco e valor. Comece com os fundamentos — local, data e detalhes sobre a equipe organizadora — para estabelecer credibilidade. Em seguida, destaque o foco principal do evento, já que diferentes conferências Ethereum atendem a diferentes públicos. Alguns são fortemente orientados para os construtores, apresentando discussões técnicas profundas, enquanto outros podem concentrar-se mais em DeFi, DAOs ou tópicos de políticas. + +Para além de apenas descrever o evento, defina expectativas claras. **Descreva o número estimado de participantes e os principais oradores já confirmados**, pois isso ajuda os patrocinadores a avaliar o seu potencial alcance. Mais importante ainda, defina claramente o que eles receberão em troca do patrocínio: espaço para estande, oportunidades de palestra, promoção em mídias sociais, visibilidade da marca ou acesso exclusivo à rede. Um deck bem estruturado não apenas informa, mas também entusiasma potenciais patrocinadores sobre a oportunidade de fazer parte do seu evento. + +#### Quem pode apoiar seu evento? {#who-might-support-your-event} + +Comece entrando em contato com empresas do ecossistema Ethereum e de tecnologia em geral na sua cidade ou país. Estas **organizações geralmente têm interesse em apoiar eventos locais** que promovam o crescimento e a inovação da comunidade. Elas também estão mais propensas a reconhecer o valor de investir no ecossistema local e enxergar sua conferência como uma oportunidade de conectar-se com talentos, parceiros e usuários. + +Depois de aproveitar o apoio local, expanda seu alcance para os participantes globais no espaço da Web3. Protocolos consolidados, DAOs e fundos de ecossistema frequentemente destinam orçamentos para eventos orientados pela comunidade. Isso pode ser um pouco desafiador para organizadores iniciantes, pois eles ainda não construíram um histórico para exibir, mas tente elaborar um pacote de patrocínio atraente que destaque claramente os benefícios de apoiar seu evento — visibilidade da marca, oportunidades de palestra e engajamento significativo com um público-alvo. Tente encontrar o seu valor único que outros possam não ter. + +#### Formas alternativas de financiamento do seu evento {#alternative-forms-of-funding-your-event} + +Os subsídios são outra fonte potencial de financiamento que muitos organizadores ignoram. Programas como o [Programa de Apoio ao Ecossistema](https://esp.ethereum.foundation/) (ESP) da Fundação Ethereum e [outras iniciativas de subsídios](https://ethereum.org/community/grants/#ethereum-grants) existem para apoiar eventos conduzidos pela comunidade. + +Além dos patrocínios financeiros, considere parcerias em espécie, especialmente para alimentos e bebidas. As marcas alinhadas com a cultura local ou com a comunidade tecnológica podem ser ótimas parceiras para o seu evento. Marcas de café, empresas de bebidas ou até pizzarias locais podem estar dispostas a fornecer produtos em troca de visibilidade no evento. Estas colaborações podem ajudar a reduzir custos e, ao mesmo tempo, melhorar a experiência do participante. + +Já que estamos falando de finanças, lembre-se: cada dólar investido na criação de uma experiência excepcional para os participantes terá um retorno exponencial. Produção de alta qualidade, locais confortáveis, brindes bem pensados e eventos paralelos bem organizados contribuem para uma experiência memorável, que os participantes lembrarão muito depois do fim da conferência. Participantes felizes se tornam seus maiores defensores e garantem o sucesso do seu evento a longo prazo. + +### Logística {#logistics} + +Paralelamente à obtenção de financiamento, seu foco principal deve ser a logística. Uma conferência bem organizada exige um planejamento meticuloso em múltiplas áreas, desde a configuração do local até a experiência do participante. Ter alguém com uma sólida experiência na organização de eventos — não necessariamente web3, mas eventos em geral — pode fazer uma grande diferença. Um líder de logística experiente pode prever possíveis problemas e resolvê-los antes que se tornem problemas, poupando tempo, dinheiro e estresse. + +Uma pessoa responsável pela logística deve escolher um local, uma produtora e diferentes fornecedores de alimentos, bebidas e produtos, bem como um sistema de venda de bilhetes online fácil de utilizar que permita aos participantes registarem-se e pagarem também em criptomoedas. + +### Infraestrutura de localização {#location-infrastructure} + +Ao decidir onde realizar seu evento, não foque apenas no espaço, analise também a infraestrutura da cidade e do país. Fatores como clima, mobilidade, segurança e cenário político desempenham um papel fundamental na formação da experiência dos participantes. + +Para locais menos conhecidos, isso se torna especialmente crucial. Os participantes e patrocinadores de todo o mundo precisa Analise aspectos como acesso ao aeroporto, qualidade do transporte público e opções de hospedagens. Também é prudente considerar o clima cultural e político da região para evitar complicações que possam desencorajar participantes internacionais, como políticas de visto. + +### Como promover o evento {#how-to-promote-the-event} + +Promover o seu evento de forma eficaz é fundamental para atrair o público certo e gerar entusiasmo. Uma estratégia de promoção bem pensada garante que a sua conferência tenha a visibilidade e o engajamento que merece. O design também desempenha um papel importante na sua marca, então você definitivamente deve incluir isso no orçamento. + +#### Redes sociais {#social-media} + +O X.com será a espinha dorsal da sua promoção nas redes sociais. Tente ser ativo e consistente ao publicar lá, mas também participe em conversas diferentes, tanto com a sua conta pessoal como com a conta da sua organização. + +Embora o LinkedIn não pareça a escolha mais óbvia para a promoção, pode alcançar um público completamente diferente lá, ou até mesmo alguns patrocinadores. + +#### Parcerias com outras comunidades Ethereum {#partnerships-with-other-ethereum-communities} + +. Ofereça descontos à comunidade, faça promoções cruzadas com outros eventos e convide parceiros para coorganizar eventos paralelos ou workshops. + +#### Extensão universitária {#university-outreach} + +Entre em contato com faculdades técnicas e econômicas da cidade por meio de clubes estudantis ou professores para promover o evento. O envolvimento com universidades pode ajudar a atrair jovens talentos, pesquisadores e futuros profissionais da indústria, promovendo uma conexão mais forte entre a academia e o ecossistema Ethereum. Isso é especialmente ótimo se você estiver organizando um hackathon, pois os alunos geralmente trazem novas ideias, entusiasmo e uma base técnica sólida. + +#### Mídia {#media} + +Entre em contato com veículos de comunicação e newsletters focados na web3 para obter cobertura do evento. Embora a mídia do Web3 espere ser paga por seus artigos de RP, você pode oferecer ingressos gratuitos ou entrevistas com alguns palestrantes e patrocinadores de alto nível se não tiver orçamento para promoção paga. Crie um pacote de PR com um comunicado à imprensa e alguns recursos visuais prontos para promoção nas mídias sociais ou em um site em diferentes formatos. Além disso, amplie o escopo para jornalistas locais ou até mesmo criadores de conteúdo (desde que tenham uma boa reputação) que possam cobrir tecnologia, pois isso pode ser crucial para mostrar o evento a públicos maiores. Isso ajuda a diminuir a distância entre a indústria de criptomoedas e o público em geral, atraindo o interesse das principais comunidades de tecnologia e negócios. + +### Também deve organizar um hackathon? {#should-you-organize-a-hackathon-as-well} + +Organizar um hackathon pode ser benéfico porque os hackathons podem ser uma ótima maneira de envolver a comunidade de desenvolvedores e promover a inovação. Ele também oferece oportunidades práticas para colaborar e construir projetos, o que pode levar a resultados tangíveis para o ecossistema. Hackathons atraem desenvolvedores que normalmente não participam de conferências, mas estão interessados ​​no desafio de construir e testar novas ideias. Se a sua conferência for voltada para desenvolvedores, inovação e projetos práticos, sediar um hackathon é uma opção natural. + +Mas, antes de organizar uma, considere se você tem recursos e tempo suficientes. **Um hackathon exige recursos significativos em termos de tempo, força de trabalho e investimento financeiro**. Certifique-se de ter uma equipe dedicada para lidar com isso, especialmente se você também estiver gerenciando uma conferência. Verifique também se há interesse na sua comunidade. Se sua comunidade for mais voltada para construtores, então provavelmente faz sentido organizá-la. + +Embora haja muitos benefícios em organizá-lo, considere que, dependendo do tamanho da conferência, adicionar um hackathon pode ser complicado. Você deve avaliar se gerenciar ambos irá diluir a qualidade de algum deles. Você pode optar por um hackathon menor e mais focado ou escalonar os eventos em meses diferentes. + +### (Quase inevitáveis) Desafios que você enfrentará {#almost-inevitable-challenges-that-you-will-face} + +Um dos maiores desafios ao organizar uma conferência, especialmente no espaço Ethereum, é garantir financiamento suficiente. **Muitos organizadores de eventos têm dificuldade para levantar o capital necessário para cobrir os custos do local**, alimentação e outras despesas logísticas. O patrocínio geralmente é essencial, mas construir relacionamentos e convencer empresas a investir no seu evento pode levar tempo. Além disso, a dificuldade de atrair patrocinadores pode aumentar durante períodos de crise do mercado, pois as empresas podem estar menos dispostas a investir em atividades não essenciais. + +Gerenciar o orçamento de forma eficaz é fundamental. **Despesas imprevistas**, como mudanças de última hora no local e requisitos técnicos adicionais para o evento, podem rapidamente estourar seu orçamento. + +Para novos eventos, **conseguir palestrantes de alta qualidade pode ser especialmente difícil**. Pessoas de renome ou influenciadores estabelecidos no espaço Ethereum podem já ter agendas lotadas e podem hesitar em se comprometer com um novo evento sem um histórico comprovado. Esteja preparado para gastar tempo fazendo networking e entrando em contato com possíveis palestrantes bem antes do evento. + +Além disso, quando se tratar de palestrantes, tenha uma comunicação clara e constante com eles — defina o prazo para o envio das apresentações e evite alterações de última hora. + +Uma conferência de sucesso requer uma equipe dedicada que possa cuidar de logística, marketing, patrocínios, suporte técnico e gerenciamento de participantes. Encontrar pessoas com experiência em organizar eventos de tecnologia pode ser desafiador, especialmente se você estiver trabalhando com um orçamento pequeno ou, na maioria dos casos, sem orçamento, mas como voluntário. + +### Você não deve fazer isso sozinho. Você precisa de voluntários. {#you-shouldnt-do-it-alone-you-need-volunteers} + +Organizar um evento Ethereum exige uma equipe diversificada e dedicada para cuidar da logística, inscrições, coordenação de palestrantes, suporte aos participantes e muito mais. Com equipes variando de apenas 3 a 15 pessoas, fica claro que os voluntários são essenciais para o bom andamento do evento. + +Os voluntários costumam ser a espinha dorsal de muitas conferências, fornecendo suporte essencial, especialmente quando você está trabalhando com um orçamento limitado. Eles podem cuidar de tudo, desde cuidar dos balcões de registro até auxiliar na configuração do evento, garantindo que o evento ocorra da forma mais tranquila possível. + +Embora seja desafiador oferecer compensação monetária aos voluntários, é essencial fornecer a eles algo de valor que faça sua experiência valer a pena. Considere oferecer a eles oportunidades de networking, desenvolvimento de habilidades, algumas vantagens exclusivas, certificados ou cartas de recomendação. + +### Noções básicas de conformidade para organizadores de eventos {#compliance-essentials-for-event-organizers} + +Ao organizar um evento, há várias considerações legais e logísticas essenciais a ter em mente: + +- **Contrato de patrocínio** – Certifique-se de ter um contrato claro para patrocinadores, incluindo uma política de cancelamento bem definida. +- **Código de conduta** – Prepare um Código de Conduta adaptado ao tipo específico de evento (conferência/hackathon, hacker houses etc.). +- **Política de privacidade** – Elabore uma política de privacidade para o seu site para cumprir com os regulamentos de proteção de dados e imagem +- **Notificação às autoridades locais** – Mesmo que seu evento seja uma reunião fechada, é aconselhável denunciá-lo à delegacia de polícia local. +- **Contrato de emissão de ingressos** – Estabeleça um acordo formal com seu provedor de serviços de emissão de ingressos para esclarecer termos e responsabilidades. +- **Conformidade regulatória** – Verifique com antecedência se o país onde você está hospedando a conferência possui regulamentações ou restrições específicas para a indústria de criptomoedas +- **Desembaraço aduaneiro de mercadorias** – Se você estiver importando mercadorias de patrocinadores, é recomendável contratar um despachante aduaneiro para lidar com o processo de forma eficiente. +- **Política de fotografia e mídia** – Defina claramente as diretrizes sobre fotografia e cobertura da mídia, garantindo que os participantes sejam informados sobre as opções de consentimento e exclusão. + +## Depois do evento: o que vem a seguir? {#after-the-event-whats-next} + +Após o término do evento, é fundamental coletar feedback dos participantes, palestrantes e patrocinadores e criar um relatório interno para que você possa estar melhor preparado para eventos futuros. Isso ajuda a identificar o que deu certo e onde melhorias podem ser feitas. Use pesquisas ou entrevistas individuais para coletar insights valiosos que orientarão iterações futuras. Reserve um tempo para revisar quaisquer erros ou áreas de ineficiência, pois eles podem ser evitados na próxima conferência, tornando o processo mais tranquilo. + +O segredo é manter o ritmo vivo. Continue interagindo com sua comunidade, compartilhe atualizações sobre o progresso que você está fazendo com base no feedback deles e crie entusiasmo para o próximo evento. Ao manter essa conexão, você garante que o impacto da conferência se estenda além do evento em si, fortalecendo relacionamentos e preparando o cenário para o sucesso futuro. + +## Reconhecimento {#acknowledgement} + +Um grande agradecimento a todos que contribuíram para este artigo compartilhando suas ideias: Slavo Fabisik da ETHBratislava; Lola da ETH Kipu e ETH Latam; Tanja Mladenovic da ETH Belgrade, Juan David da Ethereum Bogota; Monika Zając da ETHWarsaw; Raffaele Orefice da NapulETH; Xiao Wu(Ling) da ETH Riyadh; Marco da urbe.eth; Caolán Walsh da ETH Dublin; Alex Males da ETHCluj; e Stanko Devic da ETH Slovenia. + +## Documentos {#resources} + +Podcast: Como organizar e promover um evento ETH de A a Z: + +- [O estudo de caso da ETHWarsaw, por Out of Ordinary](https://www.youtube.com/watch?v=io2Dx1ouz8o) + +Twitter space: + +- [AMA da Comunidade ETH](https://x.com/NapulETH/status/1905732699094151623) + +Artigos: + +- [Construindo ETHKL, por Danny H.](https://sekto.tech/ethkl24) +- [Manual de Eventos POKT](https://docs.pokt.network/community/pokt-events-playbook) diff --git a/public/content/translations/pt-br/community/get-involved/index.md b/public/content/translations/pt-br/community/get-involved/index.md index 15b5c38836c..dda1c0648ca 100644 --- a/public/content/translations/pt-br/community/get-involved/index.md +++ b/public/content/translations/pt-br/community/get-involved/index.md @@ -4,76 +4,79 @@ description: Como fazer parte da comunidade Ethereum. lang: pt-br --- -# Como posso participar? {#get-involved} +# Como posso participar? Participe {#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). +Comece lendo sobre a missão e os valores do ethereum.org em nosso [código de conduta](/community/code-of-conduct). -## Desenvolvedores {#developers} +## 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 [reuniões do núcleo de desenvolvedores](https://www.youtube.com/@EthereumProtocol) -- [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 [Discord Ethereum Cat Herders](https://discord.gg/Nz6rtfJ8Cu) +- Aprenda sobre e experimente o Ethereum em [ethereum.org/developers/](/developers/) +- Participe de um hackathon da [ETHGlobal](http://ethglobal.co/) perto de você! +- Confira os [projetos relacionados à sua área de especialização ou linguagem de programação de sua preferência](/developers/docs/programming-languages/) +- Assista ou participe das [chamadas da camada de consenso e execução](https://www.youtube.com/@EthereumProtocol/streams) +- [Lista de desejos do Ecosystem Support Program](https://esp.ethereum.foundation/wishlist/) – áreas de ferramentas, documentação e infraestrutura onde o Ecosystem Support Program do Ethereum está ativamente buscando solicitações de subsídios +- [Web3Bridge](https://www.web3bridgeafrica.com) - junte-se à aspirante comunidade web3 em sua iniciativa para identificar, treinar e apoiar centenas de desenvolvedores e membros da comunidade em toda a África +- Junte-se ao [Discord de P&D do Eth](https://discord.com/invite/VmG7Uxc) +- Junte-se ao [Discord do Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) -## Pesquisadores e acadêmicos {#researchers-and-academics} +## 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 [Discord de P&D do Eth](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.gg/Nz6rtfJ8Cu) + 1. Envie sua ideia no [Ethereum Magicians](https://ethereum-magicians.org) + 2. Leia o [EIP-1](https://eips.ethereum.org/EIPS/eip-1) - **Sim, esse é o documento _inteiro_.** + 3. Siga as instruções do EIP-1. Consulte-a ao redigir a sua versão preliminar. + - Aprenda 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! Veja [PRs abertos com a tag `e-review`](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review). Forneça feedback técnico no link `discussion-to`. + - Participe da [Governança de EIPs](https://github.com/ethereum-cat-herders/EIPIP) + - Junte-se ao [Discord do 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 +- [Challenges.ethereum.org](https://challenges.ethereum.org/) - uma série de recompensas de pesquisa de alto valor, onde você pode ganhar >$100.000 USD +- [Ethresear.ch](https://ethresear.ch) - o principal fórum de pesquisa do Ethereum e o fórum mais influente do mundo em criptoeconomia +- [AMA da Pesquisa da EF](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - Uma série contínua de P&R com pesquisadores. À medida que cada parte seguinte é aberta, qualquer pessoa poderá publicar perguntas. +- [Lista de desejos do Ecosystem Support Program](https://esp.ethereum.foundation/wishlist/) - áreas de pesquisa onde o Ecosystem Support Program do Ethereum está ativamente buscando solicitações de subsídios +- [AllWalletDevs](https://allwallet.dev) - um fórum para desenvolvedores, designers e usuários interessados do Ethereum se reunirem regularmente para discutir sobre carteiras -[Conheça as áreas de pesquisa mais ativas](/community/research/). +[Explore mais áreas ativas de pesquisa](/community/research/). -## Habilidades que não necessitam de conhecimento técnico {#non-technical} +## Habilidades não técnicas ‍ {#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} +### Organize um meetup em sua cidade {#meetups} - Não sabe como começar? A [rede BUIDL](https://consensys.net/developers/buidlnetwork/) pode ajudar. -### Escreva sobre Ethereum {#write-content} +### Escreva conteúdo sobre o 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/)! +- Não está preparado para publicar seu próprio artigo? Considere contribuir com o conteúdo existente nos recursos da comunidade ou [proponha novo conteúdo para o ethereum.org](/contributing/)! -### Tome notas durante as reuniões da comunidade {#take-notes} +### Ofereça-se para fazer anotações nas chamadas 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! +- Existem várias chamadas open-source da comunidade, e ter pessoas tomando notas é uma grande ajuda. Se você tiver interesse, entre no [discord do Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) e apresente-se! -### Traduza conteúdo do Ethereum para a sua língua materna {#translate-ethereum} +### Traduza o conteúdo do Ethereum para o seu idioma nativo {#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) +- Descubra 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/) +- [Mais sobre como executar um nó](/developers/docs/nodes-and-clients/run-a-node/) -### Faça staking de seu ETH {#staking} +### Faça stake 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/) +- [Mais sobre staking](/staking/) ### Apoie projetos {#support-projects} @@ -82,51 +85,48 @@ O objetivo do ecossistema Ethereum é financiar bens públicos e projetos com im - [Gitcoin](https://gitcoin.co/fund) - [clr.fund](https://clr.fund/#/about) -## Profissionais de finanças e contadores {#financial-professionals} +## Profissionais financeiros 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/) +- 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 da área financeira, confira alguns aplicativos DeFi na [DeFi Llama](https://defillama.com/) ou na [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 visam ajudar os usuários de criptomoedas a resolver seus desafios de escrituração e contabilidade, como o [Rotki](https://rotki.com/) -## Gerentes de produto {#product-managers} +## 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ê quer começar contribuindo com um projeto de código aberto, entre em contato com o [Ethereum Gat Herders](https://discord.com/invite/Nz6rtfJ8Cu) ou [RaidGuild](https://www.raidguild.org/) +- O ecossistema do Ethereum precisa de suas habilidades! Muitas empresas estão contratando para as funções de gerente de produtos. Se você quer começar contribuindo para um projeto de código aberto, entre em contato com o [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) ou o [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} +## Vagas em 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/) -- [Empregos relacionados a criptomoedas](https://cryptocurrencyjobs.co/ethereum/) -- [Crypto.jobs](https://crypto.jobs/) +- [Vagas no ethereum.org](/about/#open-jobs) +- [Quadro de vagas da Ethereum Foundation](https://jobs.ashbyhq.com/ethereum-foundation) +- [JobStash](https://jobstash.xyz) +- [Quadro de Vagas do Ethereum](https://www.ethereumjobboard.com/) +- [Vagas em Criptomoeda](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 useWeb3](https://www.useweb3.xyz/jobs) -- [Empregos na Web3](https://web3.career) +- [Lista de Vagas em Cripto](https://cryptojobslist.com/ethereum-jobs) +- [Quadro de vagas da Bankless](https://pallet.xyz/list/bankless/jobs) +- [Vagas em 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) +- [Vagas na Crypto Valley](https://cryptovalley.jobs/) +- [Vagas em Ethereum](https://startup.jobs/ethereum-jobs) -## Participe de uma DAO {#decentralized-autonomous-organizations-daos} +## Junte-se a 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://www.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_ -- [MetaCartel](https://metacartel.org) [@Meta_Cartel](https://twitter.com/Meta_Cartel) – _Incubadora de DAO_ -- [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! +- [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 criarem valor através de uma 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) - _Coletivo de desenvolvimento freelancer Web3 que funciona como uma DAO_ +- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) - _Governança comunitária da DAOhaus_ +- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - _Engenharia jurídica_ +- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - _Venture para projetos de cripto pré-semente_ +- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - _Marcas de Vestuário Digifísicas_ +- [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) - _Coletivo de construtores Web3_ + +Lembre-se de seguir o [código de conduta](/community/code-of-conduct) do ethereum.org sempre e de qualquer forma que você contribua para o ethereum.org! diff --git a/public/content/translations/pt-br/community/grants/index.md b/public/content/translations/pt-br/community/grants/index.md index e72cdcdcdf4..8f9e57a2ea5 100644 --- a/public/content/translations/pt-br/community/grants/index.md +++ b/public/content/translations/pt-br/community/grants/index.md @@ -1,44 +1,68 @@ --- -title: Fundação Ethereum & Programa de Recompensas da Comunidade +title: Programas de bolsas da Ethereum Foundation e da comunidade description: Uma listagem dos programas de recompensas por meio do ecossistema Ethereum. lang: pt-br --- -# Recompensas Ethereum {#ethereum-grants} +# Bolsas da 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} + + +
Fundadores, precisam de ajuda para acelerar seus negócios? [Acesse o Suporte para Fundadores](/founders/)
+ + +## Ecossistema Ethereum amplo {#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_ +- [Programa de Apoio ao Ecossistema da EF](https://esp.ethereum.foundation) - _Financiamento de projetos de código aberto que beneficiam a Ethereum, com foco particular em ferramentas universais, infraestrutura, pesquisa e bens públicos_ +- [Bolsas Acadêmicas](https://esp.ethereum.foundation/academic-grants) - _Bolsas para apoiar trabalhos acadêmicos relacionados à Ethereum_ + +## Agregadores de listas e plataformas de bolsas {#grant-list-aggregators} + +Esses recursos compilam e organizam diversas oportunidades de subsídios no ecossistema Ethereum, facilitando a descoberta de oportunidades de financiamento que correspondem às necessidades do seu projeto. Nós os organizamos por persona para ajudar você a começar a encontrar os recursos mais relevantes com base em suas necessidades específicas de financiamento. + +### Para todos que buscam bolsas: Diretórios abrangentes {#comprehensive-directories} + +Essas plataformas gerais oferecem ampla cobertura de subsídios em todo o espaço Web3 e são pontos de partida úteis para quem busca financiamento: + +- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _A Blockworks compilou um diretório abrangente de todas as bolsas, RFPs e recompensas por bugs._ +- [Blockchain Grants](https://www.blockchaingrants.org/) - _Diretório de bolsas de blockchain e cripto_ +- [Karma Funding Map](https://gap.karmahq.xyz/funding-map) - Diretório de todos os programas de bolsas da web3, atualizado semanalmente + +### Para desenvolvedores e construtores {#for-developers-and-builders} + +- [Visualizador de Programas de Bolsas](https://airtable.com/shr86elKgWTSCP4AY) - _Banco de dados público da Airtable com programas de bolsas_ +- [Web3 Grants Spreadsheet](https://docs.google.com/spreadsheets/d/1c8koZCI-GLnD8MG-eFcXPOBCNu1v8-aXIfwAAvc7AMc/edit#gid=0) - _Planilha do Google com oportunidades de bolsas da Web3_ +- [Arbitrum Grants](https://arbitrum.foundation/grants) — Arbitrum DAO e [The Arbitrum Foundation](https://arbitrum.foundation/) + +### Para projetos DeFi e aplicações financeiras {#for-defi-projects} + +- [LlamaoGrants](https://wiki.defillama.com/wiki/LlamaoGrants) - _Diretório do programa de bolsas do DeFi Llama_ +- [AlphaGrowth Grants](https://alphagrowth.io/crypto-web3-grants-list) - _Lista abrangente de bolsas de cripto e Web3_ +- [Uniswap Foundation Grants](https://www.uniswapfoundation.org/build) - _Bolsas da Unichain e Uniswap v4 e suporte para construtores de DeFi_ -## Especificidades do projeto {#project-specific} +### Para contribuidores de DAO e inovadores de governança {#for-dao-contributors} -Estes projetos criaram seus próprios programas de recompensas destinados a desenvolvimento e experimentação de suas tecnologias. +Recursos para projetos conduzidos pela comunidade e experimentos de governança: -- [Programa de concessões Aave](https://aavegrants.org/) – _[Aave](https://aave.com/) concede DAO_ -- [Balancer](https://balancer.gitbook.io/balancer-v2/ecosystem/community/grants) – _Fundo do ecossistema [Balancer](https://balancer.fi/)_ -- [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/)_ -- [The Graph](https://airtable.com/shrdfvnFvVch3IOVm) – _Ecossistema [The Graph](https://thegraph.com/)_ -- [Uniswap Grants Program](https://www.uniswapfoundation.org/grants) - _[Comunidade da Uniswap](https://uniswap.org/)_ +- [DAO Grants](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _Planilha do Google com organizações que oferecem bolsas_ +- [MetaGov Database](https://docs.google.com/spreadsheets/d/1e5g-dlWWsK2DZoZGBgfxyfGNSddLk-V7sLEgfPjEhbA/edit#gid=780420708) - _Mapa abrangente de bolsas da Web3_ -## Financiamento quadrático {#quadratic-funding} +### Bens públicos e impacto {#public-goods-and-impact} -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) +Esses programas se concentram no financiamento de projetos que beneficiam a comunidade em geral, bens públicos e iniciativas de impacto. Isso inclui provedores de bolsas, bem como plataformas de doação que utilizam mecanismos de alocação de financiamento em cadeia, incluindo [financiamento quadrático](/defi/#quadratic-funding): -- [Gitcoin](https://gitcoin.co/grants) -- [clr.fund](https://clr.fund/) +- [Gitcoin](https://www.gitcoin.co/program) - _O Gitcoin Grants utiliza múltiplos mecanismos de alocação de capital para financiar projetos de código aberto e bens públicos no ecossistema Ethereum_ +- [Octant](https://octant.app/home) - _Ecossistema de financiamento de bens públicos que equilibra o bem comum e o empoderamento financeiro individual_ +- [Giveth](https://giveth.io/) - _Plataforma de doação de criptomoedas que permite doações diretas de projetos beneficentes sem nenhuma taxa adicional_ +- [Artizen](https://artizen.fund/) - _Ajudando criadores a obter financiamento correspondente para novos projetos na vanguarda da arte, ciência, tecnologia e cultura_ +- [Quadratic Accelerator](https://qacc.giveth.io/) - _Programa de aceleração de start-ups que usa financiamento quadrático para apoiar projetos que beneficiam o bem público_ -## Trabalhar em Ethereum {#work-in-ethereum} +## Trabalho na 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) +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 vagas relacionadas à Ethereum](/community/get-involved/#ethereum-jobs) diff --git a/public/content/translations/pt-br/community/language-resources/index.md b/public/content/translations/pt-br/community/language-resources/index.md index 8c6fa82101d..bcde429835a 100644 --- a/public/content/translations/pt-br/community/language-resources/index.md +++ b/public/content/translations/pt-br/community/language-resources/index.md @@ -12,121 +12,142 @@ Nosso objetivo é fornecer conteúdo educacional em todas as línguas e ajudar a 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! +Conhece algum recurso educacional em sua língua? [Abra um problema](https://github.com/ethereum/ethereum-org-website/issues/new/choose) para adicioná-lo à lista! -## Recursos em Ethereum.org {#ethereum-org} +## Recursos do Ethereum.org {#ethereum-org} -Ethereum.org é traduzido nativamente para mais de 40 idiomas que você pode encontrar em nossa página de idiomas. +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. -![Language selector menu](./language-selector-menu.png) +![Menu seletor de idioma](./language-selector-menu.png) -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. +Se você for bilíngue e quiser nos ajudar a alcançar mais pessoas, também pode se envolver com o [Programa de Tradução do ethereum.org](/contributing/translation-program/#translation-program) e nos ajudar a traduzir o site. -## Recursos para a comunidade {#community} +## Recursos da 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 +- [BeInCrypto](http://www.beincrypto.com.br) - notícias e artigos sobre criptomoedas, incluindo uma lista de corretoras disponíveis no Brasil +- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - versão brasileira do Cointelegraph, um grande veículo de notícias sobre criptomoedas +- [Livecoins](http://www.livecoins.com.br/ethereum) - notícias e ferramentas 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 +- [web3dev](https://www.web3dev.com.br/) - Central de conteúdo e comunidade no Discord para desenvolvedores web3. +- [Web3Brasil](https://github.com/web3brasil/web3brasil) - recursos para aprender sobre Web3 e DeFi +- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - notícias e educação sobre criptomoedas, incluindo 'Ethereum para iniciantes' e 'DeFi para iniciantes' +- [CriptoAtivos](http://www.criptoativos.wiki.br/) - informações sobre o espaço de criptomoedas, educação e blog +- [Cointimes](http://www.cointimes.com.br/) - notícias e educação 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 cripto ### 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://ethereum.org/whitepaper//[%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 +- [Ethereum.cn](https://www.ethereum.cn/) - conteúdo mantido pela comunidade, cobrindo a atualização da camada de consenso, todas as notas da reunião de desenvolvedores do núcleo, camada 2, etc. +- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - aprenda tudo, desde o básico até tópicos avançados do Ethereum +- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - conteúdo mantido pela comunidade, cobrindo conhecimentos sobre Ethereum, DeFi, NFT e relacionados à Web3 +- [123ETH](https://123eth.org/) - um Portal para o ecossistema Ethereum +- [Zhen Xiao](http://zhenxiao.com/blockchain/) - cursos online gratuitos sobre criptomoeda e suas aplicações +- [Whitepaper do Ethereum](/zh/whitepaper/) - versão em chinês do Whitepaper do Ethereum **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 +- [ETHPlanet](https://www.ethplanet.org/) - hackathons online e presenciais, oferecendo treinamento para estudantes universitários +- [PrimitivesLane](https://www.primitiveslane.org/) - um grupo de pesquisa sem fins lucrativos, com foco em tecnologia blockchain +- [Comunidade de Tradução do Ethereum CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - uma comunidade dedicada à tradução de conteúdo educacional do 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 +- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - um grupo de aprendizado para estudar os principais projetos de dapps e compartilhar ideias e comentários toda semana +- [LearnBlockchain](https://learnblockchain.cn/) - uma comunidade para desenvolvedores, que 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 +- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - uma conta do WeChat, explicando criptografia, segurança etc. +- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - uma conta do WeChat, explicando 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 +- [Gwei.cz](https://gwei.cz) - comunidade local em torno da Web3, cria conteúdo educacional, organiza eventos online e presenciais +- [Gwei.cz Příručka](https://prirucka.gwei.cz/) - guia do Ethereum para iniciantes +- [DAO Příručka](https://dao.gwei.cz/) - guia para iniciantes sobre DAOs +- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - Mastering 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 +- [Ethereum France](https://www.ethereum-france.com/) - A Ethereum France organiza eventos, cria conteúdo e incentiva discussões sobre o Ethereum +- [Ethereum.fr](https://ethereum.fr/) - notícias e educação sobre o Ethereum +- [BanklessFR](https://banklessfr.substack.com/) - newsletter da Bankless em francês +- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - fórum de criptomoedas com uma subpágina sobre 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 +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - usando Solidity +- [Microsoft Learn (smart contracts)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - escrevendo smart contracts do Ethereum com Solidity +- [Microsoft Learn (redes Ethereum)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - conecte-se e implante redes Ethereum +- [Microsoft Learn (blockchains)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - entrada no desenvolvimento de blockchain + +### Hebraico {#he} + +- [Udi Wertheimer - O que os bitcoiners podem aprender com o Ethereum](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/) +- [Omer Greismen (OpenZeppelin) - Como evitamos um hack de 15 bilhões de dólares em um smart contract](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/) +- [Shy Datika (INX) - Tokenização e o futuro dos títulos, incluindo se o Ethereum é um título](https://www.cryptojungle.co.il/shy-datika-tokenization/) +- [Roy Confino (Lemonade) - Seguro @ 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 é a 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 - Sendo um cryptopunk](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/) +- [Adan Kedem - Jogos e Metaverso](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/) +- [Uri Kolodny (Starkware) - Camadas do Ethereum e da 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 (myself) - Ethereum 2.0 - uma oportunidade?](https://www.cryptojungle.co.il/etherurm2-week-summary/) +- [Alon Muroch (Bloxstaking) - O que é o 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 +- [Ethereum Italia](https://www.ethereum-italia.it/) - educação, eventos e notícias sobre o Ethereum, com foco em smart contracts e tecnologia blockchain +- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) - podcast sobre o Ethereum em italiano +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - aprenda a usar o Solidity +- [Microsoft Learn (Smart contracts)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - aprenda sobre como escrever smart contracts usando 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 de Corretoras de Ativos Virtuais e de Criptoativos do Japão](https://jvcea.or.jp/) +- [Associação de Empresas de Criptoativos do Japão](https://cryptocurrency-association.org/) +- [Introdução ao desenvolvimento de blockchain - Aprenda | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - Este caminho de aprendizado apresenta a você a blockchain e o desenvolvimento na plataforma Ethereum +- [Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) - Mastering Ethereum em japonês +- [Desenvolvimento prático de smart contracts com Solidity e Ethereum](https://www.oreilly.co.jp/books/9784873119342/) - Desenvolvimento prático de smart contracts com Solidity e Ethereum em japonês ### Russo {#ru} -- [Cyber Academy](https://cyberacademy.dev) – espaço educacional para criadores web3 +- [Cyber Academy](https://cyberacademy.dev) - espaço educacional para construtores da web3 +- [Forklog](https://forklog.com) - notícias e artigos educacionais sobre cripto em geral, tecnologias existentes e futuras atualizações de diferentes blockchains +- [BeInCrypto](https://ru.beincrypto.com) - notícias, análise de preços de cripto e artigos não técnicos com explicações simples sobre tudo no mundo cripto ### 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. +- [Ethereum Madrid](https://ethereummadrid.com/) - cursos, eventos e blog sobre blockchain, DeFi e governança +- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - guia do Ethereum para iniciantes em espanhol +- [Tutoriales online](https://tutoriales.online/curso/solidity) - aprenda Solidity e programação no Ethereum +- [Curso de Introdução ao Desenvolvimento Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - conceitos básicos de Solidity, teste e implantação do seu primeiro smart contract +- [Curso de Introdução à Segurança e Hacking no Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - entenda as vulnerabilidades e os problemas de segurança comuns em smart contracts reais +- [Curso de Introdução ao Desenvolvimento DeFi](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - aprenda como os smart contracts de DeFi funcionam em Solidity e crie 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" +- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - curso focado em blockchain e criptomoedas +- [A grande renomeação: o que aconteceu com o Eth2?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - tradução para o turco da postagem do blog sobre a grande renomeação, explicando o afastamento 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 - -### 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 +- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - visão geral sobre Ethereum, dapps, carteiras e Perguntas Frequentes +- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - plataforma web com subpáginas para notícias e educação 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/community/online/index.md b/public/content/translations/pt-br/community/online/index.md index fd449d3da2d..b51715dabc5 100644 --- a/public/content/translations/pt-br/community/online/index.md +++ b/public/content/translations/pt-br/community/online/index.md @@ -1,50 +1,74 @@ --- title: Comunidades online -description: Uma listagem dos programas de recompensas por meio do ecossistema Ethereum. +description: "Descobrir fóruns online, salas de bate-papo e comunidades de mídia social onde os entusiastas da Ethereum se reúnem para discutir e colaborar." lang: pt-br --- -# Comunidades online {#online-communities} +# Comunidades on-line {#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. +## Política de listagem {#listing-policy} + +Para manter a integridade e o valor das comunidades listadas, o ethereum.org segue uma política rigorosa para determinar a elegibilidade: + +### Critérios de elegibilidade {#eligibility-criteria} + +- **Relevância**: a comunidade deve estar diretamente relacionada ao Ethereum e seu ecossistema. +- **Nível de atividade**: a comunidade deve ser ativa, com interações, posts ou discussões regulares. Comunidades inativas ou dormentes podem ser removidas. +- **Inclusividade**: a comunidade deve promover um ambiente acolhedor que respeite a diversidade e incentive a participação de pessoas de todas as origens. +- **Foco não comercial**: as listagens são destinadas a espaços orientados pela comunidade em vez de plataformas comerciais ou promocionais. + +### Diretrizes de conteúdo {#content-guidelines} + +- **Conteúdo apropriado**: as comunidades devem ter suas próprias diretrizes de moderação, evitando spam, discurso de ódio, assédio ou qualquer conteúdo que promova atividades ilegais. +- **Idioma**: embora o inglês seja o idioma principal, comunidades em outros idiomas são incentivadas a se inscrever, desde que mantenham uma atmosfera inclusiva e respeitosa. +- **Transparência**: informações claras sobre o propósito, as regras e os moderadores da comunidade devem estar disponíveis para os membros. + +### Outras recomendações {#other-recommendations} + +- **Acessibilidade**: os fóruns da comunidade devem ser acessíveis para que todos possam ler, sem exigir inscrição ou registro. +- **Convites para servidores do Discord**: recomenda-se que apenas convites confiáveis para servidores do Discord sejam adicionados ao ethereum.org. Idealmente, esses convites devem levar a uma página da comunidade no site (por exemplo, [ethglobal.com/discord](https://ethglobal.com/discord)) ou ser de um URL oficial (por exemplo, [discord.gg/ethstaker](https://discord.gg/ethstaker) ou [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker)). + +Se você acredita que uma comunidade deve ser adicionada ou removida com base nestas diretrizes, por favor [abra uma issue em nosso repositório do GitHub](https://github.com/ethereum/ethereum-org-website/issues). + ## 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 +r/ethereum - tudo sobre 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 - boas-vindas a todos os interessados em fazer staking no Ethereum +Fellowship of Ethereum Magicians - comunidade orientada para padrões técnicos em Ethereum +Ethereum Stackexchange - discussão e ajuda para desenvolvedores Ethereum +Ethereum Research - o messageboard mais influente para pesquisa em criptoeconomia ## 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 +Ethereum Cat Herders - comunidade orientada a oferecer suporte de gerenciamento de projetos para o desenvolvimento do Ethereum +Ethereum Hackers - Bate-papo do Discord administrado pela ETHGlobal: uma comunidade on-line para hackers do Ethereum de todo o mundo +CryptoDevs - Comunidade do Discord focada no desenvolvimento do Ethereum +EthStaker Discord - orientação, educação, suporte e recursos administrados pela comunidade para stakers existentes e em potencial +Equipe do site Ethereum.org - passe por aqui e converse sobre o desenvolvimento e design do site ethereum.org com a equipe e pessoal da comunidade +Matos Discord - comunidade de criadores da web3 onde construtores, figuras importantes da indústria e entusiastas do Ethereum se reúnem. Somos apaixonados pelo desenvolvimento, design e cultura Web3. Venha construir conosco. +Solidity Gitter - bate-papo para desenvolvimento em Solidity (Gitter) +Solidity Matrix - bate-papo para desenvolvimento em Solidity (Matrix) +Ethereum Stack Exchange - fórum de perguntas e respostas +Peera Community Forum - fórum descentralizado de perguntas e respostas -## YouTube e Twitter {#youtube-and-twitter} +## YouTube e X (antigo 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 +Ethereum Foundation - Mantenha-se atualizado com as últimas novidades da Ethereum Foundation +@ethereum - Conta principal do Ethereum para a comunidade +@ethereumfndn - Conta oficial da Ethereum Foundation +@ethdotorg - O portal para o Ethereum, construído para nossa crescente comunidade global - +
Saiba mais sobre DAOs -
+ diff --git a/public/content/translations/pt-br/community/research/index.md b/public/content/translations/pt-br/community/research/index.md index 9998ca7a482..580eeadf137 100644 --- a/public/content/translations/pt-br/community/research/index.md +++ b/public/content/translations/pt-br/community/research/index.md @@ -1,63 +1,63 @@ --- -title: Áreas ativas de pesquisa do Ethereum -description: Acesse diferentes áreas de pesquisa aberta e saiba como participar. +title: "Áreas ativas de pesquisa sobre o Ethereum" +description: "Acesse diferentes áreas de pesquisa aberta e saiba como participar." lang: pt-br --- -# Áreas ativas de pesquisa do Ethereum {#active-areas-of-ethereum-research} +# Áreas ativas de pesquisa sobre o 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 em todo o 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. +Um dos principais pontos fortes do Ethereum é que 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 a pesquisa no Ethereum {#how-ethereum-research-works} +## Como funciona a pesquisa sobre o Ethereum {#how-ethereum-research-works} -A pesquisa no Ethereum é aberta e transparente, e incorpora os princípios de [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 no Ethereum avança rapidamente, com novas constatações publicadas e discutidas abertamente em fóruns como [ethresear.ch](https://ethresear.ch/), em vez de chegar à comunidade por meio de publicações tradicionais após sessões de revisão por pares. +A pesquisa sobre o 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 consiste em 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 gerais de pesquisa {#general-research-resources} +## Recursos para pesquisa comum {#general-research-resources} -Independentemente do tópico específico, há uma riqueza de informações sobre pesquisa do Ethereum a ser descoberta em [ethresear.ch](https://ethresear.ch) e no canal [Eth R&D Discord](https://discord.gg/qGpsxSA). Esses são os principais locais onde os pesquisadores do Ethereum discutem as ideias e oportunidades mais recentes de desenvolvimento. +Independentemente do tópico específico, há uma grande quantidade de informações sobre a pesquisa sobre o Ethereum que podem ser encontradas em [ethresear.ch](https://ethresear.ch) e no [canal Eth R&D Discord](https://discord.gg/qGpsxSA). Esses são os principais locais onde os pesquisadores do Ethereum discutem as ideias e oportunidades mais recentes de desenvolvimento. -Este relatório, publicado em maio de 2022 pela [DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum), oferece uma boa visão geral do planejamento do Ethereum. +Esse relatório 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 do Ethereum. ## Fontes de financiamento {#sources-of-funding} -Você pode participar da pesquisa do Ethereum e ser pago por isso! Por exemplo, a [the Ethereum Foundation](/foundation/) realizou recentemente uma [rodada de financiamento de concessões acadêmicas](https://esp.ethereum.foundation/academic-grants). Informações sobre oportunidades de financiamento ativas e futuras estão disponíveis na [página de concessões do Ethereum](/community/grants/). +Você pode participar da pesquisa sobre o Ethereum e ser pago por isso! Por exemplo, a [Ethereum Foundation](/foundation/) realizou recentemente um [ciclo de financiamento de subsídios acadêmicos](https://esp.ethereum.foundation/academic-grants). Você pode encontrar informações sobre oportunidades de financiamento ativas e futuras na [página de subsídios do Ethereum](/community/grants/). -## Pesquisa de protocolo {#protocol-research} +## Pesquisa sobre protocolos {#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. +A pesquisa sobre protocolos está relacionada à camada de base do 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 da blockchain. A pesquisa sobre protocolos é dividida em duas categorias gerais: consenso e execução. ### Consenso {#consensus} -A pesquisa de consenso é relativa ao [mecanismo de prova de participação do Ethereum](/developers/docs/consensus-mechanisms/pos/). Alguns exemplos de tópicos de pesquisa de consenso são: +A pesquisa sobre consenso está relacionada com o [mecanismo de prova de participação do Ethereum](/developers/docs/consensus-mechanisms/pos/). Alguns exemplos de tópicos de pesquisa sobre consenso são: - identificar e resolver vulnerabilidades; - quantificar a segurança criptoeconômica; -- aumentar a segurança ou desempenho de implementações do cliente; +- aumentar a segurança ou o 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. +Além da pesquisa voltada para o futuro, algumas reformulações fundamentais do protocolo, como a finalidade de slot ú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 sobre o Casper-FFG](https://arxiv.org/abs/1710.09437) -- [Artigo sobre Casper-FFG](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) -- [Artigo sobre o Gasper](https://arxiv.org/abs/2003.03052) +- [Artigo Casper-FFG](https://arxiv.org/abs/1710.09437) +- [Explicando o Casper-FFG](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) +- [Artigo Gasper](https://arxiv.org/abs/2003.03052) #### Pesquisa recente {#recent-research} -- [Ethresear.ch Consensus](https://ethresear.ch/c/consensus/29) -- [Dilema disponibilidade/finalidade](https://arxiv.org/abs/2009.04987) -- [Finalidade de espaço único](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) -- [Separação de Proponente-Construtor](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) +- [Consenso Ethresear.ch](https://ethresear.ch/c/consensus/29) +- [Dilema entre disponibilidade/finalidade](https://arxiv.org/abs/2009.04987) +- [Finalidade de slot único](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) +- [Separação proponente-construtor](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) ### Execução {#execution} -A camada de execução se preocupa com a execução de transações, com a execução do [Máquina Virtual do Ethereum (EVM)](/developers/docs/evm/) e com a geração de cargas de execução para passar para a camada de consenso. Há muitas áreas ativas de pesquisa, incluindo: +A camada de execução é responsável pela execução de transações, pelo funcionamento da [Máquina Virtual Ethereum (EVM)](/developers/docs/evm/) e pela 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). +- e incorporando novas estruturas de dados (por exemplo, Verkle Tries). #### Leitura de apoio {#background-reading-1} @@ -66,13 +66,13 @@ A camada de execução se preocupa com a execução de transações, com a execu #### Pesquisa recente {#recent-research-1} -- [Otimizações de banco de dados](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) +- [Otimizações do banco de dados](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) - [Expiração do estado](https://notes.ethereum.org/@vbuterin/state_expiry_eip) - [Caminhos para a expiração do estado](https://hackmd.io/@vbuterin/state_expiry_paths) -- [Verkel e proposta de expiração de estado](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) +- [Verkle e a proposta de expiração do estado](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) - [Gerenciamento de histórico](https://eips.ethereum.org/EIPS/eip-4444) -- [Verkle Trees](https://vitalik.eth.limo/general/2021/06/18/verkle.html) -- [Amostragem da disponibilidade dos dados](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) +- [Á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} @@ -80,39 +80,39 @@ Os clientes Ethereum são implementações do protocolo Ethereum. O desenvolvime 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 +1. um cliente de consenso para manter o controle do início da blockchain, de propagar os blocos e processar a lógica de consenso +2. um cliente de execução para oferecer suporte à Máquina Virtual Ethereum e executar transações e contratos inteligentes -Consulte a [página de nós e clientes](/developers/docs/nodes-and-clients/) para obter mais detalhes sobre nós e clientes e uma lista de todas as implementações atuais de clientes. Um histórico de todas as melhorias do Ethereum também está disponível na [página de histórico](/ethereum-forks/). +Consulte a [página de 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 de clientes atuais. Você também pode encontrar um histórico de todas as melhorias do Ethereum na página [página Histórico](/ethereum-forks/). ### Clientes de execução {#execution-clients} - [Especificação do cliente de execução](https://github.com/ethereum/execution-specs) -- [Especificações da API de execução](https://github.com/ethereum/execution-apis) +- [Especificação da API de execução](https://github.com/ethereum/execution-apis) ### Clientes de consenso {#consensus-clients} - [Especificação do cliente de consenso](https://github.com/ethereum/consensus-specs) -- [Especificação da API Beacon](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) +- [Especificação da API do Beacon](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) -## Escalabilidade e desempenho {#scaling-and-performance} +## Dimensionamento e desempenho {#scaling-and-performance} -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 do Ethereum estão disponíveis na nossa [página de escalabilidade](/developers/docs/scaling). +O dimensionamento do Ethereum é uma importante á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 o dimensionamento do Ethereum estão disponíveis em nossa [página Dimensionamento](/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. +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 cada vez mais relevante, 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) +- [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 da Arbitrum para sequenciadores](https://eprint.iacr.org/2021/1465) -- [Camada 2 ethresear.ch](https://ethresear.ch/c/layer-2/32) -- [Roadmap centrado em rollup](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) +- [Ordenação justa do Arbitrum para sequenciadores](https://eprint.iacr.org/2021/1465) +- [Ethresear.ch Layer 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} @@ -122,59 +122,63 @@ Uma área específica da camada 2 que exige mais pesquisa e desenvolvimento são #### Leitura de apoio {#background-reading-3} - [Introdução às pontes de blockchain](/bridges/) -- [Vitalik sobre pontes](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) -- [Artigo de pontes de blockchain](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) -- [Valor bloqueado em pontes](https://dune.com/eliasimos/Bridge-Away-(from-Ethereum)) +- [Vitalik: Sobre as pontes](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) +- [Artigo sobre as pontes da 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) -### Fragmentação {#sharding} +### 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. +A fragmentação da blockchain Ethereum faz parte do roadmap de desenvolvimento há muito tempo. Entretanto, novas soluções de dimensionamento, como "Danksharding", ocupam atualmente o centro das atenções. + +O precursor do Danksharding completo, conhecido como Proto-Danksharding, entrou em operação com a melhoria de rede Cancun-Deneb ("Dencun"). + +[Mais informações sobre a melhoria Dencun](/roadmap/dencun/) #### Leitura de apoio {#background-reading-4} -- [Notas sobre Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) -- [Vídeo Bankless Danksharding](https://www.youtube.com/watch?v=N5p0TB77flM) -- [Acervo de pesquisa de fragmentação do Ethereum (Ethereum Sharding Research Compendium)](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) +- [Notas sobre o Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) +- [Danksharding sem banco: vídeo](https://www.youtube.com/watch?v=N5p0TB77flM) +- [Compêndio de pesquisa sobre fragmentação do 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 amostragem de disponibilidade de dados e fragmentação](https://hackmd.io/@vbuterin/sharding_proposal) +- [Vitalik sobre sharding e amostragem de disponibilidade de dados](https://hackmd.io/@vbuterin/sharding_proposal) ### Hardware {#hardware} -[Executar nós](/developers/docs/nodes-and-clients/run-a-node/) em hardware modesto é fundamental para manter a descentralização do Ethereum. Portanto, a pesquisa ativa para minimizar os requisitos de hardware para executar os nós é uma importante área de pesquisa. +[A execução de nós](/developers/docs/nodes-and-clients/run-a-node/) em hardware modesto é fundamental para manter a descentralização do 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 on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) +- [Ethereum em ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) #### Pesquisa recente {#recent-research-5} -- [ecdsa em FPGAs](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738) +- [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. +A 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 & ZKP {#cryptography--zkp} +### 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 hash Keccak](https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview), encontrando compromissos polinomiais melhores do que os existentes ou reduzindo o custo dos circuitos de verificação de assinaturas e de geração de chaves públicas ecdsa. +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 0xparc](https://0xparc.org/blog) +- [Blog do 0xparc](https://0xparc.org/blog) - [zkp.science](https://zkp.science/) -- [Podcast Zero Knowledge](https://zeroknowledge.fm/) +- [Podcast da Zero Knowledge](https://zeroknowledge.fm/) #### Pesquisa recente {#recent-research-6} -- [Avanço recente na criptografia de curva elíptica](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346) +- [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} @@ -185,98 +189,98 @@ As carteiras Ethereum podem ser extensões de navegador, aplicativos móveis e d - [Introdução às carteiras](/wallets/) - [Introdução à segurança da carteira](/security/) -- [Segurança no ethresear.ch](https://ethresear.ch/tag/security) -- [Abstração de conta EIP-2938](https://eips.ethereum.org/EIPS/eip-2938) -- [Abstração de conta EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) +- [Ethresear.ch Security](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 centradas em validação](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) +- [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) -- [Opcodes EIP-3074 AUTH e AUTHCALL](https://eips.ethereum.org/EIPS/eip-3074) -- [Publicação de código em um endereço EOA](https://eips.ethereum.org/EIPS/eip-5003) +- [EIP-3074 AUTH e os Opcodes AUTHCALL](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 divulgação {#community-education-and-outreach} +## 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 publicações em blogs e artigos, livros, podcasts, memes, recursos de ensino, eventos e qualquer outra atividade que desenvolva comunidades, receba novos iniciantes e eduque as pessoas sobre o Ethereum. +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 o Ethereum. -### UX/UI {#uxui} +### UX/IU {#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. +Para atrair mais pessoas para o Ethereum, o ecossistema precisa melhorar a UX/IU. Isso exigirá que designers e especialistas de produtos revejam o design de carteiras e aplicativos. #### Leitura de apoio {#background-reading-8} -- [UX/UI no ethresear.ch](https://ethresear.ch/c/ui-ux/24) +- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24) #### Pesquisa recente {#recent-research-8} -- [Design Web3 no Discord](https://discord.gg/FsCFPMTSm9) -- [Princípios de Design Web3](https://www.web3designprinciples.com/) -- [Discussão sobre UX do Ethereum Magicians](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3) +- [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} +### Aspectos econômicos {#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). +De modo geral, a pesquisa dos aspectos econômicos 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 eficientes](https://rig.ethereum.org/) -- [Workshop sobre ETHconomics no Devconnect](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm) +- [Grupo de Incentivos Robustos](https://rig.ethereum.org/) +- [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 da oferta em circulação](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954) -- [Quantificação de MEV: em que nível a floresta é escura?](https://arxiv.org/abs/2101.05511) +- [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 sombria é 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. +Os mercados de espaço de bloco regem a inclusão de transações de usuários finais, seja diretamente no 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 do EIP-1559 (Grupo de incentivos eficientes)](https://ethereum.github.io/abm1559) +- [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: aceleração, reordenação de transações e instabilidade de consenso em corretoras descentralizadas](https://arxiv.org/abs/1904.05234) +- [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 de vídeo EIP-1559 multidimensional](https://youtu.be/QbR4MTgnCko) -- [MEV entre domínios](http://arxiv.org/abs/2112.01472) -- [Leilões de MEV](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) +- [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. +Os validadores usam o ativo nativo do Ethereum (ether) como garantia contra comportamento desonesto. Os aspectos criptoeconômicos 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} -- [Masterclass sobre modelo econômico e de economia Ethereum](https://github.com/CADLabs/ethereum-economic-model) -- [Simulações de incentivos PoS (Grupo de incentivos eficientes)](https://ethereum.github.io/beaconrunner/) +- [Aula magna sobre os aspectos econômicos 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} -- [Aumentar a resistência à censura de transações no âmbito da separação proponente/construtor (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) -- [Três ataques ao PoS Ethereum](https://arxiv.org/abs/2110.10086) +- [Aumento da resistência à censura de transações sob separação entre proponente e construtor (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) +- [Três ataques à PoS Ethereum](https://arxiv.org/abs/2110.10086) -### Liquidez de participação e derivativos {#liquid-staking-and-derivatives} +### Staking líquido 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). +O staking líquido 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. No entanto, os incentivos e a dinâmica de mercado associados ao staking líquido 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} -- [Participação líquida Ethresear.ch](https://ethresear.ch/search?q=liquid%20staking) -- [Lido: o caminho para a participação de Ethereum sem confiança](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/) -- [Rocket Pool: introdução ao protocolo de participação](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd) +- [Staking líquido 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} -- [Processar saques do Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) +- [Tratamento de saques do Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) - [Credenciais de saque](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722) -- [Os riscos dos derivativos de participação líquida](https://notes.ethereum.org/@djrtwo/risks-of-lsd) +- [Os riscos dos derivativos de staking líquido](https://notes.ethereum.org/@djrtwo/risks-of-lsd) -## Testando {#testing} +## Testes {#testing} ### Verificação formal {#formal-verification} @@ -290,20 +294,20 @@ A verificação formal consiste em escrever código para verificar se as especif #### 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 de Beacon Chain](https://github.com/runtimeverification/deposit-contract-verification) +- [Verificação formal da especificação da Beacon Chain](https://github.com/runtimeverification/deposit-contract-verification) -## Ciência e análise de dados {#data-science-and-analytics} +## Ciência de dados e análise {#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} -- [Dune Analytics](https://dune.com/browse/dashboards) +- [Análise Dune](https://dune.com/browse/dashboards) - [Painel de diversidade do cliente](https://clientdiversity.org/) #### Pesquisa recente {#recent-research-14} -- [Análise de dados do grupo de incentivos eficientes](https://rig.ethereum.org/) +- [Análise robusta de dados do grupo de incentivos](https://rig.ethereum.org/) ## Aplicativos e ferramentas {#apps-and-tooling} @@ -311,17 +315,17 @@ A camada de aplicativos oferece suporte a um ecossistema diversificado de progra ### 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. +Finanças Descentralizadas (DeFi) é uma das principais classes de aplicativos criados 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) +- [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) -- [Optimism: o caminho para as transações abaixo do dólar](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) +- [Finanças descentralizadas, propriedade centralizada?](https://arxiv.org/pdf/2012.09306.pdf) +- [Optimism: O caminho para transações por menos de um dólar](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) ### DAOs {#daos} @@ -329,8 +333,8 @@ Um caso de uso de impacto para o Ethereum é a capacidade de se organizar de for #### Leitura de apoio {#background-reading-16} -- [Introdução às DAOs](/dao/) -- [Dao Collective](https://daocollective.xyz/) +- [Introdução a DAOs](/dao/) +- [Coletivo DAO](https://daocollective.xyz/) #### Pesquisa recente {#recent-research-16} @@ -342,42 +346,42 @@ As ferramentas para desenvolvedores do Ethereum têm melhorado rapidamente. Há #### Leitura de apoio {#background-reading-17} -- [Ferramental por linguagem de programação](/developers/docs/programming-languages/) -- [Frameworks do desenvolvedor](/developers/docs/frameworks/) -- [Lista de ferramentas do desenvolvedor de consenso](https://github.com/ConsenSys/ethereum-developer-tools-list) +- [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) +- [CryptoDevHub: Ferramentas EVM](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools) #### Pesquisa recente {#recent-research-17} -- [Canal de ferramental de consenso Eth P&D Discord](https://discordapp.com/channels/595666850260713488/746343380900118528) +- [Canal de ferramentas de consenso do Discord 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. +Os oráculos importam dados offchain para a blockchain de forma descentralizada e sem permissão. Obter esses dados onchain permite que os dapps sejam reativos a fenômenos do mundo real, como flutuações de preços em ativos do mundo real, eventos em aplicativos offchain ou até mesmo mudanças no clima. #### Leitura de apoio {#background-reading-18} -- [Introdução a oráculos](/developers/docs/oracles/) +- [Introdução aos oráculos](/developers/docs/oracles/) #### Pesquisa recente {#recent-research-18} -- [Pesquisa de oráculos no blockchain](https://arxiv.org/pdf/2004.07140.pdf) -- [Artigo técnico da Chainlink](https://chain.link/whitepaper) +- [Pesquisa sobre oráculos de blockchain](https://arxiv.org/pdf/2004.07140.pdf) +- [Whitepaper da Chainlink](https://chain.link/whitepaper) -### Segurança do aplicativo {#app-security} +### 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. +Os hakeios no 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 contratos do Ethereum](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) -- [Rekt News](https://twitter.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg) +- [Lista de post-mortems de hackeios de contratos Ethereum](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) +- [Rekt News](https://x.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg) #### Pesquisa recente {#recent-research-19} -- [Aplicações ethresear.ch](https://ethresear.ch/c/applications/18) +- [Ethresear.ch Applications](https://ethresear.ch/c/applications/18) ### Pilha de tecnologia {#technology-stack} @@ -385,11 +389,11 @@ A descentralização de toda a pilha de tecnologia Ethereum é uma importante á #### Leitura de apoio {#background-reading-20} -- [Pilha de Ethereum](/developers/docs/ethereum-stack/) -- [Coinbase: introdução à pilha Web3](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0) +- [Pilha Ethereum](/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 contrato inteligente](/developers/docs/smart-contracts/composability/) +- [Composição de contratos inteligentes](/developers/docs/smart-contracts/composability/) diff --git a/public/content/translations/pt-br/contributing/adding-desci-projects/index.md b/public/content/translations/pt-br/contributing/adding-desci-projects/index.md index 00f715196d2..19506e324fc 100644 --- a/public/content/translations/pt-br/contributing/adding-desci-projects/index.md +++ b/public/content/translations/pt-br/contributing/adding-desci-projects/index.md @@ -1,6 +1,6 @@ --- title: Adicionando projetos DeSci -description: A política que usamos ao adicionar links para projetos na página DeSci no ethereum.org +description: "A política que usamos ao adicionar um link para projetos na página DeSci em ethereum.org" lang: pt-br --- @@ -10,25 +10,25 @@ Queremos ter certeza de que mostraremos uma variedade de projetos e oferecemos u Qualquer um pode sugerir um projeto para listar na página DeSci no ethereum.org. Igualmente, qualquer pessoa que veja um projeto que não é mais relevante ou não atende aos nossos critérios de elegibilidade pode sugerir a remoção dele. -## A estrutura de decisão {#the-decision-framework} +## O framework de decisão {#the-decision-framework} -### Critérios para inclusão: os obrigatórios {#the-must-haves} +### Critérios para inclusão: os requisitos obrigatórios {#the-must-haves} -- **Código fonte/dados abertos** — a abertura do código e dos dados é um princípio fundamental do DeSci, portanto, os projetos DeSci não devem ser de código fechado. A base de código deveria ser acessível e idealmente aberta para PRs (solicitações de pull). -- **Os projetos DeSci deveriam ser comprovadamente descentralizados** — isso poderia incluir ser governado por um DAO ou ser construído com uma pilha de tecnologia descentralizada, incluindo carteiras sem custódia. Provavelmente, isso envolve contratos inteligentes auditáveis no Ethereum. -- **Informação de listagem honesta e precisa** - é esperado que as informações de listagem sugeridas dos projetos sejam honestas e precisas. Produtos que falsificam informações de listagem, como declarar que seu produto é de "código aberto" quando não é, serão removidos. -- **Comprometimento demonstrável para ampliar o acesso à ciência** — um projeto DeSci deve ser capaz de articular como eles ampliam a participação na ciência para o público em geral, não apenas para detentores de tokens/NFT. -- **Acessível globalmente** - seu projeto não contém limitações geográficas ou requisitos KYC (conheça seu cliente) que não permitam que ele seja acessado por certas pessoas. -- **Site Web e documentação instrutivos** - é importante que as pessoas que acessem o site do projeto possam entender o objetivo do projeto, como ele contribui para a descentralização da infraestrutura da ciência e como é possível participar. -- **O projeto deve fazer parte do ecossistema Ethereum** — no ethereum.org, acreditamos que o Ethereum (e sua camada 2) seja a camada base apropriada para o movimento DeSci. -- **O projeto está razoavelmente bem estabelecido** — o projeto tem usuários reais que puderam acessar os serviços do projeto por vários meses. +- **Código-fonte/dados abertos** - A abertura do código e dos dados é um princípio central da DeSci, então os projetos DeSci não devem ter o código fechado. A base de código deveria ser acessível e idealmente aberta para PRs (solicitações de pull). +- **Os projetos DeSci devem ser comprovadamente descentralizados** - Isso pode incluir ser governado por uma DAO ou construído com uma pilha de tecnologia descentralizada, incluindo carteiras sem custódia. Provavelmente, isso envolve contratos inteligentes auditáveis no Ethereum. +- **Informações de listagem honestas e precisas** - Espera-se que quaisquer sugestões de listagens de projetos venham com informações honestas e precisas. Produtos que falsificam informações de listagem, como declarar que seu produto é de "código aberto" quando não é, serão removidos. +- **Compromisso demonstrável em ampliar o acesso à ciência** - Um projeto DeSci deve ser capaz de articular como ele amplia a participação na ciência para o público em geral, e não apenas para detentores de tokens/NFT. +- **Acessível globalmente** - Seu projeto não tem limitações geográficas ou requisitos de KYC que excluam certas pessoas de acessar seu serviço. +- **Site e documentação informativos** - É importante que os visitantes do site do projeto possam entender o que o projeto realmente faz, como ele contribui para a descentralização da infraestrutura científica e como participar. +- **O projeto deve fazer parte do ecossistema Ethereum** - No ethereum.org, acreditamos que o Ethereum (e suas Camadas 2) é a camada de base apropriada para o movimento DeSci. +- **O projeto está razoavelmente bem estabelecido** - O projeto tem usuários reais que conseguem acessar os serviços do projeto há vários meses. ### Critérios opcionais -- **Disponível em vários idiomas** - seu projeto é traduzido em vários idiomas, permitindo que usuários ao redor do mundo o acessem. -- **Recursos educacionais** - seu produto deveria apresentar uma experiência de integração bem planejada para ajudar e informar os usuários. Ou então, oferecer conteúdo prático como artigos e vídeos. -- **Auditorias de terceiros** - uma empresa especializada confiável realizou uma auditoria em seu produto para detectar vulnerabilidades. -- **Ponto de contato** — um ponto de contato para o projeto (isto pode ser um representante de uma DAO ou comunidade) nos ajudará muito a obter informações precisas quando as alterações forem feitas. Isso manterá a atualização do ethereum.org gerenciável ao reunir informações futuras. +- **Disponível em vários idiomas** - Seu projeto é traduzido para vários idiomas, permitindo que usuários do mundo todo o acessem. +- **Recursos educacionais** - Seu produto deve ter uma experiência de integração bem projetada para ajudar e educar os usuários. Ou então, oferecer conteúdo prático como artigos e vídeos. +- **Auditorias de terceiros** - Seu produto foi auditado profissionalmente em busca de vulnerabilidades por um terceiro de confiança. +- **Ponto de contato** - Um ponto de contato para o projeto (que pode ser um representante de uma DAO ou comunidade) nos ajudará muito a obter informações precisas quando forem feitas alterações. Isso manterá a atualização do ethereum.org gerenciável ao reunir informações futuras. ## Manutenção {#maintenance} @@ -37,8 +37,8 @@ O Ethereum é fluido por natureza, por isso, suas equipes e produtos vêm e vão - Assegurar que todos os projetos listados cumpram com nossos critérios - Verificar que não existam produtos que cumpram mais critérios do que os atualmente listados -O ethereum.org é mantido pela comunidade de código aberto e dependemos da comunidade para ajudar a mantê-lo atualizado. Se você notar alguma informação sobre projetos listados que precisam ser atualizados, abra um tíquete ou uma solicitação de pull em nosso repositório do GitHub. +O ethereum.org é mantido pela comunidade de código aberto e contamos com a comunidade para ajudar a mantê-lo atualizado. Se você notar alguma informação sobre projetos listados que precisam ser atualizados, abra um tíquete ou uma solicitação de pull em nosso repositório do GitHub. ## Termos de uso {#terms-of-use} -Consulte também nossos [termos de uso](/terms-of-use/). Informações sobre o ethereum.org são fornecidas exclusivamente para fins de informação geral. +Consulte também nossos [termos de uso](/terms-of-use/). Informações sobre o ethereum.org são fornecidas exclusivamente para fins de informação geral. diff --git a/public/content/translations/pt-br/contributing/adding-developer-tools/index.md b/public/content/translations/pt-br/contributing/adding-developer-tools/index.md index ceade2cb367..76f064bf993 100644 --- a/public/content/translations/pt-br/contributing/adding-developer-tools/index.md +++ b/public/content/translations/pt-br/contributing/adding-developer-tools/index.md @@ -1,7 +1,7 @@ --- title: Adicionando ferramentas de desenvolvedor lang: pt-br -description: Nossos critérios para listar ferramentas de desenvolvedor no ethereum.org +description: "Nossos critérios para listar ferramentas de desenvolvedor no ethereum.org" --- # Adicionando ferramentas de desenvolvedor {#contributing-to-ethereumorg-} @@ -10,7 +10,7 @@ Queremos ter certeza de que listamos os melhores recursos de desenvolvedor poss Se nos esquecermos de alguma ferramenta de desenvolvedor útil, não hesite em nos sugeri-la por meio de um canal adequado. -Atualmente, listamos as ferramentas de desenvolvedor por meio do nosso [portal do desenvolvedor](/developers/). +Atualmente, listamos ferramentas de desenvolvedor em todo o nosso [portal do desenvolvedor](/developers/). **Não hesite em nos sugerir novas adições às páginas apropriadas.** @@ -46,7 +46,7 @@ Muitos projetos no espaço Ethereum são de código aberto. É mais provável qu --- -## Ordenação dos produtos {#product-ordering} +## Ordenação de Produtos {#product-ordering} A menos que os produtos sejam ordenados especificamente de outra forma, como em ordem alfabética, os produtos serão exibidos dos mais antigos aos mais recentes adicionados à página. Em outras palavras, os produtos mais recentes são adicionados ao final da lista. @@ -57,5 +57,5 @@ A menos que os produtos sejam ordenados especificamente de outra forma, como em Se você deseja adicionar uma ferramenta de desenvolvedor ao ethereum.org que atende aos critérios, crie um tíquete no GitHub. - Criar tíquete + Abrir chamado diff --git a/public/content/translations/pt-br/contributing/adding-exchanges/index.md b/public/content/translations/pt-br/contributing/adding-exchanges/index.md index 56796081355..bfce33c07a7 100644 --- a/public/content/translations/pt-br/contributing/adding-exchanges/index.md +++ b/public/content/translations/pt-br/contributing/adding-exchanges/index.md @@ -1,10 +1,10 @@ --- -title: Adicionar câmbios -description: A política que usamos ao adicionar câmbios ao ethereum.org +title: "Adicionar câmbios" +description: "A política que usamos ao adicionar câmbios ao ethereum.org" lang: pt-br --- -# Adicionar câmbios ao Ethereum {#adding-ethereum-exchanges} +# Adicionando corretoras Ethereum {#adding-ethereum-exchanges} Qualquer pessoa pode sugerir novos câmbios no ethereum.org. @@ -16,7 +16,7 @@ Esta página permite ao usuário inserir onde mora e ver quais câmbios pode usa Devido a esse contexto, precisaremos de algumas informações específicas quando você sugerir um câmbio. -**NOTA:** Se você quiser adicionar um câmbio descentralizado, confira nossa [política para adicionar carteiras e dapps](/contributing/adding-products/). +**OBSERVAÇÃO:** Se você quiser listar uma corretora descentralizada, dê uma olhada em nossa [política para listar carteiras e dapps](/contributing/adding-products/). ## Do que precisamos {#what-we-need} @@ -25,16 +25,16 @@ Devido a esse contexto, precisaremos de algumas informações específicas quand - Prova de que a agência de câmbio é uma empresa comercial legítima - Qualquer informação adicional que você tenha: podem ser informações sobre a empresa, como anos de operação, apoio financeiro, etc. -Precisamos dessas informações para poder [ajudar usuários a encontrar uma agência de câmbio que possam usar](/get-eth/#country-picker). +Precisamos dessas informações para que possamos, com precisão, [ajudar os usuários a encontrar uma corretora que possam usar](/get-eth/#country-picker). E para que o ethereum.org possa confiar na legitimidade e segurança dos serviços fornecidos pela agência de câmbio. --- -## Adicionar sua agência de câmbio {#add-exchange} +## Adicione sua corretora {#add-exchange} Se você deseja adicionar uma agência de câmbio no ethereum.org, crie um tíquete no GitHub. - Criar tíquete +Abrir chamado diff --git a/public/content/translations/pt-br/contributing/adding-glossary-terms/index.md b/public/content/translations/pt-br/contributing/adding-glossary-terms/index.md index 6f5a315b1a9..c3e66e41703 100644 --- a/public/content/translations/pt-br/contributing/adding-glossary-terms/index.md +++ b/public/content/translations/pt-br/contributing/adding-glossary-terms/index.md @@ -1,12 +1,12 @@ --- -title: Adicionar termos ao glossário +title: "Adicionar termos ao glossário" lang: pt-br -description: Nossos critérios para adicionar novos termos ao glossário do ethereum.org +description: "Nossos critérios para adicionar novos termos ao glossário do ethereum.org" --- # Adicionando termos ao glossário {#contributing-to-ethereumorg-} -Esse espaço passa por mudanças diárias. Novos termos estão constantemente entrando no léxico dos usuários do Ethereum, e precisamos da sua ajuda para fornecer referências atualizadas e precisas para tudo o que diz respeito ao Ethereum. Confira o [glossário](/glossary/) e veja abaixo se você deseja ajudar! +Esse espaço passa por mudanças diárias. Novos termos estão constantemente entrando no léxico dos usuários do Ethereum, e precisamos da sua ajuda para fornecer referências atualizadas e precisas para tudo o que diz respeito ao Ethereum. Confira o [glossário](/glossary/) atual e veja abaixo se quiser ajudar! ## Critérios {#criteria} @@ -23,4 +23,4 @@ Novos termos inseridos no glossário serão avaliados pelos seguintes critérios ## Adicione seu termo {#how-decisions-about-the-site-are-made} -Se você quiser adicionar um termo ao glossário no ethereum.org que atenda aos critérios, [abra um tíquete no GitHub](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). +Se você quiser adicionar um termo do glossário ao ethereum.org e ele atender aos critérios, [crie um problema no GitHub](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). diff --git a/public/content/translations/pt-br/contributing/adding-layer-2s/index.md b/public/content/translations/pt-br/contributing/adding-layer-2s/index.md index c465ca5edd4..1c63b404dfd 100644 --- a/public/content/translations/pt-br/contributing/adding-layer-2s/index.md +++ b/public/content/translations/pt-br/contributing/adding-layer-2s/index.md @@ -1,31 +1,31 @@ --- title: Adicionando Camada 2S -description: A política que usamos ao adicionar uma camada 2 ao ethereum.org +description: "A política que usamos ao adicionar uma camada 2 ao ethereum.org" lang: pt-br --- -# Adicionando Camada 2S {#adding-layer-2} +# Adicionando camadas 2 {#adding-layer-2} Queremos garantir que listamos os melhores recursos possíveis para que os usuários possam navegar no espaço da camada 2 de maneira segura e confiante. -Qualquer pessoa pode sugerir a adição de uma camada 2 no ethereum.org. Se houver alguma camada 2 que esquecemos, **[sugira uma](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!** +Qualquer pessoa pode sugerir a adição de uma camada 2 no ethereum.org. Se houver uma camada 2 que não incluímos, **[por favor, sugira](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!** Atualmente, listamos as 2LS nas seguintes páginas: -- [Acumulação otimista](/developers/docs/scaling/optimistic-rollups/) -- [Acumulação de conhecimento zero](/developers/docs/scaling/zk-rollups/) +- [Optimistic rollups](/developers/docs/scaling/optimistic-rollups/) +- [Rollups de conhecimento zero](/developers/docs/scaling/zk-rollups/) - [Camada 2](/layer-2/) Camada 2 é um paradigma relativamente novo e empolgante para o Ethereum. Tentamos criar uma estrutura justa a ser considerada no ethereum.org, mas os critérios listados mudarão e evoluirão com o tempo. -## A estrutura de decisão {#decision-framework} +## O framework de decisão {#decision-framework} -### Critérios para inclusão: os obrigatórios {#criteria-for-inclusion-the-must-haves} +### Critérios de inclusão: os obrigatórios {#criteria-for-inclusion-the-must-haves} **Listando na L2BEAT** -- Para ser considerado, esse projeto deve estar listado na [L2BEAT](https://l2beat.com). A L2BEAT fornece uma avaliação de riscos sólida de projetos da camada 2 que apoiamos para avaliar projetos de L2. **Se o projeto não for apresentado na L2BEAT, não o listaremos como L2 no ethereum.org.** -- [ Saiba como adicionar seu projeto L2 à L2BEAT](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md). +- Para ser considerado, este projeto deve estar listado no [L2BEAT](https://l2beat.com). A L2BEAT fornece uma avaliação de riscos sólida de projetos da camada 2 que apoiamos para avaliar projetos de L2. **Se o projeto não for apresentado na L2BEAT, não o listaremos como L2 no ethereum.org.** +- [Saiba como adicionar seu projeto L2 ao L2BEAT](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md). **Código aberto** @@ -38,11 +38,11 @@ Atualmente, consideramos as seguintes soluções para camada 2: - Acúmulo otimista - Acúmulo de conhecimento zero -_Não consideramos outras soluções de dimensionamento que não usam o Ethereum para disponibilidade de dados ou segurança para a camada 2._ +_Não consideramos outras soluções de escalabilidade que não usam o Ethereum para disponibilidade de dados ou segurança como sendo camada 2._ **Ethereum para disponibilidade de dados** -- A disponibilidade de dados é um importante fator de diferenciação entre outras soluções de dimensionamento e a camada 2. Um projeto **deve** usar a Rede principal do Ethereum para que a disponibilidade de dados seja considerada para listagem. +- A disponibilidade de dados é um importante fator de diferenciação entre outras soluções de dimensionamento e a camada 2. Um projeto **deve** usar a Rede Principal do Ethereum para que a disponibilidade de dados seja considerada para listagem. **Pontes** @@ -56,7 +56,7 @@ _Não consideramos outras soluções de dimensionamento que não usam o Ethereum **Auditoria de segurança externa** -- Seja por meio de auditoria, uma equipe de segurança interna ou algum outro método, a segurança do seu produto deve ser testada de forma confiável. Isso reduz o risco para nossos usuários e demonstra que você leva a segurança a sério. +- Seja por meio de auditoria, uma equipe de segurança interna ou algum outro método, a segurança do seu produto deve ser testada de forma confiável. Isso reduz o risco para nossos usuários e nos mostra que você leva a segurança a sério. **Base de usuários sustentável** @@ -70,7 +70,7 @@ _Não consideramos outras soluções de dimensionamento que não usam o Ethereum - Os projetos listados exigem um explorador de blocos de trabalho para permitir aos usuários navegar facilmente pela cadeia. -### Outros critérios: o que é importante ter {#nice-to-haves} +### Outros critérios: os desejáveis {#nice-to-haves} **Suporte ao câmbio para o projeto** @@ -78,7 +78,7 @@ _Não consideramos outras soluções de dimensionamento que não usam o Ethereum **Links para dapps no ecossistema da camada 2** -- Queremos ser capazes de fornecer informações sobre o que os usuários podem esperar fazer nessa camada 2. (por exemplo, https://portal.arbitrum.io/, https://www.optimism.io/apps) +- Queremos ser capazes de fornecer informações sobre o que os usuários podem esperar fazer nessa camada 2. (p. ex., https://portal.arbitrum.io/, https://www.optimism.io/apps) **Listas de contratos de token** @@ -90,8 +90,8 @@ _Não consideramos outras soluções de dimensionamento que não usam o Ethereum ## Adicione sua camada 2 {#add-exchange} -Se você quiser adicionar uma camada 2 ao ethereum.org, abra um tíquete no Github. +Se você quiser adicionar uma camada 2 ao ethereum.org, abra um tíquete no GitHub. - Crie um ticket +Abrir chamado diff --git a/public/content/translations/pt-br/contributing/adding-products/index.md b/public/content/translations/pt-br/contributing/adding-products/index.md index 48b8219cc35..a1594236f1c 100644 --- a/public/content/translations/pt-br/contributing/adding-products/index.md +++ b/public/content/translations/pt-br/contributing/adding-products/index.md @@ -1,6 +1,6 @@ --- title: Adicionando produtos -description: A política que usamos ao adicionar dapps ao ethereum.org +description: "A política que usamos ao adicionar dapps ao ethereum.org" lang: pt-br --- @@ -17,11 +17,11 @@ Atualmente, os dapps estão listados em: Embora novas adições sejam bem-vindas, escolhemos os dapps atuais baseados na experiência que estamos tentando criar aos nossos usuários. Eles são baseados em alguns dos nossos princípios de design: -- _Inspirador_: qualquer dado no ethereum.org deve oferecer algo novo para seus usuários -- _Uma boa história_: o que está listado deve proporcionar um momento "aha!" -- _Credível_: todos os negócios/projetos devem ser legítimos para minimizar o risco do usuário +- _Inspiracional_: tudo no ethereum.org deve oferecer algo novo aos usuários +- _Uma boa história_: o que está listado deve proporcionar um momento "aha" +- _Confiável_: todos os negócios/projetos devem ser legítimos para minimizar riscos aos usuários -Em geral, o **ethereum.org quer proporcionar uma "experiência de integração ininterrupta" para novos usuários**. Por essa razão, adicionamos dapps baseados em: +No geral, o **ethereum.org quer fornecer uma "experiência de integração contínua" para novos usuários**. Por essa razão, adicionamos dapps baseados em: - facilidade de uso - interoperabilidade com outros produtos @@ -30,28 +30,28 @@ Em geral, o **ethereum.org quer proporcionar uma "experiência de integração i Aqui está a nossa estrutura de decisão em mais detalhes. Não hesite em comentar ou sugerir modificações. -## A estrutura de decisão {#decision-framework} +## O framework de decisão {#decision-framework} -### Critérios para inclusão: os obrigatórios {#criteria-for-inclusion-the-must-haves} +### Critérios de inclusão: os obrigatórios {#criteria-for-inclusion-the-must-haves} -- **Um produto seguro e testado** — seja por auditoria, uma equipe interna de segurança ou outro método, a segurança do seu produto deve ser testada de forma confiável. Isso reduz o risco para nossos usuários e demonstra que você leva a segurança a sério. -- **Um produto está "ativo" por mais de 6 meses** — este é outro sinal de segurança. 6 meses é um bom prazo para encontrar erros críticos e explorações abusivas. -- **Time ativo no projeto** — Isso ajuda a garantir qualidade e suporte ao usuário para suas dúvidas. -- **Informações de listagem corretas e precisas** — espera-se que todas as listagens sugeridas de projetos venham com informações precisas e íntegras. Produtos que falsificam informações de listagem, como declarar que seu produto é de código aberto quando não é, serão removidos. +- **Um produto seguro e testado** – seja por meio de auditoria, uma equipe de segurança interna ou algum outro método, a segurança do seu produto deve ser testada de forma confiável. Isso reduz o risco para nossos usuários e nos mostra que você leva a segurança a sério. +- **Um produto que está "no ar" há mais de 6 meses** – esta é outra indicação de segurança. 6 meses é um bom prazo para encontrar erros críticos e explorações abusivas. +- **Mantido por uma equipe ativa** – isso ajuda a garantir a qualidade e que um usuário receberá suporte para suas dúvidas. +- **Informações de listagem honestas e precisas** - espera-se que quaisquer listagens sugeridas de projetos venham com informações honestas e precisas. Produtos que falsificam informações de listagem, como declarar que seu produto é de código aberto quando não é, serão removidos. -### Critérios de classificação: os aspectos desejáveis {#criteria-for-ranking-the-nice-to-haves} +### Critérios de classificação: os desejáveis {#criteria-for-ranking-the-nice-to-haves} Seu dapp ou carteira podem não ser listados no ethereum.org com tanto destaque quanto os outros devido aos seguintes critérios. **Dapps** -- **Você pode acessá-lo pela maioria das carteiras listadas** — os dapps devem funcionar com a maioria das carteiras listadas no ethereum.org. -- **Os usuários podem experimentar por conta própria** — um usuário individual deve conseguir utilizar seu dapp e alcançar algo tangível. -- **Integração** — seu produto deve ter uma experiência de integração bem projetada para auxiliar e instruir usuários. Ou então, oferecer conteúdo prático como artigos e vídeos. -- **Sem custódia** — os usuários controlam seus fundos. Se o seu produto desaparecer, os usuários ainda poderão acessar e movimentar seus fundos. -- **Globalmente acessível** — seu produto não tem limitações geográficas ou requisitos do tipo "conheça seu cliente" (KYC), que excluem certas pessoas de acessar seu serviço. -- **Código aberto** — seu código deve ser acessível e deve aceitar solicitações de pull (PR) da comunidade em geral. -- **Comunidade** — você tem uma comunidade dedicada, talvez no Discord, na qual os usuários podem interagir com sua equipe para receber auxílio ou sugerir novos recursos. +- **Você pode acessá-lo através da maioria das carteiras listadas** – os dapps devem funcionar com a maioria das carteiras listadas no ethereum.org. +- **Os usuários podem experimentar por si mesmos –** um usuário individual deve ser capaz de usar seu dapp e alcançar algo tangível. +- **Integração** – seu produto deve ter uma experiência de integração bem projetada para ajudar e educar os usuários. Ou então, oferecer conteúdo prático como artigos e vídeos. +- **Sem custódia** – os usuários controlam seus próprios fundos. Se o seu produto desaparecer, os usuários ainda poderão acessar e movimentar seus fundos. +- **Acessível globalmente** – seu produto não tem limitações geográficas ou requisitos de KYC que excluam certas pessoas de acessar seu serviço. +- **Código aberto** – seu código deve ser acessível e você deve aceitar PRs da comunidade em geral. +- **Comunidade** – você tem uma comunidade dedicada, talvez um Discord, onde os usuários podem interagir com sua equipe para obter ajuda ou sugerir novos recursos. ## Critérios na prática {#criteria-in-practice} @@ -70,13 +70,13 @@ Essa é uma decisão de design pela qual o ethereum.org é responsável. Mas fique tranquilo, **haverá links para outros sites que classificam mais dapps** -### Ordenação dos Produtos {#product-ordering} +### Ordenação de Produtos {#product-ordering} A menos que os produtos sejam ordenados especificamente de outra forma, como em ordem alfabética, os produtos serão exibidos dos mais antigos aos mais recentes adicionados à página. Em outras palavras, os produtos mais recentes são adicionados ao final da lista. -### Termos de Uso {#terms-of-use} +### Termos de uso {#terms-of-use} -Consulte também os nossos [termos de uso](/terms-of-use/). Informações sobre o ethereum.org são fornecidas exclusivamente para fins de informação geral. +Consulte também nossos [termos de uso](/terms-of-use/). Informações sobre o ethereum.org são fornecidas exclusivamente para fins de informação geral. ## Manutenção {#maintenance} @@ -85,7 +85,7 @@ O Ethereum é fluido por natureza, por isso, suas equipes e produtos vêm e vão - garantir que todos os dapps listados ainda atendam aos nossos critérios - verificar se não há produtos sugeridos que atendam mais aos nossos critérios do que os atualmente listados -Você pode nos ajudar com isso, verificando e nos informando. [Abra um tíquete](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) ou envie um e-mail para[website@ethereum.org](mailto:website@ethereum.org) +Você pode nos ajudar com isso, verificando e nos informando. [Sugira uma alteração](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) ou envie um email para [website@ethereum.org](mailto:website@ethereum.org) _Estamos também investigando opções de votação para que a comunidade possa indicar suas preferências e destacar os melhores produtos disponíveis para recomendarmos._ @@ -93,8 +93,8 @@ _Estamos também investigando opções de votação para que a comunidade possa ## Adicione seu produto {#add-your-product} -Se você quiser adicionar um dapp ao ethereum.org e ele atender aos critérios, abra um tíquete no GitHub. +Se você deseja adicionar um dapp ao ethereum.org e ele atende aos critérios, entre em contato conosco. - Criar um novo problema + Sugerir um aplicativo diff --git a/public/content/translations/pt-br/contributing/adding-resources/index.md b/public/content/translations/pt-br/contributing/adding-resources/index.md new file mode 100644 index 00000000000..02abe68a737 --- /dev/null +++ b/public/content/translations/pt-br/contributing/adding-resources/index.md @@ -0,0 +1,53 @@ +--- +title: Adicionando Recursos +description: "A política que usamos ao adicionar recursos ao ethereum.org" +lang: pt-br +--- + +# Adicionando Recursos {#adding-resources} + +Queremos ter certeza de que listamos os melhores recursos possíveis, mantendo os usuários seguros e confiantes. + +Qualquer pessoa pode sugerir novos recursos para adicionar ao painel de recursos no ethereum.org, disponível atualmente em [ethereum.org/resources](/resources/). + +Embora recebamos bem novas adições, os recursos atuais foram escolhidos com base na experiência que estamos tentando criar para nossos usuários. Eles são baseados em alguns dos nossos princípios de design: + +- _Inspiracional_: tudo no ethereum.org deve oferecer algo novo aos usuários +- _Uma boa história_: o que está listado deve proporcionar um momento "aha" +- _Confiável_: todos os negócios/projetos devem ser legítimos para minimizar riscos aos usuários + +De modo geral, **ethereum.org visa proporcionar uma experiência de integração fluida para novos usuários**. Por essa razão, adicionamos recursos com base em: + +- facilidade de uso +- precisão +- manutenção + +## O framework de decisão {#decision-framework} + +### Critérios {#criteria} + +- **Informações de listagem honestas e precisas** - Todas as sugestões de listagem devem vir com informações honestas e precisas. Produtos que falsificam informações serão removidos. +- **Projeto ativo** – O recurso deve ser mantido por uma equipe ativa para garantir qualidade e suporte aos usuários. Recursos desatualizados estão sujeitos à remoção. + +### Ordenação de Produtos {#product-ordering} + +Reservamo-nos o direito de ordenar os produtos com base em seu impacto. Novos produtos serão geralmente adicionados ao final da lista, a menos que especificado de outra forma. + +## Manutenção {#maintenance} + +À medida que o ecossistema Ethereum evolui, verificaremos nosso conteúdo rotineiramente para: + +- Garantir que todos os recursos listados ainda cumpram nossos critérios +- Verificar que não existam produtos que cumpram mais critérios do que os atualmente listados + +Você pode nos ajudar com isso, verificando e nos informando. [Sugira uma alteração](https://github.com/ethereum/ethereum-org-website/issues/new?template=bug_report.yaml) ou envie um email para [website@ethereum.org](mailto:website@ethereum.org). + +--- + +## Adicione seu recurso {#add-your-resource} + +Se você deseja adicionar um recurso que atenda aos critérios ao ethereum.org, abra um chamado no GitHub. + + +Abrir chamado + diff --git a/public/content/translations/pt-br/contributing/adding-staking-products/index.md b/public/content/translations/pt-br/contributing/adding-staking-products/index.md index 6b101be5c3b..d1b77e9b35f 100644 --- a/public/content/translations/pt-br/contributing/adding-staking-products/index.md +++ b/public/content/translations/pt-br/contributing/adding-staking-products/index.md @@ -1,20 +1,20 @@ --- -title: Adicionando participação em produtos e serviços -description: A política que usamos ao adicionar participações em produtos e serviços no ethereum.org +title: "Adicionando participação em produtos e serviços" +description: "A política que usamos ao adicionar participações em produtos e serviços no ethereum.org" lang: pt-br --- -# Adicionando participação em produtos e serviços {#adding-staking-products-or-services} +# Adicionar produtos ou serviços de staking {#adding-staking-products-or-services} Queremos ter certeza de que listamos os melhores recursos possíveis, mantendo os usuários seguros e confiantes. -Qualquer pessoa é livre para sugerir a adição de participações em produtos ou serviços no ethereum.org. Se houver algum de que esquecemos, **[sugira aqui](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!** +Qualquer pessoa é livre para sugerir a adição de participações em produtos ou serviços no ethereum.org. Se houver algum que tenhamos esquecido, **[por favor, sugira-o](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!** Atualmente, listamos participações em produtos e serviços nas seguintes páginas: -- [Participação Individual](/staking/solo/) -- [Participação sobre Serviço](/staking/saas/) -- [Pools de participação (staking)](/staking/pools/) +- [Participação individual](/staking/solo/) +- [Participação como serviço](/staking/saas/) +- [Pools de participação](/staking/pools/) A prova de participação na Beacon Chain está ativa desde 1 de dezembro de 2020. Embora fazer participações (staking) seja algo relativamente novo, tentamos criar uma estrutura justa e transparente a ser considerada no ethereum.org, porém, os critérios de listagem vão mudar e evoluir com o tempo e, em última análise, ficarão a critério da equipe do ethereum.org. @@ -26,12 +26,12 @@ A decisão de listar um produto no ethereum.org não depende de um único fator. - Ferramenta de nó ou cliente - Gerenciamento de chaves -- Participação como Serviço (SaaS) +- Staking como Serviço (SaaS) - Pool de participação (staking) Atualmente, estamos apenas listando produtos ou serviços nessas categorias. -### Critérios para inclusão {#criteria-for-inclusion} +### Critérios de inclusão {#criteria-for-inclusion} As submissões de produtos ou serviços de participação serão avaliadas pelos seguintes critérios: @@ -59,7 +59,7 @@ As submissões de produtos ou serviços de participação serão avaliadas pelos - ou seja, Linux, macOS, Windows, iOS, Android -#### Sistemas e contratos Inteligentes {#software-and-smart-contracts} +#### Software e contratos inteligentes {#software-and-smart-contracts} Para qualquer sistema personalizado ou contrato inteligente envolvido: @@ -68,7 +68,7 @@ Para qualquer sistema personalizado ou contrato inteligente envolvido: - Projetos de código aberto devem ter um repositório de código-fonte disponível publicamente - Isso é usado para determinar a pontuação de "código aberto" dos produtos. -**O produto está fora do desenvolvimento de uma versão _beta_?** +**O produto já saiu do desenvolvimento _beta_?** - Onde se encontra o produto em seu ciclo de desenvolvimento? - Os produtos na fase beta não são considerados para inclusão no ethereum.org @@ -83,18 +83,18 @@ Para qualquer sistema personalizado ou contrato inteligente envolvido: - Caso contrário, há planos para criar uma recompensa por bugs na segurança? - Isso é usado para determinar a pontuação de "recompensa por bugs encontrados" dos produtos. -#### Ferramenta de nó ou cliente {#node-or-client-tooling} +#### Ferramentas de nó ou cliente {#node-or-client-tooling} Para produtos de software relacionados à configuração de nó ou cliente, gerenciamento ou migração: -**Quais clientes da camada de consenso (como Lighthouse, Teku, Nimbus, Prysm, Grandine) são suportados?** +**Quais clientes da camada de consenso (ou seja, Lighthouse, Teku, Nimbus, Prysm, Grandine) são suportados?** - Quais clientes são suportados? O usuário pode escolher? - Isso é usado para determinar a pontuação dos produtos "multicliente". -#### Participação sobre Serviço {#staking-as-a-service} +#### Participação como serviço {#staking-as-a-service} -Para [listagens de staking-as-a-service](/staking/saas/) (ou seja, operação de nó delegada): +Para [listagens de participação como serviço](/staking/saas/) (ou seja, operação de nó delegada): **Quais são as taxas associadas ao uso do serviço?** @@ -117,11 +117,11 @@ Para [listagens de staking-as-a-service](/staking/saas/) (ou seja, operação de - Na última edição, o Prysm é o cliente da camada de consenso executado pela maioria dos nós operadores, o que é perigoso para a rede. Se um cliente atualmente estiver usando mais de 33% da rede, solicitamos os dados relacionados a esse uso. - Isso é usado para determinar a pontuação de “diversidade de clientes” dos produtos. -#### Pool de Participação {#staking-pool} +#### Pool de participação {#staking-pool} -Para [serviços de participação (stake) em pool](/staking/pools/): +Para [serviços de participação em pool](/staking/pools/): -**Qual é o mínimo de ETH necessário para colocar em participação (stake)?** +**Qual é o mínimo de ETH necessário para colocar em participação?** - por exemplo, 0,01 ETH @@ -147,11 +147,11 @@ Para [serviços de participação (stake) em pool](/staking/pools/): - Na última edição, o Prysm é o cliente da camada de consenso executado pela maioria dos nós operadores, o que é perigoso para a rede. Se um cliente atualmente estiver usando mais de 33% da rede, solicitamos os dados relacionados a esse uso. - Isso é usado para determinar a pontuação de “diversidade de clientes” dos produtos. -### Outros critérios: os bons para ter {#other-criteria} +### Outros critérios: os desejáveis {#other-criteria} **Quais interfaces de usuário são suportadas?** -- ou seja, Aplicativos de navegador, desktop, mobile ou CLI +- ou seja, aplicativo de navegador, aplicativo de desktop, aplicativo móvel, CLI **Para ferramentas de nós, o software fornece uma maneira fácil de alternar entre clientes?** @@ -163,14 +163,14 @@ Para [serviços de participação (stake) em pool](/staking/pools/): ## Como exibimos os resultados {#product-ordering} -Os [critérios de inclusão](#criteria-for-inclusion) acima são usados para calcular a pontuação acumulada para cada produto ou serviço. Isso é usado como meio de classificação e apresentação de produtos que atendem a determinados critérios objetivos. Quanto mais critérios forem fornecidos para essa evidência, maior será a classificação de um produto, com ligações exibidas aleatoriamente durante o carregamento. +Os [critérios de inclusão](#criteria-for-inclusion) acima são usados para calcular uma pontuação cumulativa para cada produto ou serviço. Isso é usado como meio de classificação e apresentação de produtos que atendem a determinados critérios objetivos. Quanto mais critérios forem fornecidos para essa evidência, maior será a classificação de um produto, com ligações exibidas aleatoriamente durante o carregamento. -Atualmente, a lógica e os valores do código para esses critérios estão contidos [neste componente JavaScript](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid/index.tsx#L350) em nosso repositório. +A lógica do código e os pesos para esses critérios estão atualmente contidos [neste componente JavaScript](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) em nosso repositório. ## Adicione seu produto ou serviço {#add-product} -Se você quiser adicionar uma participação (stake) de produto ou serviço ao ethereum.org, crie um tíquete no Github. +Se você quiser adicionar uma participação (stake) de produto ou serviço ao ethereum.org, crie um tíquete no GitHub. - Crie um ticket +Abrir chamado diff --git a/public/content/translations/pt-br/contributing/adding-wallets/index.md b/public/content/translations/pt-br/contributing/adding-wallets/index.md index 5eea27d4ba7..6d6a4103d54 100644 --- a/public/content/translations/pt-br/contributing/adding-wallets/index.md +++ b/public/content/translations/pt-br/contributing/adding-wallets/index.md @@ -1,6 +1,6 @@ --- title: Adicionando carteiras -description: A política que usamos ao adicionar uma carteira ao ethereum.org +description: "A política que usamos ao adicionar uma carteira ao ethereum.org" lang: pt-br --- @@ -12,57 +12,58 @@ Qualquer pessoa pode sugerir a adição de uma carteira no ethereum.org. Se houv As carteiras atualmente listadas estão em: -- [ethereum.org/pt-br/wallets/find-wallet/](/wallets/find-wallet/) +- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/) As carteiras estão mudando rapidamente no Ethereum. Tentamos criar uma estrutura justa a ser considerada no ethereum.org, mas os critérios listados mudarão e evoluirão com o tempo. -## A estrutura de decisão {#the-decision-framework} +## O framework de decisão {#the-decision-framework} -### Critérios para inclusão: os obrigatórios {#the-must-haves} +### Critérios para inclusão: os requisitos obrigatórios {#the-must-haves} -- **Um produto com segurança testada** — seja por meio de auditoria, equipe interna de segurança, codificação de código aberto ou algum outro método — a segurança de sua carteira deve ser confiável. Isso reduz o risco para nossos usuários e demonstra que você leva a segurança a sério. -- **Uma carteira que esteja em "atividade" há mais de seis meses OU que tenha sido lançada por um grupo com um histórico de reputação** representa mais uma indicação de segurança. Seis meses é um bom período de tempo para que bugs críticos e explorações tenham sido encontrados. Pedimos seis meses para ajudar a filtrar bifurcações (forks) que são rapidamente abandonados como projetos. -- **Trabalhado por uma equipe ativa** — isso ajuda a garantir a qualidade e que um usuário receba suporte para suas consultas. -- **Informações de listagem corretas e precisas** — espera-se que todas as listagens sugeridas de projetos venham com informações precisas e íntegras. Produtos que falsificam informações de listagem, como declarar que seu produto é de "código aberto" quando não é, serão removidos. -- **Ponto de contato** — Um ponto de contato para a carteira nos ajudará muito a obter informações precisas quando houver mudanças. Isso manterá a atualização do ethereum.org gerenciável ao reunir informações futuras. -- **Transações EIP-1559 (tipo 2)** - sua carteira precisa estar habilitada para transações EIP-1559 (tipo 2) para fazer transações na rede principal do Ethereum. -- **Boa experiência de usuário** - Mesmo que a experiência do usuário seja subjetiva, se vários membros da equipe principal testarem o produto e encontrarem dificuldade em utilizá-lo, nos reservaremos o direito de recusar a carteira e, em vez disso, fornecer sugestões úteis para melhorá-la. Isso é feito para proteger nossa base de usuários, formada principalmente de iniciantes. +- **Um produto com segurança testada** — seja por meio de auditoria, uma equipe de segurança interna, código de fonte aberta ou algum outro método, a segurança da sua carteira deve ser confiável. Isso reduz o risco para nossos usuários e nos mostra que você leva a segurança a sério. +- **Uma carteira que está “no ar” há mais de seis meses OU foi lançada por um grupo com um histórico de boa reputação** — esta é outra indicação de segurança. Seis meses é um bom período de tempo para que bugs críticos e explorações tenham sido encontrados. Pedimos seis meses para ajudar a filtrar bifurcações (forks) que são rapidamente abandonados como projetos. +- **Desenvolvida por uma equipe ativa** — isso ajuda a garantir a qualidade e que o usuário receberá suporte para suas dúvidas. +- **Informações de listagem honestas e precisas** - espera-se que quaisquer listagens sugeridas de projetos venham com informações honestas e precisas. Produtos que falsificam informações de listagem, como declarar que seu produto é de "código aberto" quando não é, serão removidos. +- **Ponto de contato** — um ponto de contato para a carteira nos ajudará muito a obter informações precisas quando forem feitas alterações. Isso manterá a atualização do ethereum.org gerenciável ao reunir informações futuras. +- **Transações EIP-1559 (tipo 2)** — sua carteira deve suportar transações EIP-1559 (tipo 2) para transações na Mainnet do Ethereum. +- **Boa experiência do usuário** — embora a UX seja subjetiva, se vários membros da equipe principal testarem o produto e o considerarem difícil de usar, nos reservamos o direito de rejeitar a carteira e, em vez disso, forneceremos sugestões úteis para melhorias. Isso é feito para proteger nossa base de usuários, formada principalmente de iniciantes. +- **Focada em Ethereum** — uma carteira deve fornecer uma experiência primariamente focada em Ethereum. Isso significa que o Ethereum (ou qualquer L2) é definido como a rede padrão, os ativos ERC são devidamente suportados e os recursos estão alinhados com o ecossistema Ethereum. Carteiras que priorizam na interface de usuário (UI) camadas 1 alternativas não serão listadas. -### Remoções de produto {#product-removals} +### Remoções de produtos {#product-removals} -- **Informação atualizada** - fornecedores de carteira são responsáveis por reenviar a informação sobre suas carteiras a cada 6 meses para assegurar a validade e relevância da informação fornecida (mesmo que não haja mudanças em seus produtos). Se a equipe de produtos não fizer isso, então ethereum.org poderá remover o projeto da página. +- **Informações atualizadas** — os provedores de carteiras são responsáveis por reenviar as informações de suas carteiras a cada 6 meses para garantir a validade e a relevância das informações fornecidas (mesmo que não haja alterações em seu produto). Se a equipe de produtos não fizer isso, então ethereum.org poderá remover o projeto da página. -### Outros critérios: o que é importante ter {#the-nice-to-haves} +### Outros critérios: os diferenciais {#the-nice-to-haves} -- **Globalmente acessível** — sua carteira não possui limitações geográficas ou requisitos de KYC que excluam certas pessoas de acessar seu serviço. -- **Disponível em vários idiomas** — sua carteira é traduzida em vários idiomas, permitindo que usuários ao redor do mundo a acessem. -- **Código aberto** — todo o código de sua projeto (não apenas módulos) deve ser acessível e você deve aceitar as PRs da comunidade em geral. -- **Sem custódia** — os usuários controlam seus fundos. Se o seu produto desaparecer, os usuários ainda poderão acessar e movimentar seus fundos. -- **Suporte à carteira de hardware** — os usuários podem conectar sua carteira de hardware para assinar transações. +- **Acessível globalmente** — sua carteira não tem limitações geográficas ou requisitos de KYC que impeçam certas pessoas de acessar seu serviço. +- **Disponível em vários idiomas** — sua carteira é traduzida para vários idiomas, permitindo que usuários de todo o mundo a acessem. +- **Código aberto** — a base de código de todo o seu projeto (não apenas os módulos) deve ser acessível e você deve aceitar PRs da comunidade em geral. +- **Não custodial** — os usuários controlam seus próprios fundos. Se o seu produto desaparecer, os usuários ainda poderão acessar e movimentar seus fundos. +- **Suporte para carteira de hardware** — os usuários podem conectar sua carteira de hardware para assinar transações. - **WalletConnect** — os usuários podem se conectar a dapps usando o WalletConnect. -- **Importação de endpoints Ethereum RPC** — os usuários podem importar dados do RPC do nó, permitindo que se conectem a um nó de sua escolha ou a outras redes compatíveis com o EVM. +- **Importação de endpoints de RPC do Ethereum** — os usuários podem importar dados de RPC do nó, o que lhes permite conectar a um nó de sua escolha ou a outras redes compatíveis com a EVM. - **NFTs** — os usuários podem visualizar e interagir com seus NFTs na carteira. - **Conectar-se a aplicativos do Ethereum** — os usuários podem se conectar e usar aplicativos do Ethereum. -- **Staking (Participações)** — os usuários podem participar (fazer staking) diretamente pela carteira. -- **Swaps (Trocas)** — os usuários podem trocar tokens pela carteira. -- **Redes Multicadeias** — sua carteira oferece suporte ao acesso de usuários a várias redes de blockchain por padrão. -- **Redes de Camada 2** — sua carteira oferece suporte ao acesso de usuários a redes de camada 2 por padrão. -- **Personalizar taxas de gás** — sua carteira permite que os usuários personalizem as taxas de gás de suas transações (taxa base, taxa prioritária, taxa máxima). -- **Suporte ENS** — sua carteira permite que os usuários enviem transações para nomes ENS. -- **Suporte a ERC-20** — sua carteira permite que os usuários importem contratos de tokens ERC-20 ou exibe automaticamente os tokens ERC-20. -- **Compre criptomoedas** — sua carteira suporta a compra direta de criptomoedas e a introdução de usuários a criptomoedas. -- **Venda para valor legal** — sua carteira dá suporte a usuários que vendam e saquem em valor legal diretamente para cartão ou conta bancária. -- **Multisig** — sua carteira suporta várias assinaturas para assinar uma transação. -- **Recuperação social** — sua carteira oferece suporte a guardiões e um usuário pode recuperar sua carteira se perder sua frase de recuperação usando esses guardiões. -- **Equipe de suporte dedicada** — sua carteira possui uma equipe de suporte dedicada à qual os usuários podem recorrer em caso de problemas. -- **Recursos de educação/documentação** — seu produto deve ter uma experiência de incorporação bem projetada para ajudar e educar os usuários. Ou então, oferecer conteúdo prático como artigos e vídeos. +- **Staking** — os usuários conseguem fazer stake diretamente pela carteira. +- **Swaps** — os usuários podem trocar tokens pela carteira. +- **Redes multichain** — sua carteira oferece suporte para que usuários acessem múltiplas redes blockchain por padrão. +- **Redes de Camada 2** — sua carteira oferece suporte para que usuários acessem redes de camada 2 por padrão. +- **Personalizar taxas de gás** — sua carteira permite que os usuários personalizem suas taxas de gás da transação (taxa base, taxa de prioridade, taxa máxima). +- **Suporte a ENS** — sua carteira permite que os usuários enviem transações para nomes ENS. +- **Suporte a ERC-20** — sua carteira permite que os usuários importem contratos de token ERC-20 ou consulta e exibe automaticamente os tokens ERC-20. +- **Comprar cripto** — sua carteira permite que os usuários comprem e iniciem no mundo cripto diretamente. +- **Vender por fiduciária** — sua carteira permite que usuários vendam e saquem para moeda fiduciária diretamente para o cartão ou conta bancária. +- **Multisig** — sua carteira suporta múltiplas assinaturas para assinar uma transação. +- **Recuperação social** — sua carteira suporta guardiões, e um usuário pode recuperar sua carteira se perder sua frase semente usando esses guardiões. +- **Equipe de suporte dedicada** — sua carteira tem uma equipe de suporte dedicada a qual os usuários podem recorrer quando tiverem problemas. +- **Recursos educacionais/documentação** — seu produto deve ter uma experiência de integração bem projetada para ajudar e educar os usuários. Ou então, oferecer conteúdo prático como artigos e vídeos. ## Adicionando uma carteira {#adding-a-wallet} Se você deseja adicionar uma carteira ao ethereum.org, crie um tíquete no GitHub. - Criar tíquete +Abrir chamado ## Manutenção {#maintenance} @@ -72,9 +73,8 @@ O Ethereum é fluido por natureza, por isso, suas equipes e produtos vêm e vão - garantir que todas as carteiras e dapps listados ainda atendam aos nossos critérios - verificar se não há produtos sugeridos que atendam mais aos nossos critérios do que os atualmente listados -ethereum.org é mantida pela comunidade de código aberto; nós confiamos na comunidade para ajudar a mantê-la atualizada. Se você notar que alguma informação sobre as carteiras listadas precisa ser atualizada, [abra um tíquete](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) ou uma [solicitação de pull](https://github.com/ethereum/ethereum-org-website/pulls)! - +O ethereum.org é mantido pela comunidade de código aberto e contamos com a comunidade para ajudar a mantê-lo atualizado. Se você notar qualquer informação sobre as carteiras listadas que precise ser atualizada, por favor, [abra um problema](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) ou uma [requisição de envio](https://github.com/ethereum/ethereum-org-website/pulls)! ## Termos de uso {#terms-of-use} -Consulte também nossos [termos de uso](/terms-of-use/). Informações sobre o ethereum.org são fornecidas exclusivamente para fins de informação geral. +Consulte também nossos [termos de uso](/terms-of-use/). Informações sobre o ethereum.org são fornecidas exclusivamente para fins de informação geral. diff --git a/public/content/translations/pt-br/contributing/content-resources/index.md b/public/content/translations/pt-br/contributing/content-resources/index.md index acba18e7eb7..087e1f4b4bf 100644 --- a/public/content/translations/pt-br/contributing/content-resources/index.md +++ b/public/content/translations/pt-br/contributing/content-resources/index.md @@ -1,10 +1,10 @@ --- -title: Adicionando recursos de conteúdo +title: "Adicionando recursos de conteúdo" lang: pt-br -description: Nossos critérios para adicionar recursos de conteúdo no ethereum.org +description: "Nossos critérios para adicionar recursos de conteúdo no ethereum.org" --- -# Adicionando fontes de conteúdo {#adding-content-resources} +# Adicionando recursos de conteúdo {#adding-content-resources} Não é possível abordar tudo sobre o Ethereum, então tentamos destacar alguns artigos, tutoriais, boletins informativos, sites de empregos e vários outros recursos de conteúdo excelentes criados pela comunidade. Elas geralmente fornecem informações aprofundadas sobre tópicos de interesse dos usuários. @@ -17,9 +17,9 @@ Conteúdos de aprendizado serão avaliados pelos seguintes critérios: - O conteúdo está atualizado? - O conteúdo é pago? - A informação é de confiança? É objetiva ou subjetiva? -- O autor tem credibilidade? As fontes são referenciadas? +- O autor tem credibilidade? Ela faz referência às suas fontes? - Esse conteúdo possui novidades inexistentes nos conteúdos anteriores? -- Esse conteúdo atende a um dos nossos [tipos de usuários](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c)? +- Este conteúdo atende a uma das nossas [personas de usuário](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c)? --- @@ -28,5 +28,5 @@ Conteúdos de aprendizado serão avaliados pelos seguintes critérios: Se você deseja adicionar uma fonte de conteúdo ao ethereum.org que atende aos critérios, abra um tíquete no GitHub. - Criar um novo problema +Abrir chamado diff --git a/public/content/translations/pt-br/contributing/design-principles/index.md b/public/content/translations/pt-br/contributing/design-principles/index.md index 4a633f79d9b..ad7d065e868 100644 --- a/public/content/translations/pt-br/contributing/design-principles/index.md +++ b/public/content/translations/pt-br/contributing/design-principles/index.md @@ -1,45 +1,45 @@ --- -title: Princípios de design +title: "Princípios de design" lang: pt-br -description: Os princípios por trás das decisões de design e conteúdo do ethereum.org +description: "Os princípios por trás das decisões de design e conteúdo do ethereum.org" --- # Nossos princípios de design {#contributing-to-ethereumorg-} - Olá, bem-vindo aos princípios de design do ethereum.org. Isso faz parte de um processo em curso para desenvolver e melhorar o ethereum.org. + Olá, e bem-vindo aos princípios de design do ethereum.org. Isso faz parte de um processo em curso para desenvolver e melhorar o ethereum.org. Nossos fundamentos orientam a aparência e percepção do site e do conteúdo dele. -Leia isso antes de [contribuir para o ethereum.org](/contributing/). +Você deve lê-los antes de [contribuir para o ethereum.org](/contributing/). -## Quais são os nossos princípios de design? {#ways-to-contribute} +## Quais são os nossos princípios de design? Formas de contribuir {#ways-to-contribute} -Não se preocupe, eles são muito simples! **Os princípios de design** são um conjunto de diretrizes a que nos referimos ao projetar (isto é, criar, manter ou atualizar) algo. +Não se preocupe, eles são muito simples! **Princípios de design** são um conjunto de diretrizes às quais nos referimos ao projetar (isto é, criar, manter ou atualizar) algo. -No contexto do ethereum.org, esses princípios de “design” são a base do que queremos que o site represente e projete para o mundo. Eles são ambiciosos **e** funcionais ao mesmo tempo. Não se trata apenas da _aparência_ do site, mas também como ele _funciona_ e até mesmo como faz alguém _se sentir._ Tudo isso, desde as cores dos "layouts" de página até a forma como falamos sobre o Ethereum no site, deve ser orientado por esses princípios. +No contexto do ethereum.org, esses princípios de “design” são a base do que queremos que o site represente e projete para o mundo. Eles são tanto aspiracionais **quanto** funcionais. Não é apenas sobre a _aparência_ do site, mas também sobre como ele _funciona_ e até mesmo como faz alguém se _sentir_. Tudo, desde as cores até os layouts da página e a forma como falamos sobre o Ethereum no site, deve ser informado por esses princípios. ## Os princípios na prática {#how-decisions-about-the-site-are-made} -Vejamos um exemplo. Um dos princípios é a Credibilidade, o que significa que queremos que os visitantes do site _sintam_ e _saibam_ que o site é confiável — assim como todo o ecossistema do Ethereum. Com base nesse princípio, temos 3 "sub-princípios" funcionais que acreditamos serem medidas viáveis para tornar o site confiável: +Vejamos um exemplo. Um dos princípios é “Confiável”, o que significa que queremos que os visitantes do site _sintam_ e _saibam_ que o site é confiável, assim como o ecossistema Ethereum em geral. Com base nesse princípio, temos 3 "sub-princípios" funcionais que acreditamos serem medidas viáveis para tornar o site confiável: -- _"Atual"_, ou seja, manter o conteúdo atualizado. -- _"Apresentar uma prova social"_, ou seja, mostrar o tamanho, diversidade e atividade do ecossistema (você sabe, o progresso de atualização do Ethereum, DeFi, jogos, todos os hackathons, etc.) -- _"Consistente"_, ou seja, consistência no “design” do site, bem como o tom e precisão da escrita. +- _“Atual”_, ou seja, manter o conteúdo atualizado. +- _“Prova Social”_, ou seja, mostrar o tamanho, a diversidade e a atividade do ecossistema (sabe: o progresso da melhoria do Ethereum, DeFi, jogos, todos os hackathons, etc.) +- _“Consistente”_, ou seja, consistência no design do site e no tom e precisão da escrita. Portanto, quando estamos tomando decisões de design ou de redação, podemos recorrer ao fundamento de credibilidade e perguntar: -- _O site reflete informações atuais?_ -- _"Como e onde estamos mostrando o tamanho e a atividade do ecossistema?"_ -- _"As novas contribuições propostas por um membro da comunidade que estou revisando são consistentes com o design e o texto atuais do site?"_ +- _“O site reflete as informações atuais?”_ +- _“Como e onde estamos mostrando o tamanho e a atividade do ecossistema?”_ +- _“As novas contribuições propostas por um membro da comunidade que estou analisando são consistentes com o design e a escrita atuais no site?”_ -## Os fundamentos de design do ethereum.org {#contributors} +## Os princípios de design do ethereum.org {#contributors} ### 1. Inspirador {#1-inspirational} O site deve inspirar os usuários a sonhar com a maneira como o Ethereum pode mudar o mundo. Ele deve motivar as pessoas a explorar, brincar e mexer com as ferramentas e aplicativos do ecossistema Ethereum. -- **Radical:** o site deve comunicar os objetivos ambiciosos do Ethereum para mudar o mundo de forma significativa. É importante deixar claro que o Ethereum não é apenas uma pilha de tecnologia, mas uma tecnologia transformacional. -- **Empoderamento por meio da educação:** o site deve educar as pessoas de modo que entendam o potencial do Ethereum, encontrem o seu lugar no ecossistema e sintam-se empoderadas a participar dele. +- **Radical:** o site deve comunicar as metas ambiciosas do Ethereum de mudar o mundo de forma significativa. É importante deixar claro que o Ethereum não é apenas uma pilha de tecnologia, mas uma tecnologia transformacional. +- **Empoderamento por meio da educação:** o site deve educar as pessoas para que elas possam entender o potencial do Ethereum, encontrar seu lugar no ecossistema e se sentirem empoderadas para participar dele. Direção Visual • Conteúdo @@ -47,8 +47,8 @@ Direção Visual • Conteúdo O Ethereum é um projeto global, descentralizado, e nosso público reflete isso. O site deve aspirar ser acessível a todos e sensível às diversas culturas do mundo. -- **Acessível:** o site deve seguir diretrizes de acessibilidade, inclusive para pessoas com conexões de baixa largura de banda. -- **Avançar:** o site deve ser simples e isento de ambiguidades. A versão não deve usar linguagem que possa ser mal interpretada ou conter traduções imprecisas. +- **Acessível:** o site deve seguir as diretrizes de acessibilidade, inclusive para pessoas com conexões de baixa largura de banda. +- **Direto ao ponto:** o site deve ser simples e sem ambiguidades. A versão não deve usar linguagem que possa ser mal interpretada ou conter traduções imprecisas. - **O Ethereum é multifacetado:** o Ethereum é um projeto, uma base de código, uma comunidade e uma visão. O Ethereum é valioso para diferentes pessoas por diferentes razões, e há muitas maneiras de se envolver com ele. Sistemas de escrita • Uso de cores • Direção visual • Conteúdo @@ -57,8 +57,8 @@ Sistemas de escrita • Uso de cores • Direção visual • Conteúdo O site deve funcionar como uma boa história. Os visitantes estão em uma jornada e o conteúdo que você contribui faz parte disso. Suas contribuições devem se encaixar em uma narrativa clara: com início (introdução/ponto de partida), meio (conjunto de aprendizados e informações) e fim (links para recursos relevantes ou próximos passos). -- **Hierárquico**: uma arquitetura de informações clara e hierarquicamente estruturada ajuda os visitantes do ethereum.org a navegar no site "como uma história" à medida que buscam atingir seus objetivos. -- **Um trampolim:** somos um trampolim para quem procura respostas. Não queremos substituir ou nos tornar um substituto para os muitos recursos que já existem. Fornecemos respostas e informações confiáveis sobre próximos passos a seguir. +- **Hierárquico**: uma arquitetura de informações clara e hierarquicamente estruturada ajuda os visitantes do ethereum.org a navegar pelo site "como uma história" enquanto buscam atingir seus objetivos. +- **Um trampolim:** somos um trampolim para qualquer pessoa que esteja procurando por respostas. Não queremos substituir ou nos tornar um substituto para os muitos recursos que já existem. Damos uma resposta e fornecemos os próximos passos confiáveis. Jornadas do usuário • Conteúdo @@ -68,26 +68,26 @@ As pessoas podem estar procurando descobrir o ecossistema Ethereum ou podem ser - **Atual:** sempre atualizado. - **Prova social:** mostre o tamanho, a diversidade e a atividade do ecossistema. -- **Consistente:** consistência no design e no conteúdo transmite credibilidade. +- **Consistente:** a consistência no design e no conteúdo comunica credibilidade. Direção Visual • Conteúdo -### 5. Melhoria colaborativa {#5-collaborative-improvement} +### 5. Melhoria Colaborativa {#5-collaborative-improvement} O site é o produto de muitos colaboradores, assim como o ecossistema como um todo. -- **Aberto:** celebre a transparência do código-fonte, processos e projetos em todo o ecossistema. -- **Extensível:** a modularidade é um elemento fundamental por trás de tudo o que fazemos e, portanto, as contribuições também devem ser modulares. O projeto principal, o código do componente e a implementação do site devem permitir que ele seja facilmente ampliado no futuro. +- **Aberto:** celebre a transparência do código-fonte, dos processos e dos projetos em todo o ecossistema. +- **Extensível:** a modularidade é um foco principal por trás de tudo o que fazemos e, portanto, as contribuições também devem ser modulares. O design principal, o código do componente e a implementação do site devem permitir que ele seja facilmente estendido no futuro. - **Experimental:** estamos constantemente experimentando, testando e iterando. -- **Colaborativo:** esse projeto reúne todos nós. -- **Sustentável:** estabelecendo uma manutenção de longo prazo pela comunidade +- **Colaborativo:** este projeto reúne todos nós. +- **Sustentável:** preparando para a manutenção de longo prazo pela comunidade -Você pode ver nossos princípios de design em ação [em nosso site](/). +Você pode ver nossos princípios de design em ação [em todo o nosso site](/). -## Enviar comentários {#give-feedback} +## Forneça feedback {#give-feedback} -**Compartilhe seus comentários sobre este documento!** Um de nossos princípios propostos é a “**Melhoria Colaborativa**”, ou seja, queremos o site seja o produto de muitos colaboradores. Portanto, no espírito desse princípio, queremos compartilhar esses princípios de design com a comunidade Ethereum. +**Compartilhe seu feedback sobre este documento!** Um dos nossos princípios propostos é a “**Melhoria Colaborativa**”, o que significa que queremos que o site seja o produto de muitos contribuidores. Portanto, no espírito desse princípio, queremos compartilhar esses princípios de design com a comunidade Ethereum. -Embora esses princípios estejam focados no site ethereum.org, esperamos que muitos deles representem os valores do ecossistema Ethereum em geral. Talvez você até queira incorporar alguns deles em seu próprio projeto! +Embora estes princípios sejam focados no site ethereum.org, esperamos que muitos deles sejam representativos dos valores do ecossistema Ethereum como um todo. Talvez você até queira incorporar alguns deles em seu próprio projeto! -Dê sua opinião no [servidor Discord](https://discord.gg/ethereum-org) ou [criando um tíquete](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=). +Conte-nos o que você pensa em nosso [servidor do Discord](https://discord.gg/ethereum-org) ou [criando um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=). diff --git a/public/content/translations/pt-br/contributing/design/adding-design-resources/index.md b/public/content/translations/pt-br/contributing/design/adding-design-resources/index.md index 95aa42d318c..7d2c66ab2f2 100644 --- a/public/content/translations/pt-br/contributing/design/adding-design-resources/index.md +++ b/public/content/translations/pt-br/contributing/design/adding-design-resources/index.md @@ -6,7 +6,7 @@ lang: pt-br # Adicionando recursos de design {#adding-design-resources} -Qualquer pessoa pode sugerir novos materiais de design para a página de [Design e UX na web3](/developers/docs/design-and-ux/). +Qualquer pessoa pode sugerir novos materiais de design para a [página de Design e UX na web3](/developers/docs/design-and-ux/). Esteja ciente de que o foco desta página é fornecer valor ao usuário para candidatos a designers web3. A seção de design não está lá para anunciar seus serviços, produtos ou plataformas. @@ -56,7 +56,7 @@ a. O objetivo principal do artigo deve ser compartilhar informações em vez de a. Os benefícios de se tornar um membro devem ser apresentados em destaque. -**Exemplos**: receber comentários sobre o trabalho, acessar oportunidades de trabalho ou recompensas, compartilhar conhecimentos de design e pesquisa. +**Exemplos**: receber feedback sobre o trabalho, acessar oportunidades de emprego ou recompensas, compartilhar insights de design e pesquisa. 3. Comunicação ativa e vibrante no Discord diff --git a/public/content/translations/pt-br/contributing/design/index.md b/public/content/translations/pt-br/contributing/design/index.md index f01744e575c..707353c99e7 100644 --- a/public/content/translations/pt-br/contributing/design/index.md +++ b/public/content/translations/pt-br/contributing/design/index.md @@ -1,26 +1,26 @@ --- -title: Contribuição no design -description: Contribuição no design do ethereum.org +title: "Contribuição no design" +description: "Contribuição no design do ethereum.org" lang: pt-br --- -# Contribuição no design do ethereum.org {#design-contributions} +# Contribuição de design para o ethereum.org {#design-contributions} -O design é um componente crítico de qualquer projeto e, dedicando seu tempo e habilidades de design ao Ethereum.org, você pode ajudar a melhorar a experiência do usuário para nossos visitantes. Contribuir para um projeto de código aberto oferece uma oportunidade de ganhar experiência relevante e desenvolver suas habilidades em um ambiente colaborativo. Você terá a chance de trabalhar com outros designers, desenvolvedores e membros da comunidade, todos com suas próprias perspectivas e visões. +O design é um componente essencial de qualquer projeto e, ao dedicar seu tempo e habilidades de design ao ethereum.org, você pode ajudar a melhorar a experiência do usuário para nossos visitantes. Contribuir para um projeto de código aberto oferece uma oportunidade de ganhar experiência relevante e desenvolver suas habilidades em um ambiente colaborativo. Você terá a chance de trabalhar com outros designers, desenvolvedores e membros da comunidade, todos com suas próprias perspectivas e visões. Por fim, essa é uma ótima maneira de construir um portfólio diversificado e impressionante que mostre suas habilidades de design. ## Como contribuir? -###  Forneça feedback sobre os primeiros protótipos de design {#design-critique} +###  Forneça feedback sobre protótipos de design iniciais {#design-critique} Às vezes, precisamos de ajuda para testar nossas ideias originais. Esta é uma ótima maneira de como contribuir sem nenhum conhecimento técnico. -1. A equipe de design compartilhará um modelo de projeto no [Discord](https://discord.com/invite/ethereum-org) e no [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). +1. A equipe de design compartilhará um mockup de design no [Discord](https://discord.com/invite/ethereum-org) e no [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). 2. Você será guiado pelos projetos para fornecer feedback por meio da função de comentários. 3. O resultado será compartilhado em problemas do GitHub e depois fechado pela equipe. -###  Participe da pesquisa de levantamento {#answer-surveys} +###  Participe de pesquisas {#answer-surveys} Forneça seus comentários em nosso site: @@ -28,50 +28,50 @@ Forneça seus comentários em nosso site: 2. Clicando no widget de feedback no canto inferior direito e respondendo a perguntas relacionadas ao design e conteúdo. 3. Foque nas perguntas de formato livre. -###  Encontre problemas relacionados ao design no site e reporte-os {#report-design-issues} +###  Encontre problemas relacionados a design no site e relate-os {#report-design-issues} -O Ethereum.org é um site de rápido crescimento com muitos recursos e conteúdo. Algumas das interfaces de usuário podem facilmente se tornar obsoletas ou poderiam ser aprimoradas. Se você encontrar qualquer caso parecido, por favor reporte ele para que chame a nossa atenção. +ethereum.org é um site de rápido crescimento com muitos recursos e conteúdo. Algumas das interfaces de usuário podem facilmente se tornar obsoletas ou poderiam ser aprimoradas. Se você encontrar qualquer caso parecido, por favor reporte ele para que chame a nossa atenção. 1. Acesse o site e preste atenção em seu design. 2. Faça capturas de tela e anotações se você notar algum problema visual ou de experiência do usuário. -3. Reporte os problemas encontrados usando um [formulário de bug](https://github.com/ethereum/ethereum-org-website/issues/new/choose). +3. Relate os problemas encontrados usando um [relatório de bug](https://github.com/ethereum/ethereum-org-website/issues/new/choose). -###  Proponha mudanças de design {#propose-design-changes} +###  Proponha alterações de design {#propose-design-changes} -Se você se sente à vontade para enfrentar desafios de design, visite nosso quadro de problemas do GitHub e filtre por [problemas relacionados ao design](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). +Se você se sentir à vontade para assumir desafios de design, pode visitar nosso quadro de problemas do GitHub e filtrar por [problemas relacionados a design](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). -1. Vá ao nosso site e preste atenção em seu design ou acesse nosso repositório GitHub e analise os problemas sinalizados com a [Etiqueta "Design necessário"](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). -2. Idealize a solução e desenhe-a. (idealmente usando nosso [sistema de design](https://www.figma.com/community/file/1134414495420383395)). -3. Proponha a solução no tíquete do GitHub correspondente ou [abra um novo.](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request) +1. Navegue em nosso site e preste atenção ao seu design ou acesse nosso repositório no GitHub e revise os problemas sinalizados com a [tag “Design required”](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). +2. Idealize a solução e desenhe-a. (de preferência, usando nosso [sistema de design](https://www.figma.com/community/file/1134414495420383395)). +3. Proponha a solução no problema correspondente do GitHub ou [crie um novo.](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request) 4. Aguarde a revisão do time de design. -###  Construir o Sistema de Design juntos {#Contribute-to-design-system} +###  Construa o Sistema de Design em conjunto {#Contribute-to-design-system} Nosso sistema de design torna o projeto ethereum.org divertido e fácil. Se você é um designer experiente, você pode nos ajudar a preparar muitos componentes para o site. -1. Selecione um problema para trabalhar no painel [sobre sistema de design](https://github.com/ethereum/ethereum-org-website/labels/design%20system) no GitHub ou crie um novo. +1. Selecione um problema para trabalhar no [quadro do sistema de design](https://github.com/ethereum/ethereum-org-website/labels/design%20system) no GitHub ou crie um novo. 2. Peça que o problema selecionado seja atribuído a você. -3. Comece a projetar o componente solicitado na figma. +3. Comece a projetar o componente solicitado no Figma. 4. Compartilhe-o com a equipe de design no GitHub, assim que você precisar de revisão ou orientação. 5. A equipe de design revisará. -6. A equipe de design vai incorporar as mudanças no arquivo principal e publicará o arquivo para a comunidade. +6. A equipe de design incorporará as alterações no arquivo principal e publicará o arquivo na comunidade. -###  Escreva o conteúdo relacionado ao design no site {#write-design-articles} +###  Escreva conteúdo relacionado a design no site {#write-design-articles} -A comunidade de desenvolvedores Ethereum é forte, mas a comunidade de design está ficando um pouco para trás. Se você é um designer com conhecimento em web3, por favor, considere compartilhar seus aprendizados com a comunidade maior, para que todos possamos crescer e melhorar juntos; temos [uma página sobre design para Ethereum](/developers/docs/design-and-ux/) para a qual você pode contribuir. Você também pode verificar nossas [políticas de listagem](/contributing/design/adding-design-resources). +A comunidade de desenvolvedores Ethereum é forte, mas a comunidade de design está ficando um pouco para trás. Se você é um designer com conhecimento em web3, por favor, considere compartilhar seus aprendizados com a comunidade maior para que todos possamos crescer e melhorar juntos; temos [uma página sobre design para Ethereum](/developers/docs/design-and-ux/) para a qual você pode contribuir. Você também pode conferir nossas [políticas de listagem](/contributing/design/adding-design-resources). 1. Idealize sobre tópicos de design que devem ser cobertos no ethereum.org e seriam benéficos para os designers no espaço. -2. Vá ao nosso repositório do GitHub e [levante um problema](https://github.com/ethereum/ethereum-org-website/issues/new) propondo um tópico (não escreva o conteúdo ainda). +2. Acesse nosso repositório do GitHub e [abra um problema](https://github.com/ethereum/ethereum-org-website/issues/new) propondo um tópico (ainda não escreva o conteúdo). 3. Aguarde a aprovação do time de design. 4. Uma vez aprovado, escreva o conteúdo. -5. Envie-o no problema GH correspondente. +5. Envie-o no ticket correspondente do GitHub. ###  Desenhe novas ilustrações {#prepare-illustrations} As visualizações são uma das ferramentas mais poderosas para explicar tópicos abstratos. Há um enorme potencial ao adicionar diagramas e infográficos. Afinal, uma imagem pode dizer mil palavras. 1. Vá ao nosso site e veja as páginas onde alguns novos infográficos poderiam ser adicionados. -2. Certifique-se de que o estilo da ilustração corresponda aos nossos [recursos](/assets/). -3. Vá ao nosso repositório GitHub e [levante um problema](https://github.com/ethereum/ethereum-org-website/issues/new) propondo a ilustração. +2. Certifique-se de que o estilo da ilustração corresponda aos nossos [ativos](/assets/). +3. Acesse nosso repositório do GitHub e [abra um problema](https://github.com/ethereum/ethereum-org-website/issues/new) propondo a ilustração. 4. A equipe de design irá analisá-lo. 5. Nós criamos um novo problema para pedir a um desenvolvedor que implemente a nova imagem. diff --git a/public/content/translations/pt-br/contributing/index.md b/public/content/translations/pt-br/contributing/index.md index effce42555b..3cba1975d88 100644 --- a/public/content/translations/pt-br/contributing/index.md +++ b/public/content/translations/pt-br/contributing/index.md @@ -1,46 +1,51 @@ --- -title: Contribuições +title: "Contribuições" description: Descubra as diferentes maneiras de contribuir com o ethereum.org lang: pt-br --- -# Contribua com o ethereum.org 🦄 {#contributing-to-ethereumorg} +# Contribuindo para o ethereum.org 🦄 {#contributing-to-ethereumorg} -Ethereum.org é um projeto de código aberto em execução com **mais de 12.000** contribuidores que ajudam a traduzir, escrever, estruturar e manter o site. +O Ethereum.org é um projeto de código aberto com mais de **12.000** colaboradores que ajudam a traduzir, escrever, criar o design e manter o site. Nós somos uma comunidade de braços abertos que irá ajudá-lo a crescer e se informar no ecossistema Ethereum enquanto você também contribui significativamente e obtém experiência prática relevante. ## Formas de contribuir {#ways-to-contribute} **Traduções** -- [Junte-se ao programa de tradução](/contributing/translation-program/) – Nos ajude a levar o ethereum.org para novos idiomas + +- [Participe do programa de tradução](/contributing/translation-program/) – Ajude-nos a levar o ethereum.org para novos idiomas **Desenvolvimento** -- [Trabalhe em um problema aberto](https://github.com/ethereum/ethereum-org-website/issues) – Trabalho que nós identificamos que deve ser feito -**Visual** -- [Ajude a estruturar o site](/contributing/design/) Profissionais de design de todos os níveis podem contribuir para melhorar o site +- [Trabalhe em um problema em aberto](https://github.com/ethereum/ethereum-org-website/issues) – Trabalho que identificamos que precisa ser feito + +**Design** + +- [Ajude a projetar o site](/contributing/design/) – Designers de todos os níveis podem contribuir para melhorar o site **Conteúdo** -- [Criar/editar conteúdo](/contributing/#how-to-update-content) – Sugira novas páginas ou ajustes para o que já existe aqui -- [Adicione recursos da comunidade](/contributing/content-resources/) – Adicione um artigo ou recurso útil a uma página -- [Sugira um recurso de design](/contributing/design/adding-design-resources/) – Adicione e atualize recursos de design que possam ajudar ou exclua algum deles -- [Adicione um termo de glossário](/contributing/adding-glossary-terms/) – Nos ajude a continuar a expandir o [glossário](/glossary/) do Ethereum -- [Jogos de perguntas e respostas](/contributing/quizzes/) – Adicione, atualize ou exclua bancos de jogos de perguntas e respostas de uma página + +- [Criar/editar conteúdo](/contributing/#how-to-update-content) – Sugira novas páginas ou faça ajustes no que já existe +- [Adicione recursos da comunidade](/contributing/content-resources/) – Adicione um artigo ou recurso útil a uma página relevante +- [Sugira um recurso de design](/contributing/design/adding-design-resources/) – Adicione, atualize e exclua recursos de design úteis +- [Questionários](/contributing/quizzes/) – Adicione, atualize e exclua bancos de perguntas de questionários para uma página relevante **Ideias para funcionalidades** -- [Solicite uma funcionalidade](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – Nos avise sobre qualquer ideia que você tenha para uma nova funcionalidade ou design + +- [Solicite um recurso](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – Conte-nos sobre qualquer ideia que você tenha para um novo recurso ou design **Listagens de produtos** -- [Adicione uma exchange](/contributing/adding-exchanges/) – Adicione uma exchange ao nosso [buscador de exchanges](/get-eth/#country-picker) -- [Adicione um produto](/contributing/adding-products/) – Adicione um dapp ou uma carteira a uma página -- [Adicione ferramentas para desenvolvimento](/contributing/adding-developer-tools/) – Adicione uma ferramenta para desenvolvimento a uma página -- [Adicione uma camada 2](/contributing/adding-layer-2s/) – Adicione a camada 2 a uma página -- [Adicione um produto ou serviço para investimentos](/contributing/adding-staking-products/) – Adicione um projeto que ajude a facilitar o staking solo, em grupo ou o staking como serviço + +- [Adicione uma corretora](/contributing/adding-exchanges/) – Adicione uma corretora ao nosso [localizador de corretoras](/get-eth/#country-picker) +- [Adicione um produto](/contributing/adding-products/) – Adicione um dapp ou uma carteira a uma página relevante +- [Adicione ferramentas de desenvolvedor](/contributing/adding-developer-tools/) – Adicione uma ferramenta de desenvolvedor a uma página relevante +- [Adicione uma layer 2](/contributing/adding-layer-2s/) – Adicione uma layer 2 a uma página relevante +- [Adicione um produto ou serviço de staking](/contributing/adding-staking-products/) – Adicione um projeto que ajude a facilitar o staking individual, staking em pool ou staking como serviço - [Adicione uma carteira](/contributing/adding-wallets/) – Adicione uma carteira para a [página de busca de carteiras](/wallets/find-wallet/) -- [Sugira um projeto para a nossa página DeSci](/contributing/adding-desci-projects/) – Adicione um projeto criado no Ethereum que contribua para descentralizar a ciência +- [Sugira um projeto para nossa página DeSci](/contributing/adding-desci-projects/) – Adicione um projeto construído no Ethereum que contribua para a ciência descentralizada -Alguma dúvida? 🤔 Junte-se ao nosso [servidor Discord](https://discord.gg/ethereum-org) +Alguma dúvida? 🤔 Junte-se ao nosso [servidor do Discord](https://discord.gg/ethereum-org) ## Tarefas adequadas para começar a contribuir @@ -52,64 +57,64 @@ Estas são algumas tarefas atuais das que você poderia se encarregar e nos ajud ## Como trabalhar no ethereum.org {#how-to-update-content} -Se você deseja contribuir com o [Programa de Tradução](/contributing/translation-program/), crie uma conta no [Crowdin](https://crowdin.com/project/ethereum-org). Para adicionar e editar conteúdo ou efeitos visuais no site, corrigir erros, trabalhar em tarefas abertas, por exemplo, você vai precisar de uma conta no [GitHub](https://github.com/). +Se você deseja contribuir no [Programa de Tradução](/contributing/translation-program/), pedimos que crie uma conta no [Crowdin](https://crowdin.com/project/ethereum-org). Para todo o resto – adicionar ou editar conteúdo ou elementos visuais do site, corrigir bugs, trabalhar em tarefas em aberto – você precisará de uma conta no [GitHub](https://github.com/). -Todas as atualizações são efetuadas por meio do processo de PR (solicitação de pull) do GitHub. Isso significa que você cria uma cópia local do site, faz as suas alterações e solicita que elas sejam implementadas. Se você nunca fez isso antes, siga as instruções na parte inferior do nosso [repositório GitHub](https://github.com/ethereum/ethereum-org-website). +Todas as atualizações são efetuadas por meio do processo de PR (solicitação de pull) do GitHub. Isso significa que você cria uma cópia local do site, faz as suas alterações e solicita que elas sejam implementadas. Se você nunca fez isso antes, siga as instruções na parte inferior do nosso [repositório do GitHub](https://github.com/ethereum/ethereum-org-website). Você não precisa de permissão para trabalhar em nada, mas é sempre melhor nos informar sobre o que está planejando fazer. Você pode fazer isso: -- Comentando sobre um problema ou uma solicitação de pull (PR) no [GitHub](https://github.com/ethereum/ethereum-org-website) -- Enviando uma mensagem via o [servidor Discord](https://discord.gg/ethereum-org) +- Comentando em um problema ou PR no [GitHub](https://github.com/ethereum/ethereum-org-website) +- Enviando mensagens em nosso [servidor do Discord](https://discord.gg/ethereum-org) Antes de contribuir, certifique-se de está familiarizado com: -- a [visão do ethereum.org](/about/) em evolução +- a [visão em evolução do ethereum.org](/about/) - nossos [princípios de design](/contributing/design-principles/) - nosso [guia de estilo](/contributing/style-guide/) - nosso [código de conduta](/community/code-of-conduct) -## Como são tomadas as decisões sobre o site {#how-decisions-about-the-site-are-made} +## How decisions about the site are made {#how-decisions-about-the-site-are-made} -As decisões sobre PRs individuais, desenvolvimento do design e melhorias importantes são feitas por uma equipe formada no ecossistema Ethereum. Esta equipe inclui gerentes de projeto, desenvolvedores, designers, gerentes de marketing e comunicação, e especialistas no assunto. Cada decisão considera as contribuições da comunidadem. Portanto, não duvide em fazer perguntas via tíquetes, enviar PRs ou entrar em contato com a equipe: +Decisions about individual PRs, design evolution and major upgrades are made by a team from across the Ethereum ecosystem. This team includes project managers, developers, designers, marketing and communications, and subject matter experts. Community input informs every decision: so please raise questions in issues, submit PRs, or contact the team: - [website@ethereum.org](mailto:website@ethereum.org) - [@ethdotorg](https://twitter.com/ethdotorg) -- [Servidor do Discord](https://discord.gg/ethereum-org) +- [Discord server](https://discord.gg/ethereum-org) -### Observação sobre plágio {#plagiarism} +### A note on plagiarism {#plagiarism} -Ao contribuir com qualquer conteúdo ou artefato no ethereum.org, use somente trabalhos ou conteúdos originais para os que você tem permissão de utilizar. Muitos projetos no ecossistema do Ethereum usam licenças de código aberto que permitem o compartilhamento livre de informações. No entanto, se você não encontrar essas informações, não tente adicioná-los ao ethereum.org. Todas as solicitações de envio (PR, pull request) consideradas como plágio serão rejeitadas. +Only use your original work or content that you have permission to use when contributing any content or artifact to ethereum.org. Many projects within the Ethereum ecosystem use open-source licensing that allows for the free sharing of information. However, if you cannot find this information, do not attempt to add it to ethereum.org. Any pull requests deemed as plagiarism will get rejected. -## Você é iniciante em código aberto? {#new-to-open-source} +## New to open-source? {#new-to-open-source} -Em nosso repositório do GitHub, temos uma categoria de envio de tíquetes especialmente criada para desenvolvedores iniciantes em código aberto. Esses tíquetes de baixa dificuldade são rotulados como [good first issue](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) (boa escolha para primeiro tíquete). +We have low barrier to entry issues on our GitHub repository specifically designed for developers who are new to open-source labelled [good first issue](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22). -## Reivindique seu token de conquista on-chain (OAT) {#oat} +## Claim your Onchain Achievement Token (OAT) {#oat} -Se sua contribuição for incluída no ethereum.org, você terá a chance de reivindicar um badge especial no [Galxe](https://app.galxe.com/quest/ethereumorg). Um token de conquista on-chain (OAT) é uma prova de que você contribuiu com o ecossistema de maneira considerável. +If your contribution gets merged into ethereum.org, you will have a chance to claim a special badge on [Galxe](https://app.galxe.com/quest/ethereumorg). An Onchain Achievement Token (OAT) is a proof that you helped make the ecosystem a little more awesome. -[Mais sobre OATs](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03) +[More on OATs](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03) -### Como solicitar seu POAP -1. Junte-se ao nosso [servidor Discord](https://discord.gg/ethereum-org). -2. Cole um link para sua contribuição no canal `#🥇 | proof-of-contribution` -3. Aguarde até que um membro da nossa equipe lhe envie um link para seu OAT. -4. Reivindique seu OAT! +### How to claim -Você só deve usar carteiras de autocustódia para reivindicar OATs. Não use contas de exchange ou outras contas cujas chaves privadas você não tenha, pois elas não permitirão que você acesse e gerencie seus OATs. +1. Join our [Discord server](https://discord.gg/ethereum-org). +2. Paste a link to your contribution in the `#🥇 | proof-of-contribution` channel. +3. Wait for a member of our team to send you a link to your OAT. +4. Claim your OAT! -## Resgate seu GitPOAP {#claim-gitpoap} +You should only use self-custody wallets to claim OATs. Do not use exchange accounts or other accounts you do not hold the private keys to, as these will not allow you to access and manage your OATs. -O GITPOAP também reconhecerá automaticamente sua contribuição fusionada e permitirá que você cunhe um POAP de colaboradores exclusivo e separado na sua própria plataforma! +## Claim your GitPOAP {#claim-gitpoap} +GitPOAP will also automatically recognize your merged contribution and let you mint a separate unique contributors POAP on their platform itself! -### Como solicitar seu POAP {#how-to-claim} +### How to claim {#how-to-claim} -1. Visite [GitPOAP](https://www.gitpoap.io). -2. Conecte-se à sua carteira ou mesmo ao seu e-mail com a opção de entrada. -3. Procure seu nome de usuário no GitHub, endereço ETH, nomes ENS ou qualquer GitPOAP para verificar se você é elegível. -4. Se sua conta no GitHub for elegível, você poderá cunhar um GitPOAP! +1. Visit [GitPOAP](https://www.gitpoap.io). +2. Connect with your wallet or even with your email through sign in option. +3. Search for your GitHub username, ETH address, ENS names or any GitPOAP to check if you're eligible. +4. If your GitHub account is eligible, then you would be able to mint a GitPOAP! -## Colaboradores {#contributors} +## Contributors {#contributors} diff --git a/public/content/translations/pt-br/contributing/quizzes/index.md b/public/content/translations/pt-br/contributing/quizzes/index.md index e972230a9b7..bb61e776c82 100644 --- a/public/content/translations/pt-br/contributing/quizzes/index.md +++ b/public/content/translations/pt-br/contributing/quizzes/index.md @@ -1,6 +1,6 @@ --- -title: Adicionando um questionário -description: A política que nós usamos quando adicionando questionários na ethereum.org +title: "Adicionando um questionário" +description: "A política que nós usamos quando adicionando questionários na ethereum.org" lang: pt-br --- @@ -14,12 +14,12 @@ Alguns exemplos de questionários atuais podem ser encontrados aqui: - [Camada 2](/layer-2) - [NFT](/nft/) -- [O que é o Ethereum?](/what-is-ethereum/) +- [O que é Ethereum?](/what-is-ethereum/) - [O que é ETH?](/what-is-ether/) ## Adicionando um questionário de aprendizado -Se há uma página que não tem um questionário de aprendizado criado para ela, por favor [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) para ela. +Se uma página ainda não tiver um questionário de aprendizado, [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) para criá-lo. Por favor forneça as seguintes informações: @@ -32,7 +32,7 @@ Por favor forneça as seguintes informações: ## Adicionando uma pergunta ao questionário -Se há uma questão que você quer adicionar para o banco de questões para um questionário, por favor [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) e forneça as seguintes informações: +Se você quiser adicionar uma pergunta ao banco de perguntas de um questionário, [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) e forneça as seguintes informações: - A página a qual você quer adicionar uma questão de questionário - Para cada questão, forneça as seguintes informações: @@ -43,7 +43,7 @@ Se há uma questão que você quer adicionar para o banco de questões para um q ## Atualizando uma questão de questionário -Se há uma questão que você quer atualizar no banco de questões para um questionário, por favor [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) e forneça as seguintes informações: +Se você quiser atualizar uma pergunta no banco de perguntas de um questionário, [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) e forneça as seguintes informações: - A página à qual você quer atualizar uma questão de questionário - Para cada questão sendo atualizada, forneça as seguintes informações: @@ -55,7 +55,7 @@ Se há uma questão que você quer atualizar no banco de questões para um quest ## Removendo uma questão de questionário -Se o conteúdo não existe mais na página de uma questão e ela precisa ser removida, [abra um tíquete](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) para remover a questão e forneça as seguintes informações: +Para remover uma pergunta cujo conteúdo não existe mais na página, [abra um issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) e forneça as seguintes informações: - A página à qual você quer excluir uma questão de questionário - A questão que você quer excluir diff --git a/public/content/translations/pt-br/contributing/translation-program/faq/index.md b/public/content/translations/pt-br/contributing/translation-program/faq/index.md index f1ef27d0e4c..d8ffa9a4a7f 100644 --- a/public/content/translations/pt-br/contributing/translation-program/faq/index.md +++ b/public/content/translations/pt-br/contributing/translation-program/faq/index.md @@ -1,10 +1,10 @@ --- -title: Perguntas frequentes sobre o Programa de tradução +title: "Perguntas frequentes sobre o Programa de tradução" lang: pt-br -description: Perguntas frequentes sobre o Programa de tradução da ethereum.org +description: "Perguntas frequentes sobre o Programa de tradução da ethereum.org" --- -# Traduzindo o guia ethereum.org {#translating-ethereum-guide} +# Guia de tradução do ethereum.org {#translating-ethereum-guide} Se você é novo no Programa de tradução e está hesitante em participar, aqui estão algumas perguntas frequentes que podem ajudá-lo a começar. Use este guia para encontrar respostas para as consultas mais comuns. @@ -18,31 +18,31 @@ O objetivo do Programa de Tradução é tornar o conteúdo do Ethereum acessíve Por essa razão, o Programa de Tradução é aberto e voluntário, e a participação não está sujeita a compensações. Se fôssemos compensar os tradutores pelo número de palavras traduzidas, só poderíamos convidar aqueles com experiência de tradução suficiente (tradutores profissionais) para participar do Programa de Tradução. Isso tornaria o Programa de Tradução exclusivo e nos impediria de alcançar os objetivos delineados, especificamente, permitindo que todos participem e se envolvam com o ecossistema. -Fazemos o possível para permitir que nossos colaboradores tenham sucesso no ecossistema Ethereum. Muitos incentivos não-monetários estão em vigor, como [oferecer POAPs](/contributing/translation-program/acknowledgements/#poap) e um [certificado de tradutor](/contributing/translation-program/acknowledgements/#certificate), além de organizar os [rankings de tradução](/contributing/translation-program/acknowledgements/) e [listar todos os nossos tradutores no site](/contributing/translation-program/contributors/). +Fazemos todos os esforços para permitir que nossos contribuidores tenham sucesso no ecossistema Ethereum; muitos incentivos não monetários estão em vigor, como: [oferecer POAPs](/contributing/translation-program/acknowledgements/#poap) e um [certificado de tradutor](/contributing/translation-program/acknowledgements/#certificate), bem como organizar os [Placares de Líderes de Tradução](/contributing/translation-program/acknowledgements/) e [listar todos os nossos tradutores no site](/contributing/translation-program/contributors/). -## Como traduzo cadeias de caracteres com ``? {#tags} +## Como traduzo strings com ``? {#tags} -Nem toda cadeia de caracteres é escrita na forma de texto puro. Há algumas cadeias de caracteres que consistem em cadeias de caracteres mistas como, por exemplo, as tags HTML (`<0>`, ``). Geralmente, elas são usadas para hiperlinks ou estilos alternativos no meio de uma frase. +Nem toda cadeia de caracteres é escrita na forma de texto puro. Existem algumas strings que consistem em scripts mistos, como tags HTML (`<0>`, ``). Isso geralmente é para hyperlinks ou estilo alternativo no meio de uma frase. -- Traduza o texto dentro das tags, mas não as tags em si. Nada entre `<` e `>` deve ser traduzido nem removido. +- Traduza o texto dentro das tags, mas não as tags em si. Qualquer coisa entre `<` e `>` não deve ser traduzida ou removida. - Para manter a string íntegra recomendamos que você clique no botão "Copiar origem" no canto inferior esquerdo. Isso vai copiar a string original e colá-la na caixa de texto. Isto permite que você ponha em evidência onde estão as tags e ajude a evitar erros. -![Interface Crowdin com o botão "copiar origem" destacado](./html-tag-strings.png) +![Interface do Crowdin com o botão de copiar origem destacado](./html-tag-strings.png) Você pode mover a posição das tags dentro da cadeia de caracteres para torná-la mais natural em seu idioma — apenas se certifique de mover a tag inteira. -Para mais informações aprofundadas sobre como lidar com tags e trechos de código, consulte o [Guia de estilo de tradução do ethereum.org](/contributing/translation-program/translators-guide/#dealing-with-tags). +Para obter informações mais detalhadas sobre como lidar com tags e trechos de código, consulte o [Guia de Estilo de Tradução do ethereum.org](/contributing/translation-program/translators-guide/#dealing-with-tags). ## Onde encontrar as cadeias de caracteres? {#strings} Geralmente, as cadeias de caracteres de origem podem não ser suficientes para que você forneça uma tradução exata. - Dê uma olhada em "capturas de tela" e "contexto" para obter mais informações. Na seção da string de origem, você verá a imagem de captura de tela anexada que mostrará como estamos usando a sequência de caracteres no contexto. -- Se você ainda não tiver certeza, coloque uma observação na "seção de comentários". [Em dúvida sobre como deixar um comentário?](#comment) +- Se você ainda não tiver certeza, coloque uma observação na "seção de comentários". [Não sabe como deixar um comentário?](#comment) -![Imagem mostrando como o contexto pode ser fornecido para uma cadeia de caracteres com uma captura de tela](./source-string.png) +![Mostrando como o contexto pode ser fornecido para uma string com uma captura de tela](./source-string.png) -![Exemplo de captura de tela adicionada para o contexto](./source-string-2.png) +![Um exemplo de captura de tela adicionada para contexto](./source-string-2.png) ## Como posso deixar comentários ou fazer perguntas? Gostaria de relatar um problema ou erro de digitação... {#comment} @@ -52,11 +52,11 @@ Se você quiser reportar um erro em uma determinada cadeia de caracteres que pre - Uma vez enviado, será reportado à nossa equipe. Vamos corrigir o problema e informar você respondendo ao seu comentário e encerrando a requisição. - Se você informar uma tradução incorreta, sua tradução e sugestão serão revisadas por um nativo na próxima revisão. -![Imagem mostrando como fazer comentários e relatar problemas](./comment-issue.png) +![Mostrando como fazer comentários e relatar problemas](./comment-issue.png) ## O que é Memória de Tradução (MT)? {#translation-memory} -Memória de Tradução (MT) é uma funcionalidade do Crowdin que armazena todas as frases traduzidas anteriormente no [ethereum.org](https://ethereum.org/). Quando uma cadeia de caracteres é traduzida, ela é automaticamente salva em nosso projeto de MT. Ela pode ser uma ferramenta útil para você economizar tempo! +Memória de Tradução (MT) é uma funcionalidade do Crowdin que armazena todas as frases traduzidas anteriormente no ethereum.org. Quando uma cadeia de caracteres é traduzida, ela é automaticamente salva em nosso projeto de MT. Ela pode ser uma ferramenta útil para você economizar tempo! - Veja na seção "Sugestões de MT " como outros tradutores traduziram a mesma string, ou similar. Se você encontrar uma sugestão com uma alta correspondência, sinta-se livre para se referir à tradução clicando nela. - Se não houver nada na lista, você poderá procurar na MT traduções feitas anteriormente e reutilizá-las para consistência. @@ -71,7 +71,7 @@ O glossário do Crowdin é o melhor lugar para esclarecer termos e definições. - Primeiro, quando você encontrar um termo sublinhado na string de origem, você pode passar o mouse por cima e ver uma breve definição dela. -![Um exemplo de definição do glossário](./glossary-definition.png) +![Uma definição de exemplo do glossário](./glossary-definition.png) - Segundo, se você ver um termo não familiar que não está sublinhado, você pode procurar na guia do glossário (o terceiro botão da coluna da direita). Você encontrará explicações de termos específicos e outros frequentemente utilizados no projeto. @@ -81,7 +81,7 @@ O glossário do Crowdin é o melhor lugar para esclarecer termos e definições. ![Uma captura de tela mostrando como adicionar um termo ao glossário do Crowdin](./add-glossary-term.png) -### Política de tradução de terminologias {#terminology} +### Política de tradução de terminologia {#terminology} _Para nomes (marcas, empresas, pessoas) e novos termos tecnológicos (Beacon Chain, cadeia de fragmentos, etc.)_ @@ -93,7 +93,7 @@ Após cuidadosa reflexão, tomamos a decisão de deixar para os tradutores a esc Quando você encontrar um termo que não é familiar para você, sugerimos o seguinte: -- Consulte o [Glossário de termos](#glossary), onde você pode ver como outros tradutores o traduziram anteriormente. Se você acha que o termo previamente traduzido não é apropriado, reverta a tradução adicionando um novo termo ao glossário do Crowdin. +- Consulte o [Glossário de termos](#glossary), você poderá encontrar como outros tradutores o traduziram anteriormente. Se você acha que o termo previamente traduzido não é apropriado, reverta a tradução adicionando um novo termo ao glossário do Crowdin. - Se tal tradução anterior não existir no Glossário, o encorajamos a procurá-lo em um mecanismo de busca ou artigo de mídia que mostre como o termo é realmente utilizado na sua comunidade. - Se você não encontrar nenhuma referência, sugira uma nova tradução para o seu idioma! - Se você se sentir menos confiante para fazê-lo, deixe o termo não traduzido. Às vezes, os termos em inglês são mais do que adequados para fornecer definições precisas. @@ -102,18 +102,18 @@ Recomendamos que deixe nomes de marcas, empresas e pessoas sem tradução, visto ## Como funciona o processo de revisão? {#review-process} -Para garantir um certo nível de qualidade e consistência nas nossas traduções, trabalhamos com a [Acolad](https://www.acolad.com/), uma das maiores empresas de serviços linguísticos no mundo. A Acolad conta com 20.000 linguistas profissionais, o que significa que ela pode fornecer revisores profissionais para cada idioma e tipo de conteúdo de que precisamos. +Para garantir um certo nível de qualidade e consistência em nossas traduções, trabalhamos com a [Acolad](https://www.acolad.com/), um dos maiores provedores de serviços linguísticos do mundo. A Acolad conta com 20.000 linguistas profissionais, o que significa que ela pode fornecer revisores profissionais para cada idioma e tipo de conteúdo de que precisamos. -O processo de revisão é simples: uma vez que um determinado [lote de conteúdo](/contributing/translation-program/) é 100% traduzido, pedimos uma revisão desse conteúdo. O processo de revisão ocorre diretamente no Crowdin. Uma vez que a revisão é concluída, atualizamos o site com o conteúdo traduzido. +O processo de revisão é simples; uma vez que um conjunto de conteúdo esteja 100% traduzido, solicitamos uma revisão para esse lote de conteúdo. O processo de revisão ocorre diretamente no Crowdin. Uma vez que a revisão é concluída, atualizamos o site com o conteúdo traduzido. ## Como faço para adicionar conteúdo no meu idioma? {#adding-foreign-language-content} Atualmente, todo o conteúdo que não está na língua inglesa é traduzido diretamente do conteúdo em inglês, e qualquer conteúdo que não esteja nesse idioma não pode ser adicionado a outros idiomas. -Para sugerir um novo conteúdo para o ethereum.org, é possível [criar um tíquete](https://github.com/ethereum/ethereum-org-website/issues) no GitHub. Se adicionado, o conteúdo será escrito em inglês e traduzido para outros idiomas usando o Crowdin. +Para sugerir novo conteúdo para o ethereum.org, você pode [criar um problema](https://github.com/ethereum/ethereum-org-website/issues) no GitHub. Se adicionado, o conteúdo será escrito em inglês e traduzido para outros idiomas usando o Crowdin. Planejamos adicionar suporte para adições de conteúdos que não estejam em inglês em um futuro próximo. -## Entre em contato conosco {#contact} +## Entre em contato {#contact} -Agradecemos por ter lido todas estas informações. Esperamos que elas tenham incentivado você a participar de nosso programa. Junte-se ao nosso [canal de tradução do Discord](https://discord.gg/ethereum-org) para fazer perguntas e colaborar com outros tradutores, ou envie um e-mail para translations@ethereum.org! +Agradecemos por ter lido todas estas informações. Esperamos que elas tenham incentivado você a participar de nosso programa. Sinta-se à vontade para entrar em nosso [canal de tradução do Discord](https://discord.gg/ethereum-org) para fazer perguntas e colaborar com outros tradutores, ou entre em contato conosco em translations@ethereum.org! diff --git a/public/content/translations/pt-br/contributing/translation-program/how-to-translate/index.md b/public/content/translations/pt-br/contributing/translation-program/how-to-translate/index.md index abc35e838aa..e9f9dbabfa0 100644 --- a/public/content/translations/pt-br/contributing/translation-program/how-to-translate/index.md +++ b/public/content/translations/pt-br/contributing/translation-program/how-to-translate/index.md @@ -1,7 +1,7 @@ --- title: Como traduzir lang: pt-br -description: Instruções de uso do Crowdin para traduzir o ethereum.org +description: "Instruções de uso do Crowdin para traduzir o ethereum.org" --- # Como traduzir {#how-to-translate} @@ -22,9 +22,10 @@ Você precisará fazer login na sua conta do Crowdin ou criar uma conta, caso ai Junte-se ao projeto -### Selecione seu idioma {#open-language} +### Abra seu idioma {#open-language} -Depois de fazer login no Crowdin, você verá uma descrição do projeto e uma lista de todos os idiomas disponíveis. Cada idioma também contém informações sobre a quantidade total de palavras traduzíveis e uma visão geral de quanto conteúdo foi traduzido e aprovado em um idioma específico. +Depois de fazer login no Crowdin, você verá uma descrição do projeto e uma lista de todos os idiomas disponíveis. +Cada idioma também contém informações sobre a quantidade total de palavras traduzíveis e uma visão geral de quanto conteúdo foi traduzido e aprovado em um idioma específico. Escolha o idioma para o qual deseja traduzir para ver a lista de arquivos disponíveis para tradução. @@ -34,16 +35,14 @@ Escolha o idioma para o qual deseja traduzir para ver a lista de arquivos dispon O conteúdo do site é dividido em vários documentos e grupos de conteúdo. Você pode verificar o progresso de cada documento à direita. Se o progresso da tradução estiver abaixo de 100%, contribua! -Não vê seu idioma na lista? [Abra um tíquete](https://github.com/ethereum/ethereum-org-website/issues/new/choose) ou faça uma pergunta no [Discord](https://discord.gg/ethereum-org) +Não vê seu idioma na lista? [Abra uma issue](https://github.com/ethereum/ethereum-org-website/issues/new/choose) ou pergunte em nosso [Discord](https://discord.gg/ethereum-org) ![Arquivos traduzidos e não traduzidos no Crowdin](./crowdin-files.png) -Uma nota sobre recipientes de conteúdo: utilizamos “recipientes de conteúdos” dentro do Crowdin para ter o conteúdo de prioridade mais alta lançado primeiro. Ao verificar um idioma, por exemplo, [Filipino](https://crowdin.com/project/ethereum-org/fil#) você verá pastas por categoria de conteúdo (“1. Página inicial", "2. Essenciais", "3. Explorando”, etc.). +Uma nota sobre recipientes de conteúdo: utilizamos “recipientes de conteúdos” dentro do Crowdin para ter o conteúdo de prioridade mais alta lançado primeiro. Quando você confere um idioma, por exemplo, [Filipino](https://crowdin.com/project/ethereum-org/fil#), você verá pastas para a categoria de conteúdo ("1. Página inicial", "2. Essenciais", "3. Explorando”, etc.). Recomendamos que você traduza nesta ordem numérica (1 → 2 → 3 → ⋯) para assegurar que as páginas de maior impacto sejam traduzidas primeiro. -[Saiba mais sobre os recipientes de conteúdo do ethereum.org](/contributing/translation-program/) - ### Traduzir {#translate} Após selecionar o arquivo que você deseja traduzir, ele será aberto no editor online. Se você nunca usou o Crowdin antes, você pode usar este guia rápido para conferir as noções básicas. @@ -60,7 +59,8 @@ Você também pode usar os botões no topo para pesquisar segmentos específicos **_2 – Área do editor_** -A área de tradução principal — o texto de origem é exibido no topo, com contexto adicional e capturas de tela, se disponíveis. Para sugerir uma nova tradução, insira sua sugestão no campo “Insira sua tradução aqui” e clique em Salvar. +A área de tradução principal — o texto de origem é exibido no topo, com contexto adicional e capturas de tela, se disponíveis. +Para sugerir uma nova tradução, insira sua sugestão no campo “Insira sua tradução aqui” e clique em Salvar. Você também pode encontrar traduções existentes do texto e traduções para outros idiomas nesta seção, além das correspondências de memória de tradução e sugestões de tradução automática. @@ -70,11 +70,11 @@ Aqui você pode encontrar comentários, assim como entradas da memória de tradu Usando os botões na parte superior, você também pode alternar para a memória de tradução, na qual você pode procurar traduções existentes, ou para o Glossário, que contém descrições e traduções padrão de termos-chave. -Quer saber mais? Confira a [documentação sobre como usar o editor online do Crowdin](https://support.crowdin.com/online-editor/) +Quer saber mais? Sinta-se à vontade para conferir a [documentação sobre como usar o editor online do Crowdin](https://support.crowdin.com/online-editor/) ### Processo de revisão {#review-process} -Quando tiver concluído a tradução (ou seja, todos os arquivos de um grupo de conteúdo que exibem 100%), nosso serviço de tradução profissional revisará (e possivelmente editará) o conteúdo. Assim que a revisão estiver completa (ou seja, o progresso de revisão atingir 100%), o adicionaremos ao site. +Quando tiver concluído a tradução (ou seja, todos os arquivos para uma categoria de conteúdo exibirem 100%), nosso serviço de tradução profissional revisará (e potencialmente editará) o conteúdo. Assim que a revisão estiver completa (ou seja, o progresso da revisão atingir 100%), nós o adicionaremos ao site. @@ -83,9 +83,9 @@ Quando tiver concluído a tradução (ou seja, todos os arquivos de um grupo de -### Entre em contato conosco {#get-in-touch} +### Entre em contato {#get-in-touch} -Você tem alguma dúvida? Ou quer colaborar com nossa equipe e outros tradutores? Publique no canal #translations do nosso [servidor Discord no ethereum.org](https://discord.gg/ethereum-org) +Você tem alguma dúvida? Ou quer colaborar com nossa equipe e outros tradutores? Publique no canal #translations do nosso [servidor do Discord do ethereum.org](https://discord.gg/ethereum-org) Você também pode entrar em contato conosco por meio do e-mail translations@ethereum.org diff --git a/public/content/translations/pt-br/contributing/translation-program/index.md b/public/content/translations/pt-br/contributing/translation-program/index.md index e7c10227529..fce4f682050 100644 --- a/public/content/translations/pt-br/contributing/translation-program/index.md +++ b/public/content/translations/pt-br/contributing/translation-program/index.md @@ -1,10 +1,10 @@ --- -title: Programa de tradução +title: "Programa de tradução" lang: pt-br -description: Informações sobre o Programa de Tradução do ethereum.org +description: "Informações sobre o Programa de Tradução do ethereum.org" --- -# Programa de tradução {#translation-program} +# Programa de Tradução {#translation-program} O Programa de tradução é um esforço colaborativo para traduzir ethereum.org em diferentes idiomas para tornar o site mais acessível a bilhões de falantes não ingleses em todo o mundo. @@ -16,11 +16,11 @@ O Programa de Tradução do ethereum.org está aberto e qualquer um pode contrib 1. Você precisará entrar na sua conta do Crowdin ou se inscrever. 2. Selecione o idioma para o qual você deseja contribuir. -3. Antes de começar, confira o guia [Como traduzir](/contributing/translation-program/how-to-translate/) para aprender como usar o Crowdin, e o [Guia de Estilo de Tradução](/contributing/translation-program/translators-guide/) para dicas e melhores práticas. +3. Antes de começar, consulte o guia [Como traduzir](/contributing/translation-program/how-to-translate/) para aprender a usar o Crowdin e o [Guia de Estilo de Tradução](/contributing/translation-program/translators-guide/) para dicas e melhores práticas. 4. As traduções automáticas não serão aprovadas. 5. Todas as traduções são revisadas antes de serem adicionadas ao site, por isso, haverá um pequeno atraso antes que suas traduções sejam publicadas. -_Junte-se ao [ethereum.org Discord](https://discord.gg/ethereum-org) para colaborar com traduções, fazer perguntas, compartilhar comentários e ideias ou juntar-se a um grupo de tradução._ +_Junte-se ao [Discord do ethereum.org](https://discord.gg/ethereum-org) para colaborar em traduções, fazer perguntas, compartilhar feedback e ideias ou participar de um grupo de tradução._ Comece a traduzir @@ -36,31 +36,32 @@ Leia mais sobre a [missão e visão](/contributing/translation-program/mission-a ### Nosso progresso até agora {#our-progress} -- [**Mais de 6.000**tradutores](/contributing/translation-program/contributors/) -- **62** idiomas presentes no site -- [**3 milhões** de palavras traduzidas em 2023](/contributing/translation-program/acknowledgements/) +- [**Mais de 6.900** tradutores](/contributing/translation-program/contributors/) +- **68** idiomas disponíveis no site +- [**2,89 milhões** de palavras traduzidas em 2024](/contributing/translation-program/acknowledgements/) ### Agradecimentos {#acknowledgements} -O Ethereum.org é traduzido por milhares de membros da comunidade e eles são a peça chave do Programa de Tradução. Queremos agradecer nossos tradutores e apoiá-los em seu percurso profissional. Aqui estão alguns de nossos agradecimentos aos tradutores: +O Ethereum.org é traduzido por milhares de membros da comunidade e eles são a peça chave do Programa de Tradução. +Queremos agradecer nossos tradutores e apoiá-los em seu percurso profissional. Aqui estão alguns de nossos agradecimentos aos tradutores: #### Certificado {#certificate} -Se você contribuiu para o Programa de Tradução e teve, pelo menos, 5.000 palavras traduzidas aprovadas, você pode receber um certificado de tradutor do ethereum.org. [Saiba mais sobre os certificados](/contributing/translation-program/acknowledgements/#certificate) +Se você contribuiu para o Programa de Tradução e teve, pelo menos, 5.000 palavras traduzidas aprovadas, você pode receber um certificado de tradutor do ethereum.org. [Mais sobre certificados](/contributing/translation-program/acknowledgements/#certificate) -#### OATs (tokens de conquista on-chain) {#oats} +#### OATs {#oats} Os contribuidores do Programa de Tradução são elegíveis para diferentes OATs (tokens de conquista on-chain) com base no número de palavras traduzidas em 2024. OATs são NFTs que comprovam sua contribuição ao Programa de Tradução do ethereum.org. [Mais sobre OATs](/contributing/translation-program/acknowledgements/#oats) #### Agradecimentos aos tradutores {#translator-acknowledgements} -Agradecimentos públicos aos nossos principais tradutores por meio de [tabelas de classificação](/contributing/translation-program/acknowledgements/) e uma [lista de todos os colaboradores do Programa de Tradução](/contributing/translation-program/contributors/). +Agradecimentos públicos aos nossos principais tradutores por meio de [placar de líderes](/contributing/translation-program/acknowledgements/) e uma [lista de todos os contribuidores do Programa de Tradução](/contributing/translation-program/contributors/). #### Recompensas {#rewards} -No passado, recompensamos retroativamente nossos colaboradores mais ativos com ingressos para conferências do Ethereum como a [Devcon](https://devcon.org/en/) e a [Devconnect](https://devconnect.org/), assim como com produtos exclusivos do ethereum.org. +No passado, recompensamos retroativamente nossos contribuidores mais ativos com ingressos para conferências da Ethereum, como a [Devcon](https://devcon.org/en/) e a [Devconnect](https://devconnect.org/), bem como produtos exclusivos do ethereum.org. Estamos constantemente pensando em maneiras novas e inovadoras de recompensar nossos colaboradores, então fique ligado! @@ -68,23 +69,23 @@ Estamos constantemente pensando em maneiras novas e inovadoras de recompensar no Se você está contribuindo para o Programa de Tradução ou pensando em se envolver com ele, confira os guias de tradução abaixo: -- [Guia de Estilo de Tradução](/contributing/translation-program/translators-guide/) _ — instruções e dicas para tradutores do ethereum.org_ -- [Perguntas frequentes sobre tradução](/contributing/translation-program/faq/) _ — perguntas frequentes e respostas sobre o Programa de Tradução do ethereum.org_ -- [Guia do editor online do Crowdin](https://support.crowdin.com/online-editor/) _ — um guia detalhado sobre como usar o editor online do Crowdin e algumas funcionalidades avançadas do Crowdin_ -- [Pacotes de conteúdo](/contributing/translation-program/) _ — quais páginas estão incluídas em cada pacote de conteúdo do ethereum.org_ +- [Guia de Estilo de Tradução](/contributing/translation-program/translators-guide/) _– instruções e dicas para tradutores do ethereum.org_ +- [Perguntas frequentes sobre tradução](/contributing/translation-program/faq/) _– perguntas e respostas frequentes sobre o Programa de Tradução do ethereum.org_ +- [Guia do editor on-line do Crowdin](https://support.crowdin.com/online-editor/) _– um guia detalhado sobre como usar o editor on-line do Crowdin e alguns dos recursos avançados do Crowdin_ -Para outras ferramentas úteis de tradução, comunidades de tradutores e postagens no blog do Programa de Tradução, visite a [Página de recursos](/contribuindo/tradução-programa/recursos/). +Para outras ferramentas de tradução úteis, comunidades de tradutores e posts de blog do Programa de Tradução, visite a [página de Recursos](/contributing/translation-program/resources/). -## Envolva-se {#get-in-touch} +## Entre em contato {#get-in-touch} -Você tem alguma dúvida? Ou quer colaborar com nossa equipe e outros tradutores? Publique no canal #translations do nosso [servidor Discord no ethereum.org](https://discord.gg/ethereum-org) +Você tem alguma dúvida? Ou quer colaborar com nossa equipe e outros tradutores? Publique no canal #translations do nosso [servidor do Discord do ethereum.org](https://discord.gg/ethereum-org) Você também pode entrar em contato conosco por meio do e-mail translations@ethereum.org -## Iniciando o seu próprio programa de tradução {#starting-a-translation-program} +## Iniciando seu próprio programa de tradução {#starting-a-translation-program} -Estamos empenhados em traduzir o conteúdo do Ethereum para o maior número possível de idiomas e tornar o conteúdo educacional disponível a todos. Em sintonia com a importância que damos às traduções, queremos ajudar outros projetos do Ethereum a organizar, gerenciar e melhorar suas próprias iniciativas de tradução. +Estamos empenhados em traduzir o conteúdo do Ethereum para o maior número possível de idiomas e tornar o conteúdo educacional disponível a todos. +Em sintonia com a importância que damos às traduções, queremos ajudar outros projetos do Ethereum a organizar, gerenciar e melhorar suas próprias iniciativas de tradução. -Por esta razão, criamos um [Manual do Programa de Tradução](/contributing/translation-program/playbook/), que contém algumas dicas e práticas recomendadas que coletamos no processo de tradução do ethereum.org. +Por esse motivo, criamos um [manual do Programa de Tradução](/contributing/translation-program/playbook/) que contém algumas dicas e melhores práticas que aprendemos no processo de tradução do ethereum.org. Quer colaborar mais ou usar alguns dos nossos recursos de tradução? Tem algum comentário sobre o manual? Envie-nos uma mensagem em translations@ethereum.org. diff --git a/public/content/translations/pt-br/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/pt-br/contributing/translation-program/mission-and-vision/index.md index 08a5a2fb95a..3261f124019 100644 --- a/public/content/translations/pt-br/contributing/translation-program/mission-and-vision/index.md +++ b/public/content/translations/pt-br/contributing/translation-program/mission-and-vision/index.md @@ -1,7 +1,7 @@ --- -title: Missão e visão +title: "Missão e visão" lang: pt-br -description: A missão e visão do Programa de Tradução do ethereum.org +description: "A missão e visão do Programa de Tradução do ethereum.org" --- # Missão e visão {#mission-and-vision} diff --git a/public/content/translations/pt-br/contributing/translation-program/playbook/index.md b/public/content/translations/pt-br/contributing/translation-program/playbook/index.md new file mode 100644 index 00000000000..a14183c884a --- /dev/null +++ b/public/content/translations/pt-br/contributing/translation-program/playbook/index.md @@ -0,0 +1,317 @@ +--- +title: "Manual do programa de tradução" +lang: pt-br +description: "Uma coleção de dicas e considerações importantes para a criação de um programa de tradução" +--- + +# Manual do Programa de Tradução {#translation-program-playbook} + +O inglês é uma das línguas mais faladas no mundo e, de longe, a língua mais estudada do mundo. Como o inglês é o idioma mais comum usado na internet — especialmente nas mídias sociais — e as linguagens de programação multilíngues são escassas, a maior parte do conteúdo no espaço blockchain é escrito nativamente em inglês. + +No entanto, como mais de 6 bilhões de pessoas no mundo (mais de 75% da população) não falam inglês, isso representa uma barreira enorme para a entrada no Ethereum para a grande maioria da população mundial. + +Por esse motivo, um número crescente de projetos nesse setor busca traduzir seu conteúdo para diferentes idiomas e localizá-lo para comunidades globais. + +Fornecer conteúdo multilíngue é uma maneira simples e eficaz de expandir sua comunidade global, fornecer educação a pessoas que não falam inglês, garantir que seu conteúdo e comunicações alcancem um público maior e atrair mais pessoas para o espaço. + +Este guia tem como objetivo abordar os desafios e equívocos comuns sobre localização de conteúdo. Ele fornece um guia passo a passo para gerenciar conteúdo, o processo de tradução e revisão, garantia de qualidade, alcance do tradutor e outros aspectos vitais do processo de localização. + +## Gerenciamento de conteúdo {#content-management} + +O gerenciamento de conteúdo de tradução refere-se ao processo de automatização do fluxo de trabalho de tradução, o que elimina a necessidade de trabalho manual repetitivo, melhora a eficiência e a qualidade, permite melhor controle e possibilita a colaboração. + +Existem muitas abordagens diferentes para o gerenciamento de conteúdo no processo de localização, dependendo do conteúdo e das suas necessidades. + +A maneira fundamental de gerenciar conteúdo é criar arquivos bilíngues, contendo o texto de origem e de destino. Isso é raramente usado em tradução, pois não oferece vantagens significativas, além da simplicidade. + +As agências de tradução geralmente abordam o gerenciamento usando softwares de tradução ou ferramentas de localização, que fornecem recursos para os projetos e permitem um controle muito maior sobre os arquivos, o conteúdo e os linguistas. + +Saiba mais sobre gerenciamento de conteúdo: + +[Trados sobre o que é gestão de tradução](https://www.trados.com/solutions/translation-management/) + +[Frase sobre gerenciamento de conteúdo multilíngue](https://phrase.com/blog/posts/multilingual-content-management/) + +### Software de gerenciamento de tradução {#translation-management-software} + +Existem muitos sistemas de gerenciamento de tradução e ferramentas de localização, e a escolha do software depende principalmente de suas necessidades. + +Embora alguns projetos decidam não usar sistemas de gerenciamento de tradução e prefiram lidar com as traduções manualmente — seja diretamente em arquivos bilíngues ou em serviços de hospedagem, como o GitHub — isso reduz drasticamente o controle, a produtividade, a qualidade, a escalabilidade e os recursos de colaboração. Essa abordagem pode ser mais benéfica para projetos de tradução de pequena escala ou pontuais. + +Uma rápida olhada em algumas das ferramentas de gerenciamento de tradução mais poderosas e amplamente utilizadas: + +**Melhor para crowdsourcing e colaboração** + +[Crowdin](https://crowdin.com/) + +- Gratuito para projetos de código aberto (número ilimitado de strings e projetos) +- TM e glossário disponíveis com todos os planos +- Mais de 60 formatos de arquivo suportados, mais de 70 integrações de API + +[Lokalise](https://lokalise.com/) + +- Grátis para 2 membros da equipe, planos pagos para mais colaboradores (número limitado de strings para a maioria dos planos) +- TM e glossário disponíveis com alguns planos pagos +- Mais de 30 formatos de arquivo suportados, mais de 40 integrações de API + +[Transifex](https://www.transifex.com/) + +- Somente planos pagos (número limitado de sequências para a maioria dos planos) +- TM e glossário disponíveis em todos os planos pagos +- Mais de 30 formatos de arquivo suportados, mais de 20 integrações de API + +[Phrase](https://phrase.com/) + +- Somente planos pagos (número ilimitado de strings para todos os planos, número limitado de projetos e membros da equipe) +- TM e glossário disponíveis com alguns planos pagos +- Mais de 40 formatos de arquivo suportados, mais de 20 integrações de API + +[Smartcat](https://www.smartcat.com/) + +- Plano básico gratuito com recursos avançados pagos (número ilimitado de strings e projetos para todos os planos) +- TM e glossário disponíveis com todos os planos +- Mais de 60 formatos de arquivo suportados, mais de 20 integrações de API + +[POEditor](https://poeditor.com/) + +- Gratuito para projetos de código aberto (número limitado de strings para todos os projetos, ilimitado para projetos de código aberto) +- TM e glossário disponíveis para planos pagos +- Mais de 20 formatos de arquivo suportados, mais de 10 integrações de API + +e muitos outros... + +**Ferramentas de tradução profissionais** + +[SDL Trados Studio](https://www.trados.com/products/trados-studio/) + +- Planos pagos para tradutores e equipes freelancers +- Ferramenta de tradução assistida por computador (CAT) muito poderosa e software de produtividade para tradutores + +[MemoQ](https://www.memoq.com/) + +- Versão gratuita limitada disponível com vários planos pagos para recursos avançados +- Software de gestão de tradução para empresas, prestadores de serviços de idiomas e tradutores + +[Memsource](https://www.memsource.com/) + +- Gratuito para tradutores individuais com vários planos pagos para equipes +- Sistema de tradução e gestão de tradução assistido por computador baseado em nuvem + +e muitos outros... + +Saiba mais sobre software de gerenciamento de tradução: + +[Definição da Wikipédia de sistemas de gestão de tradução](https://en.wikipedia.org/wiki/Translation_management_system) + +[Frase sobre 7 coisas que todo software de gerenciamento de tradução deveria ter](https://phrase.com/blog/posts/7-things-every-translation-management-software-should-have/) + +[MemoQ sobre o que é um sistema de gerenciamento de tradução](https://www.memoq.com/tools/what-is-a-translation-management-system) + +[Lista da Gengo dos 16 melhores sistemas de gestão de tradução](https://gengo.com/translator-product-updates/16-best-translation-management-systems/) + +## Workflow {#workflow} + +No mundo da tradução, o fluxo de trabalho da tradução pode significar algumas coisas diferentes, ambas de certa forma inter-relacionadas e considerações importantes para o seu projeto. + +Exploraremos ambos abaixo. + +**Significado 1** + +Esta é provavelmente a maneira mais comum de pensar sobre fluxos de trabalho de tradução e algo que geralmente vem à mente quando ouço a palavra fluxo de trabalho. + +Em essência, é o “fluxo de trabalho” desde o início da reflexão sobre as traduções até a utilização do conteúdo traduzido no seu produto. + +Um exemplo de workflow neste caso seria: + +1. **Preparando os arquivos para tradução** – Parece simples; no entanto, você precisa considerar algumas coisas importantes. Nesta etapa, você deve ter um plano claro de como todo o processo deve funcionar. + +- Quais tipos de arquivo você usará? Em qual formato você deseja receber seus arquivos traduzidos?_ + - Se o seu conteúdo estiver disponível em formato DOCX ou MD, a abordagem será muito mais direta do que se você estivesse traduzindo uma versão em PDF do seu Whitepaper ou de outros documentos. +- _Quais ferramentas de localização suportam esse tipo de arquivo? O arquivo pode ser traduzido para manter a formatação original?_ + - Nem todos os tipos de arquivo suportam localização direta (por exemplo, arquivos PDF, arquivos de imagem), e nem todas as ferramentas de localização suportam todos os tipos de arquivo. +- _Quem traduzirá o conteúdo? Você solicitará traduções profissionais ou dependerá de voluntários?_ + - Isso afeta uma série de outras decisões que você precisa tomar. Por exemplo, tradutores profissionais se sentem mais confortáveis ​​trabalhando com ferramentas avançadas de localização do que voluntários. +- Quais são suas expectativas para os linguistas? Se você estiver usando um provedor de serviços de idiomas, o que eles esperam de você?_ + - Esta é a etapa para garantir que seus objetivos, expectativas e cronogramas estejam alinhados. +- _Todo o conteúdo para tradução é igualmente importante? Algum conteúdo deve ser traduzido primeiro?_ + - Existem algumas maneiras de priorizar determinado conteúdo, que deve ser traduzido e implementado primeiro. Por exemplo, se você tem muito conteúdo para traduzir, pode usar o controle de versão para garantir que os tradutores saibam o que devem priorizar. + +2. **Compartilhamento dos arquivos para tradução** – Esta etapa também requer algum pensamento de longo prazo e não é tão simples quanto enviar os arquivos de origem para um provedor de serviços de idiomas. + +- _Quem traduzirá o conteúdo? Quantas pessoas estarão envolvidas neste processo?_ + - Se você planeja usar uma ferramenta de localização, esta etapa é simplificada, pois você pode carregar os arquivos de origem diretamente na ferramenta. Isso também é verdade se o processo de tradução ocorrer no serviço de hospedagem, já que os arquivos de origem não precisam ser exportados para lugar nenhum. +- _Os arquivos de origem serão manipulados manualmente ou esse processo pode ser automatizado?_ + - A maioria das ferramentas de localização permite algum tipo de integração ou automação do processo de gerenciamento de arquivos. Por outro lado, se você estiver trabalhando com tradutores individuais e não estiver usando uma ferramenta de localização, enviar manualmente os arquivos de origem para centenas ou milhares de tradutores não é um processo escalável. +- _Quais ferramentas serão usadas para a localização?_ + - A resposta a essa pergunta determinará como você abordará o resto. Selecionar a ferramenta adequada pode ajudar você a automatizar o gerenciamento de conteúdo, gerenciar a Memória de Tradução e o Glossário, gerenciar tradutores, acompanhar o progresso da tradução/revisão, etc., então reserve um tempo e pesquise qual ferramenta você deseja usar. Se você não planeja usar uma ferramenta de localização, tudo isso precisará ser feito manualmente. +- _Quanto tempo levará o processo de tradução? Quanto vai custar?_ + - Neste ponto, você deve estar pronto para compartilhar os arquivos de origem com o provedor de serviços de idiomas ou com o grupo de tradutores. O provedor de serviços de idiomas pode ajudar você a analisar a contagem de palavras e fornecer um orçamento, incluindo as taxas e o cronograma do processo de tradução. +- _Você está planejando fazer alterações/atualizar o conteúdo de origem durante esse processo?_ + - Se o seu conteúdo for dinâmico e mudar com frequência, quaisquer alterações ou atualizações podem atrapalhar o andamento da tradução. Usar uma memória de tradução pode ajudar a atenuar isso significativamente, embora ainda seja importante pensar em como o processo funcionará e como você pode evitar atrasos no progresso dos tradutores. + +3. **Gerenciando o processo de tradução** – Seu trabalho não termina quando o conteúdo de origem é entregue ao provedor de serviços de idioma ou aos tradutores. Para garantir a qualidade ideal das traduções, os criadores de conteúdo devem estar o mais envolvidos possível no processo de tradução. + +- _Como você planeja se comunicar com os tradutores?_ + - Se você planeja usar uma ferramenta de localização, a comunicação pode ocorrer diretamente na ferramenta. Também é recomendável criar um canal de comunicação alternativo com os tradutores, pois eles podem ficar menos hesitantes em entrar em contato, e as ferramentas de mensagens permitem uma comunicação mais fluida. +- _Como lidar com perguntas de tradutores? Quem deve responder a essas perguntas?_ + - Tradutores (profissionais e não profissionais) frequentemente entrarão em contato com perguntas e solicitações de esclarecimentos ou contexto adicional, bem como feedback e ideias para melhorias. Responder a essas perguntas geralmente pode levar a um melhor engajamento e qualidade do conteúdo traduzido. Também é valioso fornecer a eles o máximo de recursos possível (por exemplo, guias, dicas, diretrizes de terminologia, perguntas frequentes, etc.). +- _Como lidar com o processo de revisão? Você quer terceirizar ou tem capacidade de realizar revisões internamente?_ + - Embora nem sempre sejam necessárias, as revisões são parte integrante de um processo de tradução ideal. Normalmente, é mais fácil terceirizar o processo de revisão para revisores profissionais. No entanto, se você tiver uma grande equipe internacional, as revisões ou o controle de qualidade também podem ser feitos internamente. + +4. **Implementando o conteúdo traduzido** – A última parte do fluxo de trabalho, embora ainda seja importante considerar com antecedência. + +- _Todas as traduções serão concluídas ao mesmo tempo?_ + - Caso contrário, você deve pensar em quais traduções devem ser priorizadas, como acompanhar as que estão em andamento e como a implementação é tratada enquanto elas são feitas. +- _Como o conteúdo traduzido será entregue a você? Em que formato será?_ + - Esta é uma consideração importante, independentemente da abordagem que você usar. As ferramentas de localização permitem que você mantenha o controle sobre o formato do arquivo de destino e o processo de exportação e geralmente oferecem suporte à automação, por exemplo, permitindo a integração com o serviço de hospedagem. +- _Como você implementará as traduções no seu projeto?_ + - Em alguns casos, isso pode ser tão simples quanto enviar o arquivo traduzido ou adicioná-lo aos seus documentos. No entanto, em projetos mais complexos, como traduções de sites ou aplicativos, você deve garantir que o código suporte a internacionalização e estabelecer com antecedência como o processo de implementação será conduzido. +- _O que acontece se a formatação for diferente da fonte?_ + - Semelhante ao acima, se você estiver traduzindo arquivos de texto simples, a formatação provavelmente não será tão importante. No entanto, com arquivos mais complexos, como conteúdo para um site ou aplicativo, a formatação e o código precisam ser idênticos ao código-fonte para serem implementados no seu projeto. Caso contrário, os arquivos de destino precisarão ser editados, pelos tradutores ou pelos seus desenvolvedores. + +**Significado 2** + +Um fluxo de trabalho de tradução alternativo, que não considera decisões e abordagens internas. A principal consideração aqui é o fluxo do conteúdo em si. + +Um exemplo de workflow neste caso seria: + +1. _Tradução → Implementação_ + +- O fluxo de trabalho mais simples, onde a tradução provavelmente será feita por uma tradução humana, já que não há processo de revisão ou controle de qualidade para avaliar a qualidade e editar as traduções antes da implementação. +- Com esse fluxo de trabalho, é importante que os tradutores consigam manter um certo nível de qualidade, o que exigirá recursos adequados e comunicação entre os gerentes de projeto e os tradutores. + +2. _Tradução → Revisão → Implementação_ + +- Um fluxo de trabalho mais avançado, que inclui um processo de revisão e edição, para garantir que a qualidade das traduções seja aceitável e consistente. +- Há uma série de abordagens para esse fluxo de trabalho, onde as traduções podem ser realizadas por tradutores profissionais ou voluntários, enquanto o processo de revisão provavelmente será conduzido por revisores profissionais, que estão familiarizados com todas as regras gramaticais e ortográficas que precisam ser observadas no idioma de destino. + +3. _Tradução → Revisão → QA → Implementação_ + +- O fluxo de trabalho ideal para garantir o mais alto nível de qualidade. Embora o controle de qualidade nem sempre seja necessário, ele pode ser útil para lhe dar uma noção melhor da qualidade do texto traduzido após a tradução e a revisão. +- Com esse fluxo de trabalho, as traduções poderiam ser realizadas exclusivamente por voluntários ou até mesmo por tradução automática. O processo de revisão deve ser realizado por tradutores profissionais, enquanto o controle de qualidade pode ser realizado por um provedor de serviços de idiomas ou internamente, se você tiver funcionários que sejam falantes nativos dos idiomas de destino. + +Saiba mais sobre fluxos de trabalho de tradução: + +[Regras de conteúdo sobre as cinco fases do fluxo de trabalho de tradução](https://contentrules.com/creating-translation-workflow/) + +[Smartling sobre o que é gerenciamento de fluxo de trabalho de tradução](https://www.smartling.com/resources/101/what-is-translation-workflow-management/) + +[RixTrans sobre o fluxo de trabalho de tradução](https://www.rixtrans.com/translation-workflow) + +## Gestão de Terminologia {#terminology-management} + +Estabelecer um plano claro sobre como lidar com a terminologia é um dos passos mais importantes para garantir a qualidade e a consistência das suas traduções e economizar tempo dos seus tradutores. + +No setor de tradução, isso é conhecido como gerenciamento de terminologia e é um dos principais serviços que os provedores de serviços de idiomas oferecem aos seus clientes, além do acesso ao seu conjunto de linguistas e gerenciamento de conteúdo. + +Gerenciamento de terminologia se refere ao processo de identificar, reunir e gerenciar terminologia que é importante para seu projeto e deve sempre ser traduzida de forma correta e consistente. + +Há alguns passos a seguir ao começar a pensar sobre gerenciamento de terminologia: + +- Identifique os termos-chave que devem ser incluídos na base de termos. +- Crie um glossário de termos e suas definições. +- Traduza os termos e adicione-os ao glossário. +- Verifique e aprove as traduções. +- Mantenha o glossário e atualize-o com novos termos, à medida que se tornam importantes. + +Saiba mais sobre gerenciamento de terminologia: + +[Trados sobre o que é gerenciamento de terminologia](https://www.trados.com/solutions/terminology-management/translation-101-what-is-terminology-management.html) + +[Language Scientific sobre a importância da gestão de terminologia](https://www.languagescientific.com/terminology-management-why-it-matters/#:~:text=Terminology%20management%20is%20the%20process,are%20related%20to%20each%20other.) + +[Clear Words Translation sobre o que é gerenciamento de terminologia e por que isso é importante](http://clearwordstranslations.com/language/en/what-is-terminology-management/) + +### Memória de tradução e glossário {#tm-and-glossary} + +A Memória de Tradução e o Glossário são ferramentas importantes no setor de tradução e algo em que a maioria dos provedores de serviços de idiomas confia. + +Vamos ver o que esses termos significam e como eles são diferentes entre si: + +**Memória de tradução (TM)** – Um banco de dados que armazena automaticamente segmentos ou sequências de caracteres, incluindo blocos de texto mais longos, frases completas, parágrafos e termos individuais, bem como suas traduções atuais e anteriores em todos os idiomas. + +A maioria das ferramentas de localização, sistemas de gerenciamento de tradução e ferramentas de tradução assistida por computador têm memórias de tradução integradas, que geralmente podem ser exportadas e usadas em outras ferramentas semelhantes. + +Os benefícios de usar uma memória de tradução incluem traduções mais rápidas, melhor qualidade de tradução, a capacidade de reter determinadas traduções ao atualizar ou alterar o conteúdo de origem e custos de tradução mais baixos para conteúdo repetitivo. + +As memórias de tradução funcionam com base em uma porcentagem de correspondência entre diferentes segmentos e geralmente são mais úteis quando dois segmentos contêm mais de 50% do mesmo conteúdo. Eles também são usados ​​para traduzir automaticamente segmentos repetitivos, que são 100% correspondentes, eliminando assim a necessidade de traduzir conteúdo repetitivo mais de uma vez. + +Leia mais sobre memórias de tradução: + +[Memsource sobre memórias de tradução](https://www.memsource.com/translation-memory/) + +[Smartling sobre o que é uma memória de tradução](https://www.smartling.com/resources/101/what-is-translation-memory/) + +**Glossário –** Uma lista de termos importantes ou sensíveis, suas definições, funções e traduções estabelecidas. A principal diferença entre um glossário e uma memória de tradução é que um glossário não é criado automaticamente e não contém traduções de frases completas. + +A maioria das ferramentas de localização, sistemas de gerenciamento de tradução e ferramentas de tradução assistida por computador têm glossários integrados que você pode manter para garantir que contenham terminologia importante para seu projeto. Assim como a TM, o glossário geralmente pode ser exportado e usado em outras ferramentas de localização. + +Antes de começar seu projeto de tradução, é altamente recomendável reservar um tempo para criar um glossário para seus tradutores e revisores. Usar um glossário garante que termos importantes sejam traduzidos corretamente, fornece aos tradutores o contexto necessário e garante consistência nas traduções. + +Embora os glossários geralmente contenham traduções estabelecidas nos idiomas de destino, eles também são úteis sem elas. Mesmo sem traduções estabelecidas, um glossário pode ter definições de termos técnicos, destacar termos que não devem ser traduzidos e informar aos tradutores se um termo específico é usado como substantivo, verbo, nome próprio ou qualquer outra parte do discurso. + +Saiba mais sobre glossários: + +[Lionbridge sobre o que é um glossário de tradução](http://info.lionbridge.com/rs/lionbridge/images/Lionbridge%20FAQ_Glossary_2013.pdf) + +[Transifex sobre glossários](https://docs.transifex.com/glossary/glossary) + +Se você não estiver planejando usar uma ferramenta de localização para seu projeto, provavelmente não poderá usar uma memória de tradução e um glossário (você pode criar um glossário ou base de termos em um arquivo Excel; no entanto, os glossários automatizados eliminam a necessidade de os tradutores procurarem manualmente os termos e suas definições). + +Isso significa que todo conteúdo repetitivo e semelhante teria que ser traduzido manualmente todas as vezes. Além disso, os tradutores teriam que entrar em contato com perguntas sobre se um determinado termo precisa ser traduzido ou não, como ele é usado no texto e se um termo já tem uma tradução estabelecida. + +_Você quer usar a memória de tradução e o glossário do ethereum.org no seu projeto? Entre em contato conosco pelo e-mail translations@ethereum.org._ + +## Divulgação do tradutor {#translator-outreach} + +**Trabalhando com um provedor de serviços de idiomas** + +Se você estiver trabalhando com um provedor de serviços de idiomas e seus tradutores profissionais, esta seção pode não ser muito relevante para você. + +Nesse caso, é importante selecionar um provedor de serviços de idiomas com capacidade para fornecer todos os serviços que você precisa (por exemplo, tradução, revisão, controle de qualidade) em vários idiomas. + +Embora possa ser tentador selecionar um provedor de serviços de idiomas apenas com base nas taxas oferecidas, é importante observar que os maiores provedores de serviços de idiomas têm taxas mais altas por um motivo. + +- Eles têm dezenas de milhares de linguistas em seu banco de dados, o que significa que poderão designar tradutores com experiência e conhecimento suficientes do seu setor específico para o seu projeto (por exemplo, tradutores técnicos). +- Eles têm experiência significativa trabalhando em diferentes projetos e atendendo às diversas necessidades de seus clientes. Isso significa que eles estarão mais propensos a se adaptar ao seu fluxo de trabalho específico, oferecer sugestões valiosas e possíveis melhorias para seu processo de tradução e atender às suas necessidades, requisitos e prazos. +- A maioria dos grandes provedores de serviços de idiomas também tem suas próprias ferramentas de localização, memórias de tradução e glossários que você pode usar. Caso contrário, eles pelo menos têm linguistas suficientes em seu grupo para garantir que seus tradutores estejam familiarizados e consigam trabalhar com qualquer ferramenta de localização que você queira usar. + +Você pode encontrar uma comparação detalhada dos maiores provedores de serviços de idiomas do mundo, alguns detalhes sobre cada um deles e detalhamentos pelos serviços que eles fornecem, dados geográficos, etc. no [relatório Nimdzi 100 de 2021](https://www.nimdzi.com/nimdzi-100-top-lsp/). + +**Trabalhando com tradutores não profissionais** + +Você pode estar trabalhando com tradutores não profissionais e procurando voluntários para ajudá-lo a traduzir. + +Existem várias maneiras de alcançar pessoas e convidá-las a participar do seu projeto. Isso dependerá muito do seu produto e do tamanho da comunidade que você já tem. + +Algumas maneiras de integrar voluntários são descritas abaixo: + +**Divulgação –** Embora isso seja parcialmente abordado nos pontos abaixo, entrar em contato com potenciais voluntários e garantir que eles estejam cientes da sua iniciativa de tradução pode ser eficaz por si só. + +Muitas pessoas querem se envolver e contribuir com seus projetos favoritos, mas geralmente não veem uma maneira clara de fazer isso sem ser um desenvolvedor ou ter habilidades técnicas especiais. Se você puder divulgar seu projeto, muitos bilíngues provavelmente ficarão interessados ​​em se envolver. + +**Olhando para dentro da sua comunidade –** A maioria dos projetos nesse espaço já conta com comunidades grandes e ativas. Muitos membros da sua comunidade provavelmente apreciariam a oportunidade de contribuir com o projeto de uma forma simples. + +Embora contribuir para projetos de código aberto geralmente se baseie na motivação intrínseca, também é uma experiência de aprendizado fantástica. Qualquer pessoa interessada em aprender mais sobre seu projeto provavelmente ficaria feliz em se envolver em um programa de tradução como voluntário, pois isso lhe permitiria combinar o fato de ter contribuído para algo que lhe interessa com uma experiência intensiva de aprendizado prático. + +**Mencione a iniciativa em seu produto –** Se seu produto for popular e usado por um grande número de pessoas, destacar seu programa de tradução e chamar os usuários para ação enquanto usam o produto pode ser extremamente eficaz. + +Isso pode ser tão simples quanto adicionar um banner ou pop-up com um CTA ao seu produto para aplicativos e sites. Isso é eficaz porque seu público-alvo é sua comunidade — as pessoas que têm maior probabilidade de se envolver em primeiro lugar. + +**Mídias sociais –** As mídias sociais podem ser uma forma eficaz de divulgar seu programa de tradução e alcançar os membros da sua comunidade, bem como outras pessoas que ainda não são membros da sua comunidade. + +Se você tem um servidor Discord ou um canal do Telegram, é fácil usá-lo para divulgação, comunicação com seus tradutores e reconhecimento de seus colaboradores. + +Plataformas como o X (antigo Twitter) também podem ser úteis para integrar novos membros da comunidade e reconhecer publicamente seus contribuidores. + +A Linux Foundation criou um extenso [Relatório sobre a pesquisa de contribuidores FOSS de 2020](https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf), analisando os contribuidores de código aberto e suas motivações. + +## Conclusão {#conclusion} + +Este documento contém algumas considerações importantes que todo programa de tradução deve saber. Não é de forma alguma um guia exaustivo, embora possa ajudar qualquer pessoa sem experiência no setor de tradução a organizar um programa de tradução para seu projeto. + +Se você estiver procurando por instruções mais detalhadas e análises de diferentes ferramentas, processos e aspectos críticos do gerenciamento de um programa de tradução, alguns dos maiores provedores de serviços de idiomas mantêm blogs e frequentemente publicam artigos sobre diferentes aspectos do processo de localização. Estes são os melhores recursos se você quiser se aprofundar em qualquer um dos tópicos acima e entender como o processo de localização funciona profissionalmente. + +Alguns links relevantes estão incluídos no final de cada seção; no entanto, você pode encontrar muitos outros recursos online. + +Para propostas de cooperação ou informações adicionais, aprendizados e melhores práticas que adquirimos ao manter o Programa de Tradução do ethereum.org, sinta-se à vontade para entrar em contato conosco pelo e-mail translations@ethereum.org. diff --git a/public/content/translations/pt-br/contributing/translation-program/resources/index.md b/public/content/translations/pt-br/contributing/translation-program/resources/index.md index d19b83b2b26..074bc7f78ec 100644 --- a/public/content/translations/pt-br/contributing/translation-program/resources/index.md +++ b/public/content/translations/pt-br/contributing/translation-program/resources/index.md @@ -1,44 +1,49 @@ --- title: Recursos para tradutores lang: pt-br -description: Recursos úteis para tradutores do ethereum.org +description: "Recursos úteis para tradutores do ethereum.org" --- -# Recursos {#resources} +# Documentos {#resources} Você pode encontrar alguns guias e ferramentas úteis para tradutores do ethereum.org, bem como comunidades de tradução e atualizações abaixo. ## Guias {#guides} -- [Guia de estilo de tradução](/contributing/translation-program/translators-guide/) _: instruções e dicas para tradutores do ethereum.org_ -- [Perguntas frequentes sobre tradução](/contributing/translation-program/faq/) _ — perguntas frequentes e respostas sobre o Programa de Tradução do ethereum.org_ -- [Guia do editor online do Crowdin](https://support.crowdin.com/online-editor/) _ — um guia detalhado sobre como usar o editor online do Crowdin e algumas funcionalidades avançadas do Crowdin_ -- [Pacotes de conteúdo](/contributing/translation-program/) _ — quais páginas estão incluídas em cada pacote de conteúdo do ethereum.org_ +- [Guia de estilo de tradução](/contributing/translation-program/translators-guide/) _– instruções e dicas para tradutores do ethereum.org_ +- [Perguntas frequentes sobre tradução](/contributing/translation-program/faq/) _– perguntas e respostas frequentes sobre o Programa de Tradução do ethereum.org_ +- [Guia do editor on-line do Crowdin](https://support.crowdin.com/online-editor/) _– um guia detalhado sobre como usar o editor on-line do Crowdin e alguns dos recursos avançados do Crowdin_ ## Ferramentas {#tools} -- [Linguee](https://www.linguee.com/) _: mecanismo de busca para traduções e dicionário que permite a pesquisa por palavra ou frase_ -- [Proz](https://www.proz.com/search/) _: banco de dados de traduções, dicionários e glossários para termos especializados_ -- [Eurotermbank](https://www.eurotermbank.com/) _: coleções de terminologia europeia em 42 idiomas_ +- [Linguee](https://www.linguee.com/) + _– mecanismo de busca para traduções e dicionário que permite a pesquisa por palavra ou frase_ +- [Proz term search](https://www.proz.com/search/) + _– banco de dados de dicionários de tradução e glossários para termos especializados_ +- [Eurotermbank](https://www.eurotermbank.com/) + _– coleções de terminologia europeia em 42 idiomas_ ## Comunidades {#communities} -- [Grupos de tradução do Discord para idiomas específicos](https://discord.gg/ethereum-org) _: iniciativa que conecta tradutores do ethereum.org a Grupos de Tradução_ -- [Grupo de tradutores de chinês](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _: página de noções para facilitar a coordenação entre tradutores de chinês_ +- [Grupos de tradução do Discord para idiomas específicos](https://discord.gg/ethereum-org) + _– uma iniciativa para conectar os tradutores do ethereum.org aos Grupos de Tradução_ +- [Grupo de tradutores de chinês](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) + _– página do Notion para facilitar a coordenação entre os tradutores de chinês_ ## Últimas atualizações {#latest-updates} -Para se manter atualizado sobre os avanços mais recentes do Programa de Tradução, você pode seguir o [blog da Fundação Ethereum](https://blog.ethereum.org/): +Para se manter atualizado com o progresso mais recente do Programa de Tradução, você pode seguir o [blog da Ethereum Foundation](https://blog.ethereum.org/): -- [Atualização de outubro de 2021](https://blog.ethereum.org/2021/10/04/translation-program-update) -- [Atualização de dezembro de 2020](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20) -- [Atualização de julho de 2020](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone) -- [Lançamento do Programa de Tradução de agosto de 2019](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community) +- [Atualização dos marcos de outubro de 2021](https://blog.ethereum.org/2021/10/04/translation-program-update/) +- [Atualização dos marcos de dezembro de 2020](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/) +- [Atualização dos marcos de julho de 2020](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/) +- [Lançamento do Programa de Tradução de agosto de 2019](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/) -## Horários de trabalho para tradutores {#office-hours} +## Horário de atendimento para tradutores {#office-hours} -Temos horários de plantão para tradutores na segunda quarta-feira de cada mês. Eles são mantidos no canal de voz #horários de plantão no [Discord do ethereum.org](https://discord.gg/ethereum-org), no qual você também pode encontrar os horários exatos e detalhes adicionais. +Temos horários de plantão para tradutores na segunda quarta-feira de cada mês. As sessões acontecem no canal de voz #office-hours no [Discord do ethereum.org](https://discord.gg/ethereum-org), onde você também pode encontrar os horários exatos e detalhes adicionais. -O horário de plantão permite que nossos tradutores façam perguntas sobre o processo de tradução, forneçam comentários sobre o programa, compartilhem suas ideias ou simplesmente conversem com a equipe principal do ethereum.org. Por último, queremos usar essas chamadas para comunicar desenvolvimentos recentes no Programa de Tradução e compartilhar dicas importantes e instruções com nossos colaboradores. +O horário de plantão permite que nossos tradutores façam perguntas sobre o processo de tradução, forneçam comentários sobre o programa, compartilhem suas ideias ou simplesmente conversem com a equipe principal do ethereum.org. +Por último, queremos usar essas chamadas para comunicar desenvolvimentos recentes no Programa de Tradução e compartilhar dicas importantes e instruções com nossos colaboradores. Se você é um tradutor do ethereum.org ou deseja ser, venha participar dessas sessões. diff --git a/public/content/translations/pt-br/contributing/translation-program/translatathon/details/index.md b/public/content/translations/pt-br/contributing/translation-program/translatathon/details/index.md new file mode 100644 index 00000000000..093cd73f0e0 --- /dev/null +++ b/public/content/translations/pt-br/contributing/translation-program/translatathon/details/index.md @@ -0,0 +1,90 @@ +--- +title: Detalhes e regras +lang: pt-br +template: translatathon +--- + +![](./participate.png) + +O Translatathon está aberto e qualquer pessoa pode participar preenchendo o formulário de inscrição e entrando no projeto no Crowdin. + +Os tradutores acumulam pontos ao sugerir traduções para textos não traduzidos em seu idioma no editor do Crowdin durante o período de tradução. + +A pontuação final de cada participante é determinada por sua posição no placar de líderes com base no número de palavras que traduziram durante o período de tradução e quaisquer pontos de bônus que tenham acumulado. + +## Primeiros passos {#getting-started} + +O processo de tradução ocorre no projeto ethereum.org no Crowdin e os tradutores sugerem suas traduções para textos não traduzidos, compostos por quase todo o conteúdo do site ethereum.org. + +As traduções são sugeridas diretamente no editor online, portanto, não há necessidade de baixar ou enviar arquivos ou entregáveis. Cada palavra traduzida é rastreada e contada. + +**1) Junte-se ao projeto** + +- Para começar a contribuir, junte-se ao [projeto ethereum.org no Crowdin](https://crowdin.com/project/ethereum-org) +- Você precisará fazer login ou criar uma conta - tudo o que é necessário é um endereço de e-mail e uma senha + +**2) Selecione seu idioma** + +- Encontre seu idioma na lista de idiomas de destino e abra-o clicando em seu nome ou bandeira +- Se você quiser traduzir para um idioma que não está disponível, entre em contato com a [Equipe do Ethereum.org](https://crowdin.com/profile/ethdotorg) no Crowdin ou envie-nos um e-mail para translations@ethereum.org e adicionaremos idiomas de destino adicionais mediante solicitação + +**3) Abra um arquivo não traduzido** + +- Encontre o primeiro arquivo não traduzido para começar a traduzir. As pastas que contêm os arquivos de origem são baseadas em prioridade, então você deve começar a traduzir a primeira pasta que contém arquivos não traduzidos +- Cada arquivo tem um indicador de progresso que mostra quanto do conteúdo traduzível no arquivo foi traduzido e aprovado... se o progresso da tradução de qualquer arquivo estiver abaixo de 100%, traduza-o + +**4) Traduza os textos não traduzidos** + +- Ao abrir um arquivo para traduzir, certifique-se de que está traduzindo apenas os textos não traduzidos! +- Cada texto tem um indicador de status que mostra se está _Traduzido_, _Não traduzido_ ou _Aprovado_. Se um texto de origem já tiver uma tradução sugerida em seu idioma, não há necessidade de traduzi-lo +- Você também pode filtrar os textos no editor para mostrar _Não traduzidos primeiro_ ou _Apenas não traduzidos_ + +Para um guia detalhado sobre como navegar e usar o editor do Crowdin, recomendamos que todos os participantes do Translatathon leiam nosso guia [Como traduzir](/contributing/translation-program/how-to-translate/). + +Você também pode encontrar algumas dicas e melhores práticas conferindo nosso [guia de estilo de tradução](/contributing/translation-program/translators-guide/). + +**Como funcionam os pontos** + +Todo participante do Translatathon ganhará pontos para sua pontuação final, traduzindo conteúdo no projeto ethereum.org do Crowdin e em outros projetos elegíveis (a lista completa de projetos elegíveis está disponível abaixo). + +A pontuação é simples: **1 palavra traduzida = 1 ponto** + +Para receber sua alocação final de pontos, suas traduções sugeridas precisarão passar pelo processo de avaliação, onde revisores profissionais verificarão as traduções de cada participante para garantir que atendam ao limite mínimo de qualidade e que não tenham sido usadas traduções automáticas ou por IA no processo. + +## Conteúdo do ecossistema {#ecosystem-content} + +Como o programa de tradução do ethereum.org está sempre ativo, o progresso da tradução em alguns idiomas de destino no site é significativamente maior do que em outros. + +Para garantir que todos os participantes do Translatathon tenham uma oportunidade igual de traduzir o máximo de conteúdo que puderem e competir pelos prêmios principais, o conteúdo de origem que faz parte do Translatathon não se limita apenas ao conteúdo do site ethereum.org. + +Os participantes que traduzirem qualquer um dos projetos elegíveis ganharão uma quantidade igual de pontos, 1 palavra traduzida em qualquer projeto = 1 ponto. + +Aqui está uma lista de todos os projetos elegíveis que fazem parte do Translatathon de 2025: + +- [Ethereum.org](https://crowdin.com/project/ethereum-org) + +- [Tutoriais para desenvolvedores do Ethereum.org](https://crowdin.com/project/33388446abbe9d7aa21e42e49bba7f97) + +- [CLI de depósito do EthStaker](https://crowdin.com/project/ethstaker-deposit-cli) + +- [Documentação do Eth Docker](https://crowdin.com/project/eth-docker-docs) + +- [Documentação do Remix IDE](https://crowdin.com/project/remix-translation) + +- [Remix LearnEth](https://crowdin.com/project/remix-learneth) + +- [web3.py](https://crowdin.com/project/web3py) + +## Processo de avaliação {#evaluation-process} + +Todas as traduções estarão sujeitas a QA e feedback, onde linguistas profissionais avaliarão os envios com base na qualidade e precisão. + +Também estaremos aplicando **medidas contra a tradução automática** usando algumas ferramentas que detectam automaticamente traduções automáticas ou de IA. + +Embora a qualidade da tradução não desempenhe um papel crítico na pontuação, quaisquer **participantes que utilizarem traduções automáticas ou de IA** ou que sugerirem traduções de baixa qualidade e imprecisas não serão elegíveis para os prêmios! + +O período de avaliação ocorrerá durante todo o mês de setembro e os resultados serão anunciados na chamada da comunidade do ethereum.org em 25 de setembro. + +Todas as traduções também serão totalmente revisadas antes de serem adicionadas ao site. + + diff --git a/public/content/translations/pt-br/contributing/translation-program/translatathon/index.md b/public/content/translations/pt-br/contributing/translation-program/translatathon/index.md new file mode 100644 index 00000000000..496d7618a69 --- /dev/null +++ b/public/content/translations/pt-br/contributing/translation-program/translatathon/index.md @@ -0,0 +1,100 @@ +--- +title: Translatathon 2025 da ethereum.org +lang: pt-br +template: translatathon +--- + + + + + + + +## Introdução {#introduction} + +Acreditamos que o conteúdo e os recursos de integração da Ethereum devem ser acessíveis a todos, independentemente do idioma que falam. +Para nos aproximarmos desse objetivo, o programa de tradução da ethereum.org é uma iniciativa para traduzir o site para o maior número possível de idiomas. + +Como parte do programa de tradução, estamos organizando a 3ª edição da Translatathon, nosso concurso de tradução que visa incentivar contribuições de tradução em idiomas menos ativos, aumentar o número de idiomas e a quantidade de conteúdo disponível no site, integrar novos contribuidores e recompensar os já existentes. + +Se você é falante nativo de um idioma que não seja o inglês e quer ajudar a tornar o conteúdo da Ethereum mais acessível enquanto compete por prêmios, continue lendo para saber mais! + +[Saiba mais sobre o programa de tradução da ethereum.org](/contributing/translation-program/) + +## Cronograma {#timeline} + +Aqui estão as datas importantes para a Translatathon de 2025: + + + + + +## Participe {#participate} + +![Imagem de comunidade e globo](./participate.png) + + + +

Quem pode participar?

+ Qualquer pessoa com mais de 18 anos, falante nativo de pelo menos um idioma que não seja o inglês e proficiente em inglês. + + +

Preciso ser um tradutor?

+ Não. Você só precisa ser bilíngue e sugerir traduções humanas (o uso de tradução automática é proibido!) da melhor forma possível, não é necessária experiência profissional. + + + + + +

Quanto tempo preciso dedicar?

+ O quanto você quiser. O limite mínimo para ser elegível aos prêmios é de 1.000 palavras traduzidas, o que deve levar cerca de 2 horas para ser concluído, enquanto competir pelos prêmios principais exigirá um maior comprometimento de tempo. + + +

Preciso estar familiarizado com o Ethereum?

+ Não. Embora estar familiarizado com o Ethereum possa ajudar com sua produtividade e qualidade, a Translatathon também é uma experiência de aprendizado, e todos estão convidados a participar e aprender mais sobre o Ethereum enquanto participam. + + + +Para mais detalhes, [consulte os Termos e Condições completos](/contributing/translation-program/translatathon/terms-and-conditions) + +### Instruções passo a passo {#step-by-step-instructions} + + + +## Prêmios {#prizes} + +| Classificação | Valor do prêmio | +| ----------------- | ---------------------- | +| 1º lugar | $4.000 | +| 2º lugar | $2.500 | +| 3º lugar | $1.500 | +| 4º lugar | $1.100 | +| 5º lugar | $1.000 | +| 6º lugar | $600 | +| 7º lugar | $550 | +| 8º lugar | $500 | +| 9º lugar | $450 | +| 10º lugar | $400 | +| 11º - 20º lugar | $240 | +| 21º - 50º lugar | $120 | +| 51º - 100º lugar | $60 | +| 101º - 150º lugar | $40 | +| Restante | $20 | + +Todos os prêmios serão pagos em ETH. + + + + diff --git a/public/content/translations/pt-br/contributing/translation-program/translators-guide/index.md b/public/content/translations/pt-br/contributing/translation-program/translators-guide/index.md index fea6275d313..217e271684a 100644 --- a/public/content/translations/pt-br/contributing/translation-program/translators-guide/index.md +++ b/public/content/translations/pt-br/contributing/translation-program/translators-guide/index.md @@ -1,7 +1,7 @@ --- title: Guia para tradutores lang: pt-br -description: Instruções e dicas para os tradutores do ethereum.org +description: "Instruções e dicas para os tradutores do ethereum.org" --- # Guia de Estilo de Tradução do Ethereum.org {#style-guide} @@ -10,15 +10,15 @@ O Guia de Estilo de Tradução do ethereum.org contém algumas das diretrizes, i Este documento serve como um guia geral e não é específico para nenhum idioma. -Se você tiver alguma dúvida, sugestão ou feedback, envie um e-mail para translations@ethereum.org, uma mensagem para @ethdotorg no Crowdin ou [inscreva-se no Discord](https://discord.gg/ethereum-org), para nos mandar mensagens no canal #translations ou entrar em contato com qualquer um dos membros da equipe. +Se tiver alguma dúvida, sugestão ou feedback, sinta-se à vontade para entrar em contato conosco em translations@ethereum.org, enviar uma mensagem para @ethdotorg no Crowdin, ou [entrar no nosso Discord](https://discord.gg/ethereum-org), onde você pode nos enviar uma mensagem no canal #translations ou contatar qualquer um dos membros da equipe. -## Como usar o Crowdin {#using-crowdin} +## Usando o Crowdin {#using-crowdin} Você pode encontrar instruções básicas sobre como participar do projeto no Crowdin e como usar o editor online do Crowdin na [página do Programa de Tradução](/contributing/translation-program/#how-to-translate). -Se você quiser saber mais sobre o Crowdin e usar alguns dos seus recursos avançados, a [Base de conhecimento do Crowdin](https://support.crowdin.com/online-editor/) contém vários de guias detalhados e resumos de todas as funcionalidades do Crowdin. +Se você quiser aprender mais sobre o Crowdin e usar alguns de seus recursos avançados, a [base de conhecimento do Crowdin](https://support.crowdin.com/online-editor/) contém muitos guias detalhados e visões gerais de todas as funcionalidades do Crowdin. -## Entendendo a essência da mensagem {#capturing-the-essence} +## Capturando a essência da mensagem {#capturing-the-essence} Ao traduzir o conteúdo do ethereum.org, evite traduções literais. @@ -28,7 +28,7 @@ Idiomas diferentes têm diferentes regras gramaticais, convenções e ordem de p Em vez de traduzir o texto de origem palavra por palavra, é recomendado ler toda a frase e adaptá-la para que ela se adapte às convenções do idioma de destino. -## Formal ou informal {#formal-vs-informal} +## Formal vs. informal {#formal-vs-informal} Utilizamos linguagem formal, que é sempre mais educada e apropriada a todos os visitantes. @@ -36,7 +36,7 @@ O uso do estilo formal nos permite evitar soarmos ofensivos ou inapropriados, e A maioria dos idiomas indo-europeus e afro-asiáticos utiliza pronomes pessoais em segunda pessoa específicos de gênero, que fazem a distinção entre masculino e feminino. Quando nos dirigimos ao usuário ou usamos pronomes possessivos, podemos evitar supor o sexo do visitante, uma vez que a maneira formal de tratamento é geralmente aplicável e consistente, independentemente da forma como se identificam. -## Vocabulário simples e claro {#simple-vocabulary} +## Vocabulário e significado simples e claros {#simple-vocabulary} Nosso objetivo é tornar o conteúdo do site compreensível para o maior número de pessoas possível. @@ -50,17 +50,17 @@ Todo o conteúdo deve ser traduzido usando a norma padrão de seu idioma, e não Ao traduzir o conteúdo, você deve garantir que a tradução está correta. -Um engano comum é o de que Ethereum deve ser escrito sempre em caracteres latinos. Essa é uma ideia incorreta, por isso, use a grafia do Ethereum de acordo com seu idioma nativo (por exemplo, 以太坊 em chinês, إيثيريوم em árabe, etc.). +Um engano comum é o de que Ethereum deve ser escrito sempre em caracteres latinos. Isso está, em geral, incorreto. Por favor, use a grafia de Ethereum nativa do seu idioma (p. ex., 以太坊 em chinês, إيثيريوم em árabe, etc.). **O mencionado acima não se aplica a idiomas em que nomes próprios não devem ser traduzidos como regra geral.** -## Traduzindo metadados da página {#translating-metadata} +## Tradução de metadados de página {#translating-metadata} Algumas páginas contêm metadados, como "title", "lang", "description", "sidebar", etc. Ocultamos o conteúdo que os tradutores nunca devem traduzir ao carregar novas páginas no Crowdin, ou seja, todos os metadados visíveis aos tradutores no Crowdin devem ser traduzidos. -Esteja atento ao traduzir quaisquer frases em que o texto de origem seja "en". Isso representa o idioma no qual a página está disponível e deve ser traduzida para o [código de idioma ISO para o seu idioma.](https://www.andiamo.co.uk/resources/iso-language-codes/). Essas frases devem sempre ser traduzidas usando caracteres latinos, e não o script de escrita nativo do idioma de destino. +Esteja atento ao traduzir quaisquer frases em que o texto de origem seja "en". Isso representa o idioma em que a página está disponível e deve ser traduzido para o [código de idioma ISO para o seu idioma](https://www.andiamo.co.uk/resources/iso-language-codes/). Essas frases devem sempre ser traduzidas usando caracteres latinos, e não o script de escrita nativo do idioma de destino. Se você não tem certeza de qual código de idioma usar, você pode verificar a memória de tradução no Crowdin ou encontrar o código de idioma para o seu idioma na URL da página no editor online do Crowdin. @@ -78,15 +78,18 @@ Algumas frases contêm títulos de artigos externos. A maioria das nossas págin Você pode encontrar alguns exemplos de como essas frases aparecem para os tradutores e como identificá-las abaixo (os links para artigos podem ser encontrados na parte inferior destas páginas, na seção "Leitura adicional"): -![Títulos de artigos no sidebar.png](./article-titles-in-sidebar.png) ![Títulos de artigos no editor.png](./article-titles-in-editor.png) +![Títulos do artigo na barra lateral](./article-titles-in-sidebar.png) +![Títulos do artigo no editor](./article-titles-in-editor.png) -## Alertas do Crowdin {#crowdin-warnings} +## Avisos do Crowdin {#crowdin-warnings} -O Crowdin tem um recurso integrado que alerta os tradutores quando eles estão prestes a cometer um erro. O Crowdin avisará automaticamente antes de salvar sua tradução, caso você se esqueça de incluir uma tag da fonte, traduzir elementos que não devem ser traduzidos, adicionar espaços adicionais ou se esqueça da pontuação final, etc. Se você vir um aviso como este, verifique novamente a tradução sugerida. +O Crowdin tem um recurso integrado que alerta os tradutores quando eles estão prestes a cometer um erro. O Crowdin avisará automaticamente antes de salvar sua tradução, caso você se esqueça de incluir uma tag da fonte, traduzir elementos que não devem ser traduzidos, adicionar espaços adicionais ou se esqueça da pontuação final, etc. +Se você vir um aviso como este, verifique novamente a tradução sugerida. **Nunca ignore esses avisos, pois significa que algo está errado, ou está faltando uma parte importante do texto original.** -Um exemplo de alerta do Crowdin quando você se esquece de adicionar uma tag à sua tradução: ![Exemplo de um aviso do Crowdin](./crowdin-warning-example.png) +Um exemplo de um aviso do Crowdin quando você se esquece de adicionar uma tag à sua tradução: +![Exemplo de um aviso do Crowdin](./crowdin-warning-example.png) ## Lidando com tags e trechos de código {#dealing-with-tags} @@ -96,15 +99,18 @@ Grande parte do conteúdo fonte contém tags e variáveis, que são destacadas e Para tornar mais fácil gerenciar tags e copiá-las diretamente da fonte, recomendamos alterar as suas configurações no editor do Crowdin. -1. Abra as configurações ![Como abrir as configurações no editor](./editor-settings.png) +1. Abrir configurações + ![Como abrir as configurações no editor](./editor-settings.png) 2. Role para baixo até a seção "Exibição de tags HTML" -3. Selecione "Ocultar" ![Selecione "Ocultar"](./hide-tags.png) +3. Selecione 'Ocultar' + ![Por favor, selecione 'Ocultar'](./hide-tags.png) 4. Clique em "Salvar" -Ao selecionar esta opção, o texto completo da tag não será mais exibido e será substituído por um número. Ao traduzir, clicar nesta tag copiará automaticamente a tag exata para o campo de tradução. +Ao selecionar esta opção, o texto completo da tag não será mais exibido e será substituído por um número. +Ao traduzir, clicar nesta tag copiará automaticamente a tag exata para o campo de tradução. **Links** @@ -116,7 +122,7 @@ A melhor maneira de lidar com links é copiá-los diretamente da fonte, clicando ![Exemplo de link.png](./example-of-link.png) -Links também aparecem no texto fonte na forma de tags (ou seja, \<0> \). Se você passar o mouse por cima da tag, o editor exibirá seu conteúdo completo. Às vezes, essas tags representarão links. +Os links também aparecem no texto de origem na forma de tags (ou seja, `<0>` ``). Se você passar o mouse por cima da tag, o editor exibirá seu conteúdo completo. Às vezes, essas tags representarão links. É muito importante copiar os links da origem e não mudar a sua ordem. @@ -132,33 +138,33 @@ As tags sempre contêm uma identificação de abertura e fechamento. Geralmente, Exemplo: ``Descentralizado`` -`` — _Tag de abertura que deixa o texto em negrito_ +`` - _Tag de abertura que deixa o texto em negrito_ -Descentralizado — _Texto traduzível_ +Descentralizado - _Texto traduzível_ -`` — _Tag de fechamento_ +`` - _Tag de fechamento_ -![Exemplo de tags.png ''fortes"](./example-of-strong-tags.png) +![Exemplo de tags 'strong'](./example-of-strong-tags.png) Os trechos de código (snippets) devem ser abordados de maneira ligeiramente diferente das outras tags por conterem código que não deveria ser traduzido. Exemplo: ``nonce`` -`` — _Tag de abertura, que contém um trecho de código_ +`` - _Tag de abertura, que contém um trecho de código_ -nonce — _Texto não traduzível_ +nonce - _Texto não traduzível_ -`` — _Tag de fechamento_ +`` - _Tag de fechamento_ ![Exemplo de código snippets.png](./example-of-code-snippets.png) O texto original também contém tags abreviadas, que contêm apenas números, o que significa que sua função não é imediatamente óbvia. Você pode passar o mouse sobre essas tags para ver exatamente para qual função elas servem. -No exemplo abaixo, ao passar o mouse sobre a \<0> tag mostra que ela representa `` e contém um trecho de código. Portanto, o conteúdo dentro dessas tags não deve ser traduzido. +No exemplo abaixo, você pode ver que passar o mouse sobre a tag `<0>` mostra que ela representa `` e contém um trecho de código, portanto, o conteúdo dentro dessas tags não deve ser traduzido. -![Exemplo de tags.png ambíguas](./example-of-ambiguous-tags.png) +![Exemplo de tags.png](./example-of-ambiguous-tags.png ambíguas) -## Formas/abreviaturas curtas vs. completas {#short-vs-full-forms} +## Formas curtas vs. formas completas/abreviações {#short-vs-full-forms} Existem muitas abreviações usadas no site, por exemplo, dapps, NFT, DAO, DeFi, etc. Essas abreviações são comumente usadas em inglês e a maioria dos visitantes do site estão familiarizados com elas. @@ -168,7 +174,7 @@ Não traduza essas abreviaturas, já que a maioria das pessoas não estaria fami Exemplo de como traduzir dapps: -- Aplicativos descentralizados (dapps) → _Formulário completo traduzido (abreviação em inglês entre parênteses)_ +- aplicativos descentralizados (dapps) → _Forma por extenso traduzida (abreviação em inglês entre parênteses)_ ## Termos sem traduções estabelecidas {#terms-without-established-translations} @@ -180,17 +186,17 @@ Ao traduzi-los, sinta-se livre para ser criativo, use traduções descritivas ou **A razão pela qual a maioria dos termos deveria ser traduzida, em vez ser deixada em inglês, é que essa nova terminologia se tornará mais difundida no futuro, à medida que mais pessoas começarem a usar o Ethereum e tecnologias relacionadas. Se queremos envolver mais pessoas de todo o mundo nesse espaço, precisamos fornecer uma terminologia compreensível no maior número possível de idiomas, mesmo que precisemos criá-la nós mesmos.** -## Botões e chamadas para a ação (CTAs) {#buttons-and-ctas} +## Botões e CTAs {#buttons-and-ctas} O site contém vários botões, que devem ser traduzidos de forma diferente dos outros tipos de conteúdo. O texto do botão pode ser identificado visualizando o contexto das telas capturadas, conectadas com a maioria das frases, ou verificando o contexto no editor, que inclui a frase 'botão'. -As traduções dos botões devem ser o mais curtas possível, para evitar incompatibilidade de formatação. Além disso, as traduções dos botões devem ter o verbo no imperativo, ou seja, apresentar um comando ou solicitação. +As traduções dos botões devem ser o mais curtas possível, para evitar incompatibilidade de formatação. Além disso, as traduções de botões devem estar no imperativo, ou seja, apresentar um comando ou solicitação. -![Como encontrar um botão.png](./how-to-find-a-button.png) +![Como encontrar um botão](./how-to-find-a-button.png) -## Traduzindo de forma inclusiva {#translating-for-inclusivity} +## Traduzindo para a inclusividade {#translating-for-inclusivity} Os visitantes do ethereum.org vêm de todo o mundo e de diferentes origens. Por conseguinte, a linguagem utilizada no site deve ser neutra, acolhedora para todos e inclusiva. @@ -200,7 +206,7 @@ Outra forma de inclusão é tentar traduzir para um público global, sem especif Por último, a língua deve ser adequada para todos os públicos e todas as idades. -## Traduções específicas de um idioma {#language-specific-translations} +## Traduções específicas do idioma {#language-specific-translations} Ao traduzir, é importante seguir as regras gramaticais, convenções e formatação usadas em seu idioma, em vez de copiá-las do idioma de origem. O texto de origem segue as regras e convenções gramaticais do inglês, o que não é aplicável a muitos outros idiomas. @@ -208,7 +214,7 @@ Você deve estar ciente das regras do seu idioma e traduzir de acordo com elas. Aqui estão alguns exemplos a que você deve ter atenção: -### Pontuação, formatação {#punctuation-and-formatting} +### Pontuação e formatação {#punctuation-and-formatting} **Regras de uso de maiúsculas e minúsculas** @@ -220,8 +226,8 @@ Aqui estão alguns exemplos a que você deve ter atenção: - As regras da ortografia definem o uso de espaços para cada língua. Como os espaços são usados em toda a parte, essas regras são frequentemente bem específicas e estão entre os elementos mais mal traduzidos. - Algumas diferenças comuns de espaçamento entre inglês e outras línguas: - - Espaço antes das unidades de medida e moedas (por exemplo: USD, EUR, kB, MB) - - Espaço antes dos sinais de graus (ex.: °C, °F) + - Espaço antes de unidades de medida e moedas (p. ex., USD, EUR, kB, MB) + - Espaço antes de sinais de grau (p. ex., °C, ℉) - Espaço antes de algumas marcas de pontuação, especialmente as reticências (…) - Espaço antes e após barras (/) @@ -229,7 +235,7 @@ Aqui estão alguns exemplos a que você deve ter atenção: - Toda língua tem um conjunto diversificado e complexo de regras para escrever listas. Elas podem ser significativamente diferentes do inglês. - Em algumas línguas, a primeira palavra de cada nova linha precisa ser colocada em maiúscula, enquanto em outras, novas linhas devem começar com letras minúsculas. Muitas línguas também têm regras diferentes sobre o uso de maiúsculas em listas, dependendo do tamanho de cada linha. -- O mesmo se aplica à pontuação de itens de linha. A pontuação final em listas pode ser um ponto (**.**), vírgula (**,**), ou ponto e vírgula (**;**), dependendo do idioma. +- O mesmo se aplica à pontuação de itens de linha. A pontuação final em listas pode ser um ponto (.), vírgula (,) ou ponto e vírgula (;), dependendo do idioma. **Aspas** @@ -253,10 +259,10 @@ Aqui estão alguns exemplos a que você deve ter atenção: - A principal diferença entre is idiomas em relação à escrita de números é o separador usado para números decimais e milhares. Para milhares, isso pode ser um ponto, vírgula ou espaço. Da mesma forma, alguns idiomas usam um ponto decimal, enquanto outros usam uma vírgula decimal. - Alguns exemplos de números grandes: - - Inglês — **1,000.50** - - Espanhol — **1.000,50** - - Francês — **1 000,50** -- Outra consideração importante ao traduzir números é o sinal de percentagem. Ele pode ser escrito de diferentes formas: **100%**, **100 %** ou **%100**. + - Inglês – **1,000.50** + - Espanhol – **1.000,50** + - Francês – **1 000,50** +- Outra consideração importante ao traduzir números é o sinal de percentagem. Pode ser escrito de diferentes maneiras: **100%**, **100 %** ou **%100**. - Por fim, números negativos podem ser exibidos de formas diferentes, dependendo do idioma: -100, 100-, (100) ou [100]. **Datas** diff --git a/public/content/translations/pt-br/dao/index.md b/public/content/translations/pt-br/dao/index.md index 4624fef8cba..750bf6f7040 100644 --- a/public/content/translations/pt-br/dao/index.md +++ b/public/content/translations/pt-br/dao/index.md @@ -1,15 +1,16 @@ --- -title: Organizações autônomas descentralizadas (DAOs) -description: Uma visão geral de DAOs no Ethereum +title: "O que é uma DAO?" +metaTitle: "O que é uma DAO? | Organização autônoma descentralizada" +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. +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. +summaryPoint3: "Um local seguro para destinar fundos para uma causa específica." --- ## O que são DAOs? {#what-are-daos} @@ -18,7 +19,7 @@ Uma DAO é uma organização de propriedade coletiva que trabalha para uma miss 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). +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 tudo aconteça de forma transparente [onchain](/glossary/#onchain). ## Por que precisamos de DAOs? {#why-dao} @@ -28,27 +29,27 @@ Isto abre muitas novas oportunidades para a colaboração e coordenação globai ### 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. | +| DAO | Uma organização 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. | +| Toda a atividade é transparente e totalmente pública. | A atividade é tipicamente privada e limitada ao público. | -### Exemplos de DAOs {#dao-examples} +### Exemplos de DAO {#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. +- **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. +A espinha dorsal de uma DAO é seu [contrato inteligente](/glossary/#smart-contract), que define as regras da organização e detém a tesouraria 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. @@ -61,7 +62,7 @@ O Ethereum é a base perfeita para DAOs por várias razões: - 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} +## Governança de DAO {#dao-governance} Há muitas considerações ao gerenciar uma DAO, como o funcionamento da votação e das propostas. @@ -71,27 +72,25 @@ A delegação é como a versão DAO da democracia representativa. Os detentores #### 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} +### Governança de transação automática {#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. +[Nouns](https://nouns.wtf) – Na Nouns DAO, uma transação é executada automaticamente se um quórum de votos for atingido e a maioria votar afirmativamente, 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. +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 geralmente têm suas identidades reveladas (identidades públicas conhecidas pela comunidade). Após uma votação, os signatários da [multisig](/glossary/#multisig) executam a vontade da comunidade. -## Leis DAO {#dao-laws} +## Leis de 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://citizen.citydao.io/) – CityDAO usou a lei DAO do Wyoming para comprar 40 acres de terra perto do Parque Nacional de Yellowstone. +[CityDAO](https://citizen.citydao.io/) – A CityDAO usou a lei de DAO do Wyoming para comprar 40 acres de terra perto do Parque Nacional de Yellowstone. ## Adesão à DAO {#dao-membership} @@ -99,15 +98,15 @@ Existem diferentes modelos para a adesão à DAO. A adesão pode determinar como ### 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. +Geralmente totalmente [permissionless](/glossary/#permissionless), dependendo do token utilizado. Na maioria das vezes, esses tokens de governança podem ser negociados 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. +[MakerDAO](https://makerdao.com) – O token MKR da MakerDAO está amplamente disponível em corretoras descentralizadas, e qualquer pessoa pode comprar poder de voto sobre o futuro do protocolo Maker. -### Adesão compartilhada {#share-based-membership} +### Adesão baseada em cotas {#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. @@ -115,51 +114,53 @@ _Normalmente utilizado em organizações mais coesas e com abordagem humanitári #### 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. +[MolochDAO](http://molochdao.com/) – A MolochDAO é focada no financiamento de 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. +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. Votação em rede não requer permissão e os membros em potencial podem submeter livremente propostas para ingressar a DAO e solicitar o recebimento de reputação e tokens como recompensa por 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._ +_Normalmente usado para o desenvolvimento descentralizado e governança de protocolos e [dapps](/glossary/#dapp), mas também é adequado para um conjunto diversificado de organizações como instituições de caridade, coletivos de trabalhadores, 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. +[DXdao](https://DXdao.eth.limo) – A DXdao foi um coletivo soberano global que construiu e governou protocolos e aplicativos descentralizados desde 2019. Ela utilizou governança baseada em reputação e [consenso holográfico](/glossary/#holographic-consensus) para coordenar e gerenciar fundos, o que significa que ninguém poderia comprar influência sobre seu futuro ou governança. -## Iniciar/participar de uma DAO {#join-start-a-dao} +## Participe ou inicie 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) +- [Lista de DAOs da DAOHaus](https://app.daohaus.club/explore) +- [Lista de DAOs da Tally.xyz](https://www.tally.xyz/explore) +- [Lista de DAOs da DeGov.AI](https://apps.degov.ai/) ### 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) +- [Invoque uma DAO com a DAOHaus](https://app.daohaus.club/summon) +- [Inicie uma Governor DAO com a Tally](https://www.tally.xyz/get-started) +- [Crie uma DAO com a tecnologia da 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) +- [Crie uma DAO com o consenso holográfico da DAOstack](https://alchemy.daostack.io/daos/create) +- [Lance uma DAO com o DeGov Launcher](https://docs.degov.ai/integration/deploy) ## Leitura adicional {#further-reading} -### Artigos sobre DAOs {#dao-articles} +### Artigos sobre DAO {#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/) +- [Como iniciar uma comunidade digital com uma 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) +- [O que é o 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, por Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html) +- [DAOs, DACs, DAs e mais: um guia de terminologia incompleto](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [Blog do 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/) +- [Pode uma DAO 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/decentralized-identity/index.md b/public/content/translations/pt-br/decentralized-identity/index.md index 0ac4e34597e..1bd22d8facb 100644 --- a/public/content/translations/pt-br/decentralized-identity/index.md +++ b/public/content/translations/pt-br/decentralized-identity/index.md @@ -1,19 +1,19 @@ --- title: Identidade descentralizada -description: O que é uma identidade descentralizada e por que isso importa? +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. +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. +No entanto, 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. @@ -39,63 +39,89 @@ Esses exemplos tradicionais de identificadores são emitidos, mantidos e control 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. +2. As soluções de identidade descentralizadas facilitam um método com necessidade mínima de confiança, sem interrupções e que protege a 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. +4. A identidade descentralizada torna os dados de identidade portáteis. Os usuários armazenam atestados e identificadores em uma 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. +5. A identidade descentralizada deve funcionar bem com as tecnologias emergentes de [conhecimento zero](/glossary/#zk-proof) que permitirão que os 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. +6. A identidade descentralizada permite que mecanismos [anti-Sybil](/glossary/#anti-sybil) identifiquem quando um indivíduo humano está fingindo ser vários humanos para explorar ou enviar spam para algum sistema. -## Casos de uso de identidade descentralizadas {#decentralized-identity-use-cases} +## Casos de uso de identidade descentralizada {#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. +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 um [NFT](/glossary/#nft) que concede ao titular acesso a uma comunidade online. -Uma função [Entrar com Ethereum](https://siwe.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. +Uma função [Entrar com Ethereum](https://siwe.xyz/) permitiria que os servidores confirmassem a conta Ethereum do usuário e buscassem o atestado necessário em 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. +A identidade descentralizada permite que as empresas pulem os processos convencionais de [Conheça seu Cliente (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) e autentiquem as identidades dos 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} +### 3. Votação e comunidades online {#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 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 que indivíduos apresentem atestados on-chain pode melhorar a integridade dos processos de votação online. -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. +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 Ethereum Name Service, 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. +Aplicativos de concessão de doaçõ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 doação aumenta quando mais indivíduos votam nela, incentivando os usuários a dividir suas contribuições em 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. + +### 5. Identidade Nacional e Governamental {#national-and-government-id} + +Governos podem usar os princípios da identidade descentralizada para emitir documentos de identidade fundamentais — como identidades nacionais, passaportes ou carteiras de motorista — como credenciais verificáveis no Ethereum, fornecendo fortes garantias criptográficas de autenticidade para reduzir fraudes e falsificações na verificação de identidade online. Os cidadãos podem armazenar esses atestados em sua [carteira](/wallets/) pessoal e usá-los para provar sua identidade, idade ou direito de voto. + +Este modelo permite a divulgação seletiva, especialmente quando combinado com a tecnologia de privacidade de [prova de conhecimento zero (ZKP)](/zero-knowledge-proofs/). Por exemplo, um cidadão poderia provar criptograficamente que tem mais de 18 anos para acessar um serviço com restrição de idade sem revelar sua data de nascimento exata, oferecendo maior privacidade do que uma identidade tradicional. + +#### 💡Estudo de caso: Identidade Digital Nacional (NDI) do Butão no Ethereum {#case-study-bhutan-ndi} + +- Fornece acesso a credenciais de identidade verificáveis para os quase 800.000 cidadãos do Butão +- Migrado da rede Polygon [para a rede principal do Ethereum](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878) em outubro de 2025 +- Mais de [234.000 identidades digitais](https://www.blockchain-council.org/blockchain/bhutan-uses-blockchain-in-digital-id-project/) emitidas até março de 2025 + +O Reino do Butão [migrou seu sistema de Identidade Digital Nacional (NDI)](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878) para o Ethereum em outubro de 2025. Construído sobre os princípios de identidade descentralizada e identidade auto-soberana, o sistema NDI do Butão usa identificadores descentralizados e credenciais verificáveis para emitir credenciais assinadas digitalmente diretamente para a carteira pessoal de um cidadão. Ao ancorar provas criptográficas dessas credenciais no Ethereum, o sistema garante que elas sejam autênticas, à prova de adulteração e possam ser verificadas por qualquer parte sem consultar uma autoridade central. + +A arquitetura do sistema enfatiza a privacidade através do uso da tecnologia de [prova de conhecimento zero (ZKP)](/zero-knowledge-proofs/). Essa implementação de "divulgação seletiva" permite que os cidadãos provem fatos específicos (por exemplo, "Tenho mais de 18 anos" ou "Sou um cidadão") para acessar serviços sem revelar os dados pessoais subjacentes, como o número completo da identidade ou a data de nascimento exata. Isso demonstra um uso poderoso e real do Ethereum para um sistema de identidade nacional seguro, centrado no usuário e que preserva a privacidade. + +#### 💡Estudo de caso: QuarkID da Cidade de Buenos Aires na [Segunda Camada](/layer-2/) do Ethereum, ZKSync Era {#case-study-buenos-aires-quarkid} + +- Emissão de credenciais de identidade descentralizadas para mais de [3,6 milhões de usuários](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo) no lançamento +- O QuarkID é um protocolo de código aberto reconhecido como um [Bem Público Digital](https://www.digitalpublicgoods.net/r/quarkid) sob os Objetivos de Desenvolvimento Sustentável da ONU +- Enfatiza um modelo de "[governo como usuário](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)", no qual a cidade não é dona do protocolo, dando aos cidadãos total propriedade e privacidade dos dados + +Em 2024, o Governo da Cidade de Buenos Aires (GCBA) integrou o QuarkID, a "estrutura de confiança digital" de código aberto construída pela Secretaria de Inovação e Transformação Digital do GCBA, no miBA, o aplicativo oficial da cidade para que os residentes acessem serviços governamentais e documentos oficiais. No lançamento, todos os mais de 3,6 milhões de usuários do miBA receberam identidades digitais descentralizadas que lhes permitem gerenciar e compartilhar documentos e certificados digitais verificáveis on-chain, incluindo credenciais de cidadania, certidões de nascimento, casamento e óbito, registros fiscais, registros de vacinação e muito mais. + +Construído na rede de [Segunda Camada](/layer-2/) do Ethereum, ZKSync Era, o sistema QuarkID usa a tecnologia ZKP para permitir que os cidadãos verifiquem credenciais pessoais ponto a ponto por meio de seus dispositivos móveis — sem expor dados pessoais desnecessários. O programa destaca um modelo de "governo como usuário", no qual o GCBA atua como um usuário do protocolo QuarkID, de código aberto e interoperável, em vez de atuar como um proprietário centralizado. Essa arquitetura habilitada para ZKP fornece um recurso de privacidade chave: nenhum terceiro, nem mesmo o GCBA, pode rastrear como, quando ou por que um cidadão usa suas credenciais. Este programa bem-sucedido oferece aos cidadãos identidade auto-soberana completa e controle sobre seus dados sensíveis, tudo protegido pela rede globalmente distribuída do Ethereum. ## 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. +Atestados são diferentes de identificadores. Um atestado _contém_ identificadores para fazer referência a uma identidade específica e faz uma reivindicaçã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 emitidos, mantidos e controlados por indivíduos. Uma [conta Ethereum](/glossary/#account) é um exemplo de um 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. +Identificadores descentralizados são armazenados em livros-razão distribuídos ([blockchains](/glossary/#blockchain)) ou [redes ponto a ponto](/glossary/#peer-to-peer-network). Isso torna os DIDs [globalmente únicos, solucionáveis com alta disponibilidade e criptograficamente verificáveis](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} +### 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. +A criptografia de chave pública é uma medida de segurança da informação que gera uma [chave pública](/glossary/#public-key) e uma [chave privada](/glossary/#private-key) para uma entidade. A [criptografia](/glossary/#cryptography) de chave pública é usada em redes blockchain para autenticar identidades de usuários e provar 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. +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 e o uso de identidades falsas, usando [assinaturas criptográficas](https://andersbrownworth.com/blockchain/public-private-keys/) para verificar todas as reivindicações. ### 2. Armazenamentos de dados descentralizados {#decentralized-datastores} @@ -103,11 +129,11 @@ Um blockchain serve como um registro de dados verificável: um repositório de i 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} +## Como os identificadores e atestados descentralizados permitem a identidade descentralizada? Como os identificadores e atestados descentralizados viabilizam 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. +No contexto da identidade descentralizada, atestados (também conhecidos como [Credenciais Verificáveis](https://www.w3.org/TR/vc-data-model/)) são reivindicaçõ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. @@ -115,15 +141,15 @@ Os identificadores descentralizados são o motivo de os atestados serem autocont 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} +## Tipos 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} +### Atestados off-chain {#offchain-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. +Uma preocupação com o armazenamento de atestados on-chain é que eles podem conter informações que os indivíduos querem 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. +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, o 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: @@ -133,59 +159,60 @@ Aqui está um cenário hipotético para explicar os atestados off-chain: ### 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. +Nesse 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). No entanto, 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). +Atestados on-chain são mantidos em [contratos inteligentes](/glossary/#smart-contract) na blockchain Ethereum. O contrato inteligente (atuando como um registro) mapeará um atestado para o 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: +Aqui está um exemplo para mostrar como os atestados on-chain deveriam 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. +2. A empresa XYZ pode fazer com que a empresa realize verificações de fundo para emitir atestados onchain 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. +[Tokens Soulbound](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([NFTs não transferí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, concluir um curso online específico ou atingir uma pontuação limite em um jogo) ou participação na comunidade. -## Use identidade descentralizada {#use-decentralized-identity} +## Use a 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._ +- **[Ethereum Name Service (ENS)](https://ens.domains/)** - _Um sistema de nomes descentralizado para identificadores on-chain legíveis por máquina, como endereços de carteira Ethereum, hashes de conteúdo e metadados._ +- **[Entrar com Ethereum (SIWE)](https://siwe.xyz/)** - _Padrão aberto para autenticação com contas Ethereum._ +- **[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 Atestado Ethereum (EAS)](https://attest.org/)** - _Um livro-razão/protocolo descentralizado para fazer atestados on-chain ou off-chain sobre qualquer coisa._ +- **[Prova de Humanidade](https://www.proofofhumanity.id)** - _A Prova de Humanidade (ou PoH) é um sistema de verificação de identidade social construído em Ethereum._ +- **[BrightID](https://www.brightid.org/)** - _Uma rede de identidade social descentralizada e 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)** — _Infraestrutura de identidade descentralizada e de carteira de código aberto que permite que desenvolvedores e organizações aproveitem a identidade auto-soberana e NFTs/SBTs._ +- **[Veramo](https://veramo.io/)** - _Uma estrutura JavaScript que facilita para qualquer pessoa o uso de dados criptograficamente verificáveis em seus aplicativos._ ## 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_ +- [Casos de Uso de Blockchain: Blockchain na Identidade Digital](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_ +- [O que é Ethereum ERC725? [Gerenciamento de Identidade Auto-Soberana na Blockchain](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ +- [Como a Blockchain Poderia Resolver o Problema da Identidade Digital](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_ +- [O Que É Identidade Descentralizada e Por Que Você Deveria 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 +- [Identidade Descentralizada (Sessão Bônus 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 Antonopoulos_ +- [Entrar com Ethereum e Identidade Descentralizada com Ceramic, IDX, React e 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Tutorial do YouTube sobre como construir 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 do podcast Bankless discutindo o BrightID, uma solução de identidade descentralizada para o Ethereum_ +- [A Internet Off-chain: Identidade Descentralizada e Credenciais Verificáveis](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Apresentação de Evin McMullen na EthDenver 2022 +- [Credenciais Verificáveis Explicadas](https://www.youtube.com/watch?v=ce1IdSr-Kig) - Vídeo explicativo do YouTube com demonstração por 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 EthID](https://discord.com/invite/ZUyG3mSXFD) — _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_ +- [Aliança ERC-725 no GitHub](https://github.com/erc725alliance) — _Apoiadores do padrão ERC725 para gerenciamento de identidade na blockchain Ethereum_ +- [Servidor do Discord EthID](https://discord.com/invite/ZUyG3mSXFD) — _Comunidade para entusiastas e desenvolvedores que trabalham com o Entrar com Ethereum e o Ethereum Follow Protocol_ +- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _Uma comunidade de desenvolvedores contribuindo para a construção de uma estrutura para dados verificáveis para aplicativos_ +- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _Uma comunidade de desenvolvedores e construtores que trabalham em casos de uso de identidade descentralizada em vários setores_ diff --git a/public/content/translations/pt-br/defi/index.md b/public/content/translations/pt-br/defi/index.md index 78293634eff..1899e1f6d4e 100644 --- a/public/content/translations/pt-br/defi/index.md +++ b/public/content/translations/pt-br/defi/index.md @@ -1,6 +1,7 @@ --- -title: Finanças descentralizadas (DeFi) -description: Uma visão geral do DeFi na Ethereum +title: "Finanças descentralizadas (DeFi)" +metaTitle: "O que é DeFi? | O benefício das Finanças descentralizadas" +description: "Uma visão geral do DeFi na Ethereum" lang: pt-br template: use-cases emoji: ":money_with_wings:" @@ -8,8 +9,8 @@ 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. +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. @@ -31,44 +32,44 @@ Uma das melhores maneiras de avaliar o potencial das DeFi é compreender os prob - 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. +- O horário de negociação geralmente é limitado 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. | +| 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 + Explorar 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. +Ethereum baseia-se nisso. Como o Bitcoin, as regras não mudam por você, e todos têm acesso. Mas também torna esse dinheiro digital programável, usando [contratos inteligentes](/glossary/#smart-contract), para que você possa ir além de armazenar 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. +Isso soa estranho... "por que eu iria querer 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 + Explorar aplicativos DeFi @@ -77,23 +78,23 @@ Isso soa estranho... "Por que eu gostaria de programar meu dinheiro"? No entanto 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) +- [Enviar dinheiro para o mundo todo](#send-money) +- [Fazer streaming de dinheiro pelo mundo](#stream-money) +- [Acessar moedas estáveis](#stablecoins) +- [Pegar fundos emprestados com garantia](#lending) +- [Pegar fundos emprestados sem garantia](#flash-loans) +- [Começar uma poupança em cripto](#saving) - [Negociar tokens](#swaps) -- [Aumente seu portfólio](#investing) -- [Financie seus projetos](#crowdfunding) -- [Compra de seguros](#insurance) -- [Gerenciamento de portfolio](#aggregators) +- [Aumentar seu portfólio](#investing) +- [Financiar suas ideias](#crowdfunding) +- [Contratar seguro](#insurance) +- [Gerenciar seu portfólio](#aggregators) -### Envie dinheiro ao redor do mundo rapidamente {#send-money} +### Envie dinheiro para o mundo todo 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/). +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 inserir o [nome ENS](/glossary/#ens) do destinatário (como bob.eth) ou o endereço da conta dele na sua carteira e seu pagamento irá diretamente para ele em minutos (geralmente). Para enviar ou receber pagamentos, você precisará de uma [carteira](/wallets/). Ver dapps de pagamento @@ -103,7 +104,7 @@ Como um blockchain, o Ethereum foi concebido para o envio de transações de for 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). +E se você não quiser enviar ou fazer streaming de [ETH](/glossary/#ether) por causa do quanto seu valor pode mudar, existem moedas alternativas no Ethereum: [stablecoins](/glossary/#stablecoin). @@ -114,12 +115,12 @@ A volatilidade das criptomoedas é um problema para muitos produtos financeiros 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 + Mais em moedas estáveis -### Empréstimos {#lending} +### Tomar empréstimos {#lending} Empréstimos de recursos de fornecedores descentralizados se dão de duas formas principais. @@ -132,7 +133,7 @@ Empréstimos de recursos de fornecedores descentralizados se dão de duas formas Há diversas vantagens em usar um financiador descentralizado... -#### Empréstimos com privacidade {#borrowing-privacy} +#### Tomar 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. @@ -142,13 +143,13 @@ Isso permite que você tome empréstimo de dinheiro sem checagem de crédito ou #### 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. +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. Isso torna os empréstimos mais acessíveis e melhora as taxas de juros. -#### Eficiência tributária {#tax-efficiencies} +#### Eficiência fiscal {#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-relâmpago {#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. @@ -172,27 +173,27 @@ Se o estoque da exchange B cair de repente e o usuário não conseguir comprar o 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 + Mais sobre empréstimos-relâmpago -### Comece a poupar com criptomoedas {#saving} +### Comece a poupar com cripto {#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ê empresta seus 100 Dai, uma [stablecoin](/stablecoins/), para um produto como o 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! +- 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 mostrará algo como 100.1234 após alguns dias ou mesmo 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 perdas {#no-loss-lotteries} Loterias sem perda como a PoolTogether são uma divertida e inovadora maneira de economizar dinheiro. @@ -210,19 +211,19 @@ O dinheiro acumulado para premiação é gerado por todos os juros gerados pelo -### Negociar tokens {#swaps} +### Trocar 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 + Ver corretoras de tokens -### Negociações avançadas {#trading} +### Trading avançado {#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. @@ -234,7 +235,7 @@ Quando você usa uma exchange centralizada, tem que depositar seus ativos antes -### Aumente seu portfolio {#investing} +### Aumente seu portfólio {#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. @@ -255,7 +256,7 @@ Ethereum é uma plataforma ideal para financiamento colaborativo: - 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 + Ver dapps de financiamento coletivo #### Financiamento quadrático {#quadratic-funding} @@ -277,11 +278,11 @@ Isso significa que o Projeto A com suas 100 doações de 1 dólar poderia acabar -### Seguros {#insurance} +### Seguro {#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. +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 disso é a cobertura de safra da Etherisc, que visa [proteger pequenos agricultores no 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 @@ -289,12 +290,12 @@ Os produtos Ethereum, como qualquer software, estão propensos a bugs e exploits -### Agregadores e gerenciadores de portfolio {#aggregators} +### Agregadores e gerenciadores de portfólio {#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 + Ver dapps de portfólio @@ -323,41 +324,42 @@ O Ethereum é a base perfeita para DeFi por várias razões: 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](/what-is-ether/) 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](/apps/): os produtos que usamos para gerenciar e acessar os protocolos. +2. Os ativos – [ETH](/what-is-ether/) e os outros tokens (moedas). +3. Os protocolos – [contratos inteligentes](/glossary/#smart-contract) que fornecem a funcionalidade, por exemplo, um serviço que permite o empréstimo descentralizado de ativos. +4. [Os aplicativos](/apps/) – 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). +Observação: grande parte do DeFi usa o [padrão ERC-20](/glossary/#erc-20). Aplicações em DeFi utilizam um wrapper para ETH chamado Wrapped Ether (WETH). [Saiba mais sobre ether encapsulado](/wrapped-eth). -## Criar Defi {#build-defi} +## Desenvolva com 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 + Mais sobre a criação de dapps ## Leitura adicional {#further-reading} -### Dados DeFi {#defi-data} +### Dados de 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_ +- [Um guia para iniciantes sobre DeFi](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6 de janeiro de 2020_ +- [Diretrizes de Avaliação de Risco DeFi da EEA](https://entethalliance.org/specs/defi-risks/) – Uma visão geral apoiada pela indústria sobre como identificar e avaliar os principais riscos em protocolos DeFi. ### 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._ +- [Finematics - educação sobre finanças descentralizadas](https://finematics.com/) – _Vídeos sobre DeFi_ +- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _Noções básicas de DeFi: tudo o que você precisa saber para começar neste espaço ocasionalmente 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) +- [Servidor do Discord do DeFi Llama](https://discord.defillama.com/) +- [Servidor do Discord do DeFi Pulse](https://discord.gg/Gx4TCTk) diff --git a/public/content/translations/pt-br/desci/index.md b/public/content/translations/pt-br/desci/index.md index 9285d777bf7..6278591ca68 100644 --- a/public/content/translations/pt-br/desci/index.md +++ b/public/content/translations/pt-br/desci/index.md @@ -1,24 +1,24 @@ --- -title: Ciência descentralizada (DeSci) -description: Uma visão geral da ciência descentralizada no Ethereum +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. +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 ciência descentralizada (DeSci) é um movimento que visa construir uma infraestrutura pública para financiar, criar, revisar, creditar, armazenar e disseminar o conhecimento científico de forma justa e equitativa usando a pilha da [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. +A ciência descentralizada permite fontes de financiamento mais diversas (de [DAOs](/glossary/#dao), [doações quadráticas](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) a crowdfunding e muito mais), dados e métodos mais acessíveis e, ao mesmo tempo, fornece incentivos para a reprodutibilidade. ### Juan Benet — O Movimento DeSci @@ -28,16 +28,16 @@ A ciência descentralizada possibilita mais diversas fontes de financiamento (de 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. | +| **Ciência descentralizada** | **Ciência tradicional** | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| A distribuição dos fundos é **determinada pelo público** usando mecanismos como doações quadráticas ou DAOs. | Grupos pequenos, fechados e **centralizados** controlam a distribuição dos fundos. | +| Você colabora com colegas de **todo o mundo** em equipes dinâmicas. | Organizações de financiamento e instituições de origem **limitam** suas colaborações. | +| As decisões de financiamento são tomadas online e de forma **transparente**. São explorados novos mecanismos de financiamento. | As decisões de financiamento são tomadas com um longo tempo de resposta e **transparência limitada**. Existem poucos mecanismos de financiamento. | +| O compartilhamento de serviços de laboratório é facilitado e mais transparente com o uso da tecnologia [Web3](/glossary/#web3). | O compartilhamento de recursos de laboratório é muitas vezes **lento e opaco**. | +| **Novos modelos de publicação** podem ser desenvolvidos que usam primitivos da Web3 para confiança, transparência e acesso universal. | Você publica por meio de caminhos estabelecidos, frequentemente reconhecidos como **ineficientes, tendenciosos e exploratórios**. | +| Você pode **ganhar tokens e reputação pela revisão por pares** do trabalho. | Seu trabalho de **revisão por pares não é remunerado**, beneficiando editoras com fins lucrativos. | +| **Você é dono da propriedade intelectual (PI)** que gera e a distribui conforme termos transparentes. | **Sua instituição de origem detém a PI** que você gera. O acesso ao IP não é transparente. | +| **Compartilhamento de toda a pesquisa**, incluindo os dados de esforços malsucedidos, por ter todas as etapas onchain. | **Viés de publicação** significa que os pesquisadores são mais propensos a compartilhar experimentos que tiveram resultados bem-sucedidos. | ## Ethereum e DeSci {#ethereum-and-desci} @@ -49,9 +49,9 @@ A DeSci está criando um conjunto de ferramentas científicas para levar o meio ### 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. +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 geralmente chegam a cinco dígitos (em USD), minando todo o conceito de conhecimento científico como um [bem público](/glossary/#public-goods), ao mesmo tempo que geram lucros enormes 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. +Existem plataformas gratuitas e de acesso aberto na forma de servidores de pré-publicaçã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 em nível de artigo, o que significa que geralmente são 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} @@ -60,29 +60,30 @@ Reprodutibilidade e replicabilidade são os fundamentos da descoberta científic - 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. +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. A Web3 oferece a capacidade de criar [atestados](/glossary/#attestation) para cada componente de análise: os dados brutos, o mecanismo computacional e o resultado da aplicação. 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. +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 a, por vezes, **anos de espera** entre a candidatura e o recebimento de uma bolsa, este modelo é conhecido por ser altamente **vulnerável aos vieses, interesses próprios e políticas** do painel de revisã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. +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 de 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 da Web3 que podem revolucionar o financiamento da ciência. -### Propriedade e desenvolvimento de IP {#ip-ownership} +### Propriedade e desenvolvimento de PI {#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). +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 científicos ou artigos) é 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. +[IP-NFTs](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) também podem funcionar como uma chave para um repositório de dados descentralizado dos experimentos de pesquisa que estão sendo realizados e se conectar à financeirização de NFTs e [DeFi](/glossary/#defi) (desde o fracionamento até pools de empréstimo e avaliação de valor). Isso também permite que entidades nativamente onchain, como as DAOs, tal como a [VitaDAO](https://www.vitadao.com/), conduzam pesquisas diretamente onchain. +O advento dos [tokens "soulbound"](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) não transferíveis também pode desempenhar um papel importante na DeSci, permitindo que indivíduos comprovem sua experiência e credenciais vinculadas ao seu endereço Ethereum. -### Armazenamento de dados, acesso e arquitetura {#data-storage} +### Armazenamento, acesso e arquitetura de dados {#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. +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 confidencial como o [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 de acesso alternativos à replicação de dados brutos, criando Ambientes de Pesquisa Confiáveis para os dados mais sensíveis. Os 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 a privacidade e colaboração de dados, criando um ecossistema onde os pesquisadores podem trabalhar com segurança com dados no local usando ambientes padronizados para o 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. @@ -90,47 +91,49 @@ As soluções flexíveis de dados Web3 suportam os cenários acima e fornecem a 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/) +- [DeSci.Global: calendário global de eventos e encontros](https://desci.global) +- [Blockchain for Science Telegram](https://t.me/BlockchainForScience) +- [Molecule: Financie e obtenha financiamento para seus projetos de pesquisa](https://www.molecule.xyz/) +- [VitaDAO: 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/) -- [dClimate API: consulte dados climáticos coletados por uma comunidade descentralizada](https://www.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/) +- [API dClimate: consulte dados climáticos coletados por uma comunidade descentralizada](https://www.dclimate.net/) +- [DeSci Foundation: construtor de ferramentas de publicação da DeSci](https://descifoundation.org/) +- [DeSci.World: um balcão único para os usuários visualizarem e se engajarem com a ciência descentralizada](https://desci.world) +- [OceanDAO: financiamento governado por DAO para ciência relacionada a dados](https://oceanprotocol.com/) +- [Opscientia: fluxos de trabalho de ciência descentralizada 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 impulsiona 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/) +- [IdeaMarkets: viabilizando a 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) +- [Cerebrum DAO: buscando e nutrindo soluções para avançar a saúde do cérebro e prevenir a neurodegeneração](https://www.cerebrumdao.com/) +- [CryoDAO: financiando pesquisas arrojadas na área de criopreservação](https://www.cryodao.org) +- [Elata: opine sobre o futuro da medicina psiquiátrica](https://www.elata.bio/) -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! +Agradecemos sugestões de novos projetos para listar — consulte 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/desci) -- [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) +- [Wiki da DeSci por Jocelynn Pearl e Ultrarare](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#) +- [Um guia para a biotecnologia descentralizada por Jocelynn Pearl para a a16z future](https://future.a16z.com/a-guide-to-decentralized-biotech/) +- [A defesa da DeSci](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/) +- [Guia da DeSci](https://future.com/what-is-decentralized-science-aka-desci/) +- [Recursos sobre ciência descentralizada](https://www.vincentweisser.com/desci) +- [IP-NFTs de biofarma 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 necessidade de confiança por Jon Starr](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 bens comuns epistêmicos](https://zenodo.org/record/6320575) +- [DeSci: O Futuro da Pesquisa por Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) +- [Financiamento da ciência (Epílogo: DeSci e novas primitivas cripto) por Nadia](https://nadia.xyz/science-funding) +- [A descentralização está revolucionando o desenvolvimento de medicamentos](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) - [O que é DeSci – Ciência Descentralizada?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) ### 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) -- [Paige Donner – Ferramentas para Ciência Aberta com Web3 & Blockchain](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) +- [O que é Ciência Descentralizada?](https://www.youtube.com/watch?v=-DeMklVWNdA) +- [Conversa entre Vitalik Buterin e o cientista Aubrey de Grey sobre a interseção entre pesquisa de longevidade e cripto](https://www.youtube.com/watch?v=x9TSJK1widA) +- [A publicação científica está em pane. A Web3 pode consertar isso?](https://www.youtube.com/watch?v=WkvzYgCvWj8) +- [Juan Benet – DeSci, laboratórios independentes e ciência de dados em larga 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) +- [Paige Donner – Ferramentas para a ciência aberta com a Web3 e a Blockchain](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) diff --git a/public/content/translations/pt-br/developers/docs/accounts/index.md b/public/content/translations/pt-br/developers/docs/accounts/index.md index 1456285c484..40061fac959 100644 --- a/public/content/translations/pt-br/developers/docs/accounts/index.md +++ b/public/content/translations/pt-br/developers/docs/accounts/index.md @@ -1,10 +1,10 @@ --- 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. +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. +Uma conta Ethereum é uma entidade com um saldo de ether (ETH) que pode enviar mensagens na Ethereum. As contas podem ser controladas pelo usuário ou implementadas como contratos inteligentes. ## Pré-requisitos {#prerequisites} @@ -34,20 +34,21 @@ Ambos os tipos de conta têm capacidade para: **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 +- Pode enviar mensagens apenas em resposta ao recebimento de uma 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} +## Análise de uma conta {#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. +- `balance` – O número de wei detido por este endereço. Wei é uma denominação de ETH e existem 1e + 18 Wei por ETH. +- `codeHash` – Este hash refere-se 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 [Trie Merkle Patricia](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) que codifica o conteúdo de armazenamento da conta (um mapeamento entre valores inteiros de 256 bits), codificado na trie como um mapeamento do hash Keccak de 256 bits das chaves de inteiros de 256 bits para os valores inteiros de 256 bits codificados em RLP. Esta árvore codifica o hash do conteúdo de armazenamento desta conta e está vazia por padrão. -![Um diagrama mostrando a criação de uma conta](./accounts.png) _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Um diagrama mostrando a composição de uma conta](./accounts.png) +_Diagrama adaptado de [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ ## Contas de propriedade externa e pares de chaves {#externally-owned-accounts-and-key-pairs} @@ -67,32 +68,32 @@ 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. +A chave pública é gerada a partir da chave privada usando o [Algoritmo de Assinatura Digital de Curva Elíptica](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm). Você obtém um endereço público para sua conta pegando os últimos 20 bytes do hash Keccak-256 da chave pública e adicionando `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`). +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. +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 gerenciamento de contas e assinatura que vem junto com o cliente Ethereum, [Geth](https://geth.ethereum.org). O comando `clef newaccount` cria um novo par de chaves e o salva em um repositório de chaves criptografado. ``` > clef newaccount --keystore -Please enter a password for the new account to be created: +Insira uma senha para a nova conta a ser criada: > ------------ -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 +INFO [10-28|16:19:09.156] Sua nova chave foi gerada address=0x5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] Faça o backup do seu arquivo de chave path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] Lembre-se da sua senha! +Conta gerada 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**. +É possível derivar novas chaves públicas da sua chave privada, mas não é possível derivar uma chave privada de chaves públicas. É vital 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. @@ -106,13 +107,13 @@ Exemplo: 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} +## Chaves do validador {#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/). +[Mais sobre as chaves do validador](/developers/docs/consensus-mechanisms/pos/keys/). -## Observação sobre carteiras {#a-note-on-wallets} +## Uma 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. @@ -126,9 +127,9 @@ Assista a Austin mostrando passo a passo as funções de hash e os pares de chav ## Leitura adicional {#further-reading} -- [Entendendo Contas Ethereum](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan +- [Entendendo as 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} diff --git a/public/content/translations/pt-br/developers/docs/apis/backend/index.md b/public/content/translations/pt-br/developers/docs/apis/backend/index.md index b5459e72699..b75a9832bc0 100644 --- a/public/content/translations/pt-br/developers/docs/apis/backend/index.md +++ b/public/content/translations/pt-br/developers/docs/apis/backend/index.md @@ -1,64 +1,69 @@ --- 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. +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 que um aplicativo de software interaja com a blockchain Ethereum (ou seja, para ler dados da blockchain e/ou enviar transações para a rede), ele deve se conectar a um nó Ethereum. -Para este propósito, todos os clientes do Ethereum implementam a especificação [JSON-RPC](/developers/docs/apis/json-rpc/), para que haja um conjunto uniforme de [métodos](/developers/docs/apis/json-rpc/#json-rpc-methods) nos quais os aplicativos podem confiar. +Para este 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) 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/). +Pode ser útil entender a [pilha Ethereum](/developers/docs/ethereum-stack/) e os [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. +Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um nó Ethereum. Elas também fornecem funções utilitárias (p. ex., converter ETH para Gwei), de modo que, como desenvolvedor, você pode gastar menos tempo lidando com as complexidades dos clientes Ethereum e mais tempo focado na funcionalidade exclusiva do seu aplicativo. ## Bibliotecas disponíveis {#available-libraries} -### Serviços de nós e infraestrutura {#infrastructure-and-node-services} +### Infraestrutura e serviços de nó {#infrastructure-and-node-services} **Alchemy -** **_Plataforma de Desenvolvimento Ethereum._** - [alchemy.com](https://www.alchemy.com/) -- [Documentação](https://docs.alchemy.com/) +- [Documentação](https://www.alchemy.com/docs/) - [GitHub](https://github.com/alchemyplatform) - [Discord](https://discord.com/invite/alchemyplatform) -**All That Node - ** **_Nós-como-um-serviço._** +**All That Node -** **_Nó como serviço._** - [All That 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._** +**Blast da Bware Labs -** **_APIs descentralizadas para a Mainnet e Testnets da Ethereum._** - [blastapi.io](https://blastapi.io/) - [Documentação](https://docs.blastapi.io) -- [Discord](https://discord.gg/bwarelabs) +- [Discord](https://discord.gg/SaRqmRUjjQ) -**BlockPi -** **_Fornece serviços RPC mais eficientes e mais rápidos_** +**BlockPi -** **_Fornece serviços RPC mais eficientes e 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 Ethereum Gateway.** - [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_** +**Blockscout - Explorador de Blocos de Código Aberto** + +- [Documentação](https://docs.blockscout.com/) + +**GetBlock-** **_Blockchain como serviço para desenvolvimento Web3_** - [GetBlock.io](https://getblock.io/) -- [Documentação](https://getblock.io/docs/) +- [Documentação](https://docs.getblock.io/) **Infura -** **_A API da Ethereum como serviço._** @@ -74,20 +79,21 @@ Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um **NOWNodes - _Nós Completos e Exploradores de Blocos._** - [NOWNodes.io](https://nownodes.io/) +- [Documentação](https://nownodes.gitbook.io/documentation) -**QuickNode -** **_Infraestrutura Blockchain como Serviço._** +**QuickNode -** **_Infraestrutura de 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 -** **_APIs do Ethereum e Ethereum Classic como serviço, desenvolvidas com 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 -** **_Nós Ethereum orientados à velocidade como API JSON-RPC/WebSockets._** - [zmok.io](https://zmok.io/) - [GitHub](https://github.com/zmok-io) @@ -108,13 +114,13 @@ Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um - [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._** +**Ferramentas Python -** **_Variedade de bibliotecas para interação com o Ethereum via Python._** -- [py.ethereum.org](https://snakecharmers.ethereum.org) -- [web3.py GitHub](https://github.com/ethereum/web3.py) -- [web3.py Chat](https://gitter.im/ethereum/web3.py) +- [py.ethereum.org](https://snakecharmers.ethereum.org/) +- [GitHub do web3.py](https://github.com/ethereum/web3.py) +- [Bate-papo do web3.py](https://gitter.im/ethereum/web3.py) -**QuikNode -** **_A plataforma definitiva de desenvolvimento de blockchains_** +**Tatum -** **_A plataforma definitiva de desenvolvimento de blockchain._** - [Tatum](https://tatum.io/) - [GitHub](https://github.com/tatumio/) @@ -127,36 +133,36 @@ Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um - [Documentação](https://docs.web3j.io/) - [Gitter](https://gitter.im/web3j/web3j) -### Serviços blockchain {#blockchain-services} +### Serviços de blockchain {#blockchain-services} -**BlockCypher -** **_APIs Web Ethereum._** +**BlockCypher -** **_APIs web do 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 -** **_Infraestrutura de dados Web3 tudo-em-um para o 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 -** **_Nós Ethereum elásticos 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) +- [Documentação](https://docs.chainstack.com/) +- [Referência da API do Ethereum](https://docs.chainstack.com/reference/ethereum-getting-started) -**Nó da Nuvem da Coinbase -** **_API de infraestrutura Blockchain._** +**Coinbase Cloud Node -** **_API de infraestrutura de blockchain._** -- [Nó da Nuvem da Coinbase](https://www.coinbase.com/cloud) -- [Documentação](https://docs.cloud.coinbase.com/) +- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform) +- [Documentação](https://docs.cdp.coinbase.com/) -**DataHub por Figment -** **_Serviços de API Web3 API com rede principal Ethereum e rede de testes._** +**DataHub da Figment -** **_Serviços de API Web3 com a Mainnet e as testnets do Ethereum._** - [DataHub](https://www.figment.io/) - [Documentação](https://docs.figment.io/) -**Moralis -** **_Provedor de API para EVM para uso corporativo._** +**Moralis -** **_Provedor de API EVM de nível empresarial._** - [moralis.io](https://moralis.io) - [Documentação](https://docs.moralis.io/) @@ -164,20 +170,20 @@ Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um - [Discord](https://moralis.io/joindiscord/) - [Fórum](https://forum.moralis.io/) -**NFTPort -** **_Dados Ethereum e APIs Mint._** +**NFTPort -** **_Dados do Ethereum e APIs de cunhagem._** - [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._** +**Tokenview -** **_A plataforma geral de APIs de blockchain para múltiplas criptos._** - [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 -** **_Fornece acesso simples e confiável via API à blockchain do Ethereum._** - [Watchdata](https://watchdata.io/) - [Documentação](https://docs.watchdata.io/) @@ -190,17 +196,16 @@ Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um - [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!_ +_Conhece um recurso da comunidade que o ajudou? Edite essa página e adicione-o!_ ## Tópicos relacionados {#related-topics} - [Nós e clientes](/developers/docs/nodes-and-clients/) -- [Estruturas de desenvolvimento](/developers/docs/frameworks/) +- [Frameworks 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._ +- [Configurar o Web3js para usar a blockchain Ethereum em JavaScript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Instruções para configurar o web3.js em seu projeto._ +- [Chamando um contrato inteligente a partir do JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Usando o token DAI, veja como chamar funções de contratos usando JavaScript._ diff --git a/public/content/translations/pt-br/developers/docs/apis/javascript/index.md b/public/content/translations/pt-br/developers/docs/apis/javascript/index.md index fa1dba1ced9..1ec1696ddac 100644 --- a/public/content/translations/pt-br/developers/docs/apis/javascript/index.md +++ b/public/content/translations/pt-br/developers/docs/apis/javascript/index.md @@ -1,31 +1,33 @@ --- 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. +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 que um aplicativo da web interaja 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ó Ethereum. -Para esse propósito, cada cliente Ethereum implementa a especificação [JSON-RPC](/developers/docs/apis/json-rpc/), para que haja um conjunto uniforme de [métodos](/developers/docs/apis/json-rpc/#json-rpc-methods) com os quais os aplicativos podem conta. +Para este propósito, cada cliente Ethereum implementa a especificação [JSON-RPC](/developers/docs/apis/json-rpc/), portanto, há um conjunto uniforme de [métodos](/developers/docs/apis/json-rpc/#json-rpc-methods) nos quais os aplicativos podem confiar. 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/). +Observe que, desde [A Fusão](/roadmap/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 (p. ex., seu nó está sendo executado em uma instância da AWS), atualize os endereços IP no tutorial. Para mais informações, consulte nossa página sobre [como executar 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/). +Além de entender JavaScript, pode ser útil entender a [pilha Ethereum](/developers/docs/ethereum-stack/) e os [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. +Essas bibliotecas abstraem muito da complexidade de interagir diretamente com um nó Ethereum. Elas também fornecem funções utilitárias (p. ex., converter ETH para Gwei), de modo que, como desenvolvedor, você pode gastar menos tempo lidando com as complexidades dos clientes Ethereum e mais tempo focado na funcionalidade exclusiva do seu aplicativo. ## Recursos da biblioteca {#library-features} -### Conectar aos nós da Ethereum {#connect-to-ethereum-nodes} +### Conectar-se aos nós do 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. +> **Aviso:** O Web3.js foi arquivado em 4 de março de 2025. [Leia o anúncio](https://blog.chainsafe.io/web3-js-sunset/). Considere o uso de bibliotecas alternativas como [ethers.js](https://ethers.org) ou [viem](https://viem.sh) para novos projetos. + **Exemplo de Ethers** ```js @@ -33,7 +35,7 @@ Usando provedores, essas bibliotecas permitem que você se conecte à Ethereum e // 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 +// O plug-in 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() @@ -70,29 +72,29 @@ Uma vez configurado, você poderá consultar a blockchain para: - id da rede - e mais... -### Funcionalidade de carteira {#wallet-functionality} +### Funcionalidade da 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... +// Crie uma instância de carteira a partir de uma mnemônica... mnemonic = "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol" walletMnemonic = Wallet.fromPhrase(mnemonic) -// ...ou a partir de uma chave privada +// ...ou de uma chave privada walletPrivateKey = new Wallet(walletMnemonic.privateKey) walletMnemonic.address === walletPrivateKey.address // true -// O endereço como uma Promise conforme a API Signer +// O endereço como uma Promise pela API do Signer walletMnemonic.getAddress() // { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' } -// O endereço de uma Wallet também está disponível de forma síncrona +// Um endereço de Carteira também está disponível de forma síncrona walletMnemonic.address // '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' @@ -102,7 +104,7 @@ walletMnemonic.privateKey walletMnemonic.publicKey // '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64' -// A frase mnemônica da wallet +// A mnemônica da carteira walletMnemonic.mnemonic // { // locale: 'en', @@ -110,8 +112,8 @@ walletMnemonic.mnemonic // 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) +// Observação: uma carteira criada com uma chave privada não +// tem uma mnemônica (a derivação o impede) walletPrivateKey.mnemonic // null @@ -128,8 +130,8 @@ tx = { walletMnemonic.signTransaction(tx) // { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' } -// O método connect retorna uma nova instância da -// Wallet conectada a um provedor +// O método de conexão retorna uma nova instância da +// Carteira conectada a um provedor wallet = walletMnemonic.connect(provider) // Consultando a rede @@ -151,7 +153,7 @@ Uma vez configurado você será capaz de: - assinar transações - e mais... -### Interaja com funções de contrato inteligentes {#interact-with-smart-contract-functions} +### Interagir com funções de contrato inteligente {#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. @@ -164,7 +166,7 @@ contract Test { uint a; address d = 0x12345678901234567890123456789012; - function Test(uint testInt) { a = testInt;} + constructor(uint testInt) { a = testInt;} event Event(uint indexed b, bytes32 c); @@ -217,7 +219,7 @@ Isso significa que você pode: 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ê. +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 para você. E em ethers fica assim: @@ -232,59 +234,56 @@ 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/) +- [Funções utilitárias do Web3js](https://docs.web3js.org/api/web3-utils) +- [Funções utilitárias do Ethers](https://docs.ethers.org/v6/api/utils/) ## Bibliotecas disponíveis {#available-libraries} -**Web3.js -** **_API para Ethereum em JavaScript._** +**Web3.js -** **_API JavaScript do Ethereum._** -- [Documentação](https://docs.web3js.org/) -- [GitHub](https://github.com/ethereum/web3.js/) +- [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._** +**Ethers.js -** **_Implementação completa da carteira Ethereum e utilitários em JavaScript e TypeScript._** -- [Documentação](https://docs.ethers.io/) -- [GitHub](https://github.com/ethers-io/ethers.js/) +- [Página inicial do Ethers.js](https://ethers.org/) +- [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 -** **_Um protocolo para indexar dados do Ethereum e IPFS e consultá-los usando GraphQL._** -- [The Graph](https://thegraph.com/) -- [Graph Explorer](https://thegraph.com/explorer/) -- [Documentação](https://thegraph.com/docs/) -- [GitHub](https://github.com/graphprotocol/) +- [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) - -**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 SDK -** **_Wrapper em torno do Ethers.js com APIs aprimoradas._** -**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) +- [Documentação](https://www.alchemy.com/docs) +- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js) **viem -** **_Interface TypeScript para Ethereum._** - [Documentação](https://viem.sh) - [GitHub](https://github.com/wagmi-dev/viem) +**Drift -** **_Metabiblioteca TypeScript com cache, ganchos e simulações de teste integrados._** + +- [Documentação](https://ryangoree.github.io/drift/) +- [GitHub](https://github.com/ryangoree/drift/) + ## Leitura adicional {#further-reading} -_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} -- [ Nós e clientes](/developers/docs/nodes-and-clients/) -- [Estruturas de desenvolvimento](/developers/docs/frameworks/) +- [Nós e clientes](/developers/docs/nodes-and-clients/) +- [Frameworks 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._ +- [Configurar o Web3js para usar a blockchain Ethereum em JavaScript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Instruções para configurar o web3.js em seu projeto._ +- [Chamando um contrato inteligente a partir do JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Usando o token DAI, veja como chamar funções de contratos 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/developers/docs/apis/json-rpc/index.md b/public/content/translations/pt-br/developers/docs/apis/json-rpc/index.md index 8c29fca6938..2660ec71713 100644 --- a/public/content/translations/pt-br/developers/docs/apis/json-rpc/index.md +++ b/public/content/translations/pt-br/developers/docs/apis/json-rpc/index.md @@ -6,27 +6,27 @@ 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. +Para essa finalidade, todo [cliente Ethereum](/developers/docs/nodes-and-clients/#execution-clients) implementa uma [especificação JSON-RPC](https://github.com/ethereum/execution-apis), de modo que haja um conjunto uniforme de métodos nos quais os aplicativos podem confiar, independentemente da implementação específica do nó ou 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} +## Implementações de 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. +Cada cliente Ethereum pode utilizar linguagens de programação diferentes ao implementar a especificação JSON-RPC. Consulte a [documentação do cliente](/developers/docs/nodes-and-clients/#execution-clients) individual 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} +## 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. +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. Existem muitas bibliotecas de [JavaScript](/developers/docs/apis/javascript/#available-libraries) e [API de backend](/developers/docs/apis/backend/#available-libraries) que fornecem wrappers sobre a 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/#/). +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ó. Esta API está documentada na [página da Beacon API](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). +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. Isso é chamado de 'Engine API' e as 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. +[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/) e inclui um Inspetor para experimentar todos os métodos disponíveis. ## Convenções {#conventions} @@ -50,7 +50,7 @@ Veja aqui alguns exemplos: 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: +Veja aqui alguns exemplos: - 0x41 (tamanho 1, "A") - 0x004200 (tamanho 3, "0B0") @@ -58,9 +58,9 @@ Aqui estão alguns exemplos: - 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} +### O parâmetro de bloco {#block-parameter} -Os métodos a seguir têm um parâmetro de bloco padrão extra: +Os seguintes métodos têm um parâmetro de bloco: - [eth_getBalance](#eth_getbalance) - [eth_getCode](#eth_getcode) @@ -68,26 +68,27 @@ Os métodos a seguir têm um parâmetro de bloco padrão extra: - [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. +Quando são feitas solicitações que consultam o estado do Ethereum, o parâmetro de bloco fornecido determina a altura do bloco. -As seguintes opções são possíveis para o parâmetro defaultBlock: +As seguintes opções são possíveis para o parâmetro de bloco: - `String HEX` - um número de bloco inteiro -- `String "earliest"` para o bloco mais antigo/de início +- `String "earliest"` para o bloco mais antigo/gênese - `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 +- `String "safe"` - para o último bloco principal seguro +- `String "finalized"` - para o último bloco finalizado +- `String "pending"` - 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. +Nesta página, fornecemos exemplos de como usar endpoints individuais da API JSON_RPC usando a ferramenta de linha de comando [curl](https://curl.se). Esses exemplos de endpoint individuais são encontrados abaixo na seção [Exemplos de Curl](#curl-examples). Mais adiante 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 o curl. -## Exemplos Curl {#curl-examples} +## Exemplos de 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. +Abaixo, são fornecidos exemplos de uso da API JSON_RPC, fazendo solicitações com o [curl](https://curl.se) para um nó do Ethereum. 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: +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 para `application/x-www-form-urlencoded`. Se o seu nó reclamar sobre isso, defina manualmente o cabeçalho, inserindo `-H "Content-Type: application/json"` no início da chamada. Os exemplos também não incluem a combinação de URL/IP e porta que deve ser o último argumento dado ao 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 @@ -95,7 +96,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho ## 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. +Alguns métodos JSON-RPC principais exigem dados da rede Ethereum e se enquadram 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} @@ -136,7 +137,7 @@ Alguns dos métodos JSON-RPC principais exigem dados da rede Ethereum, se enquad 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} +## Métodos da API JSON-RPC {#json-rpc-methods} ### web3_clientVersion {#web3_clientversion} @@ -146,7 +147,7 @@ Retorna a versão atual do cliente. Nenhum -**Returnos** +**Retornos** `String` - A versão atual do cliente @@ -165,7 +166,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[], ### web3_sha3 {#web3_sha3} -Retorna Keccak-256 (_não_ o SHA3-256 padronizado) dos dados fornecidos. +Retorna o Keccak-256 (_não_ o SHA3-256 padronizado) dos dados fornecidos. **Parâmetros** @@ -175,16 +176,16 @@ Retorna Keccak-256 (_não_ o SHA3-256 padronizado) dos dados fornecidos. params: ["0x68656c6c6f20776f726c64"] ``` -**Retorna** +**Retornos** `DATA` - O resultado SHA3 da string fornecida. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' -// Result +// Resultado { "id":64, "jsonrpc": "2.0", @@ -200,22 +201,22 @@ Retorna a id da rede atual. Nenhum -**Retorna** +**Retornos** -`String` - A id da rede atual. +`String` - O 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: +A lista completa dos IDs de rede atuais está disponível em [chainlist.org](https://chainlist.org). Alguns exemplos comuns são: -- `1`: Ethereum Mainnet -- `11155111`: Sepolia testnet -- `560048` : Hoodi testnet +- `1`: Rede Principal do Ethereum +- `11155111`: Rede de teste Sepolia +- `560048` : Rede de teste Hoodi **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' -// Result +// Resultado { "id":67, "jsonrpc": "2.0", @@ -225,22 +226,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67 ### net_listening {#net_listening} -Retorna `true` se o cliente estiver escutando ativamente as conexões de rede. +Retorna `true` se o cliente está ativamente escutando por conexões de rede. **Parâmetros** Nenhum -**Retorna** +**Retornos** -`Boolean` - `true` quando escuta, do contrário `false`. +`Booleano` - `true` quando escutando, caso contrário, `false`. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' -// Result +// Resultado { "id":67, "jsonrpc":"2.0", @@ -256,16 +257,16 @@ Retorna o número de pares atualmente conectados ao cliente. Nenhum -**Retorna** +**Retornos** -`QUANTITY` - número inteiro do número de pares conectados. +`QUANTITY` - número inteiro de pares conectados. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' -// Result +// Resultado { "id":74, "jsonrpc": "2.0", @@ -275,22 +276,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id": ### 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). +Retorna a versão atual do protocolo Ethereum. Observe 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** +**Retornos** `String` - A versão atual do protocolo Ethereum **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}' -// Result +// Resultado { "id":67, "jsonrpc": "2.0", @@ -302,19 +303,23 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[] Retorna um objeto com dados sobre o status da sincronização ou `false`. + + Experimente o endpoint no playground + + **Parâmetros** Nenhum -**Retorna** +**Retornos** 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 está sincronizando: +`Objeto|Booleano`, um objeto com dados de status de sincronização ou `FALSE`, quando não está sincronizando: -- `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 +- `startingBlock`: `QUANTITY` - O bloco no qual a importação foi iniciada (só será reiniciado depois que a sincronização atingir o bloco principal) +- `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: @@ -362,9 +367,9 @@ Consulte a documentação do seu cliente específico para obter mais detalhes. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -374,7 +379,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1} highestBlock: '0x454' } } -// Or when not syncing +// Ou quando não estiver sincronizando { "id":1, "jsonrpc": "2.0", @@ -386,22 +391,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1} Retorna o endereço de coinbase do cliente. -> **Nota:** Este método foi descontinuado a partir da versão **v1.14.0** e não é mais suportado. Tentar usar este método resultará em um erro de "Método não suportado". + + Experimente o endpoint no playground + + +> **Observação:** Este método foi preterido a partir da **v1.14.0** e não tem mais suporte. Tentar usar este método resultará em um erro de "Método não suportado". **Parâmetros** Nenhum -**Returnos** +**Retornos** -`DATA`, 20 bytes - O endereço atual da coinbase. +`DATA`, 20 bytes - o endereço coinbase atual. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}' -// Result +// Resultado { "id":64, "jsonrpc": "2.0", @@ -413,20 +422,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6 Retorna a ID da cadeia usada para assinar transações protegidas contra reprodução. + + Experimente o endpoint no playground + + **Parâmetros** Nenhum -**Returnos** +**Retornos** -`chainId`, valor hexadecimal como uma cadeia de caracteres representando o inteiro da ID da cadeia atual. +`chainId`, valor hexadecimal como uma string representando o número inteiro do ID da cadeia atual. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}' -// Result +// Resultado { "id":67, "jsonrpc": "2.0", @@ -436,20 +449,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67 ### eth_mining {#eth_mining} -Retorna `true` se o cliente estiver minerando novos blocos de maneira ativa. Isso só pode retornar `true` para redes de prova de trabalho e pode não estar disponível em alguns clientes desde a [Fusão](/roadmap/merge/). +Retorna `true` se o cliente estiver minerando ativamente novos blocos. Isso só pode retornar `true` para redes de prova de trabalho e pode não estar disponível em alguns clientes desde [A Fusão](/roadmap/merge/). + + + Experimente o endpoint no playground + **Parâmetros** Nenhum -**Returnos** +**Retornos** -`Boolean` — retorna `true` do cliente que está minerando, caso contrário, `false`. +`Booleano` - retorna `true` se o cliente estiver minerando, caso contrário, `false`. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}' // { @@ -461,22 +478,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71} ### 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 a [Fusão](/roadmap/merge/). +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 [A Fusão](/roadmap/merge/). + + + Experimente o endpoint no playground + **Parâmetros** Nenhum -**Returnos** +**Retornos** -`QUANTITY` — número de hashes por segundo. +`QUANTITY` - número de hashes por segundo. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}' -// Result +// Resultado { "id":71, "jsonrpc": "2.0", @@ -488,20 +509,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7 Retorna uma estimativa do preço atual por unidade de 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. + + Experimente o endpoint no playground + + **Parâmetros** Nenhum -**Returnos** +**Retornos** -`QUANTITY` — Número inteiro do preço atual do gás em Wei. +`QUANTITY` - número inteiro do preço do gás atual em wei. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' -// Result +// Resultado { "id":73, "jsonrpc": "2.0", @@ -513,20 +538,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7 Retorna uma lista de endereços de propriedade do cliente. + + Experimente o endpoint no playground + + **Parâmetros** Nenhum -**Returnos** +**Retornos** -`Array of DATA`, 20 Bytes — endereços de propriedade do cliente. +`Array de DATA`, 20 Bytes - endereços pertencentes ao cliente. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -538,20 +567,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1 Retorna o número do bloco mais recente. + + Experimente o endpoint no playground + + **Parâmetros** Nenhum -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do número do bloco atual no qual o cliente está. +`QUANTITY` - número inteiro do bloco atual em que o cliente está. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' -// Result +// Resultado { "id":83, "jsonrpc": "2.0", @@ -561,27 +594,31 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id ### eth_getBalance {#eth_getbalance} -Retorna o saldo da conta do endereço fornecido. +Retorna o saldo da conta de um determinado endereço. + + + Experimente o endpoint no playground + **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) +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"`, veja o [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] ``` -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do saldo atual em Wei. +`QUANTITY` - número inteiro do saldo atual em wei. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -593,30 +630,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407 Retorna o valor de uma posição de armazenamento em um determinado endereço. + + Experimente o endpoint no playground + + **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) +1. `DATA`, 20 Bytes - endereço do armazenamento. +2. `QUANTITY` - inteiro da posição no armazenamento. +3. `QUANTITY|TAG` - número de bloco inteiro, ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, veja o [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter) -**Returnos** +**Retornos** -`DATA` — O valor nessa posição de armazenamento. +`DATA` - o valor nesta 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`. +**Exemplo** +Calcular a posição correta depende do armazenamento a ser recuperado. Considere o seguinte contrato implantado em `0x295a70b2de5e3953354a6a8344e616ed314d7251` pelo endereço `0x391694e7e0b0cce554cb130d723a9d27458f9298`. ``` contract Storage { uint pos0; mapping(address => uint) pos1; - function Storage() { + constructor() { pos0 = 1234; pos1[msg.sender] = 5678; } } ``` -Recuperar o valor da pos0 é simples: +Recuperar o valor de pos0 é simples: ```js curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 @@ -658,30 +700,34 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [ ### eth_getTransactionCount {#eth_gettransactioncount} -Retorna o número de transações _enviadas_ a partir de um endereço. +Retorna o número de transações _enviadas_ de um endereço. + + + Experimente o endpoint no playground + **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) +1. `DATA`, 20 Bytes - endereço. +2. `QUANTITY|TAG` - número de bloco inteiro, ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, veja o [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ "0x407d73d8a49eeb85d32cf465507dd71d507100c1", - "latest", // state at the latest block + "latest", // estado no bloco mais recente ] ``` -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do número de transações enviadas a partir desse endereço. +`QUANTITY` - inteiro do número de transações enviadas a partir deste endereço. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -693,17 +739,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido. + + Experimente o endpoint no playground + + **Parâmetros** -1. `DATA`, 32 bytes - Hash de um bloco +1. `DATA`, 32 Bytes - hash de um bloco ```js params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] ``` -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do número de transações nesse bloco. +`QUANTITY` - inteiro do número de transações neste bloco. **Exemplo** @@ -722,9 +772,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido. + + Experimente o endpoint no playground + + **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). +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](/developers/docs/apis/json-rpc/#block-parameter). ```js params: [ @@ -732,9 +786,9 @@ params: [ ] ``` -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do número de transações nesse bloco. +`QUANTITY` - inteiro do número de transações neste bloco. **Exemplo** @@ -753,17 +807,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido. + + Experimente o endpoint no playground + + **Parâmetros** -1. `DADOS`, 32 bytes - hash de um bloco +1. `DATA`, 32 Bytes - hash de um bloco ```js params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] ``` -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do número de transações nesse bloco. +`QUANTITY` - inteiro do número de tios neste bloco. **Exemplo** @@ -782,9 +840,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p Retorna o número de transações em um bloco a partir de um bloco que corresponde ao hash de bloco fornecido. + + Experimente o endpoint no playground + + **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) +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](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -792,9 +854,9 @@ params: [ ] ``` -**Returnos** +**Retornos** -`QUANTITY` — Inteiro do número de transações nesse bloco. +`QUANTITY` - inteiro do número de tios neste bloco. **Exemplo** @@ -813,10 +875,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber", Retorna o código em um endereço fornecido. + + Experimente o endpoint no playground + + **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) +1. `DATA`, 20 Bytes - endereço +2. `QUANTITY|TAG` - número de bloco inteiro, ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, veja o [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -825,9 +891,9 @@ params: [ ] ``` -**Returnos** +**Retornos** -`DATA` — O código do endereço fornecido. +`DATA` - o código do endereço fornecido. **Exemplo** @@ -846,25 +912,25 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA 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. +Ao adicionar um prefixo à mensagem, a assinatura calculada é reconhecível como uma assinatura específica do Ethereum. Isso evita o uso indevido, no qual um dapp mal-intencionado pode assinar dados arbitrários (por exemplo, uma transação) e usar a assinatura para se passar pela 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 +1. `DATA`, 20 Bytes - endereço +2. `DATA`, N Bytes - mensagem a ser assinada -**Returnos** +**Retornos** -`DATA`: assinatura +`DATA`: Assinatura **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -880,25 +946,25 @@ Assina uma transação que pode ser enviada à rede posteriormente usando [eth_s 1. `Objeto` - O objeto da transação -- `type`: -- `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. +- `tipo`: +- `from`: `DATA`, 20 Bytes - O 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. +- `value`: `QUANTITY` - (opcional) Inteiro do valor enviado com esta transação, em Wei. +- `data`: `DATA` - O código compilado de um contrato OU o 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. -**Returnos** +**Retornos** -`DATA`: o objeto de transação codificado em RLP assinado pela conta especificada. +`DATA`, o objeto da transação codificado por RLP e assinado pela conta especificada. **Exemplo** ```js -// Request +// Requisição 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 +// Resultado { "id": 1, "jsonrpc": "2.0", @@ -908,19 +974,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction"," ### 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`. +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 `from`. **Parâmetros** -1. `Object` - O objeto da transação +1. `Objeto` - 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. +- `from`: `DATA`, 20 Bytes - O 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. +- `value`: `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. +- `nonce`: `QUANTITY` - (opcional) Inteiro de um nonce. Isso permite substituir suas próprias transações pendentes que usam o mesmo nonce. ```js params: [ @@ -936,18 +1002,18 @@ params: [ ] ``` -**Returnos** +**Retornos** -`DATA`, 32 Bytes — O hash da transação ou o hash zero se a transação ainda não estiver disponível. +`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 de a transação ter sido proposta em um bloco, quando você criou um contrato. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -961,7 +1027,7 @@ Cria uma nova transação de chamada de mensagem ou um contrato para transaçõe **Parâmetros** -1. `DATA`, O objeto de transação assinada. +1. `DATA`, Os dados da transação assinada. ```js params: [ @@ -969,18 +1035,18 @@ params: [ ] ``` -**Returnos** +**Retornos** -`DATA`, 32 Bytes — O hash da transação ou o hash zero se a transação ainda não estiver disponível. +`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 de a transação ter sido proposta em um bloco, quando você criou um contrato. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -990,31 +1056,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params" ### 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. +Executa uma nova chamada de mensagem imediatamente sem criar uma transação no blockchain. Frequentemente usado para executar funções de contrato inteligente somente leitura, por exemplo, o `balanceOf` para um contrato ERC-20. + + + Experimente o endpoint no playground + **Parâmetros** -1. `Object` - O objeto de chamada de transação +1. `Objeto` - 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). +- `from`: `DATA`, 20 Bytes - (opcional) O endereço de onde 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 +- `value`: `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 detalhes, consulte [IAB do Contrato Ethereum 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) +2. `QUANTITY|TAG` - número de bloco inteiro, ou a string `"latest"`, `"earliest"`, `"pending"`, `"safe"` ou `"finalized"`, veja o [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter) -**Returnos** +**Retornos** -`DATA` — O valor de retorno do contrato executado. +`DATA` - o valor de retorno do contrato executado. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -1026,20 +1096,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}] Gera e retorna uma estimativa de quantas unidades de gás são necessárias 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ó. + + Experimente o endpoint no playground + + **Parâmetros** -Veja os parâmetros do [eth_call](#eth_call), a menos que todas as propriedades sejam opcionais. Se nenhum limite de gás é 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. +Consulte os parâmetros de [eth_call](#eth_call), exceto que todas as propriedades são opcionais. Se nenhum limite de gás é especificado, o geth usa o limite de gás do bloco pendente como um limite superior. Como resultado, a estimativa retornada pode 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. -**Returnos** +**Retornos** -`QUANTITY` — A quantidade de gás usada. +`QUANTITY` - a quantidade de gás usada. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -1051,10 +1125,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see Retorna informações sobre um bloco por hash. + + Experimente o endpoint no playground + + **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. +2. `Booleano` - Se `true`, retorna os objetos de transação completos; se `false`, apenas os hashes das transações. ```js params: [ @@ -1063,41 +1141,40 @@ params: [ ] ``` -**Returnos** - -`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. +**Retornos** + +`Objeto` - Um objeto de bloco, ou `nulo` 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 seu bloco estiver pendente, `0x0` para blocos de prova de participação (desde A Fusão) +- `sha3Uncles`: `DATA`, 32 Bytes - SHA3 dos dados dos 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 recibos do bloco. +- `miner`: `DATA`, 20 Bytes - o endereço do beneficiário a quem as recompensas do bloco foram dadas. +- `difficulty`: `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 +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' -// Result -{ +// Resultado { -"jsonrpc": "2.0", -"id": 1, -"result": { + "jsonrpc": "2.0", + "id": 1, + "result": { "difficulty": "0x4ea3f27bc", "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", "gasLimit": "0x1388", @@ -1120,7 +1197,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0 "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [ ] -} + } } ``` @@ -1128,10 +1205,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0 Retorna informações sobre um bloco por número de bloco. + + Experimente o endpoint no playground + + **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. +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](/developers/docs/apis/json-rpc/#block-parameter). +2. `Booleano` - Se `true`, retorna os objetos de transação completos; se `false`, apenas os hashes das transações. ```js params: [ @@ -1140,21 +1221,26 @@ params: [ ] ``` -**Retorna** Consulte [eth_getBlockByHash](#eth_getblockbyhash) +**Retornos** +Consulte [eth_getBlockByHash](#eth_getblockbyhash) **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' ``` -Veja o resultado [eth_getBlockByHash](#eth_getblockbyhash) +Resultado: consulte [eth_getBlockByHash](#eth_getblockbyhash) ### eth_getTransactionByHash {#eth_gettransactionbyhash} Retorna as informações sobre uma transação solicitada pelo hash de transação. + + Experimente o endpoint no playground + + **Parâmetros** 1. `DATA`, 32 Bytes - hash de uma transação @@ -1163,31 +1249,31 @@ Retorna as informações sobre uma transação solicitada pelo hash de transaç params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] ``` -**Returnos** +**Retornos** -`Object` — Um objeto de transação ou `null` quando nenhuma transação foi encontrada: +`Objeto` - 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 +- `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. +- `gas`: `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. +- `value`: `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 +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}' -// Result +// Resultado { "jsonrpc":"2.0", "id":1, @@ -1214,10 +1300,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param Retorna informações sobre uma transação por hash de bloco e a posição do índice de transação. + + Experimente o endpoint no playground + + **Parâmetros** -1. `DATA`, 32 Bytes - Hash de um bloco. -2. `QUANTITY` - Inteiro da posição do índice da transação. +1. `DATA`, 32 Bytes - hash de um bloco. +2. `QUANTITY` - inteiro da posição do índice da transação. ```js params: [ @@ -1226,7 +1316,8 @@ params: [ ] ``` -**Retorna** Consulte [eth_getTransactionByHash](#eth_gettransactionbyhash) +**Retornos** +Consulte [eth_getTransactionByHash](#eth_gettransactionbyhash) **Exemplo** @@ -1235,16 +1326,20 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` -Resultado. Veja [eth_getTransactionByHash](#eth_gettransactionbyhash) +Resultado: consulte [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. + + Experimente o endpoint no playground + + **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. +1. `QUANTITY|TAG` - um número de bloco, ou a string `"earliest"`, `"latest"`, `"pending"`, `"safe"` ou `"finalized"`, como no [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter). +2. `QUANTITY` - a posição do índice da transação. ```js params: [ @@ -1253,58 +1348,60 @@ params: [ ] ``` -**Retorna** Consulte [eth_getTransactionByHash](#eth_gettransactionbyhash) +**Retornos** +Consulte [eth_getTransactionByHash](#eth_gettransactionbyhash) **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' ``` -Resultado. Veja [eth_getTransactionByHash](#eth_gettransactionbyhash) +Resultado: consulte [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. +**Observação** Que o recibo não está disponível para transações pendentes. **Parâmetros** -1. `DADOS`, 32 bytes - hash de um bloco +1. `DATA`, 32 Bytes - hash de uma transação ```js params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] ``` -**Retorna** `Object` — Um objeto de recebimento de transação, ou `null` quando nenhum recebimento foi encontrado: +**Retornos** +`Objeto` - Um objeto de recibo de transação, ou `null` quando nenhum recibo 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. +- `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 foi uma criação de 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 legadas, `0x1` para tipos de lista de acesso, `0x2` para taxas dinâmicas. -Ele também retorna _seja_ : +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) +- `root`: `DATA` 32 bytes da raiz do estado pós-transação (pré-Byzantium) +- `status`: `QUANTITY` seja `1` (sucesso) ou `0` (falha) **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}' -// Result +// Resultado { "jsonrpc": "2.0", "id": 1, @@ -1312,15 +1409,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para "blockHash": "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3", "blockNumber": "0xeff35f", - "contractAddress": null, // string of the address if it was created + "contractAddress": null, // string do endereço se ele foi criado "cumulativeGasUsed": "0xa12515", "effectiveGasPrice": "0x5a9c688d4", "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7", "gasUsed": "0xb4c8", "logs": [{ - // logs as returned by getFilterLogs, etc. + // logs como retornado por getFilterLogs, etc. }], - "logsBloom": "0x00...0", // 256 byte bloom filter + "logsBloom": "0x00...0", // filtro bloom de 256 bytes "status": "0x1", "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", "transactionHash": @@ -1333,7 +1430,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para ### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex} -Retorna informações sobre o tio de um bloco por hash e a posição do índice de um tio. +Retorna informações sobre um tio de um bloco por hash e posição de índice do tio. + + + Experimente o endpoint no playground + **Parâmetros** @@ -1347,7 +1448,8 @@ params: [ ] ``` -**Retorna** Consulte [eth_getBlockByHash](#eth_getblockbyhash) +**Retornos** +Consulte [eth_getBlockByHash](#eth_getblockbyhash) **Exemplo** @@ -1356,18 +1458,22 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` -Veja o resultado [eth_getBlockByHash](#eth_getblockbyhash) +Resultado: consulte [eth_getBlockByHash](#eth_getblockbyhash) -**Observação**: um tio (bloco) não contém transações individuais. +**Observação**: um tio 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. +Retorna informações sobre um tio de um bloco por número e posição do índice do tio. + + + Experimente o endpoint no playground + **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. +1. `QUANTITY|TAG` - um número de bloco, ou a string `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, como no [parâmetro de bloco](/developers/docs/apis/json-rpc/#block-parameter). +2. `QUANTITY` - a posição do índice tio. ```js params: [ @@ -1376,38 +1482,41 @@ params: [ ] ``` -**Retorna** Consulte [eth_getBlockByHash](#eth_getblockbyhash) +**Retornos** +Consulte [eth_getBlockByHash](#eth_getblockbyhash) -**Observação**: um tio (bloco) não contém transações individuais. +**Observação**: um tio não contém transações individuais. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' ``` -Veja o resultado [eth_getBlockByHash](#eth_getblockbyhash) +Resultado: consulte [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). +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: +**Uma observação sobre a especificação de filtros de tópicos:** +Os tópicos dependem 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)” +- `[]` "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: +1. `Objeto` - 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. +- `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". +- `address`: `DATA|Array`, 20 Bytes - (opcional) Endereço do contrato ou uma lista de endereços dos quais os logs devem ser originados. +- `topics`: `Array de DATA`, - (opcional) Array de 32 Bytes de tópicos de `DATA`. Os tópicos são dependentes da ordem. Cada tópico também pode ser uma matriz de DADOS (array of DATA) com opções “ou”. ```js params: [ @@ -1427,14 +1536,15 @@ params: [ ] ``` -**Retorna** `QUANTITY` — Uma ID de filtro. +**Retornos** +`QUANTITY` - Uma ID de filtro. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -1444,18 +1554,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic ### 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). +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** Nenhum +**Parâmetros** +Nenhum -**Retorna** `QUANTITY` — Uma ID de filtro. +**Retornos** +`QUANTITY` - Uma ID de filtro. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -1465,18 +1578,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[], ### 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). +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** Nenhum +**Parâmetros** +Nenhum -**Retorna** `QUANTITY` — Uma ID de filtro. +**Retornos** +`QUANTITY` - Uma ID de filtro. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -1486,7 +1602,8 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter" ### eth_uninstallFilter {#eth_uninstallfilter} -Desinstala um filtro com a ID fornecida. Deve ser sempre chamado quando nenhum tipo de observação é necessária. Além disso, os filtros expiram quando não são solicitados com [eth_getFilterChanges](#eth_getfilterchanges) por um período de tempo. +Desinstala um filtro com a ID fornecida. Deve ser sempre chamado quando nenhum tipo de observação é necessária. +Além disso, os filtros expiram quando não são solicitados com [eth_getFilterChanges](#eth_getfilterchanges) por um período de tempo. **Parâmetros** @@ -1498,14 +1615,15 @@ params: [ ] ``` -**Retorna** `Boolean` — `true` se o filtro foi desinstalado com sucesso, caso contrário `false`. +**Retornos** +`Booleano` - `true` se o filtro foi desinstalado com sucesso, caso contrário, `false`. **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}' -// Result +// Resultado { "id":1, "jsonrpc": "2.0", @@ -1519,7 +1637,7 @@ Método de sondagem para um filtro, que retorna uma matriz de logs produzidos de **Parâmetros** -1. `QUANTITY` - A ID do filtro. +1. `QUANTITY` - a ID do filtro. ```js params: [ @@ -1527,26 +1645,30 @@ params: [ ] ``` -**Retorna** `Array` — Matriz de objetos de log ou uma matriz vazia se nada mudou desde a última sondagem. +**Retornos** +`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_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`.) + - `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 da posição do índice de transações a partir do qual o log 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. + - `address`: `DATA`, 20 Bytes - endereço de origem deste log. + - `data`: `DATA` - dados de log de comprimento variável e não indexados. (Em _solidity_: zero ou mais argumentos de log de 32 Bytes não indexados.) + - `topics`: `Array de DATA` - Matriz de 0 a 4 `DATA` de 32 Bytes de argumentos de log indexados. (Em _solidity_: O primeiro tópico é o _hash_ da assinatura do evento (ex., `Deposit(address,bytes32,uint256)`), exceto se você declarou o evento com o especificador `anonymous`.) + - **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}' -// Result +// Resultado { "id":1, "jsonrpc":"2.0", @@ -1579,16 +1701,17 @@ params: [ ] ``` -**Retorna** Consulte [eth_getFilterChanges](#eth_getfilterchanges) +**Retornos** +Consulte [eth_getFilterChanges](#eth_getfilterchanges) **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}' ``` -Resultado. Veja [eth_getFilterChanges](#eth_getfilterchanges) +Resultado: consulte [eth_getFilterChanges](#eth_getfilterchanges) ### eth_getLogs {#eth_getlogs} @@ -1596,13 +1719,13 @@ Retorna uma matriz de todos os logs que correspondem a um determinado objeto de **Parâmetros** -1. `Object` - As opções de filtro: +1. `Objeto` - 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. +- `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. +- `address`: `DATA|Array`, 20 Bytes - (opcional) Endereço do contrato ou uma lista de endereços dos quais os logs devem ser originados. +- `topics`: `Array de DATA`, - (opcional) Array de 32 Bytes de tópicos de `DATA`. Os tópicos são dependentes da ordem. Cada tópico também pode ser uma matriz de DADOS (array of DATA) 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-byte `blockHash`. Usar `blockHash` é equivalente a `fromBlock` = `toBlock` = o número do bloco com hash `blockHash`. Se `blockHash` estiver presente nos critérios de filtro, `fromBlock` e `toBlock` não serão permitidos. ```js params: [ @@ -1614,24 +1737,25 @@ params: [ ] ``` -**Retorna** Consulte [eth_getFilterChanges](#eth_getfilterchanges) +**Retornos** +Consulte [eth_getFilterChanges](#eth_getfilterchanges) **Exemplo** ```js -// Request +// Requisição curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}' ``` -Resultado. Veja [eth_getFilterChanges](#eth_getfilterchanges) +Resultado: consulte [eth_getFilterChanges](#eth_getfilterchanges) -## Exemplos de uso {#usage-example} +## Exemplo de uso {#usage-example} -### Implementando um contrato usando JSON_RPC {#deploying-contract} +### Implantando 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`. +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 em `localhost:8545`. ```javascript contract Multiply7 { @@ -1651,10 +1775,10 @@ geth --http --dev console 2>>geth.log Isso iniciará a interface HTTP RPC em `http://localhost:8545`. -Podemos verificar se a interface está em execução recuperando o endereço da coinbase (obtendo o primeiro endereço da matriz de contas) e o saldo 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. +Podemos verificar se a interface está em execução recuperando o endereço coinbase (obtendo o primeiro endereço da matriz de contas) e o saldo usando o [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_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545 +curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "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 @@ -1668,9 +1792,9 @@ web3.fromWei("0x1639e49bba16280000", "ether") // "410" ``` -Agora que já temos alguns Ether 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).) +Agora que já temos alguns Ether 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, siga a [documentação do Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Você pode usar uma versão mais antiga do `solc` para corresponder à [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. +O próximo passo é compilar o contrato Multiply7 para bytecode 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 @@ -1680,7 +1804,7 @@ 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. +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 @@ -1694,7 +1818,7 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from {"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`. +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 o recibo com o método `eth_getTransactionReceipt` da RPC. ```bash curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 @@ -1707,7 +1831,7 @@ Nosso contrato foi criado em `0x4d03d617d700cf81935d7f797f4e2ae719648262`. Um re 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 uma carga que define qual método deve ser chamado e com quais argumentos. É aqui que a [interface binária do aplicativo (ABI, na sigla em inglês)](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. +`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 payload que define qual método deve ser chamado e com quais argumentos. É aqui que a [IAB (interface binária de aplicativo)](https://docs.soliditylang.org/en/latest/abi-spec.html) entra em jogo. A ABI é um arquivo JSON que estabelece como definir e codificar dados para a EVM. Os bytes da carga 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: @@ -1718,9 +1842,9 @@ web3.sha3("multiply(uint256)").substring(0, 10) 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. +`int: enc(X)` é a codificação de complemento de dois big-endian de X, preenchida no lado de ordem superior (esquerdo) com 0xff para X negativo e com bytes zero para X positivo, de modo que o comprimento seja um múltiplo de 32 bytes. -Isso codifica em `0000000000000000000000000000000000000000000000000000000000000006`. +Isso codifica para `0000000000000000000000000000000000000000000000000000000000000006`. Combinando o seletor de função e o argumento codificado, nossos dados serão `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`. @@ -1755,7 +1879,7 @@ Como uma transação foi enviada, um hash de transação foi retornado. A recupe } ``` -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: +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 acionado com a entrada multiplicada por 7. Como o argumento para o evento `Print` era um uint256, podemos decodificá-lo de acordo com as regras da IAB, o que nos deixará com o decimal esperado 42. 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)") @@ -1766,8 +1890,8 @@ Esta foi apenas uma breve introdução a algumas das tarefas mais comuns, demons ## 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/) +- [Especificação JSON-RPC](http://www.jsonrpc.org/specification) +- [Nós e clientes](/developers/docs/nodes-and-clients/) +- [APIs de JavaScript](/developers/docs/apis/javascript/) +- [APIs de backend](/developers/docs/apis/backend/) - [Clientes de execução](/developers/docs/nodes-and-clients/#execution-clients) diff --git a/public/content/translations/pt-br/developers/docs/blocks/index.md b/public/content/translations/pt-br/developers/docs/blocks/index.md index c94e1e77c54..1455b7552fc 100644 --- a/public/content/translations/pt-br/developers/docs/blocks/index.md +++ b/public/content/translations/pt-br/developers/docs/blocks/index.md @@ -1,6 +1,6 @@ --- 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. +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 --- @@ -8,13 +8,14 @@ Blocos são lotes de transações com um hash do bloco anterior na cadeia. Isso ## 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/). +Os blocos são um tópico muito amigável para iniciantes. Mas, para ajudar você a entender melhor esta página, recomendamos que 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. -![Um diagrama mostrando transações em um bloco causando mudanças de estado](./tx-block.png) _Diagrama adaptado de [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Um diagrama mostrando transações em um bloco causando mudanças de estado](./tx-block.png) +_Diagrama adaptado de [Ethereum EVM illustrated](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. @@ -24,13 +25,13 @@ Para preservar o histórico de transação, os blocos são estritamente ordenado 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} +## Protocolo de prova de participação {#proof-of-stake-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. +- Outros validadores que ficam sabendo do novo bloco reexecutam as transações para garantir que concordam com a mudança proposta no estado global. Supondo que o bloco seja 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) @@ -40,52 +41,52 @@ Prova de participação significa o seguinte: 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 | +| :--------------- | :--------------------------------------------------------- | +| `espaço` | 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 | +| `apresentação` | um objeto contendo vários campos, conforme definido abaixo | -O bloco `body` contém vários campos próprios: +O `body` do bloco 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 | +| `atestações` | lista de atestações feitas em relação aos espaços anteriores | +| `depósitos` | 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 | +| Campo | Descrição | +| :----------------- | :-------------------------------------------------------------------------- | +| `aggregation_bits` | uma lista de quais validadores participaram desta atestação | +| `dados` | um contêiner com vários subcampos | +| `assinatura` | assinatura agregada de um conjunto de validadores em relação à parte `data` | -O campo `data` no `attestation` contém o seguinte: +O campo `data` na `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 | +| Campo | Descrição | +| :------------------ | :----------------------------------------------------------- | +| `espaço` | o local ao qual a atestação se refere | +| `índice` | índices para as atestações dos validadores | +| `beacon_block_root` | o hash raiz do bloco Beacon visto como o cabeçalho da cadeia | +| `fonte` | 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: +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 àquele no campo `state_root` do novo bloco. É 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 de resumo importantes 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 | @@ -102,48 +103,48 @@ O `execution_payload_header` contém os seguintes campos: | `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 | +O próprio `execution_payload` contém o seguinte (observe que isso é 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 | +| `retirada de fundos` | 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 | +| `índice` | 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. +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 de 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 de 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 30 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 60 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. +Uma observação final importante é que os blocos em si são delimitados por tamanho. Cada bloco tem um tamanho alvo de 30 milhões de gás, mas o tamanho dos blocos aumentará ou diminuirá de acordo com as demandas da rede, até o limite de bloco de 60 milhões de gás (2x o tamanho alvo do bloco). 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} diff --git a/public/content/translations/pt-br/developers/docs/bridges/index.md b/public/content/translations/pt-br/developers/docs/bridges/index.md index 22a4c4c95ea..5e6429e1f07 100644 --- a/public/content/translations/pt-br/developers/docs/bridges/index.md +++ b/public/content/translations/pt-br/developers/docs/bridges/index.md @@ -1,20 +1,20 @@ --- title: Pontes -description: Uma visão geral da ponte para desenvolvedores +description: "Uma visão geral da ponte para desenvolvedores" lang: pt-br --- -Com a proliferação de soluções de blockchains L1 e de [dimensionamento](/developers/docs/scaling/) L2, junto com um número cada vez maior de aplicativos descentralizados cross-chain, a necessidade de comunicação e de movimentação de ativos entre as chains tornou-se uma parte essencial da infraestrutura das redes. Há diferentes tipos de bridges para ajudar a tornar isso possível. +Com a proliferação de blockchains L1 e soluções de [escalabilidade](/developers/docs/scaling/) L2, juntamente com um número cada vez maior de aplicativos descentralizados se tornando cross-chain, a necessidade de comunicação e movimentação de ativos entre redes tornou-se uma parte essencial da infraestrutura de rede. Há diferentes tipos de bridges para ajudar a tornar isso possível. -## Necessidade de bridges {#need-for-bridges} +## Necessidade de pontes {#need-for-bridges} Bridges existem para conectar redes blockchain. Elas permitem conectividade e interoperabilidade entre blockchains. Blockchains existem em ambientes isolados, o que significa que não há maneira de blockchains negociarem e se comunicarem com outros blockchains naturalmente. Como resultado, embora possa haver atividade e inovação significantes dentro de um ecossistema, elas estão limitadas pela falta de conexão e interoperabilidade com outros ecossistemas. -Bridges oferecem uma maneira de os ambientes isolados de blockchain se conectarem entre si. Eles estabelecem uma rota de transporte entre blockchains na qual tokens, mensagens, dados arbitrários, e até mesmo chamadas de [contratos inteligentes](/developers/docs/smart-contracts/) podem ser transferidos de uma cadeia para outra. +Bridges oferecem uma maneira de os ambientes isolados de blockchain se conectarem entre si. Elas estabelecem uma rota de transporte entre blockchains onde tokens, mensagens, dados arbitrários e até mesmo chamadas de [contrato inteligente](/developers/docs/smart-contracts/) podem ser transferidos de uma rede para outra. -## Benefícios das bridges {#benefits-of-bridges} +## Benefícios das pontes {#benefits-of-bridges} De maneira simples, as bridges desbloqueiam numerosos casos de uso, já que possibilitam que as redes blockchain troquem dados e movam ativos entre si. @@ -23,97 +23,98 @@ Blockchains têm pontos fortes, pontos fracos e abordagens exclusivos para a cri Para os desenvolvedores, as bridges habilitam o seguinte: - a transferência de qualquer dado, informações e ativos entre as chains. -- desbloquear novos recursos e casos de uso para protocolos, já que as bridges expandem o espaço de desenho do que os protocolos podem oferecer. Por exemplo, um protocolo de yield farming originalmente implantado na rede principal do Ethereum pode oferecer pools de liquidez em todas as chains compatíveis com EVM. +- desbloquear novos recursos e casos de uso para protocolos, já que as bridges + expandem o espaço de desenho do que os protocolos podem oferecer. Por exemplo, um protocolo de yield farming originalmente implantado na rede principal do Ethereum pode oferecer pools de liquidez em todas as chains compatíveis com EVM. - a oportunidade de alavancar os pontos fortes das diferentes blockchains. Por exemplo, os desenvolvedores podem se beneficiar das taxas mais baixas oferecidas pelas diferentes soluções de L2, implantando seus dapps em roolups e sidechains, e os usuários podem conectá-los por meio da bridge. - colaboração entre desenvolvedores de vários ecossistemas blockchain para desenvolver novos produtos. - atrair usuários e comunidades de vários ecossistemas para seus dapps. ## Como as bridges funcionam? {#how-do-bridges-work} -Embora haja muitos [tipos de desenhos de bridge](https://blog.li.fi/what-are-blockchain-bridges-and-how-can-we-classify-them-560dc6ec05fa), há três maneiras principais de facilitar a transferência de ativos entre as cadeias: +Embora existam muitos [tipos de designs de pontes](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/), três maneiras de facilitar a transferência de ativos entre redes se destacam: -- **Lock and ming**: bloqueia os ativos na cadeia de origem e faz a "mintagem" na cadeia de destino. -- **Burn and mint**: faz o burn dos ativos na cadeia de origem e faz a mintagem de ativos na cadeia de destino. -- **Atomic swaps**: troca ativos na cadeia de origem por ativos na cadeia de destino com terceiros. +- **Bloquear e cunhar –** Bloqueia ativos na rede de origem e cunha ativos na rede de destino. +- **Queimar e cunhar –** Queima ativos na rede de origem e cunha ativos na rede de destino. +- **Swaps atômicos –** Troca de ativos na rede de origem por ativos na rede de destino com outra parte. -## Tipos de bridge {#bridge-types} +## Tipos de pontes {#bridge-types} Geralmente, as bridges podem ser classificadas como um dos seguintes tipos: -- **Bridges nativas**: estas bridges são tipicamente criadas para criar liquidez em uma determinada blockchain, o que simplifica para os usuários mover fundos para o ecossistema. Por exemplo, a [Arbitrum Bridge](https://bridge.arbitrum.io/) foi criada para que os usuários pudessem fazer uma "ponte" entre a rede principal do Ethereum e a Arbitrum. Outras bridges incluem a Polygon PoS Bridge, a [Optimism Gateway](https://app.optimism.io/bridge) etc. -- **Bridges baseadas em validador ou oráculos**: estas bridges dependem de um conjunto de validadores externos ou oráculos para validar as transferências entre cadeias. Exemplos: Multichain e Across. -- **Bridges para o envio de mensagens generalizadas**: estas bridges podem transferir ativos, juntamente com mensagens e dados arbitrários entre cadeias. Exemplos: Nomad e LayerZero. -- **Redes de liquidez**: o objetivo principal destas bridges é a transferência de ativos de uma cadeia para outra através de atomic swaps. Geralmente, elas não suportam o envio de mensagens entre cadeias. Exemplos: Connext e Hop. +- **Pontes nativas –** Essas pontes são normalmente construídas para impulsionar a liquidez em um blockchain específico, facilitando para os usuários moverem fundos para o ecossistema. Por exemplo, a [Arbitrum Bridge](https://bridge.arbitrum.io/) foi construída para facilitar que os usuários façam a ponte da Rede Principal do Ethereum para a Arbitrum. Outras pontes semelhantes incluem a Polygon PoS Bridge, a [Optimism Gateway](https://app.optimism.io/bridge), etc. +- **Pontes baseadas em validador ou oráculo –** Essas pontes dependem de um conjunto de validadores externos ou oráculos para validar as transferências entre redes. Exemplos: Multichain e Across. +- **Pontes de passagem de mensagens generalizadas –** Essas pontes podem transferir ativos, juntamente com mensagens e dados arbitrários entre redes. Exemplos: Axelar, LayerZero e Nomad. +- **Redes de liquidez –** Essas pontes focam principalmente na transferência de ativos de uma rede para outra por meio de atomic swaps. Geralmente, elas não suportam o envio de mensagens entre cadeias. Exemplos: Connext e Hop. ## Vantagens e desvantagens a considerar {#trade-offs} Com bridges, não há soluções perfeitas. Em vez disso, existem apenas compromissos feitos para cumprir uma finalidade. Desenvolvedores e usuários podem avaliar bridges com base nos seguintes fatores: - **Segurança –** Quem verifica o sistema? Bridges protegidas por validadores externos são tipicamente menos seguras do que as bridges que são locais ou nativamente protegidas pelos validadores do blockchain. -- **Conveniência –** Quanto tempo leva para completar uma transação e quantas transações um usuário precisa assinar? Para um desenvolvedor, quanto tempo leva para integrar uma bridge e qual é a complexidade do processo? -- **Connectivity –** Quais são as diferentes cadeias de destino que uma bridge pode conecta, por exemplo, rollups, sidechains, outras blockchains de camada etc, e quão difícil é integrar uma nova blockchain? -- **Capacidade de enviar dados mais complexos —** Uma bridge pode permitir a transferência de mensagens e dados arbitrários mais complexos entre cadeias ou só suporta transferências de ativos cross-chain? -- **Relação custo-benefício –** Quanto custa transferir ativos entre chains através de uma bridge? Normalmente, as bridges cobram uma taxa fixa ou variável, dependendo dos custos de gás e da liquidez de rotas específicas. É igualmente fundamental avaliar a relação custo-benefício de uma ponte baseada no capital necessário para garantir a sua segurança. +- **Conveniência –** Quanto tempo leva para concluir uma transação e quantas transações um usuário precisa assinar? Para um desenvolvedor, quanto tempo leva para integrar uma bridge e qual é a complexidade do processo? +- **Conectividade –** Quais são as diferentes redes de destino que uma ponte pode conectar (isto é, rollups, sidechains, outras blockchains de camada 1, etc.), e qual a dificuldade para integrar um novo blockchain? +- **Capacidade de passar dados mais complexos –** Uma ponte pode permitir a transferência de mensagens e dados arbitrários mais complexos entre redes, ou ela suporta apenas transferências de ativos entre redes? +- **Custo-benefício –** Quanto custa transferir ativos entre redes por meio de uma ponte? Normalmente, as bridges cobram uma taxa fixa ou variável, dependendo dos custos de gás e da liquidez de rotas específicas. É igualmente fundamental avaliar a relação custo-benefício de uma ponte baseada no capital necessário para garantir a sua segurança. Em termos gerais, as bridges podem ser categorizadas como confiáveis e não confiáveis. -- **Confiável –** Bridges confiáveis são verificadas externamente. Elas usam um conjunto externo de verificadores (federações com sistemas de computação multi-sig e multi-partes, rede de oráculos) para enviar dados através das cadeias. Como resultado, elas podem oferecer grande conectividade e permitir a transmissão de mensagens totalmente generalizadas através das cadeias. Elas também tendem a funcionar bem com velocidade e custo-eficácia. Isto vem à custa da segurança, uma vez que os usuários têm de confiar na segurança da bridge. -- **Não confiáveis –** Estas bridges dependem das blockchains que estão conectando e seus validadores para transferir mensagens e tokens. Elas são "não confiáveis" porque não agregam novas suposições de confiança (em adição aos blockchains). Como resultado, bridges não confiáveis são consideradas mais seguras do que as bridges confiáveis. +- **Confiáveis –** Pontes confiáveis são verificadas externamente. Elas usam um conjunto externo de verificadores (federações com sistemas de computação multi-sig e multi-partes, rede de oráculos) para enviar dados através das cadeias. Como resultado, elas podem oferecer grande conectividade e permitir a transmissão de mensagens totalmente generalizadas através das cadeias. Elas também tendem a funcionar bem com velocidade e custo-eficácia. Isto vem à custa da segurança, uma vez que os usuários têm de confiar na segurança da bridge. +- **Sem necessidade de confiança –** Essas pontes dependem dos blockchains que estão conectando e de seus validadores para transferir mensagens e tokens. Elas são "não confiáveis" porque não agregam novas suposições de confiança (em adição aos blockchains). Como resultado, bridges não confiáveis são consideradas mais seguras do que as bridges confiáveis. Para avaliar bridges não confiáveis baseadas em outros fatores, temos de dividi-las em mensagens generalizadas que são enviadas a bridges e redes de liquidez. -- **Bridges para o envio de mensagens generalizadas –** Estas bridges apresentam excelente segurança e a capacidade de transferir dados mais complexos entre cadeias. Normalmente, também apresentam uma boa relação custo-benefício. No entanto, estes pontos fortes geralmente afetam a conectividade para clientes leves de bridge (ex: IBC) e apresentam desvantagens em termos de velocidade para bridges otimistas (ex: Nomad) que usam provas de fraude. -- **Redes de liquidez –** Estas bridges usam atomic swaps para a transferência de ativos e são sistemas verificados localmente (ou seja, elas usam os validadores dos blockchains subjacentes para verificar transações). Como resultado, apresentam grande segurança e velocidade. Além disso, elas são consideradas relativamente eficazes em termos de custos e oferecem uma boa conectividade. No entanto, a maior desvantagem é sua incapacidade de enviar dados mais complexos, já que elas não suportam o envio de mensagens cross-chain. +- **Pontes de passagem de mensagens generalizadas –** Essas pontes se destacam pela segurança e pela capacidade de transferir dados mais complexos entre redes. Normalmente, também apresentam uma boa relação custo-benefício. No entanto, estes pontos fortes geralmente afetam a conectividade para clientes leves de bridge (ex: IBC) e apresentam desvantagens em termos de velocidade para bridges otimistas (ex: Nomad) que usam provas de fraude. +- **Redes de liquidez –** Essas pontes usam atomic swaps para transferir ativos e são sistemas verificados localmente (ou seja, usam os validadores dos blockchains subjacentes para verificar as transações). Como resultado, apresentam grande segurança e velocidade. Além disso, elas são consideradas relativamente eficazes em termos de custos e oferecem uma boa conectividade. No entanto, a maior desvantagem é sua incapacidade de enviar dados mais complexos, já que elas não suportam o envio de mensagens cross-chain. -## Riscos com bridges {#risk-with-bridges} +## Riscos das pontes {#risk-with-bridges} -As bridges são responsáveis pelos três principais [maiores hacks em DeFi](https://rekt.news/leaderboard/) e ainda estão nos estágios iniciais de desenvolvimento. Usar qualquer bridge traz os seguintes riscos: +As pontes são responsáveis pelos três [maiores hacks em DeFi](https://rekt.news/leaderboard/) e ainda estão nos estágios iniciais de desenvolvimento. Usar qualquer bridge traz os seguintes riscos: -- **Risco de contrato inteligente**: embora muitas bridges passaram com sucesso em auditorias, basta uma falha de contrato inteligente para que os ativos sejam expostos a hacks (ex: [Wormhole da bridge Solana](https://rekt.news/wormhole-rekt/)). -- **Riscos financeiros sistêmicos**: muitas bridges usam ativos encapsulados para mintar versões canônicas do ativo original em uma nova cadeia. Isso expõe o ecossistema a riscos sistêmicos. Um exemplo foi o que aconteceu com versões encapsuladas de tokens. -- **Risco de contraparte**: algumas bridges utilizam um design confiável que requer que os usuários confiem em que os validadores não roubarão fundos dos usuários. A necessidade de os usuários confiarem nesses atores externos os expõe a riscos como rug pull, censura e outras atividades maliciosas. -- **Problemas existentes**: dado que as bridges estão em fase inicial de desenvolvimento, existem muitas perguntas não respondidas relacionadas a como as bridges irão funcionar em diferentes condições de mercado, como tempos de congestionamento de rede e durante eventos imprevistos, como ataques a nível de rede ou estados de rollback. Esta incerteza comporta certos riscos, cujo grau ainda é desconhecido. +- **Risco de contrato inteligente –** Embora muitas pontes tenham sido aprovadas em auditorias, basta uma falha em um contrato inteligente para que os ativos fiquem expostos a hacks (ex.: a [Wormhole Bridge da Solana](https://rekt.news/wormhole-rekt/)). +- **Riscos financeiros sistêmicos –** Muitas pontes usam ativos encapsulados (wrapped assets) para cunhar versões canônicas do ativo original em uma nova rede. Isso expõe o ecossistema a riscos sistêmicos. Um exemplo foi o que aconteceu com versões encapsuladas de tokens. +- **Risco de contraparte –** Algumas pontes utilizam um design confiável que exige que os usuários confiem na premissa de que os validadores não entrarão em conluio para roubar os fundos dos usuários. A necessidade de os usuários confiarem nesses atores externos os expõe a riscos como rug pull, censura e outras atividades maliciosas. +- **Questões em aberto –** Como as pontes estão nos estágios iniciais de desenvolvimento, há muitas perguntas sem resposta relacionadas a como as pontes se comportarão em diferentes condições de mercado, como em momentos de congestionamento da rede e durante eventos imprevistos, como ataques no nível da rede ou reversões de estado. Esta incerteza comporta certos riscos, cujo grau ainda é desconhecido. ## Como os dApps podem usar bridges? {#how-can-dapps-use-bridges} Aqui estão algumas aplicações práticas que os desenvolvedores podem considerar sobre as bridges e levar seus dApps cross-chain: -### Como integrar bridges {#integrating-bridges} +### Integrando pontes {#integrating-bridges} Para desenvolvedores, há muitas maneiras adicionar suporte a bridges: -1. **Criar sua própria bridge**: criar uma bridge segura e confiável não é fácil, especialmente se sua abordagem considerar uma rota de confiança minimizada. Além disso, requer anos de experiência e conhecimento técnico em termos de dimensionamento e interoperabilidade. Adicionalmente, exigiria uma equipe ativa para manter uma bridge e atrair liquidez suficiente para torná-la viável. +1. **Construindo sua própria ponte –** Construir uma ponte segura e confiável não é fácil, especialmente se você seguir uma rota com confiança minimizada. Além disso, requer anos de experiência e conhecimento técnico em termos de dimensionamento e interoperabilidade. Adicionalmente, exigiria uma equipe ativa para manter uma bridge e atrair liquidez suficiente para torná-la viável. -2. **Oferecer aos usuários várias opções de bridge**: muitos [dapps](/developers/docs/dapps/) exigem que os usuários tenham o próprio token nativo para interagir com eles. Para permitir que os usuários acessem seus tokens, eles oferecem diferentes opções de bridge em seu site. No entanto, esse método é uma correção rápida para o problema, uma vez que leva o usuário para fora da interface do dapp e ainda requer que ele interaja com outros dapps e bridges. Trata-se de uma experiência pouco atraente e com maior probabilidade de erros. +2. **Mostrando aos usuários múltiplas opções de ponte –** Muitos [dapps](/developers/docs/dapps/) exigem que os usuários tenham seu token nativo para interagir com eles. Para permitir que os usuários acessem seus tokens, eles oferecem diferentes opções de bridge em seu site. No entanto, esse método é uma correção rápida para o problema, uma vez que leva o usuário para fora da interface do dapp e ainda requer que ele interaja com outros dapps e bridges. Trata-se de uma experiência pouco atraente e com maior probabilidade de erros. -3. **Integrar uma bridge**: esta solução não requer que o dapp envie usuários para a bridge externa e interfaces DEX. Ela permite que dapps melhorem a experiência de integração do usuário. No entanto, esta abordagem tem suas limitações: +3. **Integrando uma ponte –** Essa solução não exige que o dapp envie os usuários para a ponte externa e para as interfaces de DEX. Ela permite que dapps melhorem a experiência de integração do usuário. No entanto, esta abordagem tem suas limitações: - A avaliação e a manutenção das bridges são difíceis e demoradas. - Selecionar uma única bridge cria um ponto único de falha e dependência. - O dapp é limitado pelas capacidades da bridge. - Bridges por si só podem não ser suficientes. Os Dapps podem precisar de DEXs para oferecer mais funcionalidades, como swaps cross-chain. -4. **Integrar várias bridges**: esta solução resolve muitos problemas associados à integração de uma única bridge. No entanto, ela também tem limitações, já que integrar várias bridges consome recursos e cria sobrecargas técnicas e de comunicação para desenvolvedores, o recurso mais escasso em cripto. +4. **Integrando múltiplas pontes –** Essa solução resolve muitos problemas associados à integração de uma única ponte. No entanto, ela também tem limitações, já que integrar várias bridges consome recursos e cria sobrecargas técnicas e de comunicação para desenvolvedores, o recurso mais escasso em cripto. -5. **Integrar um agregador de bridge**: outra opção para dapps é integrar uma solução de agregação de bridges que permita a eles ter acesso a várias bridges. Agregadores de bridge herdam as forças de todas as bridges, e portanto, não são limitados pelas capacidades de uma única bridge. É importante observar que os agregadores de bridge normalmente mantêm as integrações da bridge, o que permite que o dapp não tenha que monitorar os aspectos técnicos e operacionais de uma integração de bridge. +5. **Integrando um agregador de pontes –** Outra opção para dapps é integrar uma solução de agregação de pontes que lhes dê acesso a múltiplas pontes. Agregadores de bridge herdam as forças de todas as bridges, e portanto, não são limitados pelas capacidades de uma única bridge. É importante observar que os agregadores de bridge normalmente mantêm as integrações da bridge, o que permite que o dapp não tenha que monitorar os aspectos técnicos e operacionais de uma integração de bridge. Dito isto, os agregadores de bridge também têm as suas limitações. Por exemplo, enquanto eles podem oferecer mais opções de bridge, há muitas outras bridges disponíveis no mercado, além das oferecidas na plataforma do agregador. Além disso, tal como as bridges, os agregadores de bridge também estão expostos a riscos de contratos inteligentes e tecnológicos, ou seja, uma maior quantidade de contratos inteligentes implica em mais riscos. Se um dapp for integrar uma bridge ou um agregador, existem diferentes opções com base no do grau de integração pretendido. Por exemplo, se for apenas uma integração front-end para melhorar a experiência de integração do usuário, um dapp integraria o widget. No entanto, se a integração é para conhecer mais em detalhes estratégias cross-chain, como staking, yield farming etc, o dapp integra o SDK ou API. -### Como implantar um dapp em múltiplas cadeias {#deploying-a-dapp-on-multiple-chains} +### Fazendo deploy de um dapp em múltiplas redes {#deploying-a-dapp-on-multiple-chains} -Para implantar um dapp em várias cadeias, os desenvolvedores podem usar plataformas de desenvolvimento como [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) etc. Normalmente, essas plataformas vêm com plugins compostos que podem habilitar dapps para cross-chain. Por exemplo, os desenvolvedores podem usar um proxy de implantação determinístico oferecido pelo [plugin hardhat-deploy](https://github.com/wighawag/hardhat-deploy). +Para fazer deploy de um dapp em múltiplas redes, os desenvolvedores podem usar plataformas de desenvolvimento como [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), etc. Normalmente, essas plataformas vêm com plugins compostos que podem habilitar dapps para cross-chain. Por exemplo, os desenvolvedores podem usar um proxy de implantação determinístico oferecido pelo [plugin hardhat-deploy](https://github.com/wighawag/hardhat-deploy). #### Exemplos: -- [Como criar dapps cross-chain](https://moralis.io/how-to-build-cross-chain-dapps/) -- [Como criar um marketplace de NFT cross-chain](https://youtu.be/WZWCzsB1xUE) -- [Moralis: Como criar dapps NFT cross-chain](https://www.youtube.com/watch?v=ehv70kE1QYo) +- [Como construir dapps de cross-chain](https://moralis.io/how-to-build-cross-chain-dapps/) +- [Construindo um Marketplace de NFT de Múltiplas Redes](https://youtu.be/WZWCzsB1xUE) +- [Moralis: Construindo dapps de NFT de múltiplas redes](https://www.youtube.com/watch?v=ehv70kE1QYo) -### Como monitorar atividades de contrato entre cadeias {#monitoring-contract-activity-across-chains} +### Monitorando a atividade de contratos entre redes {#monitoring-contract-activity-across-chains} -Para monitorar atividades de contrato entre cadeias, os desenvolvedores podem usar subgraphs e plataformas de desenvolvedores, como Tenderly, para acompanhar os contratos inteligentes em tempo real. Tais plataformas também têm ferramentas que oferecem melhor funcionalidade de monitoramento de dados para atividades cross-chain, tais como a busca por [eventos emitidos por contratos](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) etc. +Para monitorar atividades de contrato entre cadeias, os desenvolvedores podem usar subgraphs e plataformas de desenvolvedores, como Tenderly, para acompanhar os contratos inteligentes em tempo real. Essas plataformas também têm ferramentas que oferecem maior funcionalidade de monitoramento de dados para atividades entre redes, como a verificação de [eventos emitidos por contratos](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events), etc. #### Ferramentas @@ -122,14 +123,17 @@ Para monitorar atividades de contrato entre cadeias, os desenvolvedores podem us ## Leitura adicional {#further-reading} -- [Blockchain Bridges](/bridges/) – ethereum.org -- [Blockchain Bridges: Building Networks of Cryptonetworks](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 8 set., 2021 – Dmitriy Berenzon -- [The Interoperability Trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 1 out., 2021 – Arjun Bhuptani -- [Clusters: How Trusted & Trust-Minimized Bridges Shape the Multi-Chain Landscape](https://blog.celestia.org/clusters/) 4 out, 2021 – Mustafa Al-assam -- [LI.FI: With Bridges, Trust is a Spectrum](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 28 abril, 2022 – Arjun Chand +- [Pontes de Blockchain](/bridges/) – ethereum.org +- [Estrutura de Risco de Pontes do L2Beat](https://l2beat.com/bridges/summary) +- [Pontes de Blockchain: Construindo Redes de Cripto-redes](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 8 de setembro de 2021 – Dmitriy Berenzon +- [O Trilema da Interoperabilidade](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 1 de outubro de 2021 – Arjun Bhuptani +- [Clusters: Como as pontes confiáveis e com confiança minimizada moldam o cenário de múltiplas redes](https://blog.celestia.org/clusters/) - 4 de outubro de 2021 – Mustafa Al-Bassam +- [LI.FI: Com as pontes, a confiança é um espectro](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 28 de abril de 2022 – Arjun Chand +- [O estado das soluções de interoperabilidade de rollup](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 20 de junho de 2024 – Alex Hook +- [Aproveitando a segurança compartilhada para interoperabilidade segura entre redes: Comitês de Estado de Lagrange e além](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 12 de junho de 2024 – Emmanuel Awosika -Além disso, aqui estão algumas grandes apresentações úteis por[James Prestwich](https://twitter.com/_prestwich) que podem ajudar a desenvolver uma compreensão mais profunda das bridges: +Além disso, aqui estão algumas apresentações perspicazes de [James Prestwich](https://twitter.com/_prestwich) que podem ajudar a desenvolver uma compreensão mais profunda sobre pontes: -- [Building Bridges, Not Walled Gardens](https://youtu.be/ZQJWMiX4hT0) -- [Breaking Down Bridges](https://youtu.be/b0mC-ZqN8Oo) -- [Why are the Bridges Burning](https://youtu.be/c7cm2kd20j8) +- [Construindo Pontes, Não Jardins Murados](https://youtu.be/ZQJWMiX4hT0) +- [Analisando as Pontes](https://youtu.be/b0mC-ZqN8Oo) +- [Por que as Pontes Estão Queimando?](https://youtu.be/c7cm2kd20j8) diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/index.md index 58765e328f7..538a7948dc8 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/index.md @@ -1,20 +1,20 @@ --- title: Mecanismos de consenso -description: Uma explicação dos protocolos de consenso em sistemas distribuídos e o papel que desempenham no Ethereum. +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. +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 em 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/). +Para entender melhor esta página, recomendamos que você leia primeiro 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. +No que diz respeito à blockchain da Ethereum, o processo é formalizado, e alcançar o consenso significa que pelo menos 66% dos nós na rede concordam com o estado global da rede. ## O que é um mecanismo de consenso? {#what-is-a-consensus-mechanism} @@ -32,9 +32,9 @@ Esses componentes juntos formam o mecanismo de consenso. ### 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)**. +Assim como o Bitcoin, a Ethereum já usou um protocolo de consenso baseado em **prova de trabalho (PoW)**. -#### Criação de blocos {#pow-block-creation} +#### Criação de bloco {#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. @@ -46,9 +46,9 @@ 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)**. +A Ethereum agora usa um protocolo de consenso baseado em **prova de participação (PoS)**. -#### Criação de blocos {#pos-block-creation} +#### Criação de bloco {#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). @@ -68,21 +68,21 @@ Saiba mais sobre os diferentes tipos de mecanismos de consenso utilizados no Eth 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. +**A resistência a ataques Sybil** mede como um protocolo se comporta contra 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. +Uma **regra de seleção de cadeia** é usada para decidir qual cadeia é a "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. 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 de fork 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). +A Ethereum usa um mecanismo de consenso conhecido como [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) que combina a [prova de participação Casper FFG](https://arxiv.org/abs/1710.09437) com a [regra GHOST de escolha de bifurcação](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/) +- [O que é Consenso de Nakamoto? Guia completo para iniciantes](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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/poa/index.md index 8b22af17858..c5518051edd 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/poa/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/poa/index.md @@ -1,6 +1,6 @@ --- title: Prova de autoridade (PoA) -description: Uma explicação do protocolo de consenso de prova de autoridade e seu papel no ecossistema. +description: "Uma explicação do protocolo de consenso de prova de autoridade e seu papel no ecossistema." lang: pt-br --- @@ -77,3 +77,4 @@ Assista a uma explicação visual da prova de autoridade: - [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/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index 68395a28f94..f37960c6baf 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -1,6 +1,6 @@ --- -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. +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 --- @@ -12,7 +12,7 @@ Ladrões e sabotadores estão constantemente buscando oportunidades para atacar ## O que os atacantes querem? {#what-do-attackers-want} -Um equívoco comum é achar que um atacante bem-sucedido pode gerar um novo ether ou drenar ethers de contas arbitrárias. Nenhuma dessas duas situações é possível, pois todas as transações são executadas por todos os clientes de execução na rede. Elas devem satisfazer condições básicas de validade (por exemplo, transações são assinadas pela chave privada do remetente, o remetente tem saldo suficiente, etc.) ou então elas simplesmente são anuladas. Há três classes de resultado que um atacante pode visar realisticamente: reorgs, dupla finalidade ou atraso de finalidade. +Um equívoco comum é achar que um atacante bem-sucedido pode gerar um novo ether ou drenar ethers de contas arbitrárias. Nenhuma dessas duas situações é possível, pois todas as transações são executadas por todos os clientes de execução na rede. Elas devem satisfazer as condições básicas de validade (por exemplo, as transações são assinadas pela chave privada do remetente, o remetente tem saldo suficiente, etc.), caso contrário, elas simplesmente revertem. Há três classes de resultado que um atacante pode visar realisticamente: reorgs, dupla finalidade ou atraso de finalidade. Uma **“reorg”** é uma reorganização de blocos em uma nova ordem, possivelmente com a adição ou subtração de alguns blocos na cadeia padrão. Uma reorg 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 de finalidade”, que remove ou substitui blocos que foram previamente finalizados. Isso só é possível se mais de ⅓ do ether total em stake for destruído pelo atacante — esta garantia é conhecida como “finalidade econômica” — falaremos sobre isso mais tarde. @@ -58,11 +58,11 @@ Essencialmente, todos os ataques com pouco stake são variações sutis de dois #### reorgs {#reorgs} -Vários artigos descreveram ataques ao Ethereum que realizam reorgs ou atraso de finalidade com apenas uma pequena proporção do total de ethers em stake. Geralmente, esses ataques dependem de o atacante reter algumas informações de outros validadores e, em seguida, divulgá-las de maneira sutil e/ou em algum momento oportuno. Eles geralmente visam deslocar algum(ns) bloco(s) honesto(s) da cadeia padrão. [Neuder et al. 2020](https://arxiv.org/pdf/2102.02247.pdf) mostrou como um validador atacante pode criar e atestar um bloco ("B") para um determinado slot "n+1", mas evita propagá-lo para outros nós na rede. Em vez disso, eles mantêm o bloco atestado até o próximo slot "n+2". Um validador honesto propõe um bloco ("C") para o slot "n+2". Quase simultaneamente, o atacante pode liberar seu bloco retido ("B") e suas atestações retidas para ele, além de atestar que "B" é a cabeça da cadeia com seus votos para o slot "n+2", efetivamente negando a existência do bloco honesto "C". Quando o bloco honesto "D" é liberado, o algoritmo de escolha de fork vê "D" construindo sobre "B" como sendo mais pesado do que "D" construindo sobre "C". O atacante conseguiu, portanto, remover o bloco honesto "C" no slot "n+2" da cadeia padrão usando uma reorganização ex ante de 1 bloco. [Um atacante com 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) do stake tem uma chance muito alta de sucesso nesse ataque, como explicado [nesta nota](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). Em teoria, porém, esse ataque poderia ser tentado com stakes menores. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) descreveu esse ataque funcionando com 30% do stake, mas posteriormente foi demonstrado que ele é viável com [2% do stake total](https://arxiv.org/pdf/2009.04987.pdf) e, depois, até mesmo para um [único validador](https://arxiv.org/abs/2110.10086#) usando técnicas de balanceamento que examinaremos na próxima seção. +Vários artigos descreveram ataques ao Ethereum que realizam reorgs ou atraso de finalidade com apenas uma pequena proporção do total de ethers em stake. Geralmente, esses ataques dependem de o atacante reter algumas informações de outros validadores e, em seguida, divulgá-las de maneira sutil e/ou em algum momento oportuno. Eles geralmente visam deslocar algum(ns) bloco(s) honesto(s) da cadeia padrão. [Neuder et al. 2020 (https://arxiv.org/pdf/2102.02247.pdf) mostrou como um validador atacante pode criar e atestar um bloco (`B`) para um determinado slot `n+1`, mas evita propagá-lo para outros nós na rede. Em vez disso, eles mantêm o bloco atestado até o próximo slot `n+2`. Um validador honesto propõe um bloco (`C`) para o slot `n+2`. Quase simultaneamente, o atacante pode liberar seu bloco retido (`B`) e suas atestações retidas para ele, além de atestar que `B` é a cabeça da cadeia com seus votos para o slot `n+2`, efetivamente negando a existência do bloco honesto `C`. Quando o bloco honesto `D` é liberado, o algoritmo de escolha de fork vê `D` construindo sobre `B` como sendo mais pesado do que `D` construindo sobre `C`. O atacante conseguiu, portanto, remover o bloco honesto `C` no slot `n+2` da cadeia padrão usando uma reorganização ex ante de 1 bloco. [Um atacante com 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) do stake tem uma chance muito alta de sucesso nesse ataque, como explicado [nesta nota](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). Em teoria, porém, esse ataque poderia ser tentado com stakes menores. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) descreveu esse ataque funcionando com 30% do stake, mas posteriormente foi demonstrado que ele é viável com [2% do stake total](https://arxiv.org/pdf/2009.04987.pdf) e, depois, até mesmo para um [único validador](https://arxiv.org/abs/2110.10086#) usando técnicas de balanceamento que examinaremos na próxima seção. ![ex-ante re-org](reorg-schematic.png) -Um diagrama conceitual do ataque de reorg de um bloco descrito acima [adaptado de](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) +Um diagrama conceitual do ataque de reorg de um bloco descrito acima (adaptado de https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) Um ataque mais sofisticado pode dividir o conjunto do validador honesto em grupos discretos contendo visões diferentes da cabeça da cadeia. Isso é conhecido como um **ataque de balanceamento**. O atacante espera pela sua oportunidade de propor um bloco e, quando ela chega, engana e propõe dois. Ele envia um bloco para metade do conjunto do validador honesto e o outro bloco para a outra metade. O erro seria detectado pelo algoritmo de escolha de fork e o proponente de blocos seria reduzido e removido pela rede, mas os dois blocos ainda existiriam e teriam cerca de metade do conjunto validador atestando cada fork. Enquanto isso, os demais validadores maliciosos retêm suas atestações. Então, ao liberar seletivamente as atestações favorecendo um ou outro fork para apenas validadores suficientes no momento em que o algoritmo de escolha de fork é executado, eles inclinam o peso acumulado das atestações a favor de um ou outro fork. Isso pode continuar indefinidamente, com os validadores atacantes mantendo uma divisão igual de validadores entre os dois forks. Como nenhum fork pode atrair uma supermaioria de 2/3, a rede não seria finalizada. @@ -74,9 +74,9 @@ Tanto os ataques de salto, quanto os ataques de balanceamento, dependem de o ata 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 “reorgs baratas”, ou seja, tentativas feitas por um atacante com um stake pequeno. Na verdade, o próprio impulsionador do 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 atacante com 7% de stake pode implantar seus votos estrategicamente para enganar validadores honestos para construir sobre o 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 atacante, e o stake maior também significa mais capital em risco e um desincentivo econômico maior. +Vale notar que o proposer boosting, por si só, apenas defende contra “reorgs baratas”, ou seja, aquelas tentadas por um atacante com um stake pequeno. Na verdade, o próprio impulsionador do 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 atacante com 7% de stake pode implantar seus votos estrategicamente para enganar validadores honestos para construir sobre o 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 atacante, e o stake maior também significa mais capital em risco e um desincentivo econômico maior. -Um [ataque de balanceamento visando especificamente a regra LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) também foi proposto, e foi sugerido que ele é viável apesar do impulsionamento do proponente. Um atacante 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. +Um [ataque de balanceamento visando especificamente a regra LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) também foi proposto, e foi sugerido que ele é viável apesar do impulsionamento do proponente. Um atacante 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 ao [atualizar o algoritmo de escolha de fork](https://github.com/ethereum/consensus-specs/pull/2845) para descartar completamente os validadores que cometerem equívocos de consideração na 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. @@ -84,7 +84,7 @@ Outra classe de ataque, chamada de [**ataques de avalanche**](https://ethresear. 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 [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), na qual os atestadores congelam sua visão da escolha de fork "n" segundos antes do início de um slot e, em seguida, o proponente ajuda a sincronizar a visão da cadeia em toda a rede. Outra possível melhoria é a [finalidade em slot único](https://notes.ethereum.org/@vbuterin/single_slot_finality), que protege contra ataques baseados no tempo das mensagens ao finalizar a cadeia após apenas um slot. +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 [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), na qual os atestadores congelam sua visão da escolha de fork `n` segundos antes do início de um slot e, em seguida, o proponente ajuda a sincronizar a visão da cadeia em toda a rede. Outra possível melhoria é a [finalidade em slot único](https://notes.ethereum.org/@vbuterin/single_slot_finality), que protege contra ataques baseados no tempo das mensagens ao finalizar a cadeia após apenas um slot. #### Atraso de finalidade {#finality-delay} @@ -120,7 +120,7 @@ Com >50% do stake total, o atacante poderia dominar o algoritmo de escolha do fo ### Atacantes usando >=66% do stake total {#attackers-with-66-stake} -Um atacante com 66% ou mais do ether total em stake pode finalizar sua cadeia preferida sem ter que coagir nenhum validador honesto. O atacante pode simplesmente votar no seu fork preferido e depois finalizá-lo, simplesmente porque ele pode votar com uma supermaioria desonesta. Como detentor da supermaioria, o atacante 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 atacante está efetivamente comprando a capacidade de fazer reorganizações ex post e anulaçõ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 de 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. +Um atacante com 66% ou mais do ether total em stake pode finalizar sua cadeia preferida sem ter que coagir nenhum validador honesto. O atacante pode simplesmente votar no seu fork preferido e depois finalizá-lo, simplesmente porque ele pode votar com uma supermaioria desonesta. Como detentor da supermaioria, o atacante 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. Ao comprar ether adicional para controlar 66% em vez de 51%, o atacante está efetivamente comprando a capacidade de fazer reorganizações ex post e reversões de finalidade (ou seja, mudar o passado, bem como controlar o futuro). As únicas defesas reais aqui são o enorme custo de 66% do total de 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} @@ -130,9 +130,9 @@ Um dos pontos fortes do consenso de prova de participação do Ethereum é que e Seja qual for a penalidade imposta ao atacante, 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 atacantes 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 anuladas, perturbando a camada de aplicação, o que simplesmente compromete a ética de alguns usuários que tendem a acreditar que “código é lei”. Agências de câmbio e aplicações teriam provavelmente vinculado ações fora da cadeia a transações na cadeia, que agora podem ser anuladas, começando uma cascata de retratações e revisões que seria difícil de desfazer de forma justa, especialmente se os ganhos obtidos ilicitamente tiverem sido misturados, depositados em DeFi ou em outros derivados com efeitos secundários para usuários honestos. Sem dúvida que alguns usuários, talvez mesmo institucionais, já teriam se beneficiado da cadeia desonesta, seja por esperteza ou por acaso, e poderiam se opor a um fork para proteger seus ganhos. Houve pedidos para ensaiar a resposta da comunidade a ataques de >51% para que uma mitigação coordenada e sensata possa ser executada rapidamente. Há uma discussão útil de Vitalik no ethresear.ch [aqui](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) e [aqui](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) e no Twitter aqui. O objetivo de uma resposta social coordenada é o de ser muito direcionada e específica para punir o atacante e minimizar os efeitos para outros usuários. +No entanto, isso constituiria um desafio substancial em termos de governança. Alguns usuários e validadores certamente se perderiam ao retornar à cadeia honesta. As transações em blocos validados após o ataque poderiam ser anuladas, perturbando a camada de aplicação, o que simplesmente compromete a ética de alguns usuários que tendem a acreditar que “código é lei”. Agências de câmbio e aplicações teriam provavelmente vinculado ações fora da cadeia a transações na cadeia, que agora podem ser anuladas, começando uma cascata de retratações e revisões que seria difícil de desfazer de forma justa, especialmente se os ganhos obtidos ilicitamente tiverem sido misturados, depositados em DeFi ou em outros derivados com efeitos secundários para usuários honestos. Sem dúvida que alguns usuários, talvez mesmo institucionais, já teriam se beneficiado da cadeia desonesta, seja por esperteza ou por acaso, e poderiam se opor a um fork para proteger seus ganhos. Houve pedidos para ensaiar a resposta da comunidade a ataques de >51% para que uma mitigação coordenada e sensata possa ser executada rapidamente. Há uma discussão útil de Vitalik no ethresear.ch [aqui](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) e [aqui](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) e no Twitter [aqui](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 atacante e minimizar os efeitos para outros usuários. -Governança já é um tema complicado. Gerenciar uma resposta de emergência na Camada 0 para uma cadeia de finalização desonesta seria, sem dúvida, um desafio para a comunidade Ethereum, mas isso [já aconteceu](/ethereum-forks/#dao-fork-summary) — [duas vezes](/ethereum-forks/#tangerine-whistle) — na história da Ethereum. +Governança já é um tema complicado. Gerenciar uma resposta de emergência na Camada 0 para uma cadeia de finalização desonesta seria, sem dúvida, um desafio para a comunidade Ethereum, mas isso [já aconteceu](/ethereum-forks/#dao-fork-summary) — [duas vezes](/ethereum-forks/#tangerine-whistle) — na história da Ethereum). No entanto, há algo que é bastante satisfatório na última tentativa no mundo real. Por fim, mesmo com essa pilha fenomenal de tecnologia acima de nós, se o pior alguma vez acontecer, pessoas reais terão de coordenar a solução. diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attestations/index.md index d37ffa9b2c4..35ba9012abe 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attestations/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -1,6 +1,6 @@ --- -title: Atestações -description: Uma descrição de atestações em prova de participação Ethereum. +title: "Atestações" +description: "Uma descrição de atestações em prova de participação Ethereum." lang: pt-br --- @@ -8,31 +8,31 @@ Espera-se que um validador crie, assine e transmita uma atestação durante cada ## 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 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) +- `aggregation_bits`: uma bitlist de validadores onde a posição mapeia para o índice do validador em seu comitê; o valor (0/1) indica se o validador assinou o `data` (ou seja, se ele está ativo e concorda com o proponente de bloco) - `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: +A primeira tarefa de um validador de atestação é construir o `data`. O `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 +- `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ê no cabeçalho da cadeia (o resultado da aplicação do algoritmo de escolha de bifurcação) +- `source`: parte do voto de finalidade que indica o que os validadores veem como o bloco justificado mais recente +- `target`: parte do voto de finalidade que indica 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. +Depois que o `data` for construído, o validador pode inverter o bit no `aggregation_bits` correspondente ao seu próprio índice de validador de 0 para 1 para mostrar que participou. 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. +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 para que uma atestação transmitida inclua o `data` de consenso e uma única assinatura formada pela combinação das assinaturas de todos os validadores que concordam com esse `data`. Isso pode ser verificado usando `aggregation_bits`, pois isso fornece o índice de cada validador em seu comitê (cujo ID é fornecido em `data`), que pode ser usado 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. +Em cada época, 16 validadores em cada sub-rede são selecionados para serem os `agregadores`. Os agregadores coletam todas as atestações que recebem pela rede gossip que têm `data` equivalente aos seus. O remetente de cada atestação correspondente é registrado no `aggregation_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. @@ -64,29 +64,29 @@ A taxa de atestação do sinalizador é medida usando a soma dos saldos efetivos 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)` +`recompensa base = saldo efetivo do validador x 2^6 / SQRT(saldo efetivo de todos os validadores ativos)` -#### Atraso de inclusão {#inclusion-delay} +#### Atraso na 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. +No momento em que os validadores votaram no cabeçalho da cadeia (`bloco n`), o `bloco n+1` ainda não havia sido proposto. Portanto, as atestações são naturalmente incluídas **um bloco depois**, de modo que todas as atestações que votaram no `bloco n` como cabeçalho da cadeia foram incluídas no `bloco n+1`, e o **atraso na inclusão** é de 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} +#### Validador de votação ausente {#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} +#### Agregador ausente {#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. +Existem 16 Agregadores por época no total. Além disso, validadores aleatórios se inscrevem em **duas sub-redes por 256 épocas** e servem como backup caso os agregadores estejam ausentes. -#### Proponente de bloco faltante {#missing-block-proposer} +#### Proponente de bloco ausente {#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. +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 na 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 na especificação de consenso anotada do 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/block-proposal/index.md index 52527a8e786..2668b7b87ca 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/block-proposal/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -1,6 +1,6 @@ --- title: Proposta de bloqueio -description: Explicação de como os blocos são propostos na prova de participação do Ethereum. +description: "Explicação de como os blocos são propostos na prova de participação do Ethereum." lang: pt-br --- @@ -8,7 +8,7 @@ Os blocos são as unidades fundamentais da blockchain. Blocos são unidades disc ## 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/). +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 [prova de participação](/developers/docs/consensus-mechanisms/pos/) e [arquitetura de blocos](/developers/docs/blocks/). ## Quem produz os blocos? {#who-produces-blocks} @@ -18,7 +18,7 @@ Contas validadoras propõem blocos. Contas validadoras são gerenciadas por oper 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`). +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` (onde `N` = total de validadores ativos). Em vez disso, ele é ponderado pelo saldo de ETH efetivo de cada validador. O saldo efetivo máximo é de 32 ETH (isso significa que `balance < 32 ETH` leva a um peso menor do que `balance == 32 ETH`, mas `balance > 32 ETH` não leva a um peso maior do que `balance == 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”. @@ -42,9 +42,9 @@ class BeaconBlockBody(Container): 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 campo `randao_reveal` recebe um valor aleatório verificável que o propositor do bloco cria ao assinar o número da época atual. `eth1_data` é um voto para a visão do propositor do bloco sobre o contrato de depósito, incluindo a raiz da árvore de Merkle de depósito e o número total de depósitos que permitem que novos depósitos sejam verificados. `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 certos validadores cometeram ofensas passíveis de slashing de acordo com a visão da cadeia do propositor. `deposits` é uma lista de novos depósitos de validadores dos quais o propositor do bloco está ciente, e `voluntary_exits` é uma lista de validadores que desejam sair e dos quais o propositor do bloco ouviu falar na rede gossip 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 servem 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`. +O `execution_payload` permite que informações sobre transações sejam passadas entre os clientes de execução e de consenso. O `execution_payload` é um bloco de dados de execução que fica aninhado dentro de um bloco de beacon. Os campos dentro do `execution_payload` refletem a estrutura de blocos descrita no yellow paper do Ethereum, exceto que não há ommers e o `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. @@ -52,18 +52,18 @@ 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. +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` é desempacotado, e o cliente de execução do validador reexecuta as transações na lista para verificar a mudança de estado proposta. 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} +## Recompensas de 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. +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 propositor do bloco então recebe uma fração da `base_reward` para cada atestação válida incluída no bloco; quanto mais validadores atestarem o bloco, maior será a recompensa do propositor do bloco. Há também uma recompensa por denunciar validadores que deveriam sofrer slashing, igual a 1/512 \* saldo efetivo para cada validador que sofreu slashing. -[Recompensas e penalidades da PoS](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) +[Mais sobre recompensas e penalidades](/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/) +- [Especificações de consenso do Ethereum](https://github.com/ethereum/consensus-specs) +- [Introdução ao Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) - [Atualizando o Ethereum](https://eth2book.info/) diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/faqs/index.md index c66156b53a3..0db8a00edc6 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/faqs/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -1,6 +1,6 @@ --- title: Perguntas Frequentes -description: Perguntas frequentes sobre a prova de participação do Ethereum. +description: "Perguntas frequentes sobre a prova de participação do Ethereum." lang: pt-br --- @@ -18,7 +18,7 @@ A prova de participação requer nós, conhecidos como validadores, para enviar 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 comparação entre prova de trabalho e prova de participação é um tópico controverso. O [blog de 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. @@ -32,8 +32,8 @@ Sim. Os nós em uma rede com prova de participação usam uma pequena quantidade 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) +- [Mais sobre como defender a prova de participação do Ethereum contra invasores](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Mais sobre o projeto 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} @@ -50,7 +50,7 @@ Nós são computadores conectados à rede Ethereum. Clientes são o software que ## 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). +Não. Um usuário no 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} @@ -66,7 +66,7 @@ A combinação do Casper com o LMD_GHOST é conhecida como Gasper. 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) +[Mais sobre remoção](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) ## Por que os validadores precisam de 32 ETH? {#why-32-eth} @@ -74,34 +74,34 @@ Os validadores têm que colocar ETH em participação (stake) para que tenham al ## 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. +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 validador total definido. 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) +[Mais sobre a seleção de validadores](/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) +[Mais sobre 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) +- [Mais sobre 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) +[Mais sobre as 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) +[Mais sobre o problema do 'nada em jogo'](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} @@ -109,7 +109,7 @@ Um algoritmo de escolha de bifurcação (fork) implementa regras que determinam 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) +[Mais sobre o LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) ## Qual a finalidade da prova de participação? {#what-is-finality} @@ -127,19 +127,19 @@ A subjetividade fraca é um recurso de redes de prova de participação, em que 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) +[Mais sobre a separação proponente-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) +[Mais sobre ataques à 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) +[Leia mais sobre 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} @@ -147,9 +147,9 @@ Quanto mais ETH alguém tiver para colocar em participação (stake), mais os va ## 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. +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 (solo staking)](/staking/solo) é 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) +[Mais sobre a centralização de 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} @@ -163,10 +163,10 @@ Não, há várias blockchains que possuem prova de participação. No entanto, n 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) +[Mais sobre A Fusã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. +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. A segurança se refere a quão difícil é atacar a cadeia, ou seja, finalizar 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/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/gasper/index.md index 4a633193622..e93496bd22d 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/gasper/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -1,16 +1,16 @@ --- title: Gasper -description: Uma explicação do mecanismo de prova de participação do 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. +**Nota**: a definição original do Casper-FFG foi ligeiramente atualizada para inclusão no Gasper. Nesta página consideramos a versão atualizada. -## Pré-requisitos +## Pré-Requisitos -Para entender este material, é necessário ler a página introdutória em [prova de participação](/developers/docs/consensus-mechanisms/pos/). +Para entender este material, é necessário ler a página introdutória sobre [prova de participação](/developers/docs/consensus-mechanisms/pos/). ## O papel do Gasper {#role-of-gasper} @@ -23,30 +23,30 @@ Finalidade é uma propriedade de certos blocos que significa que eles não podem 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. +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 de supermaioria" deve existir entre dois checkpoints sucessivos (ou seja, dois terços do total de ether em stake votando 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). +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 do [Casper, o Gadget de Finalidade Amigável (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf). -### Incentivos e cortes {#incentives-and-slashing} +### Incentivos e Remoção {#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} +### Vazamento 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} +### Escolha de bifurcação {#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. +A definição original do Casper-FFG incluía um algoritmo de escolha de bifurcação que impunha a regra: `siga a cadeia que contém o checkpoint justificado que tem a maior altura`, onde 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} +## 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) +- [Gasper: Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper, o Gadget de Finalidade Amigável](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/index.md index 9ee5d73316d..437868396ce 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/index.md @@ -1,14 +1,14 @@ --- -title: Prova de participação (PoS) -description: Explicação do protocolo de consenso "Prova de participação" e seu papel no Ethereum. +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. +A Prova de participação (PoS) fundamenta o [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/). +Para entender melhor esta página, recomendamos que você leia primeiro sobre os [mecanismos de consenso](/developers/docs/consensus-mechanisms/). ## O que é prova de participação (PoS)? {#what-is-pos} @@ -20,38 +20,38 @@ Para participar como validador, um usuário deve depositar 32 ETH no contrato de 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} +## Como uma transação é executada no 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. +Abaixo está uma explicação completa de como uma transação é executada no proof-of-stake do 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 [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) etc., mas, no fundo, o 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. +1. Um usuário cria e assina uma [transação](/developers/docs/transactions/) com sua chave privada. Isso geralmente é tratado por uma carteira ou uma biblioteca como [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/), etc., mas, por baixo dos panos, o usuário está fazendo uma solicitação a um nó usando a [API JSON-RPC](/developers/docs/apis/json-rpc/) do Ethereum. 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 [gorjetas](/developers/docs/gas/#priority-fee) são pagas ao validador, enquanto a [taxa base](/developers/docs/gas/#base-fee) é queimada. +2. A transação é enviada para um [cliente de execução](/developers/docs/nodes-and-clients/#execution-client) do Ethereum, que verifica 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. Usuários avançados podem abster-se de transmitir sua transação e, em vez disso, encaminhá-la a construtores de blocos especializados, como o [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 de consenso é descrita com 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 próximo bloco lógico em sua visão da cadeia (o que significa que ele se baseia na cadeia com o maior peso de atestações, conforme definido nas [regras de escolha de 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} +## Finality {#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". +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". Este processo de atualização dos pontos de verificação é tratado pelo **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. O Casper-FFG é uma ferramenta de finalidade de bloco para consenso. Uma vez que um bloco é finalizado, ele não pode ser revertido ou alterado sem uma remoção da maioria dos stakers, tornando-o economicamente inviável. -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. +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. Há um mecanismo para se defender contra isso: o [vazamento por 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. +A quantidade de ETH reduzida depende de quantos validadores também estão sendo removidos ao mesmo tempo. Isso é conhecido como a ["penalidade de correlação"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), e pode ser pequena (\~1% de participação para um único validador removido por conta própria) 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} +## Escolha de 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. +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 é chamado [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), e funciona identificando a bifurcação que tem o maior peso de atestações em sua história. ## 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%. +A ameaça de um [ataque de 51%](https://www.investopedia.com/terms/1/51-attack.asp) ainda existe na prova de participação, assim como na prova de trabalho, mas é ainda mais arriscado para os atacantes. 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: @@ -64,12 +64,12 @@ No geral, a prova de participação, conforme implementada no Ethereum, demonstr ## 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 | | +| 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} @@ -84,14 +84,14 @@ O Ethereum originalmente usava prova de trabalho, mas mudou para prova de partic ## 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) +- [FAQ 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 é a Prova de Participação e por que ela é importante](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [Por que Prova de Participação (Nov 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [Prova de Participação: Como Aprendi a Amar a Subjetividade Fraca](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [Ataque e defesa na prova de participação do Ethereum](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Uma Filosofia de 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} diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md index 273fde5b8b7..24b780bf934 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -1,31 +1,31 @@ --- -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 +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). +As chaves do Ethereum são geradas usando [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} +## Os dois tipos de chaves de validador {#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**. +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 desejavam ser stakers solo também precisavam de uma **chave de validador** e uma **chave de saque**. -### A chave de validação {#validator-key} +### A chave do validador {#validator-key} A chave de assinatura de validação consiste em dois elementos: -- Chave de validação **privada** -- Chave de validação **pública** +- Chave **privada** do validador +- Chave **pública** do validador 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: +Essa flexibilidade tem a vantagem de mover as chaves de assinatura do validador muito rapidamente de um dispositivo para outro, no entanto, se elas forem perdidas ou roubadas, um ladrão pode **agir maliciosamente** de algumas maneiras: - Remover o validador por: - Ser um proponente e assinar dois blocos diferentes da beacon para o mesmo slot @@ -33,36 +33,36 @@ Essa flexibilidade tem a vantagem de mover rapidamente as chaves de assinatura d - 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. +A **chave pública do validador** é incluída nos dados da transação quando um usuário deposita ETH no contrato de depósito de staking. 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. +Todo validador tem uma propriedade conhecida como _credenciais de saque_. Este campo de 32 bytes começa com `0x00`, representando as credenciais de saque BLS, ou `0x01`, representando as 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`. +Os validadores com chaves `0x00` BLS devem atualizar essas credenciais para apontar para um endereço de execução, a fim de ativar pagamentos de saldo excedente ou saque total do staking. 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 {#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** +- Chave **privada** de saque +- Chave **pública** de saque -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. +Perder essa 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. -![esquema da chave de validação](validator-key-schematic.png) +![esquema de chave de validador](validator-key-schematic.png) -**Nota**: Sair das funções de staking e sacar o saldo de um validador atualmente requer a assinatura de uma [mensagem de saída voluntária (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) com a chave do validador. No entanto, o [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) é uma proposta que permitirá que um usuário acione a saída de um validador e saque seu saldo assinando mensagens de saída com a chave de saque no futuro. Isso reduzirá as suposições de confiança ao permitir que os participantes que delegam ETH a [provedores de staking como serviço](/staking/saas/#what-is-staking-as-a-service) mantenham o controle de seus fundos. +**Observação**: Sair das tarefas de staking e sacar o saldo de um validador atualmente exige a assinatura de uma [mensagem de saída voluntária (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) com a chave do validador. No entanto, o [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) é uma proposta que permitirá a um usuário acionar a saída de um validador e sacar seu saldo, assinando mensagens de saída com a chave de saque no futuro. Isso reduzirá as premissas de confiança, permitindo que stakers que delegam ETH a [provedores de staking como serviço](/staking/saas/#what-is-staking-as-a-service) permaneçam no controle de seus fundos. -## Obtendo chaves de uma frase semente {#deriving-keys-from-seed} +## Derivando 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. +[Mnemônicos](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) e caminhos são recursos proeminentes que os usuários costumam encontrar quando [acessam](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 os padrões [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 baseada em mnemônicos. Esses caminhos possuem a seguinte estrutura, que será familiar para usuários que já interagiram com carteiras de hardware: @@ -76,7 +76,7 @@ As barras nesse caminho separam os componentes da chave privada da seguinte form 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. +Essa lógica permite que os usuários anexem 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 nos ramos. O usuário pode **derivar qualquer número de chaves** da frase mnemônica. ``` [m / 0] @@ -88,13 +88,13 @@ Essa lógica permite aos usuários anexar o maior número possível de validador [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. +Cada ramo é separado por `/`, então `m/2` significa começar com a chave mestra e seguir o ramo 2. No esquema abaixo, uma única frase mnemônica é usada para armazenar três chaves de saque, cada uma com dois validadores associados. -![lógica da chave de validação](multiple-keys.png) +![lógica da chave do validador](multiple-keys.png) ## 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) -- [EIP-7002: Saídas acionadas pela camada de execução](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Postagem no blog da Ethereum Foundation por Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 Geração de chave BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: Saídas acionadas pela Camada de Execução](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) - [Gerenciamento de chaves em escala](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md index 5f774fa10ab..1f6edbf34e2 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -1,6 +1,6 @@ --- -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 +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 --- @@ -12,7 +12,7 @@ Esta página explica a lógica por trás da mudança do Ethereum para prova de p 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} +### Custo para atacar {#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. @@ -20,11 +20,11 @@ Atacar a rede pode significar impedir a cadeia de finalizar ou garantir uma cert 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. +Com >33% da participação total, um atacante tem a chance de ter um efeito menor (atraso de finalização) ou mais grave (finalização dupla) na rede Ethereum. Com mais de 14.000.000 de ETH em participação na rede e um preço representativo de $1000/ETH, o custo mínimo para montar esses ataques é de `1000 x 14,000,000 x 0.33 = $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 (a $1000/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 é limitada não apenas pela taxa com que o atacante pode acumular >33% da participação total, mas também pelo tempo que leva para integrar todos os seus validadores na 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. +Compare isso com a prova de trabalho. O custo de lançar um ataque no Ethereum com prova de trabalho era o custo de possuir consistentemente >50% da taxa de hash total 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% é ~[20x 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} @@ -32,7 +32,7 @@ A prova de participação é muito mais complexa do que a prova de trabalho. Iss 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} +### 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. @@ -50,7 +50,7 @@ A melhor opção para o Ethereum é que os validadores sejam executados localmen 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) +[Mais sobre o consumo de energia da Ethereum](/energy-consumption) ## Emissão {#issuance} @@ -64,6 +64,6 @@ Assista Justin Drake explicando os benefícios da prova de participação em rel ## 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) +- [Filosofia de design de prova de participação de Vitalik](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Perguntas frequentes sobre prova de participação de Vitalik](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [Vídeo "Simply Explained" sobre pos vs pow](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index d0f64d36a63..a9200bb2c23 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -1,10 +1,10 @@ --- -title: Recompensas e penalidades na prova de participação -description: Saiba mais sobre os incentivos no protocolo da prova de participação Ethereum. +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. +Ethereum é protegido usando sua criptomoeda nativa, ether (ETH). 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/) no 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. @@ -18,51 +18,51 @@ Leia para obter mais detalhes... ### 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: +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 é calculado a partir de uma `base_reward`. Essa é a unidade base a partir da qual outras recompensas são calculadas. A `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. +onde `base_reward_factor` é 64, `base_rewards_per_epoch` é 4 e `sum(active balance)` é o total de ether em stake de 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). +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 [anotações 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 +1. voto de origem: o validador votou oportunamente no checkpoint de origem correto +2. voto de destino: o validador votou oportunamente no checkpoint de destino correto +3. voto de cabeçalho: o validador votou oportunamente no 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 +5. recompensa do propositor: 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) +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`. +Esses pesos somam 64. A recompensa é calculada como a soma dos pesos aplicáveis dividido por 64. Um validador que tenha feito votos de origem, destino e cabeçalho oportunos, proposto um bloco e participado de um comitê de sincronização pode receber `64/64 * base_reward == base_reward`. No entanto, um validador geralmente não é um propositor de bloco, portanto, sua recompensa máxima é `64-8 /64 * base_reward == 7/8 * base_reward`. Validadores que não são propositores 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. +Uma recompensa adicional é incluída para incentivar atestações rápidas. Esta é a `inclusion_delay_reward`. Isso tem um valor igual à `base_reward` multiplicada por `1/delay`, em que `delay` é o número de slots que separam a proposta de bloco e a atestação. Por exemplo, se a atestação for enviada dentro de um slot da proposta de bloco, o atestador recebe `base_reward * 1/1 == base_reward`. Se a atestação chegar no próximo slot, o atestador recebe `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`. +Os propositores de bloco recebem `8 / 64 * base_reward` para **cada atestação válida** incluída no bloco, de modo que o valor real da recompensa escala 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 propositor de bloco que inclui slashing será recompensado com `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. +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çalho 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/master/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). +Leia mais sobre recompensas e penalidades nas [especificações de consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). As recompensas e penalidades foram ajustadas na atualização Bellatrix. Assista a Danny Ryan e Vitalik discutirem sobre isso neste [vídeo Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). -## Remoção {#slashing} +## Slashing {#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: @@ -70,9 +70,9 @@ Remoção é uma ação mais severa que resulta na remoção forçada de um vali - 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”. +Se essas ações forem detectadas, o validador é removido. Isso significa que 0,0078125 é imediatamente queimado para um validador de 32 ETH (escalado linearmente com saldo ativo), então um período de remoção de 36 dias começa. 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. O slashing máximo é o saldo efetivo total de todos os validadores que sofreram slashing (ou seja, se muitos validadores sofrerem slashing, eles podem perder todo o seu stake). 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} +## Vazamento por 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! @@ -82,9 +82,9 @@ O design de recompensa, penalidade e corte do mecanismo de consenso incentiva os - [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) -- [Análise das penalidades de remoção sob o EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) +- [Especificação comentada de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Dicas de prevenção de slashing do Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Análise das penalidades de slashing sob o EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) _Fontes_ diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md index a001e71118c..19da9a79bfe 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -1,14 +1,14 @@ --- title: Subjetividade fraca -description: Uma explicação de subjetividade fraca e o seu papel na prova de participação do Ethereum. +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} +## Pré-requisitos {#prerequisites} -Para entender esta página é necessário primeiro entender os fundamentos de [prova de participação](/developers/docs/consensus-mechanisms/pos/). +Para entender esta página, é necessário primeiro entender os fundamentos da [prova de participação](/developers/docs/consensus-mechanisms/pos/). ## Quais são os problemas que a subjetividade fraca resolve? {#problems-ws-solves} @@ -16,7 +16,7 @@ A subjetividade é inerente às blockchains de prova de participação porque 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. +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 ao mesmo propósito de "verdade universal" dos blocos iniciais, exceto que não ficam 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} @@ -32,8 +32,8 @@ Finalmente, os pontos de verificação podem ser solicitados a partir de outros ## 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/master/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) +- [Subjetividade fraca no Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik: Como aprendi a amar a subjetividade fraca](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Subjetividade fraca (docs do Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Guia de subjetividade fraca da Fase 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Análise da 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/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/index.md index 83ce699a367..5417e9297a2 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/index.md @@ -1,27 +1,27 @@ --- title: Prova de trabalho (PoW) -description: Uma explicação do protocolo de consenso de prova de trabalho e seu papel no Ethereum. +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 rede Ethereum começou usando um mecanismo de consenso que envolvia a **[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 passou 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](/developers/docs/consensus-mechanisms/pos/) e [participação](/staking/). + 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 em [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e [staking](/staking/). ## 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/). +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 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/). +O consenso de Nakamoto, que utiliza a prova de trabalho, é o mecanismo que permitiu que a rede descentralizada do Ethereum chegasse a um consenso (isto é, que todos os nós concordassem) sobre questões 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} @@ -39,7 +39,7 @@ As transações Ethereum são processadas em blocos. Na agora obsoleta prova de Esses dados de bloco estavam diretamente relacionados à prova de trabalho. -### O trabalho em prova-de-trabalho {#the-work} +### O trabalho na 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. @@ -57,31 +57,31 @@ O objetivo da prova de trabalho era estender a cadeia. A cadeia mais longa era m 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} +### Economia 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](/ethereum-forks/#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. +Desde a [atualização Constantinople](/ethereum-forks/#constantinople), os mineradores que criaram blocos com sucesso 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} +## Finality {#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. +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, "finalidade" se refere ao tempo que você deve esperar antes de considerar uma transação irreversível. No Ethereum com prova de trabalho anterior, quanto mais blocos fossem minerados sobre 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} +## Uso de energia da 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). +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 da mudança 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 o [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. | +| 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. Com a [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} @@ -92,7 +92,7 @@ Em termos gerais, a prova de participação tem o mesmo objetivo final que a pro - 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/) +[Mais sobre a prova de participação](/developers/docs/consensus-mechanisms/pos/) ## Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner} @@ -100,8 +100,8 @@ Em termos gerais, a prova de participação tem o mesmo objetivo final que a pro ## 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) +- [Ataque de maioria](https://en.bitcoin.it/wiki/Majority_attack) +- [Sobre a finalidade da liquidação](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) ### Vídeos {#videos} diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/index.md index e4d080759df..0aac89c90de 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -1,6 +1,6 @@ --- -title: Mineração -description: Uma explicação de como a mineração funcionava no Ethereum. +title: "Mineração" +description: "Uma explicação de como a mineração funcionava no Ethereum." lang: pt-br --- @@ -8,14 +8,14 @@ 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. +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 de 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/). +Para entender melhor esta página, recomendamos que você leia primeiro sobre [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} @@ -42,30 +42,30 @@ Anteriormente, qualquer era capaz de minerar na rede Ethereum usando seu computa - 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). +Para explorar ainda mais a rentabilidade da mineração, use uma calculadora de mineração, como a que o [Etherscan](https://etherscan.io/ether-mining-calculator) oferece. ## 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). +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 do 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/). +2. O usuário transmite a solicitação de transação para toda a rede Ethereum a partir 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. +4. Em algum momento, um nó de mineração agrega várias dezenas ou centenas de solicitações de transação em um [bloco](/developers/docs/blocks/) potencial, de uma forma que maximize as [taxas de transação](/developers/docs/gas/) que ele ganha, enquanto ainda permanece abaixo do limite de gás do bloco. Então, o nó de mineração: + 1. Verifica a validade de cada solicitação de transação (ou seja, ninguém está tentando transferir 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 da 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 **. +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). +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 incentivou 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. +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 a 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} @@ -75,7 +75,7 @@ Acompanhe o Austin enquanto ele explica como funciona o processo de mineração ## 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/). +A rede principal do Ethereum sempre usou apenas um algoritmo de mineração - ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). O Ethash foi o sucessor de um algoritmo de P&D original 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/). diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md index 84ae914d111..37899ccb0e8 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -4,32 +4,32 @@ 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. +Dagger-Hashimoto foi a implementação original de pesquisa e especificação para o algoritmo de mineração do Ethereum. O Dagger-Hashimoto foi substituído pelo [Ethash](#ethash). A mineração foi completamente desligada em [A Fusão](/roadmap/merge/) em 15 de setembro de 2022. Desde então, o Ethereum tem sido protegido usando um mecanismo de [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} +## 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). +Para entender melhor esta página, recomendamos que você leia primeiro sobre [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. +1. **Resistência a ASIC**: o benefício de criar hardware especializado para o algoritmo deve ser o menor possível +2. **Verificabilidade de cliente leve**: um bloco deve ser eficientemente verificável 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). +**Armazenamento completo da cadeia**: a mineração deve exigir o armazenamento do estado completo da blockchain (devido à estrutura irregular da trie de estado do Ethereum, prevemos que alguma poda será possível, particularmente de alguns contratos usados com frequência, mas queremos minimizar isso). -## Geração do DAG {#dag-generation} +## Geração de 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: +O código do algoritmo será definido em Python abaixo. Primeiro, apresentamos o `encode_int` para o empacotamento (marshaling) de 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" + "Codifica um inteiro x como uma string de 64 caracteres usando um esquema big-endian" o = '' for _ in range(NUM_BITS / 8): o = chr(x % 256) + o @@ -37,7 +37,7 @@ def encode_int(x): return o def decode_int(s): - "Unencode an integer x from a string using a big-endian scheme" + "Decodifica um inteiro x de uma string usando um esquema big-endian" x = 0 for c in s: x *= 256 @@ -45,7 +45,7 @@ def decode_int(s): 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: +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 estiver convertendo este código de referência em uma implementação, use: ```python from pyethereum import utils @@ -65,26 +65,26 @@ def dbl_sha3(x): Os parâmetros usados para o algoritmo são: ```python -SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512 +SAFE_PRIME_512 = 2**512 - 38117 # O maior primo seguro menor que 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 + "n": 4000055296 * 8 // NUM_BITS, # Tamanho do conjunto de dados (4 Gigabytes); DEVE SER MÚLTIPLO DE 65536 + "n_inc": 65536, # Incremento no valor de n por período; DEVE SER MÚLTIPLO DE 65536 + # com epochtime=20000 resulta em um crescimento de 882 MB por ano + "cache_size": 2500, # Tamanho do cache do cliente leve (pode ser escolhido pelo cliente + # leve; não faz parte da especificação do algoritmo) + "diff": 2**14, # Dificuldade (ajustada durante a avaliação do bloco) + "epochtime": 100000, # Duração de uma época em blocos (com que frequência o conjunto de dados é atualizado) + "k": 1, # Número de pais de um nó + "w": w, # Usado para hashing de exponenciação modular + "accesses": 200, # Número de acessos ao conjunto de dados durante o hashimoto + "P": SAFE_PRIME_512 # Primo Seguro para hashing e geração de números aleatórios } ``` -`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. +`P` neste caso é um primo escolhido tal que `log₂(P)` é apenas um pouco menor que 512, o 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} +### Construção do grafo Dagger {#dagger-graph-building} A construção primitiva de gráfico dagger é definida da seguinte forma: @@ -101,11 +101,11 @@ def produce_dag(params, seed, length): 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. +Essencialmente, ele inicia um grafo como um único nó, `sha3(seed)`, e a partir daí começa a adicionar sequencialmente outros nós com base em nós anteriores aleatórios. Quando um novo nó é criado, uma potência modular da semente é computada para selecionar aleatoriamente alguns índices menores que `i` (usando `x % i` acima), e os valores dos nós nesses índices são usados em um cálculo para gerar um novo valor para `x`, que é então alimentado em uma pequena função de prova de trabalho (baseada em XOR) para finalmente gerar o valor do grafo 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} +## Avaliação do 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. @@ -131,11 +131,11 @@ def quick_calc(params, seed, 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. +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 adicional na verdade pré-compute os primeiros milhares de valores do DAG e mantenha isso como um cache estático para computações; veja 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. +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 os DAGs sejam 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: @@ -164,7 +164,7 @@ 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 + # Nenhum buffer traseiro é possível, apenas crie o buffer frontal return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), "block_number": 0}} else: @@ -256,54 +256,50 @@ Além disso, note que Dagger-Hashimoto impõe requisitos adicionais no cabeçalh ## Leitura adicional {#further-reading} -_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## 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. +Como mencionado acima, o RNG usado para geração de DAGs depende de alguns resultados da teoria de números. Primeiro, fornecemos a garantia de que o Lehmer RNG, que é a base para a variável `picker`, tem um período amplo. Segundo, mostramos que `pow(x,3,P)` não mapeará `x` para `1` ou `P-1`, desde que `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} +### Gerador de números aleatórios de 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. +Embora a função `produce_dag` não precise produzir números aleatórios imparciais, uma ameaça em potencial é que `seed**i % P` assuma apenas 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
+Para evitar isso, apela-se a um resultado da teoria dos números. Um [_Primo Seguro_](https://en.wikipedia.org/wiki/Safe_prime) é definido como um primo `P` 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) `ℤ/nℤ` é definida como o `m` mínimo 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`. +> Observação 1. Seja `x` um membro do grupo multiplicativo `ℤ/Pℤ` para um primo seguro `P`. 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`. +_Prova_. Como `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: +A ordem de `x` não pode ser `1`, uma vez que, pelo Pequeno Teorema de Fermat, 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. +Portanto, `x` deve ser uma identidade multiplicativa de `ℤ/nℤ`, que é única. Como assumimos 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 ordem de `x` não pode ser `2` a menos que `x = P-1`, pois isso violaria o fato de `P` ser 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. +A partir da proposição acima, podemos reconhecer que a iteração de `(picker * init) % P` terá um comprimento de ciclo de pelo menos `(P-1)/2`. Isso ocorre 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 devemos 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: +Quando estamos atribuindo a primeira célula no DAG (a variável rotulada `init`), nós computamos `pow(sha3(seed) + 2, 3, P)`. À primeira vista, isso não garante que o resultado não seja nem `1` nem `P-1`. No entanto, como `P-1` é um primo seguro, temos a seguinte garantia adicional, que é um corolário 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` +> Observação 2. Seja `x` um membro do grupo multiplicativo `ℤ/Pℤ` para um primo seguro `P`, e seja `w` um número natural. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, bem 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} +### Exponenciação modular como uma função de 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}`. +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)` só assume os 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: +Dado que `P` é primo, um `w` apropriado para uma função de hashing de exponenciação modular pode ser escolhido 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` ->
+> Observação 3. Seja `P` um primo; `w` e `P-1` são primos entre si se, e somente se, para todo `a` e `b` em `ℤ/Pℤ`:
`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. +Assim, dado que `P` é primo e `w` é primo em relação a `P-1`, temos que `|{pow(x, w, P) : x ∈ ℤ}| = P`, o que implica que a função de hashing tem a taxa de colisão mínima 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. +No caso especial em que `P` é um primo seguro, como o que selecionamos, `P-1` tem apenas os fatores 1, 2, `(P-1)/2` e `P-1`. Como `P` > 7, sabemos que 3 é primo em relação a `P-1`, portanto `w=3` satisfaz a proposição acima. -## Algoritmo de avaliação baseado em cache mais eficiente {#cache-based-evaluation} +## Algoritmo de avaliação mais eficiente baseado em cache {#cache-based-evaluation} ```python def quick_calc(params, seed, p): diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index 80acd9a4c94..55bd00f8917 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -1,6 +1,6 @@ --- title: Ethash -description: O algoritmo de mineração Ethash em detalhes +description: "O algoritmo de mineração Ethash em detalhes" lang: pt-br --- @@ -8,12 +8,12 @@ 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](/developers/docs/consensus-mechanisms/pos/). Leia mais sobre [A Fusão](/roadmap/merge/) (The Merge), [prova de participação](/developers/docs/consensus-mechanisms/pos/) e [participação (stake)](/staking/). Esta página é de interesse histórico! + Ethash foi o algoritmo de mineração da prova de trabalho do Ethereum. A prova de trabalho foi **totalmente desativada** e o Ethereum agora é protegido usando a [prova de participação](/developers/docs/consensus-mechanisms/pos/) em vez disso. Leia mais sobre [The Merge](/roadmap/merge/), [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e [staking](/staking/). Esta página é de interesse histórico! -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. +Ethash é uma versão modificada do algoritmo [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). A prova de trabalho do Ethash tem [uso intensivo de memória](https://wikipedia.org/wiki/Memory-hard_function), o que se pensava que tornaria o algoritmo resistente a ASICs. 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} @@ -21,9 +21,9 @@ Dificuldade de memória é alcançada com um algoritmo de prova de trabalho que 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. +1. Existe uma **seed** que pode ser calculada para cada bloco, escaneando os cabeçalhos do bloco até esse ponto. +2. A partir da seed, pode-se calcular um **cache pseudoaleatório 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 de 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. @@ -33,23 +33,26 @@ O grande conjunto de dados é atualizado uma vez a cada 30.000 blocos, então o 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 +WORD_BYTES = 4 # bytes em palavra +DATASET_BYTES_INIT = 2**30 # bytes no conjunto de dados na gênese +DATASET_BYTES_GROWTH = 2**23 # crescimento do conjunto de dados por época +CACHE_BYTES_INIT = 2**24 # bytes em cache na gênese +CACHE_BYTES_GROWTH = 2**17 # crescimento do cache por época +CACHE_MULTIPLIER=1024 # Tamanho do DAG em relação ao cache +EPOCH_LENGTH = 30000 # blocos por época +MIX_BYTES = 128 # largura da mistura +HASH_BYTES = 64 # comprimento do hash em bytes +DATASET_PARENTS = 256 # número de pais de cada elemento do conjunto de dados +CACHE_ROUNDS = 3 # número de rodadas na produção de cache +ACCESSES = 64 # número de acessos no loop hashimoto ``` ### 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). +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, p. ex., [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. @@ -83,12 +86,12 @@ Agora, especificamos a função para produzir um cache: def mkcache(cache_size, seed): n = cache_size // HASH_BYTES - # Sequentially produce the initial dataset + # Produzir sequencialmente o conjunto de dados inicial o = [sha3_512(seed)] for i in range(1, n): o.append(sha3_512(o[-1])) - # Use a low-round version of randmemohash + # Usar uma versão de poucas rodadas do randmemohash for _ in range(CACHE_ROUNDS): for i in range(n): v = o[i][0] % n @@ -97,11 +100,11 @@ def mkcache(cache_size, seed): 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. +O processo de produção de cache envolve primeiro preencher sequencialmente 32 MB de memória e, em seguida, realizar 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. +Usamos um algoritmo inspirado no [hash FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) em alguns casos como um substituto não associativo para 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 @@ -120,11 +123,11 @@ Cada item de 64 bytes no conjunto de dados completo de 1 GB é calculado da segu def calc_dataset_item(cache, i): n = len(cache) r = HASH_BYTES // WORD_BYTES - # initialize the mix + # inicializar a mistura 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 + # aplicar fnv com muitos nós de cache aleatórios com base em i for j in range(DATASET_PARENTS): cache_index = fnv(i ^ j, mix[j % r]) mix = map(fnv, mix, cache[cache_index % n]) @@ -140,27 +143,27 @@ def calc_dataset(full_size, cache): ## 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: +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 que exclui os campos **mixHash** e **nonce**. `nonce` são os oito bytes de um inteiro sem sinal de 64 bits em 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 + # combinar header+nonce em uma seed de 64 bytes s = sha3_512(header + nonce[::-1]) - # start the mix with replicated s + # iniciar a mistura com s replicado mix = [] for _ in range(MIX_BYTES / HASH_BYTES): mix.extend(s) - # mix in random dataset nodes + # misturar em nós de conjunto de dados aleatórios 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 + # comprimir mistura 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])) @@ -176,9 +179,9 @@ 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. +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. +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 verificação rápida de PoW externa 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} @@ -186,7 +189,7 @@ 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 + # preencher com zeros o alvo para comparar com o hash no mesmo dígito target = zpad(encode_int(2**256 // difficulty), 64)[::-1] from random import randint nonce = randint(0, 2**64) @@ -195,7 +198,7 @@ def mine(full_size, dataset, header, difficulty): return nonce ``` -## Definição do hash seed {#seed-hash} +## Definindo o hash da seed {#seed-hash} Para calcular o hash seed que seria usado para minerar no topo de um determinado bloco, usamos o seguinte algoritmo: @@ -211,7 +214,7 @@ Observe que, para que a mineração e a verificação aconteçam sem contratempo ## Leitura adicional {#further-reading} -_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Apêndice {#appendix} @@ -220,7 +223,7 @@ O código a seguir deve ser precedido se você estiver interessado em executar a ```python import sha3, copy -# Assumes little endian bit ordering (same as Intel architectures) +# Assume a ordem de bits little endian (a mesma das arquiteturas Intel) def decode_int(s): return int(s[::-1].encode('hex'), 16) if s else 0 @@ -248,7 +251,7 @@ def serialize_cache(ds): serialize_dataset = serialize_cache -# sha3 hash function, outputs 64 bytes +# função de hash sha3, produz 64 bytes def sha3_512(x): return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) @@ -265,7 +268,7 @@ def isprime(x): return True ``` -### Tamanho dos dados {#data-sizes} +### Tamanhos 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. @@ -993,7 +996,7 @@ cache_sizes = [ 265287488, 265418432, 265550528, 265681216, 265813312, 265943488, 266075968, 266206144, 266337728, 266468032, 266600384, 266731072, 266862272, 266993344, 267124288, 267255616, 267386432, 267516992, -267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +267648704, 26777728, 267910592, 268040512, 268172096, 268302784, 268435264, 268566208, 268696256, 268828096, 268959296, 269090368, 269221312, 269352256, 269482688, 269614784, 269745856, 269876416, 270007616, 270139328, 270270272, 270401216, 270531904, 270663616, diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md index 1ef0b1ea911..9fddd7cb895 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -1,6 +1,6 @@ --- -title: Algoritmos de mineração -description: Os algoritmos usados para mineração Ethereum +title: "Algoritmos de mineração" +description: "Os algoritmos usados para mineração Ethereum" lang: pt-br --- @@ -8,24 +8,24 @@ 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 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 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} +## 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). +Para entender melhor esta página, recomendamos que você leia primeiro sobre o [consenso de 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. +[Dagger](http://www.hashcash.org/papers/dagger.html) envolve a geração de um [Grafo Acíclico Dirigido](https://en.wikipedia.org/wiki/Directed_acyclic_graph), cujas fatias aleatórias são combinadas por hash. 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. +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) é um algoritmo que adiciona resistência a ASICs por ser vinculado a E/S (isto é, as 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. @@ -33,9 +33,9 @@ Mais sobre [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/m ## 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. +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. O 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). +[Mais sobre o Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). ## Leitura adicional {#further-reading} diff --git a/public/content/translations/pt-br/developers/docs/dapps/index.md b/public/content/translations/pt-br/developers/docs/dapps/index.md index 0e3bcc4e169..f48548f24cb 100644 --- a/public/content/translations/pt-br/developers/docs/dapps/index.md +++ b/public/content/translations/pt-br/developers/docs/dapps/index.md @@ -1,47 +1,47 @@ --- -title: Introdução à aplicativos descentralizados (dapps) +title: "Introdução Técnica aos 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. +Um aplicativo descentralizado (dapp) é um aplicativo criado 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. +Antes de aprender sobre dapps, você deve entender sobre os fundamentos da blockchain, ler sobre a [rede Ethereum](/developers/docs/intro-to-ethereum/) e como ela é descentralizada. -## Definição de dapp {#definition-of-a-dapp} +## Definição de um 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/). +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, seu front-end pode ser hospedado em armazenamento descentralizado, como o [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 +- **Descentralizado** – os dapps operam no Ethereum, uma plataforma pública descentralizada e aberta, onde nenhuma pessoa ou grupo tem controle +- **Determinístico** – os dapps executam a mesma função, independentemente do ambiente em que são executados +- **Turing completo** – os dapps podem executar qualquer ação, considerando os recursos necessários +- **Isolado** – os dapps são executados em um ambiente virtual conhecido como Máquina Virtual Ethereum para que, se o contrato inteligente tiver um bug, ele não prejudique 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/). +Para introduzir dapps, precisamos introduzir contratos inteligentes (que são dapps de back-end, para assim dizer). Para uma visão geral detalhada, acesse 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. +- **Tempo de inatividade zero** – uma vez que o contrato inteligente é implantado na blockchain, a rede como um todo sempre será capaz de atender aos 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 uma identidade do mundo real para implantar ou interagir com um dapp. +- **Resistência à censura** – Nenhuma entidade única na rede pode impedir que os usuários enviem transações, implantem dapps ou leiam dados da blockchain. +- **Integridade total dos dados** – Os dados armazenados na blockchain são imutáveis e indisputáveis, graças às primitivas criptográficas. 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 a garantia de serem executados 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. ## Desvantagens 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. +- **Manutenção** – Pode ser mais difícil manter os Dapps 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. +- **Sobrecarga de desempenho** – Há uma enorme sobrecarga de 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** – Quando um dapp usa muitos recursos computacionais, toda a rede fica sobrecarregada. 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 fáceis de usar, pois o usuário final médio pode achar muito difícil configurar a pilha de ferramentas necessária para interagir com a blockchain de uma forma verdadeiramente segura. +- **Centralização** – Soluções amigáveis ao usuário e ao desenvolvedor, construídas sobre a camada de base da Ethereum, podem acabar parecendo serviços centralizados de qualquer maneira. 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} @@ -49,32 +49,32 @@ Um contrato inteligente é um código presente na blockchain Ethereum e funciona ## Ferramentas para criar dapps {#dapp-tools} -**Scaffold-ETH _: experimente rapidamente com Solidity usando um front-end que se adapta ao seu contrato inteligente._** +**Scaffold-ETH** _– Experimente rapidamente 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._** +**Create Eth App** _– Crie aplicativos baseados em Ethereum com um único 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)._** +**One Click Dapp** _– Ferramenta FOSS para gerar front-ends de dapps a partir de uma [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** _– Ferramenta FOSS para desenvolvedores Ethereum testarem seu nó, compor e depurar chamadas RPC a partir 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._** +**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** _– 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) @@ -82,15 +82,15 @@ Um contrato inteligente é um código presente na blockchain Ethereum e funciona ## Leitura adicional {#further-reading} -- [Ver dapps](/apps) -- [A arquitetura de um aplicativo Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [Explore os dapps](/apps) +- [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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} -- [Introdução à pilha de Ethereum](/developers/docs/ethereum-stack/) -- [Estruturas de desenvolvimento](/developers/docs/frameworks/) +- [Introdução à Pilha de Ethereum](/developers/docs/ethereum-stack/) +- [Frameworks de desenvolvimento](/developers/docs/frameworks/) diff --git a/public/content/translations/pt-br/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/pt-br/developers/docs/data-and-analytics/block-explorers/index.md index 985faa7eeb3..74bf5341e47 100644 --- a/public/content/translations/pt-br/developers/docs/data-and-analytics/block-explorers/index.md +++ b/public/content/translations/pt-br/developers/docs/data-and-analytics/block-explorers/index.md @@ -1,11 +1,11 @@ --- 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. +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 on-chain. +Exploradores de blocos são o seu portal para os dados do Ethereum. Você pode usá-los pelos dados atuais dos blocos, transações, validadores, contas e outras atividades on-chain. ## Pré-requisitos {#prerequisites} @@ -13,19 +13,17 @@ Você deve entender os conceitos básicos do Ethereum; para que você possa ente ## Serviços {#services} -- [Etherscan](https://etherscan.io/) -_Também disponível em chinês, coreano, russo e japonês_ +- [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_ +- [Blockchair](https://blockchair.com/ethereum) - _Também disponível em espanhol, francês, italiano, holandês, português, russo, chinês e farsi_ - [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_ +- [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/) - [Ethseer](https://ethseer.io) ## Ferramentas de código aberto {#open-source-tools} @@ -43,7 +41,7 @@ Aqui está um resumo dos tipos de dados que você pode obter de um explorador de 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** +**Dados padrão** - 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 @@ -95,7 +93,7 @@ Os exploradores de blocos se tornaram um lugar comum para as pessoas acompanhare - 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 +- Nonce - O número da transação para o endereço `from` (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} @@ -141,11 +139,11 @@ Alguns dados do bloco estão preocupados com a funcionalidade da Ethereum de for - 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 +- Preço ETH - As avaliações atuais de 1 ETH - 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 +- Capitalização de mercado - Cálculo do preço \ \* oferta -## Dados de camada de consenso {#consensus-layer-data} +## Dados da camada de consenso {#consensus-layer-data} ### Época {#epoch} @@ -184,7 +182,7 @@ Espaços são oportunidades para criação de blocos, os dados disponíveis para - 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 +- Remoções - Número de penalidades dadas aos proponentes de blocos ou atestadores - Votos - Os validadores que votaram no bloco neste espaço ### Blocos {#blocks-1} @@ -236,20 +234,18 @@ Os dados de nível superior da camada consensual incluem os seguintes: - 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} +## 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 +- [Etherscan](https://etherscan.io/) - um explorador de blocos que você pode usar para buscar dados da rede principal e da rede de teste da Ethereum - [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 +- [Beaconcha.in](https://beaconcha.in/) - um explorador de blocos de código aberto para a rede principal e a rede de teste da Ethereum - [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 rede principal de Ethereum +- [Etherchain](https://www.etherchain.org/) - um explorador de blocos para a rede principal da Ethereum. +- [Ethplorer](https://ethplorer.io/) - um explorador de blocos com foco em tokens para a rede principal da Ethereum e a rede de teste Kovan. ## Leitura adicional {#further-reading} -_Conhece um recurso da comunidade que ajudou você? Edite esta página e adicione-o!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} diff --git a/public/content/translations/pt-br/developers/docs/data-and-analytics/index.md b/public/content/translations/pt-br/developers/docs/data-and-analytics/index.md index af6527def2a..16d7eb95a7d 100644 --- a/public/content/translations/pt-br/developers/docs/data-and-analytics/index.md +++ b/public/content/translations/pt-br/developers/docs/data-and-analytics/index.md @@ -1,55 +1,72 @@ --- -title: Dados e Estatísticas -description: Como obter dados e análises on-chain para uso em dapps +title: "Dados e Estatísticas" +description: "Como obter dados e análises on-chain usados 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. +À medida que a utilização da rede continua a aumentar, crescerá dados valiosos 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. +Você deve entender o conceito básico de [Exploradores de Bloco](/developers/docs/data-and-analytics/block-explorers/) para entender melhor seu uso no contexto de 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 um projeto de 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. +Em termos de fundamentos de arquitetura, entender o que são [API](https://www.wikipedia.org/wiki/API) e [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), mesmo que em teoria. -## Exploradores de bloco {#block-explorers} +## Exploradores de Bloco {#block-explorers} -Muitos [exploradores de bloco](/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 on-chain. +Muitos [Exploradores de Bloco](/developers/docs/data-and-analytics/block-explorers/) oferecem gateways de [API](https://www.wikipedia.org/wiki/API) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) que fornecem aos desenvolvedores visibilidade de dados em tempo real sobre blocos, transações, validadores, contas e outras atividades em 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. +Os desenvolvedores podem então processar e transformar esses dados para dar aos seus usuários insights e interações únicas com a [blockchain](/glossary/#blockchain). Por exemplo, [Etherscan](https://etherscan.io) e [Blockscout](https://eth.blockscout.com) fornecem 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. +[The Graph](https://thegraph.com/) é um protocolo de indexação que oferece uma maneira fácil de consultar dados de blockchain por meio de APIs abertas conhecidas como subgráficos. -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. +Com o The Graph, os desenvolvedores podem se beneficiar de: -## Diversidade dos clientes +- Indexação descentralizada: permite a indexação de dados de blockchain por meio de vários indexadores, eliminando assim qualquer ponto único de falha +- Consultas GraphQL: fornece uma interface GraphQL poderosa para consultar dados indexados, tornando a recuperação de dados super simples +- Personalização: Defina sua própria lógica para transformar e armazenar dados de blockchain, e reutilize subgráficos publicados por outros desenvolvedores na The Graph Network -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/). +Siga este guia de [início rápido](https://thegraph.com/docs/en/quick-start/) para criar, implantar e consultar um subgráfico em 5 minutos. + +## Diversidade de clientes {#client-diversity} + +A [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity/) é importante para a saúde geral da rede Ethereum, pois fornece resiliência a bugs e exploits. Existem agora vários painéis de diversidade de clientes, 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} -[Dune Analytics](https://dune.com/) pré-processa os dados de blockchain em tabelas de banco de dados relacional (DuneSQL), permitindo que os usuários consultem dados de blockchain usando SQL e criem dashboards com base nos resultados das consultas. 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. +[Dune Analytics](https://dune.com/) pré-processa dados de blockchain em tabelas de banco de dados relacional (DuneSQL), permitindo que os usuários consultem dados de blockchain usando SQL e criem dashboards com base nos resultados das consultas. Os dados em cadeia são organizados em 4 tabelas brutas: `blocks`, `transactions`, `logs` (de evento) e `traces` (de chamada). 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. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) é uma plataforma de dados descentralizada e hiperescalável, otimizada para fornecer acesso eficiente e sem permissão a grandes volumes de dados. Atualmente, ele fornece dados históricos on-chain, incluindo registros de eventos, recibos de transações, rastreamentos e diferenças de estado por transação. O SQD oferece um poderoso kit de ferramentas para criar pipelines personalizados de extração e processamento de dados, alcançando uma velocidade de indexação de até 150mil blocos por segundo. + +Para começar, visite a [documentação](https://docs.sqd.dev/) ou veja [exemplos de EVM](https://github.com/subsquid-labs/squid-evm-examples) do que você pode construir com o SQD. ## SubQuery Network {#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 projetos web3. A SubQuery capacita desenvolvedores de mais de 165 ecossistemas (incluindo Ethereum) com dados indexados avançados para criar experiências intuitivas e imersivas para seus usuários. A SubQuery Network impulsiona seus aplicativos com uma infraestrutura resiliente e descentralizada. Utilize o kit de ferramentas para desenvolvedores de blockchain da SubQuery para construir os aplicativos web3 do futuro, sem precisar gastar tempo criando um back-end personalizado para atividades de processamento de dados. +[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 avançados para criar experiências intuitivas e imersivas para seus usuários. A SubQuery Network impulsiona seus aplicativos com uma infraestrutura resiliente e descentralizada. Utilize o kit de ferramentas para desenvolvedores de blockchain da SubQuery para construir os aplicativos web3 do futuro, sem precisar gastar tempo criando um back-end personalizado para atividades de processamento de dados. + +Para começar, visite o [guia de início rápido do Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) para começar a indexar os dados da blockchain do Ethereum em minutos em um ambiente Docker local para testes antes de ir para produção em um [serviço gerenciado do SubQuery](https://managedservice.subquery.network/) ou na [rede descentralizada do SubQuery](https://app.subquery.network/dashboard). -Para começar, acesse 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 do lançamento em um [serviço gerenciado da SubQuery](https://managedservice.subquery.network/) ou na [rede descentralizada da SubQuery](https://app.subquery.network/dashboard). +## Linguagem de Consulta EVM {#evm-query-language} -## 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 que pesquisadores e bons projetos comunitários explorem a camada pré-chain da rede principal de Ethereum. 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/). +O EQL é uma linguagem semelhante ao SQL por consultar EVM chains. O objetivo do EQL é dar suporte a consultar relações entre os EVM chain first-class citizens (blocos, contas e transações) e fornece aos desenvolvedores e pesquisadores uma sintaxe ergonômica por uso. Com o EQL, os desenvolvedores podem buscar dados de Cadeia de blocos usando uma sintaxe semelhante ao SQL sem códigos complexos. O EQL suporta solicitações aos dados de Cadeia de blocos e está continuamente suportando solicitações e featuresets mais complexos. -## Leitura Adicional {#further-reading} +## Leitura adicional {#further-reading} -- [Visão geral da rede de gráficos](https://thegraph.com/docs/en/about/) -- [Á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) +- [Explorando Dados de Cripto I: Arquiteturas de Fluxo de Dados](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Visão Geral da Graph Network](https://thegraph.com/docs/en/about/) +- [Playground de Consultas do Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Exemplos de código da API no EtherScan](https://etherscan.io/apis#contracts) +- [Documentação da API no Blockscout](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in, explorador da Beacon Chain](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) +- [Guia de Início Rápido do Ethereum da SubQuery](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Visão Geral da SQD Network](https://docs.sqd.dev/) +- [Linguagem de Consulta EVM](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/pt-br/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/pt-br/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..f8d6c3a1b23 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "Estratégias de armazenamento de dados em blockchain" +description: "Existem várias maneiras de armazenar dados usando a blockchain. Este artigo comparará as diferentes estratégias, seus custos e compensações, bem como os requisitos para usá-las com segurança." +lang: pt-br +--- + +Existem várias maneiras de armazenar informações diretamente na blockchain ou de uma maneira protegida pela blockchain: + +- Blobs EIP-4844 +- Calldata +- Offchain com mecanismos L1 +- Contrato "code" +- Eventos +- Armazenamento EVM + +A escolha do método a ser utilizado é baseada em vários critérios: + +- A fonte da informação. As informações nos calldatas não podem vir diretamente da própria blockchain. +- O destino da informação. Calldata está disponível apenas na transação que o inclui. Os eventos não são acessíveis na cadeia. +- Qual é o nível de complexidade aceitável? Computadores que executam um nó em grande escala podem executar mais processamento do que um cliente leve em um aplicativo executado em um navegador. +- É necessário facilitar o acesso às informações de cada nó? +- Os requisitos de segurança. + +## Os requisitos de segurança {#security-requirements} + +Em geral, a segurança da informação consiste em três atributos: + +- _Confidentiality_: entidades não autorizadas não estão autorizadas a ler as informações. Isso é importante em muitos casos, mas não aqui. _Não há segredos na blockchain_. As blockchains funcionam porque qualquer pessoa pode verificar as transições de estado, então é impossível usá-las para armazenar segredos diretamente. Existem maneiras de armazenar informações confidenciais na blockchain, mas todas elas dependem de algum componente offchain para armazenar pelo menos uma chave. + +- _Integrity_: as informações estão corretas, não podem ser alteradas por entidades não autorizadas ou de maneiras não autorizadas (por exemplo, transferindo [tokens ERC-20](https://eips.ethereum.org/EIPS/eip-20#events) sem um evento `Transfer`). Na blockchain, cada nó verifica cada mudança de estado, o que garante integridade. + +- _Availability_: a informação está disponível para qualquer entidade autorizada. Na blockchain, isso é geralmente obtido ao ter as informações disponíveis em cada [nó completo](https://ethereum.org/developers/docs/nodes-and-clients#full-node). + +Todas as diferentes soluções aqui têm excelente integridade, porque os hashes são postados no L1. No entanto, elas têm diferentes garantias de disponibilidade. + +## Pré-requisitos {#prerequisites} + +Você deve ter um bom entendimento dos [fundamentos da blockchain](/developers/docs/intro-to-ethereum/). Esta página também pressupõe que o leitor esteja familiarizado com [blocos](/developers/docs/blocks/), [transações](/developers/docs/transactions/) e outros tópicos relevantes. + +## Blobs EIP-4844 {#eip-4844-blobs} + +Começando com [o hardfork Dencun](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md), a blockchain Ethereum inclui [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), que adiciona blobs de dados Ethereum com uma vida útil limitada (inicialmente cerca de [18 dias](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)). Esses blobs têm preços separados do [gás de execução](/developers/docs/gas), embora usem um mecanismo semelhante. Eles são uma maneira barata de postar dados temporários. + +O principal caso de uso dos blobs EIP-4844 é a publicação das transações pelos rollups. [Optimistic rollups](/developers/docs/scaling/optimistic-rollups) precisam publicar as transações em suas blockchains. Essas transações precisam estar disponíveis para qualquer pessoa durante o [período do desafio](https://docs.optimism.io/connect/resources/glossary#challenge-period) para permitir que os [validadores](https://docs.optimism.io/connect/resources/glossary#validator) corrijam o erro se o [sequenciador](https://docs.optimism.io/connect/resources/glossary#sequencer) do rollup publicar uma raiz de estado incorreta. + +Entretanto, uma vez que o período de desafio tenha passado e a raiz do estado tenha sido finalizada, o propósito restante para conhecer essas transações é replicar o estado atual da cadeia. Esse estado também está disponível nos nós da cadeia, exigindo muito menos processamento. Portanto, as informações de transações ainda devem ser preservadas em alguns lugares, como [exploradores de bloco](/developers/docs/data-and-analytics/block-explorers), mas não há necessidade de pagar pelo nível de resistência à censura que o Ethereum oferece. + +[Rollups de conhecimento zero](/developers/docs/scaling/zk-rollups/#data-availability) também publicam seus dados de transações para permitir que outros nós repliquem o estado existente e verifiquem provas de validade, mas, novamente, esse é um requisito de curto prazo. + +No momento em que escrevo, postar no EIP-4844 custa um wei (10-18 ETH) por byte, o que é insignificante comparado aos [21.000 gases de execução que qualquer transação, incluindo uma que publica blobs, custa](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Você pode ver o preço atual do EIP-4844 em [blobscan.com](https://blobscan.com/blocks). + +Aqui estão os endereços para ver os blobs postados por alguns rollups famosos. + +| Rollup | Endereço | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +Calldata refere-se aos bytes enviados como parte da transação. Ele é armazenado como parte do registro permanente da blockchain no bloco que inclui essa transação. + +Este é o método mais barato para colocar dados permanentemente na blockchain. O custo por byte é de 4 unidades de gás de execução (se o byte for zero) ou 16 gás (qualquer outro valor). Se os dados forem compactados, o que é uma prática padrão, cada valor de byte será igualmente provável, então o custo médio será de aproximadamente 15,95 unidades de gás por byte. + +No momento em que este artigo foi escrito, os preços eram 12 gwei/gás e 2300 $/ETH, o que significa que o custo é de aproximadamente 45 centavos por quilobyte. Como esse era o método mais barato antes do EIP-4844, esse é o método usado pelos rollups para armazenar informações de transações, que precisam estar disponíveis para [desafios de falhas](https://docs.optimism.io/stack/protocol/overview#fault-proofs), mas não precisam estar acessíveis diretamente na cadeia. + +Aqui estão os endereços para ver as transações publicadas por alguns rollups famosos. + +| Rollup | Endereço | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## Offchain com mecanismos L1 {#offchain-with-l1-mechs} + +Dependendo das suas compensações de segurança, pode ser aceitável colocar as informações em outro lugar e usar um mecanismo que garanta que os dados estejam disponíveis quando necessário. Há dois requisitos para que isso funcione: + +1. Publique um [hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) dos dados na blockchain, chamado de _input commitment_. Pode ser uma única palavra de 32 bytes, portanto não é caro. Enquanto o comprometimento de entrada estiver disponível, a integridade estará garantida porque não é possível encontrar outros dados que tenham o mesmo valor. Portanto, se dados incorretos forem fornecidos, eles poderão ser detectados. + +2. Tenha um mecanismo que garanta a disponibilidade. Por exemplo, em [Redstone](https://redstone.xyz/docs/what-is-redstone) qualquer nó pode enviar um desafio de disponibilidade. Se o sequenciador não responder onchain dentro do prazo, o comprometimento de entrada será descartado, então a informação será considerada como nunca tendo sido publicada. + +Isso é aceitável para um pptimistic rollup porque já estamos contando com pelo menos um verificador honesto para a raiz do estado. Um verificador honesto também garantirá que possui os dados para processar blocos e emitirá um desafio de disponibilidade se as informações não estiverem disponíveis off-chain. Esse tipo de optimistic rollup é chamado de [plasma](/developers/docs/scaling/plasma/). + +## Código do contrato {#contract-code} + +Informações que só precisam ser escritas uma vez, nunca são substituídas e precisam estar disponíveis na cadeia podem ser armazenadas como código de contrato. Isso significa que criamos um "contrato inteligente" com os dados e então usamos [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) para ler as informações. A vantagem é que copiar código é relativamente barato. + +Além do custo de expansão de memória, `EXTCODECOPY` custa 2.600 unidades de gás para o primeiro acesso a um contrato (quando ele está "frio") e 100 unidades de gás para cópias subsequentes do mesmo contrato, mais 3 unidades de gás por palavra de 32 bytes. Comparado com o calldata, que custa 15,95 por byte, este é mais barato a partir de cerca de 200 bytes. Com base na [fórmula para custos de expansão de memória](https://www.evm.codes/about#memoryexpansion), desde que você não precise de mais de 4 Mb de memória, o custo de expansão de memória é menor que o custo de adicionar dados de chamada. + +Claro, esse é apenas o custo para ler os dados. A criação do contrato custa aproximadamente 32.000 unidades de gás + 200 unidades de gás/byte. Este método só é econômico quando a mesma informação precisa ser lida muitas vezes em transações diferentes. + +O código do contrato pode ser absurdo, desde que não comece com `0xEF`. Contratos que começam com `0xEF` são interpretados como [formato de objeto ethereum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), que tem requisitos muito mais rigorosos. + +## Eventos {#events} + +[Eventos](https://docs.alchemy.com/docs/solidity-events) são emitidos por contratos inteligentes e lidos por software offchain. +A vantagem é que o código offchain pode escutar eventos. O custo é [gás](https://www.evm.codes/#a0?fork=cancun), 375 mais 8 unidades de gás por byte de dados. A 12 gwei/gás e 2.300 $/ETH, isso se traduz em um centavo mais 22 centavos por kilobyte. + +## Armazenamento {#storage} + +Contratos inteligentes têm acesso a [armazenamento persistente](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Porém, é muito caro. Escrever uma palavra de 32 bytes em um slot de armazenamento previamente vazio pode [custar 22.100unidades de gás](https://www.evm.codes/#55?fork=cancun). A 12 gwei/gás e 2.300 $/ETH, isso é cerca de 61 centavos por operação de gravação, ou US$ 19,5 por kilobyte. + +Esta é a forma mais cara de armazenamento no Ethereum. + +## Resumo {#summary} + +Esta tabela resume as diferentes opções, suas vantagens e desvantagens. + +| Tipo de armazenamento | Fonte de dados | Garantia de disponibilidade | Disponibilidade onchain | Limitações adicionais | +| -------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | +| Blobs EIP-4844 | Offchain | Garantia Ethereum por [cerca de 18 dias](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Apenas hash está disponível | | +| Calldata | Offchain | Garantia perpétua Ethereum (parte da blockchain) | Disponível somente se escrito em um contrato e nessa transação específica | | +| Offchain com mecanismos L1 | Offchain | Garantia de "Um verificador honesto" durante o período de desafio | Somente hash | Garantido pelo mecanismo de desafio, apenas durante o período de desafio | +| Código do contrato | Onchain ou offchain | Garantia perpétua Ethereum (parte da blockchain) | Sim | Escrito em um endereço "aleatório". Não pode começar com `0xEF` | +| Eventos | Onchain | Garantia perpétua Ethereum (parte da blockchain) | Não | | +| Armazenamento | Onchain | Garantia perpétua Ethereum (parte da blockchain e o estado atual até ser substituído) | Sim | | diff --git a/public/content/translations/pt-br/developers/docs/data-availability/index.md b/public/content/translations/pt-br/developers/docs/data-availability/index.md index 316e918b191..38be0705b70 100644 --- a/public/content/translations/pt-br/developers/docs/data-availability/index.md +++ b/public/content/translations/pt-br/developers/docs/data-availability/index.md @@ -1,83 +1,84 @@ --- title: Disponibilidade de dados -description: Uma visão geral dos problemas e soluções relacionados à disponibilidade de dados no Ethereum +description: "Uma visão geral dos problemas e soluções relacionados à disponibilidade de dados no Ethereum" lang: pt-br --- “Não confie, verifique” é uma máxima comum no Ethereum. A ideia é que seu nó possa verificar de modo independente se a informação que recebe está correta, executando todas as transações nos blocos que recebem dos pares, a fim de garantir que as mudanças propostas correspondam precisamente àquelas calculadas de forma independente pelo nó. Isso significa que os nós não precisam confiar na honestidade dos remetentes do bloco. Isso não é possível se estiverem faltando dados. -**Disponibilidade de dados** se refere à confiança que um usuário pode ter de que os dados necessários para verificar um bloco estão realmente disponíveis para todos os participantes da rede. Para nós completos na camada 1 do Ethereum, isso é relativamente simples; o nó completo baixa uma cópia de todos os dados em cada bloco — os dados _devem_ estar disponíveis para que o download seja possível. Um bloco com dados faltando seria descartado em vez de ser adicionado à blockchain. Isso é “disponibilidade de dados on-chain” e é um recurso de blockchains monolíticas. Os nós completos não podem ser enganados em aceitar transações inválidas porque eles baixam e executam todas as transações para si mesmos. No entanto, para blockchains modulares, rollups de camada 2 e clientes leves, o cenário de disponibilidade de dados é mais complexo, exigindo alguns procedimentos de verificação mais sofisticados. +**Disponibilidade de dados** se refere à confiança que um usuário pode ter de que os dados necessários para verificar um bloco estão realmente disponíveis para todos os participantes da rede. Para nós completos na camada 1 do Ethereum, isso é relativamente simples; o nó completo baixa uma cópia de todos os dados em cada bloco — os dados _têm_ que estar disponíveis para que o download seja possível. Um bloco com dados faltando seria descartado em vez de ser adicionado à blockchain. Está é a "disponibilidade de dados on-chain" e é uma característica das blockchains monolíticas. Os nós completos não podem ser enganados em aceitar transações inválidas porque eles baixam e executam todas as transações para si mesmos. No entanto, para blockchains modulares, rollups de camada 2 e clientes leves, o cenário de disponibilidade de dados é mais complexo, exigindo alguns procedimentos de verificação mais sofisticados. ## Pré-requisitos {#prerequisites} -Você deve ter uma boa compreensão dos [fundamentos da blockchain](/developers/docs/intro-to-ethereum/), especialmente sobre [mecanismos de consenso](/developers/docs/consensus-mechanisms/). Esta página também pressupõe que o leitor esteja familiarizado com [blocos](/developers/docs/blocks/), [transações](/developers/docs/transactions/), [nós](/developers/docs/nodes-and-clients/), [soluções de dimensionamento](/developers/docs/scaling/) e outros tópicos relevantes. +Você deve ter um bom entendimento dos [fundamentos da blockchain](/developers/docs/intro-to-ethereum/), especialmente dos [mecanismos de consenso](/developers/docs/consensus-mechanisms/). Esta página também pressupõe que o leitor esteja familiarizado com [blocos](/developers/docs/blocks/), [transações](/developers/docs/transactions/), [nós](/developers/docs/nodes-and-clients/), [soluções de escalabilidade](/developers/docs/scaling/) e outros tópicos relevantes. ## O problema da disponibilidade de dados {#the-data-availability-problem} O problema da disponibilidade de dados é a necessidade de provar para toda a rede que a forma resumida de alguns dados de transação que estão sendo adicionados à blockchain realmente representa um conjunto de transações válidas, mas fazendo isso sem exigir que todos os nós baixem todos os dados. Os dados completos da transação são necessários para verificar os blocos de forma independente, mas exigir que todos os nós baixem todos os dados da transação é uma barreira para a escalabilidade. As soluções para o problema da disponibilidade de dados visam fornecer garantias suficientes de que os dados completos da transação foram disponibilizados para verificação aos participantes da rede que não baixam e armazenam os dados por conta própria. -[Nós leves](/developers/docs/nodes-and-clients/light-clients) e [rollups da camada 2](/developers/docs/scaling) são importantes exemplos de participantes da rede que exigem fortes garantias de disponibilidade de dados, mas não podem baixar e processar dados de transações por conta própria. Evitar baixar dados de transações é o que torna os nós leves e permite que os rollups sejam soluções de escalabilidade eficazes. +[Nós leves](/developers/docs/nodes-and-clients/light-clients) e [rollups de Camada 2](/developers/docs/scaling) são exemplos importantes de participantes da rede que exigem fortes garantias de disponibilidade de dados, mas não podem baixar e processar os dados de transações por conta própria. Evitar baixar dados de transações é o que torna os nós leves e permite que os rollups sejam soluções de escalabilidade eficazes. -A disponibilidade de dados é também uma preocupação crítica para futuros clientes do Ethereum [“sem estado”](/roadmap/statelessness) que não precisam baixar e armazenar dados de estado para verificar os blocos. Os clientes sem estado ainda precisam ter certeza de que os dados estão disponíveis _em algum lugar_ e que foram processados corretamente. +A disponibilidade de dados também é uma preocupação crítica para futuros clientes Ethereum ["sem estado"](/roadmap/statelessness) que não precisam baixar e armazenar dados de estado para verificar os blocos. Os clientes sem estado ainda precisam ter certeza de que os dados estão disponíveis _em algum lugar_ e que foram processados corretamente. ## Soluções de disponibilidade de dados {#data-availability-solutions} ### Amostragem de disponibilidade de dados (DAS) {#data-availability-sampling} -Amostragem de Disponibilidade de Dados (DAS, do inglês Data Availability Sampling) é uma forma de a rede verificar se os dados estão disponíveis sem sobrecarregar um nó excessivamente. Cada nó (incluindo os nós que não foram nomeados para o staking) baixa um subconjunto pequeno e selecionado aleatoriamente do total de dados. Baixar com sucesso as amostras confirma com alta confiança que todos os dados estão disponíveis. Isso se baseia na codificação de eliminação de dados, que expande um determinado conjunto de dados com informações redundantes (a maneira como isso é feito é encaixando uma função conhecida como _polinomial_ sobre os dados e avaliando esse polinômio em pontos adicionais). Isso permite que os dados originais sejam recuperados a partir dos dados redundantes quando necessário. Consequentemente, se _qualquer_ dado original estiver indisponível, a criação dos dados causaria a perda de _metade_ dos dados expandidos! A quantidade de amostras de dados baixadas por cada nó pode ser ajustada de modo que seja _extremamente_ provável que pelo menos um dos fragmentos de dados amostrados por cada cliente esteja faltando _se_ menos da metade dos dados estiver realmente disponível. +Amostragem de Disponibilidade de Dados (DAS, do inglês Data Availability Sampling) é uma forma de a rede verificar se os dados estão disponíveis sem sobrecarregar um nó excessivamente. Cada nó (incluindo os nós que não foram nomeados para o staking) baixa um subconjunto pequeno e selecionado aleatoriamente do total de dados. Baixar com sucesso as amostras confirma com alta confiança que todos os dados estão disponíveis. Isso se baseia na codificação de eliminação de dados, que expande um determinado conjunto de dados com informações redundantes (a maneira como isso é feito é ajustar uma função conhecida como um _polinômio_ sobre os dados e avaliar esse polinômio em pontos adicionais). Isso permite que os dados originais sejam recuperados a partir dos dados redundantes quando necessário. Uma consequência dessa criação de dados é que, se _qualquer_ parte dos dados originais não estiver disponível, _metade_ dos dados expandidos estará faltando! A quantidade de amostras de dados baixadas por cada nó pode ser ajustada para que seja _extremamente_ provável que pelo menos um dos fragmentos de dados amostrados por cada cliente esteja faltando _se_ menos da metade dos dados estiver realmente disponível. -O DAS será usado para garantir que os operadores de rollup tornem seus dados de transação disponíveis após o [EIP-4844](/roadmap/danksharding) ser implementado. Os nós do Ethereum usarão como amostras os dados da transação fornecidos nos blobs aleatoriamente usando o esquema de redundância explicado acima para garantir que todos os dados existam. A mesma técnica também poderá ser utilizada para garantir que os produtores de blocos estejam disponibilizando todos os seus dados para proteger clientes leves. Da mesma forma, na [separação entre proponentes e construtores](/roadmap/pbs), apenas o construtor do bloco seria necessário para processar um bloco inteiro, enquanto outros validadores verificariam usando uma amostragem da disponibilidade de dados. +O DAS será usado para garantir que os operadores de rollup disponibilizem seus dados de transação após a implementação do [Full Danksharding](/roadmap/danksharding/#what-is-danksharding). Os nós do Ethereum usarão como amostras os dados da transação fornecidos nos blobs aleatoriamente usando o esquema de redundância explicado acima para garantir que todos os dados existam. A mesma técnica também poderá ser utilizada para garantir que os produtores de blocos estejam disponibilizando todos os seus dados para proteger clientes leves. Da mesma forma, na [separação entre proponentes e construtores](/roadmap/pbs), apenas o construtor do bloco seria necessário para processar um bloco inteiro, enquanto outros validadores verificariam usando uma amostragem da disponibilidade de dados. ### Comitês de disponibilidade de dados {#data-availability-committees} -Os Comitês de Disponibilidade de Dados (DACs, do inglês Data Availability Committees) são partes confiáveis que fornecem ou atestam a disponibilidade de dados. DACs podem ser usados em vez de, [ou em combinação com](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS. As garantias de segurança que chegam aos comitês dependem de configuração específica. O Ethereum usa amostras de subconjuntos de validadores escolhidos aleatoriamente para atestar a disponibilidade de dados para nós leves, por exemplo. +Os Comitês de Disponibilidade de Dados (DACs, do inglês Data Availability Committees) são partes confiáveis que fornecem ou atestam a disponibilidade de dados. Os DACs podem ser usados em vez de, [ou em combinação com](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS), o DAS. As garantias de segurança que chegam aos comitês dependem de configuração específica. O Ethereum usa amostras de subconjuntos de validadores escolhidos aleatoriamente para atestar a disponibilidade de dados para nós leves, por exemplo. -DACs também são usados por alguns validiums. O DAC é um conjunto confiável de nós que armazena cópias de dados offline. O DAC é necessário para disponibilizar os dados em caso de litígio. Os membros do DAC também publicam certificados na cadeia para provar que os referidos dados estão efetivamente disponíveis. Alguns validiums substituem os DACs por um sistema validador de prova de participação (proof-of-stake ou PoS). Aqui, qualquer pessoa pode se tornar um validador e armazenar dados off-chain. No entanto, eles devem fornecer uma “caução”, que é depositada em um contrato inteligente. No caso de comportamento malicioso, por exemplo, o validador retendo dados, a caução pode ser interrompida. Os comitês de disponibilidade de dados da prova de participação são consideravelmente mais seguros do que os DACs regulares, porque incentivam diretamente um comportamento honesto. +DACs também são usados por alguns validiums. O DAC é um conjunto confiável de nós que armazena cópias de dados offline. O DAC é necessário para disponibilizar os dados em caso de litígio. Os membros da DAC também publicam atestados em cadeia para provar que esses dados estão realmente disponíveis. Alguns validiums substituem os DACs por um sistema validador de prova de participação (proof-of-stake ou PoS). Aqui, todo mundo pode se tornar um validador e armazenador de dados off-chain. No entanto, eles devem fornecer uma “caução”, que é depositada em um contrato inteligente. No caso de comportamento malicioso, por exemplo, o validador retendo dados, a caução pode ser interrompida. Os comitês de disponibilidade de dados da prova de participação são consideravelmente mais seguros do que os DACs regulares, porque incentivam diretamente um comportamento honesto. ## Disponibilidade de dados e nós leves {#data-availability-and-light-nodes} -Os [Nós leves](/developers/docs/nodes-and-clients/light-clients) precisam validar a exatidão dos cabeçalhos do bloco que recebem sem baixar os dados do bloco. O custo dessa leveza é a incapacidade de verificar de forma independente os cabeçalhos do bloco reexecutando as transações localmente da maneira que os nós completos fazem. +[Nós leves](/developers/docs/nodes-and-clients/light-clients) precisam validar a exatidão dos cabeçalhos do bloco que recebem sem baixar os dados do bloco. O custo dessa leveza é a incapacidade de verificar de forma independente os cabeçalhos do bloco reexecutando as transações localmente da maneira que os nós completos fazem. -Os nós leves do Ethereum confiam em conjuntos aleatórios de 512 validadores que foram atribuídos a um _comitê de sincronização_. O comitê de sincronização atua como um DAC que sinaliza aos clientes leves que os dados no cabeçalho estão corretos usando uma assinatura criptográfica. O comitê de sincronização é atualizado diariamente. Cada cabeçalho do bloco alerta os nós leves, indicando quais validadores serão destinados a assinar o _próximo_ bloco, para não serem enganados confiando em um grupo malicioso fingindo ser o verdadeiro comitê de sincronização. +Os nós leves do Ethereum confiam em conjuntos aleatórios de 512 validadores que foram atribuídos a um _comitê de sincronização_. O comitê de sincronização atua como um DAC que sinaliza aos clientes leves que os dados no cabeçalho estão corretos usando uma assinatura criptográfica. O comitê de sincronização é atualizado diariamente. Cada cabeçalho de bloco alerta os nós leves sobre quais validadores devem assinar o _próximo_ bloco, para que não possam ser enganados a confiar em um grupo mal-intencionado que finja ser o verdadeiro comitê de sincronização. -No entanto, o que acontece se um invasor _conseguir_ de alguma forma passar um cabeçalho de bloco malicioso para clientes leves e convencê-los de que foi assinado por um comitê de sincronização honesto? Nesse caso, o invasor poderia incluir transações inválidas e o cliente leve as aceitaria cegamente, pois não verifica de forma independente todas as alterações de estado resumidas no cabeçalho do bloco. Para se proteger contra isso, o cliente leve pode usar provas de fraude. +No entanto, o que acontece se um invasor de alguma forma _conseguir_ passar um cabeçalho de bloco malicioso para clientes leves e convencê-los de que foi assinado por um comitê de sincronização honesto? Nesse caso, o invasor poderia incluir transações inválidas e o cliente leve as aceitaria cegamente, pois não verifica de forma independente todas as alterações de estado resumidas no cabeçalho do bloco. Para se proteger contra isso, o cliente leve pode usar provas de fraude. Essas provas de fraude funcionam da seguinte maneira: um nó completo observa uma transição de estado inválido sendo espalhada pela rede, que poderia rapidamente gerar uma pequena parte de dados demonstrando que uma transição de estado proposta não poderia surgir de um determinado conjunto de transações e transmitir esses dados aos seus pares. Os nós leves poderiam pegar essas provas de fraude e usá-las para descartar cabeçalhos de bloco ruins, garantindo que permaneçam na mesma cadeia honesta que os nós completos. Isso depende de nós completos com acesso a dados completos da transação. Um invasor que transmite um cabeçalho de bloco inválido e também falha em disponibilizar os dados da transação seria capaz de impedir que os nós completos gerassem provas de fraude. Os nós completos poderiam conseguir sinalizar um aviso sobre um bloco ruim, mas não poderiam fazer validar seu aviso com uma prova, pois os dados não foram disponibilizados para gerar a prova! -A solução para esse problema de disponibilidade de dados é o DAS. Nós leves baixam partes aleatórias muito pequenas dos dados de estado completos e usam as amostras para verificar se o conjunto completo de dados está disponível. A probabilidade real de assumir incorretamente a disponibilidade total dos dados após baixar N blocos aleatórios pode ser calculada ([para 100 partes, a chance é de 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), ou seja, incrivelmente improvável). +A solução para esse problema de disponibilidade de dados é o DAS. Nós leves baixam partes aleatórias muito pequenas dos dados de estado completos e usam as amostras para verificar se o conjunto completo de dados está disponível. A probabilidade real de assumir incorretamente a disponibilidade total de dados após baixar N partes aleatórias pode ser calculada ([para 100 partes, a chance é de 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), ou seja, incrivelmente improvável). Mesmo nesse cenário, os ataques que retêm apenas alguns bytes poderiam passar despercebidos pelos clientes que fazem solicitações de dados aleatórios. A codificação de eliminação (remoção segura e permanente de dados de contratos) corrige isso reconstruindo pequenas partes de dados ausentes que podem ser usadas para verificar as alterações de estado propostas. Uma prova de fraude poderia então ser construída usando os dados reconstruídos, evitando que clientes leves aceitem cabeçalhos ruins. -**Nota:** DAS e provas de fraude ainda não foram implementados para clientes leves da prova de participação do Ethereum, mas estão no roteiro, muito provavelmente assumindo a forma de provas baseadas em ZK-SNARK. Os clientes leves de hoje dependem de uma forma de DAC: eles verificam as identidades do comitê de sincronização e, em seguida, confiam nos cabeçalhos de bloco assinados que recebem. +**Nota:** DAS e provas de fraude ainda não foram implementados para clientes leves de prova de participação do Ethereum, mas estão no roteiro, muito provavelmente assumindo a forma de provas baseadas em ZK-SNARK. Os clientes leves de hoje dependem de uma forma de DAC: eles verificam as identidades do comitê de sincronização e, em seguida, confiam nos cabeçalhos de bloco assinados que recebem. -## Disponibilidade de dados e rollups de camada 2 {#data-availability-and-layer-2-rollups} +## Disponibilidade de dados e rollups de Camada 2 {#data-availability-and-layer-2-rollups} -[As soluções de escalabilidade de Camada 2](/layer-2/), como [rollups](/glossary/#rollups), reduzem os custos de transação e aumentam o rendimento do Ethereum processando transações off-chain. As transações de rollup são compactadas e postadas no Ethereum em lotes. Os lotes representam milhares de transações individuais off-chain em uma única transação no Ethereum. Isso reduz o congestionamento na camada base e reduz as taxas para os usuários. +[Soluções de escalabilidade de Camada 2](/layer-2/), como [rollups](/glossary/#rollups), reduzem os custos de transação e aumentam o throughput do Ethereum ao processar transações off-chain. As transações de rollup são compactadas e postadas no Ethereum em lotes. Lotes representam milhares de transações individuais off-chain em uma única transação no Ethereum. Isso reduz o congestionamento na camada base e reduz as taxas para os usuários. -No entanto, só é possível confiar nas transações “resumidas” publicadas no Ethereum se a mudança de estado proposta puder ser verificada de forma independente e confirmada como resultado da aplicação de todas as transações individuais off-chain. Se os operadores de rollup não disponibilizarem os dados da transação para essa verificação, eles poderão enviar dados incorretos para o Ethereum. +No entanto, só é possível confiar nas transações 'resumidas' postadas na Ethereum se a mudança de estado proposta puder ser verificada e confirmada de forma independente como resultado da aplicação de todas as transações individuais fora da cadeia. Se os operadores de rollup não disponibilizarem os dados da transação para essa verificação, eles poderão enviar dados incorretos para o Ethereum. -[Rollups otimistas](/developers/docs/scaling/optimistic-rollups/) publicam dados de transação compactados no Ethereum e esperam algum tempo (normalmente 7 dias) para permitir que verificadores independentes confiram os dados. Se alguém identificar um problema, poderá gerar uma prova de fraude e usá-la para contestar o rollup. Isso faria com que a cadeia fosse revertida e omitisse o bloco inválido. Isso só é possível se houver dados disponíveis. Atualmente, os dados são disponibilizados de forma permanente como `CALLDATA`, que reside permanentemente on-chain. No entanto, o EIP-4844 em breve permitirá que os rollups publiquem seus dados de transação em um armazenamento de blob mais barato. Esse armazenamento não é permanente. Os verificadores independentes terão que consultar os blobs e reportar seus desafios entre 1 e 3 meses antes de os dados serem excluídos da camada 1 do Ethereum. A disponibilidade dos dados só é garantida pelo protocolo Ethereum para esse curto espaço de tempo fixo. Depois disso, ela é de responsabilidade de outras entidades do ecossistema Ethereum. Qualquer nó pode verificar a disponibilidade de dados usando DAS, ou seja, baixando pequenas amostras aleatórias dos dados do blob. +[Optimistic rollups](/developers/docs/scaling/optimistic-rollups/) publicam dados de transação compactados no Ethereum e esperam por um certo tempo (geralmente 7 dias) para permitir que verificadores independentes verifiquem os dados. Se alguém identificar um problema, poderá gerar uma prova de fraude e usá-la para contestar o rollup. Isso faria com que a cadeia fosse revertida e omitisse o bloco inválido. Isso só é possível se houver dados disponíveis. Atualmente, há duas maneiras pelas quais os optimistic rollups publicam dados de transações no L1. Alguns rollups tornam os dados permanentemente disponíveis como `CALLDATA`, que reside permanentemente on-chain. Com a implementação do EIP-4844, alguns rollups publicam seus dados de transações em um armazenamento de blobs mais barato. Esse armazenamento não é permanente. Verificadores independentes precisam consultar os blobs e apresentar seus desafios dentro de 18 dias (aproximadamente) antes que os dados sejam excluídos da camada 1 do Ethereum. A disponibilidade dos dados só é garantida pelo protocolo Ethereum para esse curto espaço de tempo fixo. Depois disso, ela é de responsabilidade de outras entidades do ecossistema Ethereum. Qualquer nó pode verificar a disponibilidade de dados usando DAS, ou seja, baixando pequenas amostras aleatórias dos dados do blob. -[ZK-rollups (rollups de conhecimento zero)](/developers/docs/scaling/zk-rollups) não precisam publicar dados de transação, já que as [provas de validação de conhecimento zero](/glossary/#zk-proof) garantem a exatidão das transições de estado. No entanto, a disponibilidade dos dados ainda é um problema, pois não podemos garantir a funcionalidade do ZK-rollup (ou interagir com ele) sem acesso aos seus dados de estado. Por exemplo, os usuários não podem saber os saldos deles se um operador retiver detalhes sobre o estado do rollup. Eles tampouco podem realizar atualizações de estado utilizando informações contidas em um bloco recém-adicionado. +[Rollups de conhecimento zero (ZK)](/developers/docs/scaling/zk-rollups) não precisam publicar dados de transação, pois as [provas de validade de conhecimento zero](/glossary/#zk-proof) garantem a exatidão das transições de estado. No entanto, a disponibilidade dos dados ainda é um problema, pois não podemos garantir a funcionalidade do ZK-rollup (ou interagir com ele) sem acesso aos seus dados de estado. Por exemplo, os usuários não podem saber os saldos deles se um operador retiver detalhes sobre o estado do rollup. Eles tampouco podem realizar atualizações de estado utilizando informações contidas em um bloco recém-adicionado. ## Disponibilidade de dados vs. recuperabilidade de dados {#data-availability-vs-data-retrievability} Disponibilidade de dados é diferente de recuperabilidade de dados. A disponibilidade de dados é a garantia de que nós completos conseguiram acessar e verificar o conjunto completo de transações associadas a um bloco específico. Isso não significa necessariamente que os dados ficarão acessíveis para sempre. -Recuperabilidade de dados é a capacidade de os nós recuperarem _informações históricas_ da blockchain. Esses dados históricos não são necessários para verificar novos blocos, apenas para sincronizar nós completos do bloco de origem ou servir solicitações históricas específicas. +A recuperabilidade de dados é a capacidade dos nós de recuperar _informações históricas_ da blockchain. Esses dados históricos não são necessários para verificar novos blocos, apenas para sincronizar nós completos do bloco de origem ou servir solicitações históricas específicas. -A preocupação do protocolo principal Ethereum é a disponibilidade de dados, e não a recuperação de dados. A capacidade de recuperar dados pode ser fornecida por uma pequena população de nós de arquivos executados por terceiros ou pode ser distribuída pela rede usando um armazenamento de arquivos descentralizado, como o [Portal Network](https://www.ethportal.net/). +A preocupação do protocolo principal Ethereum é a disponibilidade de dados, e não a recuperação de dados. A recuperabilidade de dados pode ser fornecida por uma pequena população de nós de arquivamento executados por terceiros, ou pode ser distribuída pela rede usando armazenamento de arquivos descentralizado, como a [Portal Network](https://www.ethportal.net/). ## Leitura adicional {#further-reading} -- [O que é disponibilidade de dados?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) -- [O que é a disponibilidade de dados?](https://coinmarketcap.com/alexandria/article/what-is-data-availability) -- [O cenário da disponibilidade de dados off-chain do Ethereum](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/) -- [Uma cartilha sobre verificações de disponibilidade de dados](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) -- [Uma explicação da proposta de particionamento + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [Uma nota sobre disponibilidade de dados e codificação de exclusão](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [WTF is Data Availability?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [O que é Disponibilidade de Dados?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [Uma introdução às verificações de disponibilidade de dados](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [Uma explicação da proposta de fragmentação + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Uma nota sobre disponibilidade de dados e codificação por apagamento](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) - [Comitês de disponibilidade de dados.](https://medium.com/starkware/data-availability-e5564c416424) -- [Comitês de disponibilidade de dados da prova de participação.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) -- [Soluções para o problema de recuperação de dados](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Comitês de disponibilidade de dados de prova de participação.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Soluções para o problema da recuperabilidade de dados](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Disponibilidade de Dados ou: Como os Rollups Aprenderam a Parar de Se Preocupar e Amar o Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: Aumentando o Custo do Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/index.md index 21302a4f94a..67f557fdc6b 100644 --- a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/index.md +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/index.md @@ -1,31 +1,31 @@ --- -title: Codificação e estruturas de dados -description: Visão geral das estruturas de dados fundamentais do Ethereum +title: "Codificação e estruturas de dados" +description: "Visão geral das estruturas de dados fundamentais do Ethereum" lang: pt-br sidebarDepth: 2 --- -O Ethereum cria, armazena e transfere grandes volumes de dados. Esses dados precisam ser formatados de maneiras padronizadas e eficientes em memória para permitir que qualquer pessoa [execute um nó](/run-a-node/) em um hardware de nível de consumo relativamente modesto. Para isso, várias estruturas de dados específicas são usadas na pilha do Ethereum. +O Ethereum cria, armazena e transfere grandes volumes de dados. Esses dados devem ser formatados de maneiras padronizadas e com uso eficiente de memória para permitir que qualquer pessoa [execute um nó](/run-a-node/) em um hardware de consumo relativamente modesto. Para isso, várias estruturas de dados específicas são usadas na pilha do Ethereum. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Você deve entender os fundamentos sobre o Ethereum e o [software cliente](/developers/docs/nodes-and-clients/). Recomenda-se familiaridade com a camada de rede e [o whitepaper sobre o Ethereum](/whitepaper/). +Você deve entender os fundamentos do Ethereum e do [software cliente](/developers/docs/nodes-and-clients/). Recomenda-se familiaridade com a camada de rede e com [o whitepaper do Ethereum](/whitepaper/). ## Estruturas de dados {#data-structures} -### Árvores Merkle Patricia {#patricia-merkle-tries} +### Tries Patricia Merkle {#patricia-merkle-tries} Árvores Merkle Patricia são estruturas que codificam pares de valor-chave em uma árvore determinística e criptograficamente autenticada. Estas são amplamente usadas em toda a camada de execução do Ethereum. -[Mais sobre Árvores Merkle Patricia](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) +[Mais sobre Tries Patricia Merkle](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) -### Prefixo de comprimento recursivo (RLP) {#recursive-length-prefix} +### Prefixo de Comprimento Recursivo {#recursive-length-prefix} Prefixo de comprimento recursivo (RLP) é um método de serialização usado extensivamente em toda a camada de execução do Ethereum. [Mais sobre RLP](/developers/docs/data-structures-and-encoding/rlp) -### Serialização simples {#simple-serialize} +### Serialização Simples {#simple-serialize} Serialização simples (SSZ) é o formato de serialização dominante na camada de consenso do Ethereum devido à sua compatibilidade com a "merklelização". diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 8867c855bf6..8ff1c6e6bac 100644 --- a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -1,23 +1,23 @@ --- -title: Árvore Merkle Patricia -description: Introdução à àrvore Merkle Patricia +title: "Árvore Merkle Patricia" +description: "Introdução à àrvore Merkle Patricia" lang: pt-br sidebarDepth: 2 --- O estado do Ethereum (a totalidade de todas as contas, saldos e contratos inteligentes) é codificado em uma versão especial da estrutura de dados conhecida geralmente na ciência da computação como Árvore Merkle. Essa estrutura é útil para muitas aplicações em criptografia porque cria um relacionamento verificável entre todos os dados individuais emaranhados na árvore, resultando em um único valor **raiz** que pode ser usado para provar coisas sobre os dados. -A estrutura de dados do Ethereum é uma 'Merkle-Patricia Trie modificada', assim chamada porque toma emprestados alguns recursos do PATRICIA (o Algoritmo Prático para Recuperar Informações Codificadas em Alfanumérico) e porque foi projetada para ser eficiente na **recuperação de dados** de itens que compõem o estado do Ethereum. +A estrutura de dados do Ethereum é uma 'Merkle-Patricia Trie modificada', assim chamada porque toma emprestados alguns recursos do PATRICIA (o Algoritmo Prático para Recuperar Informações Codificadas em Alfanumérico) e porque foi projetada para ser eficiente na recuperação de dados de itens que compõem o estado do Ethereum. -Uma Merkle-Patricia é determinística e criptograficamente verificável: a única maneira de gerar uma raiz de estado é computando-a a partir de cada parte individual do estado, e dois estados que são idênticos podem ser facilmente provados comparando o hash raiz e os hashes que levaram a ele (_uma prova de Merkle_). Por outro lado, não há como criar dois estados diferentes com o mesmo hash raiz, e qualquer tentativa de modificar o estado com valores diferentes resultará em um hash raiz de estado diferente. Teoricamente, essa estrutura fornece o "Santo Graal" da eficiência `O(log(n))` para inserções, pesquisas e exclusões. +Uma Merkle-Patricia trie é determinística e criptograficamente verificável: a única maneira de gerar uma raiz de estado é computando-a a partir de cada parte individual do estado, e dois estados idênticos podem ser facilmente comprovados comparando o hash raiz e os hashes que levaram a ele (_uma prova de Merkle_). Por outro lado, não há como criar dois estados diferentes com o mesmo hash raiz, e qualquer tentativa de modificar o estado com valores diferentes resultará em um hash raiz de estado diferente. Teoricamente, essa estrutura fornece o 'Santo Graal' da eficiência de `O(log(n))` para inserções, buscas e exclusões. Em um futuro próximo, o Ethereum planeja migrar para uma estrutura de [Verkle Tree](/roadmap/verkle-trees), o que abrirá muitas novas possibilidades para futuras melhorias de protocolo. ## Pré-requisitos {#prerequisites} -Para entender melhor esta página, seria útil ter conhecimento básico sobre [hashes](https://en.wikipedia.org/wiki/Hash_function), [Árvores Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [árvores](https://en.wikipedia.org/wiki/Trie) e [serialização](https://en.wikipedia.org/wiki/Serialization). Este artigo começa com uma descrição de uma [árvore radix](https://en.wikipedia.org/wiki/Radix_tree) básica e, em seguida, introduz gradualmente as modificações necessárias para a estrutura de dados mais otimizada do Ethereum. +Para entender melhor esta página, seria útil ter conhecimento básico de [hashes](https://en.wikipedia.org/wiki/Hash_function), [árvores de Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [tries](https://en.wikipedia.org/wiki/Trie) e [serialização](https://en.wikipedia.org/wiki/Serialization). Este artigo começa com uma descrição de uma [árvore radix](https://en.wikipedia.org/wiki/Radix_tree) básica e, em seguida, introduz gradualmente as modificações necessárias para a estrutura de dados mais otimizada do Ethereum. -## Árvores radix básicas {#basic-radix-tries} +## Tries radix básicas {#basic-radix-tries} Em uma árvore radix básica, cada nó se parece com o seguinte: @@ -25,146 +25,149 @@ Em uma árvore radix básica, cada nó se parece com o seguinte: [i_0, i_1 ... i_n, value] ``` -Onde `i0 ... in` representa o símbolo do alfabeto (muitas vezes binário ou hex), `value` é o valor terminal no nó, e os valores nos slots `i0 . . in` são ou `NULL` ou ponteiros para (em nosso caso, hashes de) outros nós. Isto forma um armazenamento básico `(key, value)`. +Onde `i_0 ...` `i_n` representam os símbolos do alfabeto (geralmente binário ou hexadecimal), `value` é o valor terminal no nó, e os valores nos `i_0, i_1 ...` slots `i_n` são `NULL` ou ponteiros para (no nosso caso, hashes de) outros nós. Isso forma um armazenamento básico de `(key, value)`. -Digamos que você queria usar uma estrutura de dados da árvore radix para persistir em uma ordem em um conjunto de pares de valor-chave. Para encontrar o valor atualmente relacionado com a chave `dog` na árvore, primeiro você converteria `dog` em letras do alfabeto (dando `64 6f 67`), e então desceria pela árvore seguindo o caminho até encontrar o valor. Ou seja, você começa por procurar o hash raiz em uma base de dados texto chave/valor para encontrar o nó raiz da árvore. Ele é representado como uma matriz de chaves apontando para outros nós. Use o valor no índice `6` como uma chave e procure na base chave/valor para obter o nó um nível abaixo. Em seguida, escolha o índice `4` para procurar o próximo valor, depois escolha o índice `6` e assim por diante. Uma vez tendo seguido o caminho: `root-> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, procure o valor do nó e retorne o resultado. +Digamos que você queria usar uma estrutura de dados da árvore radix para persistir em uma ordem em um conjunto de pares de valor-chave. Para encontrar o valor atualmente mapeado para a chave `dog` na trie, primeiro você converteria `dog` em letras do alfabeto (resultando em `64 6f 67`), e então desceria pela trie seguindo esse caminho até encontrar o valor. Ou seja, você começa por procurar o hash raiz em uma base de dados texto chave/valor para encontrar o nó raiz da árvore. Ele é representado como uma matriz de chaves apontando para outros nós. Você usaria o valor no índice `6` como uma chave e o procuraria no banco de dados simples de chave/valor para obter o nó um nível abaixo. Então, pegue o índice `4` para procurar o próximo valor, depois o índice `6`, e assim por diante, até que, depois de seguir o caminho: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, você procuraria o valor do nó e retornaria o resultado. -Há uma diferença entre buscar algo na árvore e no banco de dados base subjacente (chave/valor). Ambos definem arranjos chave/valor, mas o DB subjacente pode fazer uma tradicional busca de 1 passo pela chave. Procurar uma chave na árvore requer várias buscas no banco de dados subjacente para obter o valor final descrito acima. Vamos nos referir a este último como um `path` para eliminar ambiguidade. +Há uma diferença entre buscar algo na árvore e no banco de dados base subjacente (chave/valor). Ambos definem arranjos chave/valor, mas o DB subjacente pode fazer uma tradicional busca de 1 passo pela chave. Procurar uma chave na árvore requer várias buscas no banco de dados subjacente para obter o valor final descrito acima. Vamos nos referir a este último como um `path` para eliminar a ambiguidade. As operações de atualização e exclusão em árvores radix são simples, e podem ser definidas da seguinte forma: -``` - def update(node,path,value): - curnode = db.get(node) if node else [ NULL ] * 17 +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = value else: - newindex = update(curnode[path[0]],path[1:],value) + newindex = update(curnode[path[0]], path[1:], value) newnode[path[0]] = newindex - db.put(hash(newnode),newnode) + db.put(hash(newnode), newnode) return hash(newnode) - def delete(node,path): - if node is NULL: + def delete(node_hash, path): + if node_hash is NULL: return NULL else: - curnode = db.get(node) + curnode = db.get(node_hash) newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = NULL else: - newindex = delete(curnode[path[0]],path[1:]) + newindex = delete(curnode[path[0]], path[1:]) newnode[path[0]] = newindex if all(x is NULL for x in newnode): return NULL else: - db.put(hash(newnode),newnode) + db.put(hash(newnode), newnode) return hash(newnode) ``` -Uma árvore Radix "Merkle" é construída ligando os nós usando digests de hash criptográficos gerados deterministicamente. Este endereçamento de conteúdo (no BD chave/valor `key == keccak256(rlp(value))`) fornece uma integridade criptográfica garantida do dado armazenado. Se o hash raiz de um Trie - teste - determinado for conhecido publicamente, então, qualquer um com acesso aos dados da folha subjacente poderá fornecer uma prova de que o Trie - teste - inclui um determinado valor em um caminho específico, fornecendo os hashes de cada nódulo que se junta a um valor específico para a raiz da árvore. +Uma árvore Radix "Merkle" é construída ligando os nós usando digests de hash criptográficos gerados deterministicamente. Este endereçamento de conteúdo (no banco de dados de chave/valor `key == keccak256(rlp(value))`) fornece uma garantia de integridade criptográfica dos dados armazenados. Se o hash raiz de um Trie - teste - determinado for conhecido publicamente, então, qualquer um com acesso aos dados da folha subjacente poderá fornecer uma prova de que o Trie - teste - inclui um determinado valor em um caminho específico, fornecendo os hashes de cada nódulo que se junta a um valor específico para a raiz da árvore. -É impossível para um atacante fornecer uma prova de um par `(path, value)` que não exista, já que o hash raiz é, em última análise, baseado em todos os hashes abaixo dele. Qualquer modificação subjacente alteraria o hash raiz. Você pode pensar no hash como uma representação comprimida de informações estruturais sobre os dados, seguros pela proteção pré-imagem da função de hash. +É impossível para um invasor fornecer uma prova de um par `(path, value)` que não existe, pois o hash raiz é, em última instância, baseado em todos os hashes abaixo dele. Qualquer modificação subjacente alteraria o hash raiz. Você pode pensar no hash como uma representação comprimida de informações estruturais sobre os dados, seguros pela proteção pré-imagem da função de hash. -Vamos nos referir a uma unidade atômica de uma árvore de radix (por exemplo, um único caractere hexadecimal, ou número binário de 4 bits) como um "nibble". Ao percorrerem um caminho um nibble de cada vez, conforme descrito acima, os nós podem fazer referência a 16 filhos, no máximo, mas incluir um elemento `value`. Portanto, nós os representamos como uma faixa de comprimento 17. Chamamos esses arrays de 17 elementos de "branch nodes". +Nós nos referiremos a uma unidade atômica de uma árvore radix (por exemplo, um único caractere hexadecimal, ou um número binário de 4 bits) como um \"nibble\". Ao percorrer um caminho um nibble de cada vez, como descrito acima, os nós podem se referir a no máximo 16 filhos, mas incluem um elemento de `value`. Portanto, nós os representamos como uma faixa de comprimento 17. Chamamos esses arrays de 17 elementos de "branch nodes". -## Árvore Merkle Patricia {#merkle-patricia-trees} +## Trie Merkle Patricia {#merkle-patricia-trees} -As árvores radix têm uma grande limitação: são ineficientes. Se você quiser armazenar uma vinculação `(path, value)` em que o caminho tem, como no Ethereum, 64 caracteres de comprimento (o número de nibbles em `bytes32`), você vai precisar de mais de um kilobyte de espaço extra para armazenar um nível por caractere, e cada busca ou exclusão precisará das 64 etapas completas. A árvore Patricia apresentada aqui resolve esta questão. +As árvores radix têm uma grande limitação: são ineficientes. Se você quiser armazenar uma vinculação `(path, value)` onde o caminho, como no Ethereum, tem 64 caracteres (o número de nibbles em `bytes32`), precisaremos de mais de um kilobyte de espaço extra para armazenar um nível por caractere, e cada busca ou exclusão levará 64 passos completos. A árvore Patricia apresentada aqui resolve esta questão. ### Otimização {#optimization} Um nó em uma árvore Merkle Patricia é um dos seguintes: -1. `NULL` (representado como a string vazia) -2. `branch` Um nó de 17 itens `[ v0 ... v15, vt ]` -3. `leaf` Um nó de 2 itens `[ encodedPath, value ]` -4. `extension` Um nó de 2 itens `[ encodedPath, key ]` +1. `NULL` (representado como a string vazia) +2. `branch` Um nó de 17 itens `[ v0 ...` `v15, vt ]` +3. `leaf` Um nó de 2 itens `[ encodedPath, value ]` +4. `extension` Um nó de 2 itens `[ encodedPath, key ]` -Com caminhos de 64 caracteres, é inevitável que depois de atravessar as primeiras poucas camadas da árvore, você alcançe um nó em que não existe caminho divergente para pelo menos parte do caminho para baixo. Para evitar ter que criar até 15 nós esparsos `NULL` ao longo do caminho, encurtamos a descida configurando um nó de ` extension` do formulário `[ encodedPath, key ]`, em que `encodedPath` contém o "caminho parcial" a ignorar (usando uma codificação compacta descrita abaixo), e a `key` é para a próxima pesquisa no banco de dados. +Com caminhos de 64 caracteres, é inevitável que depois de atravessar as primeiras poucas camadas da árvore, você alcançe um nó em que não existe caminho divergente para pelo menos parte do caminho para baixo. Para evitar ter que criar até 15 nós `NULL` esparsos ao longo do caminho, encurtamos a descida configurando um nó de `extension` da forma `[ encodedPath, key ]`, onde `encodedPath` contém o \"caminho parcial\" para avançar (usando uma codificação compacta descrita abaixo), e a `key` é para a próxima consulta ao banco de dados. -Para um nó de `leaf`, que pode ser marcado por um flag na primeira nibble do `encodedPath`, o caminho codifica todos os fragmentos de caminho do nó anterior e podemos procurar o `value` diretamente. +Para um nó `leaf`, que pode ser marcado por uma flag no primeiro nibble do `encodedPath`, o caminho codifica todos os fragmentos de caminho do nó anterior e podemos consultar o `value` diretamente. Esta otimização acima, porém, introduz ambiguidade. -Quando atravessamos caminhos em nibbles, podemos acabar com um número ímpar de nibbles para percorrer, mas porque todos os dados são armazenados no formato `bytes`. Não é possível diferenciar entre, por exemplo, o nibble `1` e os nibbles`01` (ambos devem ser armazenados como `<01>`). Para especificar comprimento ímpar, o caminho parcial é precedido com um flag. +Ao percorrer caminhos em nibbles, podemos acabar com um número ímpar de nibbles para atravessar, mas como todos os dados são armazenados em formato de `bytes`. Não é possível diferenciar, por exemplo, o nibble `1` dos nibbles `01` (ambos devem ser armazenados como `<01>`). Para especificar comprimento ímpar, o caminho parcial é precedido com um flag. ### Especificação: Codificação compacta de sequência hexadecimal com terminador opcional {#specification} -A sinalização de _largura restante do caminho parcial, par ou ímpar,_ e de _nó leaf vs nó de extensão_ conforme descrito acima reside no primeiro nibble do caminho parcial de qualquer nó de 2 elementos. Eles resultam no seguinte: +A sinalização de _comprimento do caminho parcial restante par ou ímpar_ e de _nó folha versus nó de extensão_, como descrito acima, reside no primeiro nibble do caminho parcial de qualquer nó de 2 itens. Eles resultam no seguinte: - hex char bits | node type partial path length - ---------------------------------------------------------- - 0 0000 | extension even - 1 0001 | extension odd - 2 0010 | terminating (leaf) even - 3 0011 | terminating (leaf) odd +| caractere hexadecimal | bits | node tipo parcial | comprimento do caminho | +| --------------------- | ---- | ------------------------------------- | ---------------------- | +| 0 | 0000 | extensão | par | +| 1 | 0001 | extensão | mínima vantagem | +| 2 | 0010 | terminação (folha) | par | +| 3 | 0011 | terminação (folha) | mínima vantagem | -Para um comprimento restante de caminho par (`0` ou `2`), sempre seguirá um outro nibble "padding" `0`. +Para um comprimento de caminho restante par (`0` ou `2`), outro nibble `0` de \"preenchimento\" sempre se seguirá. -``` +```python def compact_encode(hexarray): term = 1 if hexarray[-1] == 16 else 0 - if term: hexarray = hexarray[:-1] + if term: + hexarray = hexarray[:-1] oddlen = len(hexarray) % 2 flags = 2 * term + oddlen if oddlen: hexarray = [flags] + hexarray else: hexarray = [flags] + [0] + hexarray - // hexarray now has an even length whose first nibble is the flags. - o = '' - for i in range(0,len(hexarray),2): - o += chr(16 * hexarray[i] + hexarray[i+1]) + # hexarray agora tem um comprimento par cujo primeiro nibble são as flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) return o ``` Exemplos: -``` - > [ 1, 2, 3, 4, 5, ...] +```python + > [1, 2, 3, 4, 5, ...] '11 23 45' - > [ 0, 1, 2, 3, 4, 5, ...] + > [0, 1, 2, 3, 4, 5, ...] '00 01 23 45' - > [ 0, f, 1, c, b, 8, 10] + > [0, f, 1, c, b, 8, 10] '20 0f 1c b8' - > [ f, 1, c, b, 8, 10] + > [f, 1, c, b, 8, 10] '3f 1c b8' ``` Aqui está o código estendido para obter um nó na árvore Merkle Patricia: -``` - def get_helper(node,path): - if path == []: return node - if node = '': return '' - curnode = rlp.decode(node if len(node) < 32 else db.get(node)) +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) if len(curnode) == 2: (k2, v2) = curnode k2 = compact_decode(k2) - if k2 == path[:len(k2)]: - return get(v2, path[len(k2):]) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) else: - return '' + return "" elif len(curnode) == 17: - return get_helper(curnode[path[0]],path[1:]) + return get_helper(curnode[path[0]], path[1:]) - def get(node,path): + def get(node_hash, path): path2 = [] for i in range(len(path)): path2.push(int(ord(path[i]) / 16)) path2.push(ord(path[i]) % 16) path2.push(16) - return get_helper(node,path2) + return get_helper(node_hash, path2) ``` -### Árvore de exemplo {#example-trie} +### Exemplo de Trie {#example-trie} -Suponha que queremos um trie contendo quatro pares de caminho/valor `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. +Suponha que queiramos uma trie contendo quatro pares de caminho/valor: `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. -Primeiro, convertemos ambos caminhos e valores para `bytes`. Abaixo, representações reais em bytes para _caminhos_ são indicadas por `<>`, embora _valores_ ainda sejam mostrados como strings, denotado por `''`, para melhor compreensão (eles, também, seriam `bytes`): +Primeiro, convertemos os caminhos e valores para `bytes`. Abaixo, as representações de bytes reais para _paths_ são denotadas por `<>`, embora os _values_ ainda sejam mostrados como strings, denotados por `''`, para facilitar a compreensão (eles também seriam `bytes`): ``` <64 6f> : 'verb' @@ -183,38 +186,38 @@ Agora, construímos uma árvore com os seguintes pares chave/valor no banco de d hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] ``` -Quando um nó é referenciado dentro de outro nó, o que é incluído é `H(rlp.encode(node))`, onde `H(x) = keccak256(x) if len(x) >= 32 else x` e `rlp.encode` é a função de codificação [RLP](/developers/docs/data-structures-and-encoding/rlp). +Quando um nó é referenciado dentro de outro nó, o que é incluído é `keccak256(rlp.encode(node))`, se `len(rlp.encode(node)) >= 32` senão `node`, onde `rlp.encode` é a função de codificação [RLP](/developers/docs/data-structures-and-encoding/rlp). -Observe que, ao atualizar uma árvore, é necessário armazenar o par chave/valor `(keccak256(x), x)` em uma tabela de pesquisa persistente _se_ o nó recém-criado tem comprimento >= 32. Entretanto, se o nó é menor do que isso, não é preciso armazenar nada, já que a função f(x) = x é reversível. +Observe que, ao atualizar uma trie, é necessário armazenar o par de chave/valor `(keccak256(x), x)` em uma tabela de consulta persistente _se_ o nó recém-criado tiver um comprimento >= 32. Entretanto, se o nó é menor do que isso, não é preciso armazenar nada, já que a função f(x) = x é reversível. -## Árvores no Ethereum {#tries-in-ethereum} +## Tries no Ethereum {#tries-in-ethereum} Todas as árvores Merkle na camada de execução do Ethereum usam uma árvore Merkle Patricia. Do cabeçalho do bloco há 3 raízes dessas 3 árvores. -1. stateRoot -2. transactionsRoot -3. receiptsRoot +1. stateRoot +2. transactionsRoot +3. receiptsRoot -### Árvore de estado {#state-trie} +### Trie de Estado {#state-trie} -Existe um estado global da árvore que é atualizado toda vez que um cliente processa um bloco. Nela, um `path` é sempre: `keccak256(ethereumAddress)` e um `value` é sempre: `rlp(ethereumAccount)`. Mais especificamente uma `conta` Ethereum é uma array de 4 itens `[nonce,balance,storageRoot,codeHash]`. Neste ponto, vale a pena notar que este `storageRoot` é a raiz de outra árvore Patricia: +Existe um estado global da árvore que é atualizado toda vez que um cliente processa um bloco. Nela, um `path` é sempre: `keccak256(ethereumAddress)` e um `value` é sempre: `rlp(ethereumAccount)`. Mais especificamente, uma `conta` Ethereum é um array de 4 itens: `[nonce,balance,storageRoot,codeHash]`. Neste ponto, vale a pena notar que esta `storageRoot` é a raiz de outra trie Patricia: -### Árvore de armazenamento {#storage-trie} +### Trie de armazenamento {#storage-trie} -Árvore de armazenamento é onde _todos_ os dados de contrato se encontram. Há uma árvore de armazenamento separada para cada conta. Para recuperar valores em posições específicas de armazenamento em um determinado endereço, o endereço de armazenamento, posição inteira dos dados armazenados no armazenamento, e a ID do bloco, são necessárias. Eles podem então ser passados como argumentos para `eth_getStorageAt` definido na API JSON-RPC, por exemplo, para recuperar os dados no slot de armazenamento 0 para o endereço `0x295a70b2de5e3953354a6a8344e616ed314d7251`: +A trie de armazenamento é onde _todos_ os dados de contrato residem. Há uma árvore de armazenamento separada para cada conta. Para recuperar valores em posições específicas de armazenamento em um determinado endereço, o endereço de armazenamento, posição inteira dos dados armazenados no armazenamento, e a ID do bloco, são necessárias. Estes podem então ser passados como argumentos para o `eth_getStorageAt` definido na API JSON-RPC, por exemplo, para recuperar os dados no slot de armazenamento 0 para o endereço `0x295a70b2de5e3953354a6a8344e616ed314d7251`: -``` +```bash 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 outros elementos no armazenamento é um pouco mais complicado, porque a posição na árvore de armazenamento deve ser calculada primeiro. A posição é calculada como o hash `keccak256` do endereço e da posição de armazenamento, ambos alinhados à esquerda com zeros para um comprimento de 32 bytes. Por exemplo, a posição para os dados no slot 1 de armazenamento para o endereço `0x391694e7e0b0cce554cb130d723a9d27458f9298` é: +Recuperar outros elementos no armazenamento é um pouco mais complicado, porque a posição na árvore de armazenamento deve ser calculada primeiro. A posição é calculada como o hash `keccak256` do endereço e da posição de armazenamento, ambos preenchidos à esquerda com zeros para um comprimento de 32 bytes. Por exemplo, a posição dos dados no slot de armazenamento 1 para o endereço `0x391694e7e0b0cce554cb130d723a9d27458f9298` é: -``` +```python keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) ``` @@ -229,19 +232,19 @@ undefined O `path` é, portanto, `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Isso agora pode ser usado para recuperar os dados da árvore de armazenamento como antes: -``` +```bash 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"} ``` -Nota: O `storageRoot` para uma conta Ethereum está vazio pelo padrão se ele não for uma conta de contrato. +Observação: O `storageRoot` de uma conta Ethereum está vazio por padrão se não for uma conta de contrato. -### Árvore de transações {#transaction-trie} +### Trie de Transações {#transaction-trie} -Há uma árvore de transações separada para cada bloco, armazenando novamente pares `(key, value)`. Um caminho aqui é: `rlp(transactionIndex)` que representa a chave que corresponde a um valor determinado por: +Existe uma trie de transações separada para cada bloco, armazenando novamente pares `(chave, valor)`. Um caminho aqui é: `rlp(transactionIndex)`, que representa a chave que corresponde a um valor determinado por: -``` +```python if legacyTx: value = rlp(tx) else: @@ -250,14 +253,14 @@ else: Mais informações sobre isso podem ser encontradas na documentação do [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). -### Árvore de recibos {#receipts-trie} +### Trie de Recibos {#receipts-trie} -Cada bloco tem sua própria árvore de recibos. Um `path` aqui é: `rlp(transactionIndex)`. `transactionIndex` é seu índice dentro do bloco em que foi incluído. A árvore de recibos nunca é atualizada. De maneira similar à árvore de Transações, existem recibos atuais e legados. Para consultar um recibo específico na árvore de Recibos, o índice da transação em seu bloco, o payload do recibo e o tipo de transação são necessários. O recibo retornado pode ser do tipo `Receipt`, que é definido como a concentração de `TransactionType` e `ReceiptPayload`, ou pode ser do tipo `LegacyReceipt`, que é definido como `rlp([status, acumulativoGasUsed, logsBloom, logs])`. +Cada bloco tem sua própria árvore de recibos. Um `path` aqui é: `rlp(transactionIndex)`. `transactionIndex` é seu índice dentro do bloco em que foi incluído. A árvore de recibos nunca é atualizada. De maneira similar à árvore de Transações, existem recibos atuais e legados. Para consultar um recibo específico na árvore de Recibos, o índice da transação em seu bloco, o payload do recibo e o tipo de transação são necessários. O recibo retornado pode ser do tipo `Receipt`, que é definido como a concatenação de `TransactionType` e `ReceiptPayload` ou pode ser do tipo `LegacyReceipt`, que é definido como `rlp([status, cumulativeGasUsed, logsBloom, logs])`. Mais informações sobre isso podem ser encontradas na documentação do [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). -## Leitura Adicional {#further-reading} +## Leitura adicional {#further-reading} -- [Árvore Merkle Patricia modificada: como o Ethereum salva um estado](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) -- [Fazendo Merkle no Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum) -- [Entendendo a árvore Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) +- [Trie Merkle Patricia Modificada — Como o Ethereum salva um estado](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Merkling no Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Entendendo a trie do Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/rlp/index.md index f30c5045b80..cc40d982410 100644 --- a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/rlp/index.md +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/rlp/index.md @@ -1,24 +1,24 @@ --- -title: Serialização do prefixo de comprimento recursivo (RLP) -description: Uma definição da codificação RLP na camada de execução do Ethereum +title: "Serialização do prefixo de comprimento recursivo (RLP)" +description: "Uma definição da codificação RLP na camada de execução do Ethereum" lang: pt-br sidebarDepth: 2 --- -A Serialização do prefixo de comprimento recursivo (RLP) é usado extensivamente nos clientes de execução Ethereum. RLP padroniza a transferência de dados entre nós em um formato eficiente em espaço. O objetivo do RLP é codificar arbitrariamente arrays de dados binários aninhados, e o RLP é o principal método de codificação usado para serializar objetos na camada de execução do Ethereum. O principal objetivo do RLP é codificar a estrutura; com exceção de números inteiros positivos, o RLP delega a codificação de tipos de dados específicos (por exemplo, strings, floats) para protocolos de ordem superior. Os inteiros positivos devem ser representados no formato binário big-endian, sem zeros à esquerda (tornando assim o valor inteiro zero equivalente ao array de bytes vazio). Inteiros positivos desserializados com zeros à esquerda devem ser tratados como inválidos por qualquer protocolo de ordem superior que use RLP. +A Serialização do prefixo de comprimento recursivo (RLP) é usado extensivamente nos clientes de execução Ethereum. RLP padroniza a transferência de dados entre nós em um formato eficiente em espaço. O objetivo do RLP é codificar arbitrariamente arrays de dados binários aninhados, e o RLP é o principal método de codificação usado para serializar objetos na camada de execução do Ethereum. O objetivo principal do RLP é codificar a estrutura; com exceção de números inteiros positivos, o RLP delega a codificação de tipos de dados específicos (por exemplo, strings, floats) para protocolos de ordem superior. Os inteiros positivos devem ser representados no formato binário big-endian, sem zeros à esquerda (tornando assim o valor inteiro zero equivalente ao array de bytes vazio). Inteiros positivos desserializados com zeros à esquerda devem ser tratados como inválidos por qualquer protocolo de ordem superior que use RLP. -Mais informações nas [ páginas amarelas Ethereum (Apêndice B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). +Mais informações em [o yellow paper do Ethereum (Apêndice B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). Para usar o RLP para codificar um dicionário, as duas formas canônicas são: -- usar `[[k1,v1],[k2,v2]...]` com chaves em ordem lexicográfica +- use `[[k1,v1],[k2,v2]...]` com chaves em ordem lexicográfica - usar a codificação da Árvore Patricia de nível superior como Ethereum faz ## Definição {#definition} A função de codificação RLP recebe um item. Um item é definido como abaixo： -- uma string (ou seja, um byte array) é um item +- uma string (ou seja, matriz de bytes) é um item - uma lista de itens é um item - um inteiro positivo é um item @@ -27,7 +27,7 @@ Por exemplo, todos os seguintes são itens: - uma string vazia; - a string que contém a palavra "cat"; - uma lista contendo qualquer número de strings; -- e uma estrutura de dados mais complexa, como `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. +- e estruturas de dados mais complexas como `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. - o número `100` Observe que, no contexto do restante desta página, 'string' significa "um certo número de bytes de dados binários"; nenhuma codificação especial é usada, e nenhum conhecimento sobre o conteúdo das strings é implícito (exceto conforme exigido pela regra contra inteiros positivos não mínimos). @@ -35,12 +35,12 @@ Observe que, no contexto do restante desta página, 'string' significa "um certo A codificação RLP é definida da seguinte forma: - Para um número inteiro positivo, ele é convertido para o menor array de bytes cuja interpretação big-endian é o número inteiro e, então, codificado como uma string de acordo com as regras abaixo. -- Para um único byte cujo valor está na faixa `[0x00, 0x7f]` (decimal `[0, 127]`), este byte é a sua própria codificação RLP. -- Caso contrário, se uma string tem de 0 a 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0x80** (dec. 128) mais o comprimento da string seguida pela string. O intervalo do primeiro byte é, portanto, `[0x80, 0xb7]` (dec. `[128, 183]`). -- Se uma string tem mais de 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0xb7** (dec. 183) mais o comprimento em bytes do comprimento da sequência de caracteres na forma binária, seguido pelo comprimento da string, seguido pela string. Por exemplo, uma string de 1024 bytes de comprimento seria codificada como `\xb9\x04\x00` (dec. `185, 4, 0`) seguida pela string. Aqui, `0xb9` (183 + 2 = 185) como o primeiro byte, seguido pelos 2 bytes `0x0400` (dec. 1024) que denotam o comprimento da string real. O intervalo do primeiro byte é, portanto, `[0x80, 0xb7]` (dec. `[184, 191]`). +- Para um único byte cujo valor está no intervalo `[0x00, 0x7f]` (decimal `[0, 127]`), esse byte é sua própria codificação RLP. +- Caso contrário, se uma string tiver de 0 a 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0x80** (dec. 128) mais o comprimento da string, seguido pela string. O intervalo do primeiro byte é, portanto, `[0x80, 0xb7]` (dec. `[128, 183]`). +- Se uma string tiver mais de 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0xb7** (dec. 183) mais o comprimento em bytes do comprimento da string em forma binária, seguido pelo comprimento da string, seguido pela string. Por exemplo, uma string de 1024 bytes de comprimento seria codificada como `\xb9\x04\x00` (dec. `185, 4, 0`) seguida pela string. Aqui, `0xb9` (183 + 2 = 185) como o primeiro byte, seguido pelos 2 bytes `0x0400` (dec. 1024) que indicam o comprimento da string real. O intervalo do primeiro byte é, portanto, `[0xb8, 0xbf]` (dec. `[184, 191]`). - Se uma string tiver 2^64 bytes de comprimento ou mais, ela poderá não ser codificada. -- Se o total de carga de uma lista (ou seja, o comprimento combinado de totos os seus itens com codificação RLP) tiver 0 a 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0xc0** mais o comprimento da carga seguido da concatenação das codificações dos itens. O intervalo do primeiro byte é, portanto, `[0x80, 0xb7]` (dec. `[192, 247]`). -- Se o payload total de uma lista tem mais de 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0xf7** mais o comprimento em bytes do payload na forma binária, seguida pelo comprimento do payload, seguido pela concatenação das codificações RLP dos itens. O intervalo do primeiro byte é, portanto, `[0x80, 0xb7]` (dec. `[248, 255]`). +- Se o payload total de uma lista (ou seja, o comprimento combinado de todos os seus itens codificados em RLP) tiver de 0 a 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0xc0** mais o comprimento do payload, seguido pela concatenação das codificações RLP dos itens. O intervalo do primeiro byte é, portanto, `[0xc0, 0xf7]` (dec. `[192, 247]`). +- Se o payload total de uma lista tiver mais de 55 bytes de comprimento, a codificação RLP consiste em um único byte com valor **0xf7** mais o comprimento em bytes do comprimento do payload em forma binária, seguido pelo comprimento do payload, seguido pela concatenação das codificações RLP dos itens. O intervalo do primeiro byte é, portanto, `[0xf8, 0xff]` (dec. `[248, 255]`). Em código, isto é: @@ -62,7 +62,7 @@ def encode_length(L, offset): elif L < 256**8: BL = to_binary(L) return chr(len(BL) + offset + 55) + BL - raise Exception("input too long") + raise Exception("input too long") def to_binary(x): if x == 0: @@ -80,30 +80,30 @@ def to_binary(x): - o byte '\\x00' = `[ 0x00 ]` - o byte '\\x0f' = `[ 0x0f ]` - os bytes '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` -- [define a representação teórica](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) para três, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- a [representação teórica de conjuntos](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) de três, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` - a string "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` ## Decodificação RLP {#rlp-decoding} De acordo com as regras e o processo de codificação RLP, a entrada da decodificação RLP é considerada uma matriz de dados binários. O processo de decodificação do RLP é o seguinte: -1. de acordo com o primeiro byte (ou seja, o prefixo) dos dados de entrada e a decodificação do tipo de dados, o comprimento do dado em si e deslocamento; +1. de acordo com o primeiro byte (ou seja, prefixo) dos dados de entrada e decodificando o tipo de dados, o comprimento dos dados reais e o deslocamento; -2. de acordo com o tipo e deslocamento dos dados, decodificar os dados de maneira correspondente, respeitando a regra de codificação mínima para inteiros positivos; +2. de acordo com o tipo e deslocamento dos dados, decodificar os dados de maneira correspondente, respeitando a regra de codificação mínima para inteiros positivos; -3. continue a decodificar o resto da entrada; +3. continue a decodificar o resto da entrada; Entre elas, as regras de decodificação de tipos de dados e deslocamento são as seguintes: -1. os dados são uma string se a faixa do primeiro byte (por exemplo, prefixo) é [0x00, 0x7f], e a string é exatamente o primeiro byte; +1. os dados são uma string se o intervalo do primeiro byte (ou seja, prefixo) for [0x00, 0x7f], e a string for exatamente o primeiro byte; -2. o dado é uma string se o intervalo do primeiro byte é [0x80, 0xb7], e a string cujo comprimento é igual ao primeiro byte menos 0x80 segue o primeiro byte; +2. o dado é uma string se o intervalo do primeiro byte é [0x80, 0xb7], e a string cujo comprimento é igual ao primeiro byte menos 0x80 segue o primeiro byte; -3. os dados são uma string se o intervalo do primeiro byte é [0xb8, 0xbf] e o comprimento da string cujo comprimento em bytes é igual ao primeiro byte menos 0xb7 segue primeiro byte, e a cadeia de caracteres segue o comprimento da string; +3. os dados são uma string se o intervalo do primeiro byte é [0xb8, 0xbf] e o comprimento da string cujo comprimento em bytes é igual ao primeiro byte menos 0xb7 segue primeiro byte, e a cadeia de caracteres segue o comprimento da string; -4. os dados são uma lista se o intervalo do primeiro byte é [0xc0, 0xf7], e a concatenação das codificações RLP de todos os itens da lista que a carga total é igual ao primeiro byte menos 0xc0 e segue o primeiro byte; +4. os dados são uma lista se o intervalo do primeiro byte é [0xc0, 0xf7], e a concatenação das codificações RLP de todos os itens da lista que a carga total é igual ao primeiro byte menos 0xc0 e segue o primeiro byte; -5. os dados são uma string se o intervalo do primeiro byte é [0xb8, 0xbf], e o payload total da lista cujo comprimento é igual ao primeiro byte menos 0xf7 segue o primeiro byte, e a concatenação das codificações RLP de todos os itens da lista segue o payload total da lista; +5. os dados são uma string se o intervalo do primeiro byte é [0xb8, 0xbf], e o payload total da lista cujo comprimento é igual ao primeiro byte menos 0xf7 segue o primeiro byte, e a concatenação das codificações RLP de todos os itens da lista segue o payload total da lista; Em código, isto é: @@ -154,10 +154,10 @@ def to_integer(b): ## Leitura adicional {#further-reading} -- [RLP em Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) -- [Ethereum nos bastidores: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [RLP no Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum por baixo dos panos: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) - [Coglio, A. (2020). Prefixo de comprimento recursivo do Ethereum em ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) ## Tópicos relacionados {#related-topics} -- [Árvore Patricia Merkle](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) +- [Patricia Merkle trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/ssz/index.md index 0193151103a..1f2bf0a91cf 100644 --- a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/ssz/index.md +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/ssz/index.md @@ -1,11 +1,11 @@ --- -title: Serialização simples -description: Explicação do formato SSZ do Ethereum +title: "Serialização simples" +description: "Explicação do formato SSZ do Ethereum" lang: pt-br sidebarDepth: 2 --- -A **serialização simples (SSZ ou simple serialize)** é o método de serialização usado na Beacon Chain. Ela substitui a serialização RLP usada na camada de execução em toda a camada de consenso, exceto no protocolo de descoberta de pares. SSZ foi projetado para ser determinístico e também para Merkleize (transformações em árvores de Merkle) de forma eficiente. SSZ pode ser pensado como tendo dois componentes: um esquema de serialização e um esquema de Merkleization que é projetado para trabalhar eficientemente com a estrutura de dados serializada. +**A serialização simples (SSZ)** é o método de serialização usado na Beacon Chain. Ela substitui a serialização RLP usada na camada de execução em toda a camada de consenso, exceto no protocolo de descoberta de pares. Para saber mais sobre a serialização RLP, consulte [Prefixo de comprimento recursivo (RLP)](/developers/docs/data-structures-and-encoding/rlp/). SSZ foi projetado para ser determinístico e também para Merkleize (transformações em árvores de Merkle) de forma eficiente. SSZ pode ser pensado como tendo dois componentes: um esquema de serialização e um esquema de Merkleization que é projetado para trabalhar eficientemente com a estrutura de dados serializada. ## Como funciona o SSZ? {#how-does-ssz-work} @@ -16,7 +16,7 @@ SSZ é um esquema de serialização que não é autodescritivo. Em vez disso, el - inteiros sem sinal - booleanos -Para tipos complexos de "composição", a serialização é mais complicada porque o tipo composto contém múltiplos elementos que podem ter diferentes tipos ou tamanhos diferentes, ou ambos. Onde todos esses objetos têm comprimentos fixos (ou seja, o tamanho dos elementos sempre será constante, independentemente de seus valores reais), a serialização é simplesmente uma conversão de cada elemento no tipo composto ordenado em strings de bytes little-endian. Estas strings de bytes estão unidas. O objeto serializado tem a representação de bytelist (array de bytes) dos elementos de comprimento fixo na mesma ordem em que aparecem no objeto desserializado. +Para tipos complexos de "composição", a serialização é mais complicada porque o tipo composto contém múltiplos elementos que podem ter diferentes tipos ou tamanhos diferentes, ou ambos. Quando estes objetos têm todos comprimentos fixos (isto é, o tamanho dos elementos é sempre constante, independentemente dos seus valores reais), a serialização é simplesmente a conversão de cada elemento no tipo composto, ordenado em strings de bytes little-endian. Estas strings de bytes estão unidas. O objeto serializado tem a representação de bytelist (array de bytes) dos elementos de comprimento fixo na mesma ordem em que aparecem no objeto desserializado. Para tipos com comprimentos variáveis, os dados reais são substituídos por um valor de "deslocamento" na posição desse elemento no objeto serializado. Os dados reais são adicionados a uma pilha (área de memória dinâmica) no final do objeto serializado. O valor de deslocamento é o índice para o início dos dados reais na pilha, atuando como um ponteiro para os bytes relevantes. @@ -44,14 +44,14 @@ O exemplo abaixo ilustra como o deslocamento funciona para um contêiner com ele ``` -`serialized` teria a seguinte estrutura (apenas preenchido com 4 bits aqui, mas preenchido com 32 bits na realidade e mantendo a representação `int` para clareza): +`serialized` teria a seguinte estrutura (apenas preenchido para 4 bits aqui, preenchido para 32 bits na realidade e mantendo a representação `int` para maior clareza): ``` [37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] ------------ ----------- ----------- ----------- ---------- | | | | | - number1 number2 offset for number 3 value for - vector vector + number1 number2 deslocamento number3 valor + do vector do vector ``` @@ -59,11 +59,11 @@ dividido em linhas para clareza: ``` [ - 37, 0, 0, 0, # little-endian encoding of `number1`. - 55, 0, 0, 0, # little-endian encoding of `number2`. - 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 22, 0, 0, 0, # little-endian encoding of `number3`. - 1, 2, 3, 4, # The actual values in `vector`. + 37, 0, 0, 0, # codificação little-endian de `number1`. + 55, 0, 0, 0, # codificação little-endian de `number2`. + 16, 0, 0, 0, # O "deslocamento" que indica onde o valor de `vector` começa (little-endian 16). + 22, 0, 0, 0, # codificação little-endian de `number3`. + 1, 2, 3, 4, # Os valores reais em `vector`. ] ``` @@ -71,54 +71,54 @@ Isso ainda é uma simplificação. Os inteiros e zeros nos esquemas acima, na ve ``` [ - 10100101000000000000000000000000 # little-endian encoding of `number1` - 10110111000000000000000000000000 # little-endian encoding of `number2`. - 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 10010110000000000000000000000000 # little-endian encoding of `number3`. - 10000001100000101000001110000100 # The actual value of the `bytes` field. + 10100101000000000000000000000000 # codificação little-endian de `number1` + 10110111000000000000000000000000 # codificação little-endian de `number2`. + 10010000000000000000000000000000 # O "deslocamento" que indica onde o valor de `vector` começa (little-endian 16). + 10010110000000000000000000000000 # codificação little-endian de `number3`. + 10000001100000101000001110000100 # O valor real do campo `bytes`. ] ``` Assim, os valores reais para tipos de comprimento variável são armazenados em uma pilha no final do objeto serializado com seus deslocamentos armazenados em suas posições corretas na lista ordenada de campos. -Existem também alguns casos especiais que requerem tratamento específico, como o tipo `BitList` que requer que seja adicionado um limite de comprimento durante a serialização e removido durante a desserialização. Os detalhes completos estão disponíveis na [especificação SSZ](https://github.com/ethereum/consensus-specs/blob/master/ssz/simple-serialize.md). +Há também alguns casos especiais que exigem tratamento específico, como o tipo `BitList`, que requer que um limite de comprimento seja adicionado durante a serialização e removido durante a desserialização. Detalhes completos estão disponíveis na [especificação SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). ### Desserialização {#deserialization} Para desserializar este objeto é necessário o esquema (diagrama, desenho). O esquema define o layout preciso dos dados serializados, para que cada elemento específico possa ser desserializado, de um blob de bytes em algum objeto significativo, com os elementos tendo o tipo, valor, tamanho e posição corretos. É o esquema que diz ao desserializador quais valores são valores reais e quais são deslocamentos. Todos os nomes de campo desaparecem quando um objeto é serializado, mas reinstanciados na desserialização de acordo com o esquema. -Veja [ssz.dev](https://www.ssz.dev/overview) para uma explicação interativa sobre isso. +Consulte [ssz.dev](https://www.ssz.dev/overview) para obter uma explicação interativa sobre isso. -## "Merkleização" {#merkleization} +## Merkleização {#merkleization} Esse objeto serializado SSZ pode então ser merkleizado, o seja, transformado em uma representação de árvore Merkle dos mesmos dados. Primeiro, o número de partes de 32 bytes no objeto serializado é determinado. Estas são as "folhas" da árvore. O número total de folhas deve ser uma potência de 2 para que a combinação das folhas eventualmente produza uma única raiz de árvore hash. Se este não for o caso natural, são adicionadas folhas extras que contêm 32 bytes de zeros. Diagramaticamente: ``` - hash tree root + raiz da árvore de hash / \ / \ / \ / \ - hash of leaves hash of leaves - 1 and 2 3 and 4 + hash das folhas hash das folhas + 1 e 2 3 e 4 / \ / \ / \ / \ / \ / \ - leaf1 leaf2 leaf3 leaf4 + folha1 folha2 folha3 folha4 ``` Há também casos em que as folhas da árvore não se distribuem naturalmente, de maneira uniforme, como o fazem no exemplo acima. Por exemplo, a folha 4 pode ser um contêiner com vários elementos que exige "profundidade" adicional para serem adicionados à árvore Merkle, criando uma árvore desnivelada. -Em vez de nos referirmos a esses elementos da árvore como folha X, nó X etc., podemos dar a eles índices generalizados, começando com raiz = 1 e contando da esquerda para a direita ao longo de cada nível. Este é o índice generalizado explicado acima. Cada elemento na lista serializada tem um índice genérico igual a `2**profundidade + idx`, onde o idx é a sua posição indexada por zero no objeto serializado e a profundidade é o número de níveis na árvore Merkle, que pode ser determinado como o logaritmo de base dois do número de elementos (folhas). +Em vez de nos referirmos a esses elementos da árvore como folha X, nó X etc., podemos dar a eles índices generalizados, começando com raiz = 1 e contando da esquerda para a direita ao longo de cada nível. Este é o índice generalizado explicado acima. Cada elemento na lista serializada tem um índice generalizado igual a `2**depth + idx`, onde `idx` é sua posição indexada a zero no objeto serializado e a profundidade (`depth`) é o número de níveis na árvore Merkle, que pode ser determinada como o logaritmo de base dois do número de elementos (folhas). ## Índices generalizados {#generalized-indices} -Um índice generalizado é um número inteiro que representa um nó em uma árvore Merkle binária em que cada nó tem um índice generalizado `2 ** profundidade + índice da linha`. +Um índice generalizado é um número inteiro que representa um nó em uma árvore Merkle binária, onde cada nó tem um índice generalizado de `2 ** depth + index in row`. ``` - 1 --depth = 0 2**0 + 0 = 1 - 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3 - 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + 1 --profundidade = 0 2**0 + 0 = 1 + 2 3 --profundidade = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --profundidade = 2 2**2 + 0 = 4, 2**2 + 1 = 5... ``` @@ -126,12 +126,13 @@ Essa representação produz um índice de nó para cada parte dos dados na árvo ## Multiprovas {#multiproofs} -Fornecer a lista de índices generalizados, que representam um elemento específico, nos permite verificá-lo em relação à raiz da árvore hash. Esta raiz é nossa versão aceita da realidade. Qualquer dado que nos for fornecido pode ser verificado em relação a essa realidade, inserindo-o no lugar certo na árvore Merkle (determinado pelo seu índice generalizado) e observando que a raiz permanece constante. Há funções na especificação [aqui](https://github.com/ethereum/consensus-specs/blob/master/ssz/merkle-proofs.md#merkle-multiproofs) que mostram como calcular o conjunto mínimo de nós necessários, para verificar o conteúdo de um conjunto particular de índices generalizados. +Fornecer a lista de índices generalizados, que representam um elemento específico, nos permite verificá-lo em relação à raiz da árvore hash. Esta raiz é nossa versão aceita da realidade. Qualquer dado que nos for fornecido pode ser verificado em relação a essa realidade, inserindo-o no lugar certo na árvore Merkle (determinado pelo seu índice generalizado) e observando que a raiz permanece constante. Há funções na especificação [aqui](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) que mostram como calcular o conjunto mínimo de nós necessários para verificar o conteúdo de um determinado conjunto de índices generalizados. -Por exemplo, para verificar o dado no índice 9 na árvore abaixo, precisamos do hash dos dados nos índices 8, 9, 5, 3, 1. O hash de (8,9) deve ser igual ao hash (4), que faz hash com 5 para produzir 2, que faz hash com 3 para produzir a raiz da árvore 1. Se dados incorretos fossem fornecidos para 9, a raiz mudaria; detectaríamos isso e falharíamos ao verificar a branch. +Por exemplo, para verificar o dado no índice 9 na árvore abaixo, precisamos do hash dos dados nos índices 8, 9, 5, 3, 1. +O hash de (8,9) deve ser igual ao hash (4), que faz hash com 5 para produzir 2, que faz hash com 3 para produzir a raiz da árvore 1. Se dados incorretos fossem fornecidos para 9, a raiz mudaria; detectaríamos isso e falharíamos ao verificar a branch. ``` -* = data required to generate proof +* = dados necessários para gerar a prova 1* 2 3* @@ -140,10 +141,10 @@ Por exemplo, para verificar o dado no índice 9 na árvore abaixo, precisamos do ``` -## Leia mais {#further-reading} +## Leitura adicional {#further-reading} -- [Atualização do Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) -- [Atualização do Ethereum: "Merkleização"](https://eth2book.info/altair/part2/building_blocks/merkleization) -- [Implementações SSZ](https://github.com/ethereum/consensus-specs/issues/2138) +- [Atualizando o Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [Atualizando o Ethereum: Merkleização](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [Implementações do SSZ](https://github.com/ethereum/consensus-specs/issues/2138) - [Calculadora SSZ](https://simpleserialize.com/) - [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md index 70b036fdda7..b36611d4f51 100644 --- a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md @@ -1,6 +1,6 @@ --- -title: Definição de armazenamento secreto Web3 -description: Definição formal para armazenamento secreto web3 +title: "Definição de armazenamento secreto Web3" +description: "Definição formal para armazenamento secreto web3" lang: pt-br sidebarDepth: 2 --- diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..3e6b4607f34 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: "Definição de armazenamento secreto Web3" +description: "Definição formal para armazenamento secreto web3" +lang: pt-br +sidebarDepth: 2 +--- + +Para fazer seu aplicativo funcionar no Ethereum, você pode usar o objeto web3 fornecido pela biblioteca web3.js. Internamente, ele se comunica com um nó local por meio de chamadas RPC. [web3](https://github.com/ethereum/web3.js/) funciona com qualquer nó Ethereum que expõe uma camada RPC. + +`web3` contém o objeto eth - web3.eth. + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** resultado + * [ 'web3', 3 ] arquivo de chave web3 (v3) + * [ 'ethersale', undefined ] arquivo de chave Ethersale + * null arquivo de chave inválido + */ +``` + +Este documento descreve a **versão 3** da Definição de Armazenamento Secreto da Web3. + +## Definição {#definition} + +A codificação e decodificação atuais do arquivo permanece em grande medida inalteradas da versão 1, exceto que o algoritmo cripto já não é fixo no AES-128-CBC (AES-128-CTR agora é o requisito mínimo). A maioria dos significados/algoritmos são semelhantes à versão 1, exceto o `mac`, que é dado como o SHA3 (keccak-256) das concatenações dos segundos 16 bytes mais à esquerda da chave derivada, juntamente com o `ciphertext` completo. + +Arquivos de chave secreta são armazenados diretamente em `~/.web3/keystore` (para sistemas do tipo Unix) e `~/AppData/Web3/keystore` (para Windows). Eles podem receber qualquer nome, mas uma boa convenção é `.json`, onde `` é o UUID de 128 bits atribuído à chave secreta (um proxy de preservação de privacidade para o endereço da chave secreta). + +Todos esses arquivos possuem uma senha associada. Para derivar a chave secreta de um determinado arquivo `.json`, primeiro derive a chave de criptografia do arquivo; isso é feito pegando a senha do arquivo e passando-a por uma função de derivação de chave, conforme descrito pela chave `kdf`. Os parâmetros estáticos e dinâmicos dependentes do KDF para a função KDF são descritos na chave `kdfparams`. + +PBKDF2 deve ser apoiado por todas as implementações minimamente compatíveis, denotadas assim: + +- `kdf`: `pbkdf2` + +Para PBKDF2, os kdfparams incluem: + +- `prf`: Deve ser `hmac-sha256` (pode ser estendido no futuro); +- `c`: número de iterações; +- `salt`: salt (sequência de bits aleatórios) passado para o PBKDF; +- `dklen`: comprimento da chave derivada. Deve ser >= 32. + +Uma vez que a chave do arquivo tenha sido derivada, ela deveria ser verificada através da derivação do MAC. O MAC deve ser calculado como o hash SHA3 (keccak-256) do array de bytes formado pelas concatenações dos segundos 16 bytes mais à esquerda da chave derivada com o conteúdo da chave `ciphertext`, ou seja: + +```js +KECCAK(DK[16..31] ++ ) +``` + +(onde `++` é o operador de concatenação) + +Este valor deve ser comparado com o conteúdo da chave `mac`; se forem diferentes, uma senha alternativa deve ser solicitada (ou a operação cancelada). + +Após a verificação da chave do arquivo, o texto cifrado (a chave `ciphertext` no arquivo) pode ser descriptografado usando o algoritmo de criptografia simétrica, especificado pela chave `cipher` e parametrizado através da chave `cipherparams`. Se o tamanho da chave derivada e o tamanho da chave do algoritmo forem incompatíveis, os zeros à esquerda, os bytes à direita da chave derivada deverão ser usados como a chave para o algoritmo. + +Todas as implementações minimamente compatíveis devem suportar o algoritmo AES-128-CTR, indicado através de: + +- `cipher: aes-128-ctr` + +Esta cifra toma os seguintes parâmetros, dados como chaves para a chave dos parâmetros de decifração: + +- `iv`: vetor de inicialização de 128 bits para a cifra. + +A chave para a cifra são os 16 bytes mais à esquerda da chave derivada, ou seja, `DK[0..15]` + +A criação/criptografia de uma chave secreta deve ser essencialmente o inverso dessas instruções. Certifique-se de que o `uuid`, o `salt` e o `iv` sejam realmente aleatórios. + +Além do campo `version`, que deve atuar como um identificador "rígido" da versão, as implementações também podem usar o `minorversion` para rastrear alterações menores, que não quebram o formato. + +## Vetores de Teste {#test-vectors} + +Detalhes: + +- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `Password`: `testpassword` +- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +Vetor de teste usando `AES-128-CTR` e `PBKDF2-SHA-256`: + +Conteúdo do arquivo `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Intermediários**: + +`Chave derivada`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`Corpo do MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`Chave de cifra`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +Vetor de teste usando AES-128-CTR e Scrypt: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Intermediários**: + +`Chave derivada`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`Corpo do MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`Chave de cifra`: `7446f59ecc301d2d79bc3302650d8a5c` + +## Alterações da Versão 1 {#alterations-from-v2} + +Esta versão corrige várias inconsistências com a versão 1 publicada [aqui](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). Em resumo, estas são: + +- A capitalização é injustificada e inconsistente (scrypt minúsculas, Kdf caso misto, MAC maiúsculas). +- Endereço desnecessário e compromete a privacidade. +- `Salt` é intrinsecamente um parâmetro da função de derivação de chave e merece ser associado a ela, não à criptografia em geral. +- _SaltLen_ desnecessário (basta derivá-lo do Salt). +- A função chave de derivação é dada, no entanto, o algoritmo de criptografia é difícil de especificar. +- `Version` é intrinsecamente numérico, mas é uma string (o versionamento estruturado seria possível com uma string, mas pode ser considerado fora do escopo para um formato de arquivo de configuração que muda raramente). +- `KDF` e `cipher` são conceitos conceitualmente semelhantes, mas organizados de forma diferente. +- `MAC` é calculado através de um trecho de dados agnóstico a espaços em branco(!) + +Foram feitas alterações no formato para dar o seguinte arquivo, funcionalmente equivalente ao exemplo dado na página anteriormente vinculada: + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## Alterações da Versão 2 {#alterations-from-v2} + +A versão 2 foi uma implementação inicial de C++ com um número de bugs. Todos os elementos essenciais permanecem inalterados. diff --git a/public/content/translations/pt-br/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/pt-br/developers/docs/design-and-ux/dex-design-best-practice/index.md new file mode 100644 index 00000000000..65afa5021df --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -0,0 +1,220 @@ +--- +title: "Melhores práticas de design para exchanges descentralizadas (DEX)" +description: "Um guia que explica decisões de UX/UI para troca de tokens." +lang: pt-br +--- + +Desde o lançamento do Uniswap em 2018, centenas de exchanges descentralizadas foram lançadas em dezenas de cadeias diferentes. +Muitos deles introduziram novos elementos ou adicionaram seu próprio toque, mas a interface permaneceu, em geral, a mesma. + +Um dos motivos para isso é a [Lei de Jakob](https://lawsofux.com/jakobs-law/): + +> Os usuários passam a maior parte do tempo em outros sites. Isso significa que os usuários preferem que o seu site funcione da mesma maneira que os outros sites com os quais já estão familiarizados. + +Graças a inovadores pioneiros como Uniswap, Pancakeswap e Sushiswap, os usuários de DeFi têm uma ideia coletiva de como uma DEX deve ser. +Por essa razão, está surgindo o conceito de "práticas recomendadas". Vemos cada vez mais decisões de design sendo padronizadas entre os sites. A evolução das exchanges descentralizadas pode ser vista como um grande exemplo de teste em tempo real. O que funcionou permaneceu, o que não funcionou foi descartado. Ainda há espaço para personalização, mas existem certos padrões que uma DEX deve seguir. + +Este artigo é um resumo de: + +- o que deve ser incluído +- como torná-lo o mais utilizável possível +- as principais formas de personalizar o design + +Todos os wireframes de exemplo foram desenvolvidos especialmente para este artigo, embora se baseiem em projetos reais. + +O kit do Figma também está incluído ao final. Sinta-se à vontade para usá-lo e acelerar a criação dos seus próprios wireframes! + +## Anatomia básica de um DEX {#basic-anatomy-of-a-dex} + +A interface do usuário geralmente contém três elementos: + +1. Formulário principal +2. Botão +3. Painel de detalhes + +![Interface de usuário genérica da DEX, mostrando os três elementos principais](./1.png) + +## Variações {#variations} + +Esse será um tema comum neste artigo, mas existem várias maneiras diferentes de organizar esses elementos. O “painel de detalhes” pode ser: + +- Acima do botão +- Abaixo do botão +- Escondido em um painel sanfonado +- E/ou em um modal de “pré-visualização” + +Nota: Um modal de “pré-visualização” é opcional, mas se você está mostrando poucos detalhes na interface de usuário principal, ele se torna essencial. + +## Estrutura do formulário principal {#structure-of-the-main-form} + +É nesta caixa em que você escolhe o token que deseja trocar. O componente é composto de um campo de entrada e um botão pequeno dispostos em linha. + +Normalmente, as exchanges descentralizadas exibem detalhes adicionais em uma linha acima e outra abaixo, embora isso possa ser configurado de forma diferente. + +![Linha de entrada, com uma linha de detalhes acima e abaixo](./2.png) + +## Variações {#variations2} + +Duas variações de interface do usuário são mostradas aqui: uma sem bordas, criando um design muito aberto, e outra em que a linha de entrada tem uma borda, criando um foco nesse elemento. + +![Duas variações de UI do formulário principal](./3.png) + +Essa estrutura básica permite que **quatro informações importantes** sejam exibidas no design: uma em cada canto. Se houver apenas uma linha superior/inferior, haverá apenas dois pontos. + +Durante a evolução do DeFi, muitas coisas diferentes foram incluídas aqui. + +## Informações importantes a serem incluídas {#key-info-to-include} + +- Saldo na carteira +- Botão máximo +- Equivalente em moeda fiduciária +- Impacto do preço no valor “recebido” + +No início do DeFi, o equivalente em moeda fiduciária muitas vezes não era exibido. Se você está desenvolvendo qualquer tipo de projeto Web3, é essencial que o equivalente em moeda fiduciária seja exibido. Os usuários ainda pensam em termos de moedas locais, então, para alinhar com os modelos mentais do mundo real, isso deve ser incluído. + +No segundo campo (aquele onde você escolhe o token para o qual está trocando), você também pode incluir o impacto no preço ao lado do valor em moeda fiduciária, calculando a diferença entre o valor de entrada e os valores estimados de saída. Esse é um detalhe bastante útil a ser incluído. + +Botões de porcentagem (p. ex., 25%, 50%, 75%) podem ser um recurso útil, mas ocupam mais espaço, adicionam mais chamadas para ação e adicionam mais carga mental. O mesmo se aplica aos controles deslizantes de porcentagem. Algumas dessas decisões de interface dependerão da sua marca e do tipo de usuário. + +Detalhes adicionais podem ser exibidos abaixo do formulário principal. Como esse tipo de informação é voltado principalmente para usuários profissionais, faz sentido optar por: + +- mantê-la o mínimo possível, ou; +- escondê-la em um painel sanfonado + +![Detalhes mostrados nos cantos do formulário principal](./4.png) + +## Informações extras a serem incluídas {#extra-info-to-include} + +- Preço do token +- Derrapagem +- Mínimo recebido +- Resultado esperado +- Impacto no preço +- Estimativa de custo de transação +- Outras taxas +- Roteamento de pedidos + +Certamente, alguns desses detalhes poderiam ser opcionais. + +O roteamento de pedidos é interessante, mas não faz muita diferença para a maioria dos usuários. + +Alguns outros detalhes estão simplesmente reafirmando a mesma coisa de maneiras diferentes. Por exemplo, "mínimo recebido" e "derrapagem" são dois lados da mesma moeda. Se você tiver uma derrapagem definida em 1%, então o mínimo que você pode esperar receber = resultado esperado-1%. Algumas interfaces de usuário mostrarão o valor esperado, o valor mínimo e a derrapagem. O que é útil, mas possivelmente excessivo. + +A maioria dos usuários deixará a derrapagem predefinida de qualquer maneira. + +O “impacto no preço” é geralmente mostrado entre parênteses ao lado do equivalente em moeda fiduciária no campo “para”. Este é um ótimo detalhe de experiência do usuário para adicionar, mas se ele é mostrado aqui, realmente precisa ser mostrado novamente abaixo? E depois novamente em uma tela de pré-visualização? + +Muitos usuários (especialmente os que trocam pequenos valores) não se preocuparão com esses detalhes; eles vão apenas inserir um valor e trocar. + +![Alguns detalhes mostram a mesma coisa](./5.png) + +Quais detalhes serão exibidos exatamente dependerá do seu público e da sensação que você deseja que o aplicativo transmita. + +Se você incluir a tolerância de derrapagem no painel de detalhes, também deverá torná-la editável diretamente daqui. Este é um bom exemplo de um “acelerador”; um truque inteligente de experiência do usuário que pode agilizar o fluxo de usuários experientes, sem comprometer a usabilidade geral do aplicativo. + +![A derrapagem pode ser controlada no painel de detalhes](./6.png) + +É uma boa ideia pensar cuidadosamente não apenas em uma informação específica em uma tela, mas em todo o fluxo, considerando: +Introduzir os números no formulário principal → Verificar os detalhes → Clicar na tela de pré-visualização (se houver uma tela de pré-visualização). +O painel de detalhes deve estar visível o tempo todo ou o usuário precisa clicar para expandi-lo? +Você deve criar atrito ao adicionar uma tela de pré-visualização? Isso força o usuário a desacelerar e considerar sua troca, o que pode ser útil. Mas eles querem ver todas as mesmas informações novamente? O que é mais útil para eles neste momento? + +## Opções de design {#design-options} + +Como mencionado, muito disso depende do seu estilo pessoal +Quem é o seu usuário? +Qual é a sua marca? +Você quer uma interface “profissional” mostrando todos os detalhes ou quer ser minimalista? +Mesmo que você esteja considerando os usuários profissionais que querem todas as informações possíveis, você ainda deve se lembrar das sábias palavras de Alan Cooper: + +> Não importa quão bonita ou legal seja sua interface, seria melhor que ela fosse mais simples. + +### Estrutura {#structure} + +- tokens à esquerda ou tokens à direita +- 2 linhas ou 3 +- detalhes acima ou abaixo do botão +- detalhes expandidos, minimizados ou não mostrados + +### Estilo do componente {#component-style} + +- vazio +- delineado +- preenchido + +De um ponto de vista puramente UX, o estilo da interface do usuário é menos importante do que você pensa. As tendências visuais vêm e vão em ciclos e muitas preferências são subjetivas. + +A maneira mais fácil de ter uma ideia disso – e pensar nas várias configurações diferentes – é dar uma olhada em alguns exemplos e depois fazer alguns experimentos você mesmo. + +O kit Figma incluído contém componentes vazios, contornados e preenchidos. + +Dê uma olhada nos exemplos abaixo para ver diferentes maneiras de juntar tudo: + +![3 linhas em estilo preenchido](./7.png) + +![3 linhas em estilo contornado](./8.png) + +![2 linhas em estilo vazio](./9.png) + +![3 filas em estilo contornado, com um painel de detalhes](./10.png) + +![3 linhas com uma linha de entrada em stilo contornado](./11.png) + +![2 linhas em estilo preenchido](./12.png) + +## Mas de que lado o token deve ficar? {#but-which-side-should-the-token-go-on} + +O ponto principal é que isso provavelmente não faz uma grande diferença na usabilidade. No entanto, há alguns aspectos que você deve ter em mente que podem fazer você decidir de uma forma ou de outra. + +Tem sido um pouco interessante ver a mudança de comportamento com o tempo. Inicialmente, o Uniswap tinha o token à esquerda, mas desde então o moveu para a direita. O Sushiswap também fez essa alteração durante uma atualização de design. A maioria dos protocolos, mas não todos, seguiu o exemplo. + +A convenção financeira tradicionalmente coloca o símbolo da moeda antes do número, p. ex., $50, €50, £50, mas nós _dizemos_ 50 dólares, 50 euros, 50 libras. + +Para o usuário em geral, especialmente alguém que lê da esquerda para a direita, de cima para baixo, o token à direita provavelmente parece mais natural. + +![A IU com tokens à esquerda](./13.png) + +Colocar o token à esquerda e todos os números à direita parece agradavelmente simétrico, o que é uma vantagem, mas há uma desvantagem neste layout. + +A lei da proximidade afirma que os itens que estão próximos são percebidos como relacionados. Dessa forma, nós queremos colocar os itens relacionados próximos uns dos outros. O saldo do token está diretamente relacionado ao próprio token e será alterado sempre que um novo token for selecionado. Portanto, faz um pouco mais de sentido que o saldo do token esteja próximo ao botão de seleção do token. Ele poderia ser movido para debaixo do token, mas isso quebraria a simetria do layout. + +Em última análise, há vantagens e desvantagens em ambas as opções, mas é interessante como a tendência parece estar se voltando para o token à direita. + +## Comportamento do botão {#button-behavior} + +Não tenha um botão separado para Aprovar. Também não tenha um clique separado para Aprovar. O usuário deseja trocar, então basta dizer “trocar” no botão e iniciar a aprovação como primeiro passo. Um modal pode mostrar o progresso com um passo a passo ou uma simples notificação “tx 1 de 2 - aprovando”. + +![IU com botões separados para Aprovar e Trocar](./14.png) + +![IU com um botão que diz "Aprovar"](./15.png) + +### Botão como ajuda contextual {#button-as-contextual-help} + +O botão também pode servir de alerta! + +Esse é, na verdade, um padrão de design bastante incomum fora da Web3, mas que se tornou padrão dentro dela. Essa é uma boa inovação, pois economiza espaço e mantém a atenção focalizada. + +Se a ação principal – SWAP – não está disponível devido a um erro, o motivo pode ser explicado com o botão, por exemplo.: + +- trocar de rede +- conectar carteira +- vários erros + +O botão também pode ser **correlacionado à ação** que precisa ser executada. Por exemplo, se o usuário não puder trocar porque está na rede errada, o botão deverá dizer “mudar para Ethereum” e, quando o usuário clicar no botão, ele deverá mudar a rede para Ethereum. Isso acelera significativamente o fluxo do usuário. + +![Ações fundamentais sendo iniciadas na chamada para ação principal](./16.png) + +![Mensagem de erro mostrada na chamada para ação principal](./17.png) + +## Construa o seu próprio com este arquivo figma {#build-your-own-with-this-figma-file} + +Graças ao trabalho intenso de vários protocolos, o design do DEX melhorou muito. Sabemos quais informações o usuário precisa, como devemos mostrá-las e como tornar o fluxo o mais fluido possível. +Esperamos que este artigo forneça uma visão geral sólida dos princípios de UX. + +Se você quiser experimentar, sinta-se à vontade para usar o kit de wireframe (diagramas) do Figma. Ele é mantido o mais simples possível, mas tem flexibilidade suficiente para construir a estrutura básica de várias maneiras. + +[Kit de wireframe Figma](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) + +O DeFi continuará a evoluir e sempre há espaço para melhorias. + +Boa sorte! diff --git a/public/content/translations/pt-br/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/pt-br/developers/docs/design-and-ux/heuristics-for-web3/index.md new file mode 100644 index 00000000000..28efb3ac3e5 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -0,0 +1,138 @@ +--- +title: "Sete heurísticas para o design da interface Web3" +description: "Princípios para melhorar a usabilidade do Web3" +lang: pt-br +--- + +As heurísticas de usabilidade são “regras gerais” que você pode usar para medir a usabilidade do seu site. +As 7 heurísticas apresentadas aqui são especificamente adaptadas para Web3 e devem ser usadas em conjunto com os [10 princípios gerais de design de interação](https://www.nngroup.com/articles/ten-usability-heuristics/) de Jakob Nielsen. + +## Sete heurísticas de usabilidade para web3 {#seven-usability-heuristics-for-web3} + +1. O feedback vem depois da ação +2. Segurança e confiança +3. A informação mais importante é evidente +4. Terminologia clara +5. As ações são tão curtas quanto possível +6. As conexões de rede são visíveis e flexíveis +7. Controle pelo aplicativo, não pela carteira + +## Definições e exemplos {#definitions-and-examples} + +### 1. O feedback vem depois da ação {#feedback-follows-action} + +**Deve ser óbvio quando algo aconteceu ou está acontecendo.** + +Os usuários decidem as próximas etapas com base no resultado das etapas anteriores. Portanto, é essencial que eles permaneçam informados sobre o status do sistema. Isso é especialmente importante na Web3, pois às vezes as transações podem levar um curto período de tempo para serem confirmadas na blockchain. Se não houver nenhum feedback informando para esperar, os usuários não terão certeza se algo aconteceu. + +**Dicas:** + +- Informe o usuário por meio de mensagens, notificações e outros alertas. +- Comunique claramente os tempos de espera. +- Se uma ação demorar mais do que alguns segundos, tranquilize o usuário com um cronômetro ou uma animação para fazê-lo sentir que algo está acontecendo. +- Se houver várias etapas em um processo, mostre cada etapa. + +**Exemplo:** +Mostrar cada etapa envolvida em uma transação ajuda os usuários a saber onde estão no processo. Ícones apropriados permitem que o usuário saiba o status de suas ações. + +![Informando o usuário sobre cada etapa da troca de tokens](./Image1.png) + +### 2. A segurança e a confiança são incorporadas {#security-and-trust-are-backed-in} + +A segurança deve ser priorizada, e isso deve ser enfatizado para o usuário. +As pessoas se importam profundamente com seus dados. A segurança é frequentemente uma preocupação principal para os usuários, por isso deve ser considerada em todos os níveis do design. Você deve sempre tentar ganhar a confiança dos seus usuários, mas a maneira como você faz isso pode significar coisas diferentes em aplicativos diferentes. Isso não deve ser uma reflexão tardia, mas sim algo planejado conscientemente ao longo de todo o processo de design. Crie confiança em toda a experiência do usuário, inclusive nos canais sociais e na documentação, bem como na interface do usuário final. Aspectos como o nível de descentralização, o status de multi-sig da tesouraria e se os membros da equipe são conhecidos publicamente afetam a confiança dos usuários. + +**Dicas:** + +- Liste suas auditorias com orgulho +- Obtenha várias auditorias +- Anuncie quaisquer recursos de segurança que você projetou +- Destaque os possíveis riscos, incluindo integrações subjacentes +- Comunique a complexidade das estratégias +- Considere questões além da interface que possam influenciar a percepção de segurança dos seus usuários + +**Exemplo:** +Inclua suas auditorias no rodapé, em um tamanho destacado. + +![Auditorias referenciadas no rodapé do site](./Image2.png) + +### 3. A informação mais importante é evidente {#the-most-important-info-is-obvious} + +Para sistemas complexos, mostre apenas os dados mais relevantes. Determine o que é mais importante e priorize sua exibição. +O excesso de informações é esmagador e os usuários geralmente se concentram em uma única informação ao tomar decisões. No DeFi, isso provavelmente será APR em aplicativos de rendimento e LTV em aplicativos de empréstimo. + +**Dicas:** + +- A pesquisa com usuários revelará a métrica mais importante +- Faça com que as informações principais sejam grandes e os outros detalhes sejam pequenos e discretos +- As pessoas não leem, elas escaneiam; garanta que seu design seja escaneável + +**Exemplo:** Tokens grandes e coloridos são fáceis de encontrar ao escanear. O APR é grande e destacado em uma cor de destaque. + +![O token e a APR são fáceis de encontrar](./Image3.png) + +### 4. Terminologia clara {#clear-terminology} + +A terminologia deve ser compreensível e apropriada. +O jargão técnico pode ser um grande obstáculo, porque exige a construção de um modelo mental completamente novo. Os usuários não conseguem relacionar o design a palavras, frases e conceitos que já conhecem. Tudo parece confuso e desconhecido, e há uma curva de aprendizado íngreme antes mesmo que eles tentem usá-lo. Um usuário pode abordar o DeFi querendo economizar algum dinheiro, e o que ele encontra é: Mineração, farming, staking, emissões, subornos, cofres, armários, veTokens, vesting, épocas, algoritmos descentralizados, liquidez de propriedade do protocolo. +Tente usar termos simples que sejam compreendidos pelo maior número possível de pessoas. Não invente termos novos apenas para o seu projeto. + +**Dicas:** + +- Use terminologia simples e consistente +- Use a linguagem existente o máximo possível +- Não invente seus próprios termos +- Siga as convenções conforme elas aparecem +- Eduque os usuários o máximo possível + +**Exemplo:** +“Suas recompensas” é um termo amplamente compreendido e neutro; não é uma palavra nova inventada para este projeto. As recompensas são denominadas em dólares americanos para corresponder aos modelos mentais do mundo real, mesmo que as recompensas em si estejam em outro token. + +![Recompensas de token, exibidas em dólares americanos](./Image4.png) + +### 5. As ações são tão curtas quanto possível {#actions-are-as-short-as-possible} + +Acelere as interações do usuário agrupando subações. +Isso pode ser feito no nível do contrato inteligente, bem como na interface do usuário. O usuário não deve ter que se mover de uma parte do sistema para outra – ou sair do sistema completamente – para concluir uma ação comum. + +**Dicas:** + +- Combine “Aprovar” com outras ações sempre que possível +- Agrupe as etapas de assinatura o mais próximo possível umas das outras + +**Exemplo:** Combinar “adicionar liquidez” e “stake” é um exemplo simples de um acelerador que economiza tempo e combustível para o usuário. + +![Modal mostrando um interruptor para combinar as ações de depósito e stake](./Image5.png) + +### 6. As conexões de rede são visíveis e flexíveis {#network-connections-are-visible-and-flexible} + +Informe ao usuário a qual rede ele está conectado e forneça atalhos claros para alterar a rede. +Isto é especialmente importante em aplicativos multichain. As principais funções do aplicativo ainda devem estar visíveis quando desconectado ou conectado a uma rede não suportada. + +**Dicas:** + +- Mostre o máximo possível do aplicativo enquanto estiver desconectado +- Mostre a qual rede o usuário está conectado no momento +- Não faça o usuário ir até a carteira para trocar de rede +- Se o aplicativo exigir que o usuário troque de rede, que essa ação possa ser feita na chamada para ação principal +- Se o aplicativo contiver mercados ou cofres para várias redes, indique claramente qual conjunto o usuário está visualizando no momento + +**Exemplo:** Mostre ao usuário a qual rede ele está conectado e permita que ele a altere na barra de aplicativos. + +![Botão suspenso mostrando a rede conectada](./Image6.png) + +### 7. Controle pelo aplicativo, não pela carteira {#control-from-the-app-not-the-wallet} + +A interface do usuário deve informar ao usuário tudo o que ele precisa saber e dar a ele controle sobre tudo o que ele precisa fazer. +No Web3, há ações que você realiza na interface do usuário e ações que você realiza na carteira. Geralmente, você inicia uma ação na interface do usuário e depois a confirma na carteira. Os usuários podem se sentir desconfortáveis ​​se essas duas janelas não forem integradas cuidadosamente. + +**Dicas:** + +- Comunique o status do sistema por meio de feedback na IU +- Mantenha um histórico das ações do usuário +- Forneça links para exploradores de blocos de transações antigas +- Forneça atalhos para alterar redes + +**Exemplo:** Um contêiner sutil mostra ao usuário quais tokens relevantes ele tem em sua carteira, e a CTA principal fornece um atalho para alterar a rede. + +![A CTA principal está solicitando que o usuário troque de rede](./Image7.png) diff --git a/public/content/translations/pt-br/developers/docs/design-and-ux/index.md b/public/content/translations/pt-br/developers/docs/design-and-ux/index.md new file mode 100644 index 00000000000..68989ae4dc7 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/design-and-ux/index.md @@ -0,0 +1,86 @@ +--- +title: Design e UX em web3 +description: "Introdução ao design UX e pesquisa no espaço web3 e Ethereum" +lang: pt-br +--- + +Você é novo em design com Ethereum? Este é o lugar certo para você. A comunidade Ethereum tem escrito recursos para apresentá-lo aos conceitos básicos de design web3 e pesquisa. Você irá aprender sobre os principais conceitos que podem diferir de outros designs de aplicativos com os quais você está familiarizado. + +Precisa de uma compreensão mais básica da web3 primeiro? Confira o [**Hub de Aprendizagem**](/learn/). + +## Comece com a pesquisa de usuário {#start-with-user-research} + +O design eficaz vai além de criar interfaces de usuário visualmente atraentes. Ele envolve adquirir uma compreensão profunda das necessidades, objetivos e fatores determinantes do usuário. Portanto, recomendamos fortemente que todos os designers adotem um processo de design, como o [**processo do diamante duplo**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)), para garantir que seu trabalho seja deliberado e intencional. + +- [A Web3 precisa de mais pesquisadores e designers de UX](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Uma visão geral da maturidade atual do design +- [Um guia simples para pesquisa de UX na web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Guia simples de como fazer pesquisa +- [Como abordar as decisões de UX na Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Uma breve visão geral da pesquisa quantitativa e qualitativa e as diferenças entre as duas (vídeo, 6 min) +- [Ser um pesquisador de UX na web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Uma visão pessoal sobre como é ser um pesquisador de UX na web3 + +## Estudos de pesquisa na web3 {#research-in-web3} + +Esta é uma lista selecionada de pesquisa de usuários feita na web3, que podem ajudar nas decisões de design e produto ou servir de inspiração para realizar um estudo próprio. + +| Área de foco | Nome | +| :--------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Integração em cripto | [The Reown Pulse 2024: sentimento e uso do consumidor de cripto](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | +| Integração em cripto | [CRADL: UX em Criptomoedas](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| Integração em cripto | [CRADL: Integração em Criptomoedas](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| Integração em cripto | [Relatório de UX do Bitcoin](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| Integração em cripto | [ConSensys: O estado da percepção da Web3 ao redor do mundo 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| Integração em cripto | [NEAR: acelerando a jornada rumo à adoção](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| Staking | [OpenUX: UX do Operador de Nó da Rocket Pool](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| Staking | [Staking: principais tendências, conclusões e previsões - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| Staking | [Staking em múltiplos aplicativos](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [Atualização da pesquisa DAO de 2022: Do que os construtores de DAO precisam?](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [Pools de cobertura](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [ConSensys: Relatório de pesquisa de usuário DeFi 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| Metaverso | [Metaverso: relatório de pesquisa do usuário](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| Metaverso | [Fazendo um safári: pesquisando usuários no Metaverso](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (vídeo, 27 min) | + +## Design para a web3 {#design-for-web3} + +- [Manual de design de UX da Web3](https://web3ux.design/) - Guia prático para projetar aplicativos da Web3 +- [Princípios de design da Web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Uma estrutura de regras de UX para dapps baseados em cadeia de blocos +- [Princípios de design da cadeia de blocos](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Lições aprendidas pela equipe de design da cadeia de blocos da IBM +- [Neueux.com](https://neueux.com/apps) - Biblioteca de UI de fluxos de usuário com diversas opções de filtragem +- [Crise de usabilidade da Web3: o que você PRECISA saber!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Um painel de discussão sobre as armadilhas da criação de projetos com foco no desenvolvedor (vídeo, 34 min) + +## Primeiros passos {#getting-started} + +- [Heurísticas para a Web3](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 heurísticas para o design de interface da Web3 +- [Melhores práticas de design para DEX](/developers/docs/design-and-ux/dex-design-best-practice/) - Um guia para projetar Corretoras Descentralizadas + +## Estudos de caso de design da Web3 {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) +- [Vendendo um NFT na OpenSea](https://builtformars.com/case-studies/opensea) +- [Análise detalhada de UX da carteira: como as carteiras precisam mudar](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (vídeo, 20 min) + +## Recompensas de design {#bounties} + +- [Dework](https://app.dework.xyz/bounties) +- [Buildbox hackathons](https://app.buidlbox.io/) +- [ETHGlobal hackathons](https://ethglobal.com/) + +## DAOs e comunidades de design {#design-daos-and-communities} + +Se envolva em organizações profissionais dirigidas à comunidade ou junte-se a grupos de desenho para discutir com outros membros tópicos relacionados a desenho e pesquisa, e tendências. + +- [Vectordao.com](https://vectordao.com/) +- [Deepwork.studio](https://www.deepwork.studio/) +- [We3.co](https://we3.co/) +- [Openux.xyz](https://openux.xyz/) + +## Sistemas de design e outros recursos de design {#design-systems-and-resources} + +- [Optimism Design](https://www.figma.com/@optimism) (Figma) +- [Sistema de design do Ethereum.org](https://www.figma.com/@ethdotorg) (Figma) +- [Finity, um sistema de design da Polygon](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) +- [Sistema de design da Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) +- [Sistema de design da Safe](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) +- [Sistema de design do ENS](https://thorin.ens.domains/) +- [Sistema de design do Mirror](https://degen-xyz.vercel.app/) + +**Os artigos e projetos listados nesta página não são endossos oficiais e são fornecidos apenas para fins informativos.** +Adicionamos links a esta página com base nos critérios de nossa [política de listagem](/contributing/design/adding-design-resources). Se você quiser que adicionemos um projeto/artigo, edite esta página no [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). diff --git a/public/content/translations/pt-br/developers/docs/development-networks/index.md b/public/content/translations/pt-br/developers/docs/development-networks/index.md index cf9d77c18f8..00d8d4b49c5 100644 --- a/public/content/translations/pt-br/developers/docs/development-networks/index.md +++ b/public/content/translations/pt-br/developers/docs/development-networks/index.md @@ -1,6 +1,6 @@ --- title: Redes de desenvolvimento -description: Uma visão geral das redes de desenvolvimento e ferramentas disponíveis para ajudar a construir aplicativos Ethereum. +description: "Uma visão geral das redes de desenvolvimento e ferramentas disponíveis para ajudar a construir aplicativos Ethereum." lang: pt-br --- @@ -10,7 +10,7 @@ Assim como é possível executar um servidor local do seu computador para desenv ## 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. +Você deve entender os [conceitos básicos da pilha de Ethereum](/developers/docs/ethereum-stack/) e das [redes Ethereum](/developers/docs/networks/) antes de mergulhar nas redes de desenvolvimento. ## O que é uma rede de desenvolvimento? {#what-is-a-development-network} @@ -18,15 +18,15 @@ Redes de desenvolvimento são essencialmente clientes Ethereum (implementações **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: +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 repletas de recursos convenientes, como: -- Semeando deterministicamente sua blockchain local com dados (por exemplo, contas com saldo ETH) +- Semeando deterministicamente sua cadeia de blocos local com dados (por exemplo, contas com saldos de 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/). +**Observação**: a maioria dos [frameworks de desenvolvimento](/developers/docs/frameworks/) inclui uma rede de desenvolvimento integrada. Recomendamos começar com um framework para [configurar seu ambiente de desenvolvimento local](/developers/local-environment/). ### Rede Hardhat {#hardhat-network} @@ -34,23 +34,21 @@ Uma rede local Ethereum concebida para desenvolvedores. Isso permite que você i A rede Hardhat vem integrada com Hardhat, um ambiente de desenvolvimento para profissionais. -- [Website](https://hardhat.org/) -- [GitHub](https://github.com/nomiclabs/hardhat) +- [Site](https://hardhat.org/) +- [GitHub](https://github.com/NomicFoundation/hardhat) -### Beacon Chains Locais {#local-beacon-chains} +### 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/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) -- [Testnet local usando Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) +- [Rede de teste local usando Lodestar](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) +- [Rede de teste local usando Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) -### Cadeias de teste públicas do Ethereum {#public-beacon-testchains} +### Redes de teste públicas da Ethereum {#public-beacon-testchains} -Existem também duas implementações públicas de testes da Ethereum: Sepolia e Hoodi. Sepolia é a rede de testes padrão recomendada para o desenvolvimento de aplicativos, com um conjunto fechado de validadores para sincronização rápida. Hoodi é uma rede de testes para validação e staking, que usa um conjunto aberto de validadores e permite potencialmente que qualquer pessoa valide. +Há também duas implementações de testes públicos mantidas do Ethereum: Sepolia e Hoodi. A rede de testes recomendada com suporte de longo prazo é a Hoodi, que qualquer pessoa pode validar livremente. Sepolia usa um conjunto de validadores com permissão, o que significa que não há acesso geral a novos validadores nesta rede de teste. -- [Plataforma de lançamento de staking Hoodi](https://hoodi.launchpad.ethereum.org/en/) -- [Website Sepolia](https://sepolia.dev/) -- [Website Hoodi](https://hoodi.ethpandaops.io/) +- [Plataforma de lançamento de participação da Hoodi](https://hoodi.launchpad.ethereum.org/) ### Pacote Kurtosis do Ethereum {#kurtosis} @@ -59,15 +57,15 @@ Kurtosis é um sistema de construção para ambientes de teste em vários contê 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 do Ethereum. - [Pacote de rede Ethereum](https://github.com/kurtosis-tech/ethereum-package) -- [Website](https://www.kurtosis.com/) +- [Site](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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} -- [Estruturas de desenvolvimento](/developers/docs/frameworks/) -- [Configure um ambiente de desenvolvimento](/developers/local-environment/) +- [Frameworks de desenvolvimento](/developers/docs/frameworks/) +- [Configure um ambiente de desenvolvimento local](/developers/local-environment/) diff --git a/public/content/translations/pt-br/developers/docs/ethereum-stack/index.md b/public/content/translations/pt-br/developers/docs/ethereum-stack/index.md index 6d06607dc29..89965186446 100644 --- a/public/content/translations/pt-br/developers/docs/ethereum-stack/index.md +++ b/public/content/translations/pt-br/developers/docs/ethereum-stack/index.md @@ -1,5 +1,5 @@ --- -title: Introdução à pilha de Ethereum +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 --- @@ -10,41 +10,41 @@ Entretanto, existem tecnologias centrais da Ethereum que ajudam a fornecer um mo ## 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. +A [Máquina Virtual Ethereum (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. +Por trás das cortinas, a EVM utiliza um conjunto de instruções opcode para executar tarefas específicas. Esses opcodes (140 únicos) 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} +## Nível 2: Contratos inteligentes {#smart-contracts} -[Contratos inteligentes](/developers/docs/smart-contracts/) são os programas executáveis que funcionam na blockchain Ethereum. +[Contratos inteligentes](/developers/docs/smart-contracts/) são os programas executados 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). +Os contratos inteligentes são escritos usando [linguagens de programação](/developers/docs/smart-contracts/languages/) específicas que compilam para bytecode da EVM (instruções de máquina de baixo nível chamadas de 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. +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 usuários e aplicativos ([dapps](/developers/docs/dapps/)) podem interagir, sem precisar de permissão. Qualquer aplicativo pode se integrar com contratos inteligentes implantados para compor funcionalidades, como adicionar [feeds de dados](/developers/docs/oracles/) ou para suportar trocas de tokens. 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} +## Nível 3: Nós da 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. +Para que um aplicativo interaja 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. +Os nós Ethereum são computadores executando um software - um cliente Ethereum. Um cliente é uma implementação do 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). +Ao conectar seu aplicativo a um nó Ethereum (via [API JSON-RPC](/developers/docs/apis/json-rpc/)), seu aplicativo pode ler dados da blockchain (como saldos de contas de usuário), bem como transmitir novas transações para a rede (como transferir ETH entre contas de usuário ou executar funções de contratos inteligentes). -## Nível 4: API de Cliente Ethereum {#ethereum-client-apis} +## Nível 4: APIs 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/). +Se o seu aplicativo voltado para o usuário for um aplicativo da web, você pode optar por fazer o `npm install` de uma [API JavaScript](/developers/docs/apis/javascript/) diretamente em seu frontend. Ou talvez você opte por implementar essa funcionalidade no lado do servidor, usando uma API em [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. +Embora essas APIs não sejam uma parte necessária da pilha, elas abstraem muito da complexidade de interagir diretamente com um nó Ethereum. Elas também fornecem funções utilitárias (p. ex., converter ETH para Gwei) para que, como desenvolvedor, você possa passar menos tempo lidando com as complexidades dos clientes Ethereum e mais tempo focado na funcionalidade específica de seu aplicativo. -## Nível 5: Aplicativos para o usuário final {#end-user-applications} +## Nível 5: Aplicativos de 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. @@ -56,6 +56,6 @@ Confira o nosso guia para [configurar um ambiente de desenvolvimento local](/dev ## 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_ +- [A Arquitetura de um aplicativo 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/evm/index.md b/public/content/translations/pt-br/developers/docs/evm/index.md index c2a58be1975..78ea61961ee 100644 --- a/public/content/translations/pt-br/developers/docs/evm/index.md +++ b/public/content/translations/pt-br/developers/docs/evm/index.md @@ -1,62 +1,72 @@ --- -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. +title: "Máquina virtual 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. +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 "[gás](/developers/docs/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). +É necessária uma familiaridade básica com a terminologia comum da 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\)) para entender a EVM. Também seria útil estar familiarizado com conceitos de criptografia/blockchain, como [funções de hash](https://wikipedia.org/wiki/Cryptographic_hash_function) e a [árvore de Merkle](https://wikipedia.org/wiki/Merkle_tree). -## Do livro-razão para a máquina de estado {#from-ledger-to-state-machine} +## Do livro-razão à 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. +Embora o Ethereum tenha sua própria criptomoeda nativa (ether) que segue quase exatamente as mesmas regras intuitivas, ele também permite uma função muito mais poderosa: [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, o Ethereum é uma [máquina de estado](https://wikipedia.org/wiki/Finite-state_machine) distribuída. 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 e que pode executar um código de máquina arbitrário. As regras específicas para mudar o estado de bloco em bloco são definidas pela EVM. -![Um diagrama mostrando a criação da EVM](./evm.png) _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Um diagrama que mostra a composição da EVM](./evm.png) +_Diagrama adaptado de [Ethereum EVM illustrated](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 função de transição de estado do 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**: +A EVM se comporta como uma função matemática seria: de acordo com a entrada, ele produz uma saída determinística. Portanto, é muito ú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'` +Dado um estado válido antigo `(S)` e um novo conjunto de transações válidas `(T)`, a função de transição de estado do 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. +No contexto do Ethereum, o estado é uma enorme estrutura de dados chamada de [á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. +A criação de contrato resulta na criação de uma nova conta de contrato contendo 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). +A EVM é executada como uma [máquina de pilha](https://wikipedia.org/wiki/Stack_machine) com uma profundidade de 1024 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. +Durante a execução, a EVM mantém uma _memória_ transiente (como um array de bytes endereçado por palavra), que não persiste entre 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. +### Armazenamento transitório -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. +O armazenamento transitório é um repositório de chave-valor por transação, acessado através dos opcodes `TSTORE` e `TLOAD`. Ele persiste em todas as chamadas internas durante a mesma transação, mas é apagado no final da transação. Diferentemente da memória, o armazenamento transitório é modelado como parte do estado da EVM, e não do quadro de execução, e ainda assim não é confirmado no estado global. O armazenamento transitório permite o compartilhamento temporário de estado com uso eficiente de gás entre as chamadas internas durante uma transação. -![Diagrama mostrando onde o consumo de gás é utilizado para as operações da EVM](../gas/gas.png) _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +### Armazenamento + +Os contratos contêm uma trie de _armazenamento_ Merkle Patricia (como um array de palavras endereçável por palavra), associada à conta em questão e parte do estado global. Este armazenamento persistente difere do armazenamento transitório, que está disponível apenas durante uma única transação e não faz parte da trie de armazenamento persistente da conta. + +### OpCodes + +O bytecode de contrato inteligente compilado é executado como uma série de [opcodes](/developers/docs/evm/opcodes) da EVM, que realizam operações de pilha padrão como `XOR`, `AND`, `ADD`, `SUB`, etc. A EVM também implementa várias operações de pilha específicas da blockchain, como `ADDRESS`, `BALANCE`, `BLOCKHASH`, etc. O conjunto de opcodes também inclui `TSTORE` e `TLOAD`, que fornecem acesso ao armazenamento transitório. + +![Um diagrama mostrando onde o gás é necessário para as operações da EVM](../gas/gas.png) +_Diagramas adaptados de [Ethereum EVM illustrated](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. +Ao longo dos dez anos de história do Ethereum, a EVM passou por diversas revisões, e existem várias implementações da EVM em diversas 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: +Os [clientes de execução do Ethereum](/developers/docs/nodes-and-clients/#execution-clients) incluem uma implementação da 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++_ @@ -65,13 +75,13 @@ Os [clientes de execução Ethereum](/developers/docs/nodes-and-clients/#executi ## 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/openedition/13evm.asciidoc) +- [Yellowpaper do Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Jellopaper, também conhecido como KEVM: Semântica da EVM em K](https://jellopaper.org/) +- [The Beigepaper](https://github.com/chronaeon/beigepaper) +- [Opcodes da Máquina Virtual do Ethereum](https://www.ethervm.io/) +- [Referência interativa dos opcodes da Máquina Virtual Ethereum](https://www.evm.codes/) +- [Uma breve introdução na documentação do Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) +- [Mastering Ethereum – A Máquina Virtual do Ethereum](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) ## Tópicos relacionados {#related-topics} diff --git a/public/content/translations/pt-br/developers/docs/evm/opcodes/index.md b/public/content/translations/pt-br/developers/docs/evm/opcodes/index.md index 9f31f9c451c..a98c0050a02 100644 --- a/public/content/translations/pt-br/developers/docs/evm/opcodes/index.md +++ b/public/content/translations/pt-br/developers/docs/evm/opcodes/index.md @@ -1,174 +1,177 @@ --- title: Opcodes para o EVM -description: Uma lista de todos os opcodes disponíveis para a máquina virtual do Ethereum. +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. +Esta é uma versão atualizada da página de referência da EVM em [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). +Também extraído do [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), do [Jello Paper](https://jellopaper.org/evm/) e da implementação do [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). +Para operações com custos de gás dinâmicos, 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. +💡 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 | +| Pilha | Nome | Gás | Pilha inicial | Pilha resultante | Memória / Armazenamento | Observações | | +| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | +| 00 | STOP | 0 | | | | interromper execução | | +| 01 | ADD | 3 | `a, b` | `a + b` | | adição de (u)int256 módulo 2\*\*256 | | +| 02 | MUL | 5 | `a, b` | `a * b` | | multiplicação de (u)int256 módulo 2\*\*256 | | +| 03 | SUB | 3 | `a, b` | `a - b` | | subtração de (u)int256 módulo 2\*\*256 | | +| 04 | DIV | 5 | `a, b` | `a // b` | | divisão de uint256 | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | divisão de int256 | | +| 06 | MOD | 5 | `a, b` | `a % b` | | módulo uint256 | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | módulo int256 | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | adição de (u)int256 módulo N | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | multiplicação de (u)int256 módulo N | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | exponenciação de uint256 módulo 2\*\*256 | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [estender sinal](https://wikipedia.org/wiki/Sign_extension) de `x` de `(b+1)` bytes para 32 bytes | | +| 0C-0F | _inválido_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 menor que | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 maior que | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 menor que | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 maior que | | +| 14 | EQ | 3 | `a, b` | `a == b` | | igualdade de (u)int256 | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 é zero | | +| 16 | AND | 3 | `a, b` | `a && b` | | AND bit a bit | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | OR bit a bit | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | XOR bit a bit | | +| 19 | NOT | 3 | `a` | `~a` | | NOT bit a bit | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`-ésimo byte de (u)int256 `x`, da esquerda | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | deslocamento à esquerda | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | deslocamento lógico à direita | | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | deslocamento aritmético à direita | | +| 1E-1F | _inválido_ | | | | | | | +| 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 | _inválido_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | endereço do contrato em execução | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | saldo, em wei | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | endereço que originou a tx | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | endereço do remetente da msg | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | valor da msg, em wei | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | lê a palavra dos dados da msg no índice `idx` | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | comprimento dos dados da msg, em 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] | copiar dados da msg | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | comprimento do código do contrato em execução, em 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] | copia o bytecode do contrato em execução | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | preço do gás da transação, em wei por unidade de gás [\*\*](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)` | | tamanho do código no endereço (addr), em 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] | copia o código de `addr` | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | tamanho dos dados retornados da última chamada externa, em 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] | copia os dados retornados da última chamada externa | | +| 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` | | carimbo de data/hora do bloco atual | | +| 43 | NUMBER | 2 | `.` | `block.number` | | número do bloco atual | | +| 44 | PREVRANDAO | 2 | `.` | `sinalizador de aleatoriedade` | | sinalizador de aleatoriedade | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | limite de gás do bloco atual | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | envia o [ID da cadeia](https://eips.ethereum.org/EIPS/eip-155) atual para a pilha | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | saldo do contrato em execução, em wei | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | taxa base do bloco atual | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | taxa base do blob do bloco atual ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _inválido_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | remove o item do topo da pilha e o descarta | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | lê uma palavra da memória no deslocamento `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 | escreve uma palavra na memória | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | escreve um único byte na memória | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | lê a palavra do armazenamento | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | escreve uma palavra no armazenamento | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` marca que `pc` só é atribuído se `dst` for um jumpdest válido | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | contador de programa | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | tamanho da memória no contexto de execução atual, em bytes | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | marca um destino de salto válido | um destino de salto válido, por exemplo, um destino de salto que não esteja dentro dos dados push | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | lê palavra do armazenamento transiente ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | escreve palavra no armazenamento transiente ([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] | copia memória de uma área para outra ([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` | | envia um valor de 1 byte para a pilha | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | envia um valor de 2 bytes para a pilha | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | envia um valor de 3 bytes para a pilha | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | envia um valor de 4 bytes para a pilha | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | envia um valor de 5 bytes para a pilha | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | envia um valor de 6 bytes para a pilha | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | envia um valor de 7 bytes para a pilha | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | envia um valor de 8 bytes para a pilha | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | envia um valor de 9 bytes para a pilha | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | envia um valor de 10 bytes para a pilha | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | envia um valor de 11 bytes para a pilha | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | envia um valor de 12 bytes para a pilha | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | envia um valor de 13 bytes para a pilha | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | envia um valor de 14 bytes para a pilha | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | envia um valor de 15 bytes para a pilha | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | envia um valor de 16 bytes para a pilha | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | envia um valor de 17 bytes para a pilha | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | envia um valor de 18 bytes para a pilha | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | envia um valor de 19 bytes para a pilha | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | envia um valor de 20 bytes para a pilha | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | envia um valor de 21 bytes para a pilha | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | envia um valor de 22 bytes para a pilha | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | envia um valor de 23 bytes para a pilha | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | envia um valor de 24 bytes para a pilha | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | envia um valor de 25 bytes para a pilha | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | envia um valor de 26 bytes para a pilha | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | envia um valor de 27 bytes para a pilha | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | envia um valor de 28 bytes para a pilha | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | envia um valor de 29 bytes para a pilha | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | envia um valor de 30 bytes para a pilha | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | envia um valor de 31 bytes para a pilha | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | envia um valor de 32 bytes para a pilha | | +| 80 | DUP1 | 3 | `a` | `a, a` | | clona o 1º valor na pilha | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clona o 2º valor na pilha | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clona o 3º valor na pilha | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clona o 4º valor na pilha | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clona o 5º valor na pilha | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clona o 6º valor na pilha | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clona o 7º valor na pilha | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clona o 8º valor na pilha | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clona o 9º valor na pilha | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clona o 10º valor na pilha | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clona o 11º valor na pilha | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clona o 12º valor na pilha | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clona o 13º valor na pilha | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clona o 14º valor na pilha | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clona o 15º valor na pilha | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clona o 16º valor na pilha | | +| 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 | _inválido_ | | | | | | | +| 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) | gás, addr, val, argOst, argLen, retOst, retLen | `sucesso` | mem[retOst:retOst+retLen-1] := returndata | | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gás, addr, val, argOst, argLen, retOst, retLen` | `sucesso` | mem[retOst:retOst+retLen-1] = returndata | o mesmo que DELEGATECALL, mas não propaga o msg.sender e o msg.value originais | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | retorna mem[ost:ost+len-1] | | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gás, addr, argOst, argLen, retOst, retLen` | `sucesso` | 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 | _inválido_ | | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gás, addr, argOst, argLen, retOst, retLen` | `sucesso` | mem[retOst:retOst+retLen-1] := returndata | | | +| FB-FC | _inválido_ | | | | | | | +| 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) | | | opcode inválido designado - [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` | `.` | | envia todo o ETH para `addr`; se executado na mesma transação em que um contrato foi criado, destrói o contrato | | diff --git a/public/content/translations/pt-br/developers/docs/frameworks/index.md b/public/content/translations/pt-br/developers/docs/frameworks/index.md index 344059241c4..6e40d7e2737 100644 --- a/public/content/translations/pt-br/developers/docs/frameworks/index.md +++ b/public/content/translations/pt-br/developers/docs/frameworks/index.md @@ -1,32 +1,39 @@ --- title: Frameworks de Desenvolvimento de Dapp -description: Explore as vantagens de frameworks e compare as opções disponíveis. +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. +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. +- Recursos para ativar uma instância local de 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. +- Complementos de desenvolvimento de cliente para criar seu aplicativo voltado para o usuário + no mesmo projeto/repositório. +- Configuração para se conectar às redes Ethereum e implantar + contratos, seja em uma instância em execução local ou em uma das + redes públicas da Ethereum. +- Distribuição de aplicativos descentralizados: 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/). +Antes de mergulhar nos frameworks, recomendamos que você leia primeiro nossa introdução aos [dapps](/developers/docs/dapps/) e à [pilha 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 aplicativos Ethereum_** +**Foundry** - **_O Foundry é um kit de ferramentas incrivelmente rápido, portátil e modular para o desenvolvimento de aplicativos Ethereum_** -- [Instalar Foundry](https://book.getfoundry.sh/) -- [Livro sobre Foundry](https://book.getfoundry.sh/) -- [Bate-papo da comunidade Foundry no Telegram](https://t.me/foundry_support) +- [Instalar o Foundry](https://book.getfoundry.sh/) +- [Livro do Foundry](https://book.getfoundry.sh/) +- [Chat da comunidade Foundry no Telegram](https://t.me/foundry_support) - [Awesome Foundry](https://github.com/crisgarner/awesome-foundry) **Hardhat -** **_Ambiente de desenvolvimento da Ethereum para profissionais._** @@ -34,12 +41,12 @@ Antes de mergulhar em frameworks, recomendamos que você primeiro leia a nossa i - [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._** +**Ape -** **_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._** +**Web3j -** **_Uma plataforma para desenvolver aplicativos de blockchain na JVM._** - [Página inicial](https://www.web3labs.com/web3j-sdk) - [Documentação](https://docs.web3j.io) @@ -51,23 +58,23 @@ Antes de mergulhar em frameworks, recomendamos que você primeiro leia a nossa i - [Exemplos](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) - [Discord](https://discord.gg/rx35NzQGSb) -**Criar um app Eth-** **_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._** +**Create Eth App -** **_Crie aplicativos baseados em Ethereum com 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 -** **_componentes e hooks Ethers.js + Hardhat + React para web3: tudo o que você precisa para começar a criar aplicativos descentralizados com tecnologia de contratos inteligentes._** +**Scaffold-Eth -** **_Ethers.js + Hardhat + componentes e hooks React para web3: tudo o que você precisa para começar a construir aplicativos descentralizados com tecnologia de contratos inteligentes._** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -**Tenderly -** **_Plataforma de desenvolvimento web3 que permite aos desenvolvedores de blockchain criar, testar, depurar, monitorar e operar contratos inteligentes e melhorar a UX do dapp._** +**Tenderly -** **_Plataforma de desenvolvimento Web3 que permite aos desenvolvedores de blockchain construir, testar, depurar, monitorar e operar contratos inteligentes e melhorar a UX do dapp._** -- [Website](https://tenderly.co/) +- [Site](https://tenderly.co/) - [Documentação](https://docs.tenderly.co/) -**The Graph -** **_The Graph para consultar dados de blockchain com eficiência._** +**The Graph -** **_O The Graph para consultar dados de blockchain com eficiência._** -- [Website](https://thegraph.com/) +- [Site](https://thegraph.com/) - [Tutorial](/developers/tutorials/the-graph-fixing-web3-data-querying/) **Alchemy -** **_Plataforma de Desenvolvimento Ethereum._** @@ -82,7 +89,7 @@ Antes de mergulhar em frameworks, recomendamos que você primeiro leia a nossa i - [GitHub](https://github.com/node-real) - [Discord](https://discord.gg/V5k5gsuE) -**thirdweb SDK -** **_Crie aplicativos web3 que podem interagir com seus contratos inteligentes usando nossos SDKs e CLI avançados._** +**thirdweb SDK -** **_Crie aplicativos web3 que possam interagir com seus contratos inteligentes usando nossos poderosos SDKs e CLI._** - [Documentação](https://portal.thirdweb.com/sdk/) - [GitHub](https://github.com/thirdweb-dev/) @@ -93,44 +100,46 @@ Antes de mergulhar em frameworks, recomendamos que você primeiro leia a nossa i - [GitHub](https://github.com/chainstack) - [Discord](https://discord.gg/BSb5zfp9AT) -**Crossmint-****_A plataforma web3 de desenvolvimento a nível empresarial que permite a criação de NFTs nas principais cadeias EVM (entre outras)._** +**Crossmint -** **_Plataforma de desenvolvimento web3 de nível empresarial, que permite criar aplicativos NFT em todas as principais cadeias EVM (e outras)._** -- [Website](https://www.crossmint.com) +- [Site](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._** +**Brownie -** **_Ambiente de desenvolvimento e framework de testes baseado em Python._** - [Documentação](https://eth-brownie.readthedocs.io/en/latest/) - [GitHub](https://github.com/eth-brownie/brownie) - **Brownie deixou de ser desenvolvido** -**OpenZeppelin SDK -** **_The Ultimate Smart Contract Toolkit: um conjunto de ferramentas para ajudar você a desenvolver, compilar, atualizar, implantar e interagir com contratos inteligentes._** +**OpenZeppelin SDK -** **_O kit de ferramentas definitivo para contratos inteligentes: um conjunto de ferramentas para ajudar você a desenvolver, compilar, atualizar, implantar e interagir com contratos inteligentes._** -- [SDK da OpenZeppelin](https://openzeppelin.com/sdk/) +- [SDK do OpenZeppelin Defender](https://docs.openzeppelin.com/defender/sdk) - [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) -- [Fórum da Comunidade](https://forum.openzeppelin.com/c/support/17) +- [Fórum da comunidade](https://forum.openzeppelin.com/c/support/17) - **O desenvolvimento do SDK da OpenZeppelin foi finalizado** -**Catapulta -** **_Ferramenta de contrato inteligente em várias cadeias que automatiza 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._** +**Catapulta -** **_Ferramenta de implantação de contratos inteligentes multi-chain, automatiza verificações em exploradores de blocos, acompanha contratos inteligentes implantados e compartilha relatórios de implantação, plug-n-play para projetos Foundry e Hardhat._** +- [Site](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._** +**GoldRush (desenvolvido por Covalent) -** **_O GoldRush oferece o mais completo conjunto de APIs de dados de blockchain para desenvolvedores, analistas e empresas._** Esteja você construindo um painel DeFi, uma carteira, um bot de negociação, um agente de IA ou uma plataforma de conformidade, as APIs de dados fornecem acesso rápido, preciso e amigável ao desenvolvedor para os dados essenciais na cadeia de que você precisa_\*\* -- [covalenthq.com](https://www.covalenthq.com/) -- [Documentação](https://www.covalenthq.com/docs/api/) +- [Site](https://goldrush.dev/) +- [Documentação](https://goldrush.dev/docs/chains/ethereum) - [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 no código._** +**Wake -** **_Framework Python completo para teste 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) -- [Extensão VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) +- [Extensão do VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) -**Veramo -** **_Framework de código aberto, modular e agnóstico que facilita para os desenvolvedores de aplicativos descentralizados a integração de identidades descentralizadas e credenciais verificáveis em suas aplicações._** +**Veramo -** **_Framework de código aberto, modular e agnóstico que facilita para desenvolvedores de aplicativos descentralizados criarem identidades descentralizadas e credenciais verificáveis em seus aplicativos._** - [Página inicial](https://veramo.io/) - [Documentação](https://veramo.io/docs/basics/introduction) @@ -140,8 +149,8 @@ Antes de mergulhar em frameworks, recomendamos que você primeiro leia a nossa i ## Leitura adicional {#further-reading} -_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tópicos relacionados {#related-topics} -- [Configure um ambiente de desenvolvimento](/developers/local-environment/) +- [Configure um ambiente de desenvolvimento local](/developers/local-environment/) diff --git a/public/content/translations/pt-br/developers/docs/gas/index.md b/public/content/translations/pt-br/developers/docs/gas/index.md index 19e848e668f..70727aab724 100644 --- a/public/content/translations/pt-br/developers/docs/gas/index.md +++ b/public/content/translations/pt-br/developers/docs/gas/index.md @@ -1,6 +1,7 @@ --- -title: Gás e taxas -description: +title: "Gás e taxas" +metaTitle: "Ethereum despesas: visão geral tecnológica" +description: "Saiba mais sobre a taxa de gás Ethereum, como eles são calculados e seu papel na segurança da rede e processamento de transações." lang: pt-br --- @@ -8,7 +9,7 @@ O gás é essencial para a rede Ethereum. É o combustível que permite que ele ## 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/). +Para entender melhor esta página, recomendamos que você leia primeiro sobre [transações](/developers/docs/transactions/) e a [EVM](/developers/docs/evm/). ## O que é gás? {#what-is-gas} @@ -16,25 +17,26 @@ Gás refere-se à unidade que mede a quantidade de esforço computacional necess 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. +A taxa de gás é **a quantidade de gás usada para fazer alguma operação, multiplicada pelo custo por unidade de gás**. A taxa é paga independentemente da transação ter sucesso ou falhar. -![Diagrama mostrando onde o consumo de gás é utilizado para as operações da EVM](./gas.png) _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Um diagrama mostrando onde o gás é necessário nas operações da EVM](./gas.png) +_Diagrama adaptado de [Ethereum EVM illustrated](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/WeiDai), criador do [B-Money](https://www.investopedia.com/terms/b/bmoney.asp)) é a menor unidade de ETH. +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). +O gás total que você paga é dividido em dois componentes: a `taxa base` e a `taxa de prioridade` (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. +A `taxa base` é definida pelo protocolo — você precisa pagar pelo menos esse valor para que sua transação seja considerada válida. A `taxa de prioridade` é uma gorjeta que você adiciona à `taxa base` 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. +Uma transação que paga apenas a `taxa base` é tecnicamente válida, mas é improvável que seja incluída, pois não oferece incentivo aos validadores para escolhê-la em vez de qualquer outra transação. A taxa de `prioridade` 'correta' é determinada pelo uso da rede no momento do envio da sua transação — se houver muita demanda, talvez você precise definir sua taxa de `prioridade` mais alta, mas quando houver menos demanda, você poderá 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. @@ -42,44 +44,44 @@ 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. +onde a `taxa base` é um valor definido pelo protocolo e a `taxa de prioridade` é um valor definido pelo usuário como uma gorjeta para o validador. -ou seja, `21.000 * (10 + 2) = 252.000 gwei` (0.000252 ETH). +p. ex., `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. +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 é 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. +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"**, sendo removida 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. +A taxa base é calculada por uma fórmula que compara o tamanho do bloco anterior (a quantidade de gás usada para todas as transações) com o tamanho alvo (metade do limite de gás). A taxa base aumentará ou diminuirá em no máximo 12,5% por bloco se o tamanho do bloco alvo estiver acima ou abaixo do alvo, respectivamente. 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`. +| Número do bloco | Gás incluído | Aumento da taxa | Taxa base atual | +| --------------- | -----------: | --------------: | --------------: | +| 1 | 18M | 0% | 100 gwei | +| 2 | 36M | 0% | 100 gwei | +| 3 | 36M | 12,5% | 112,5 gwei | +| 4 | 36M | 12,5% | 126,6 gwei | +| 5 | 36M | 12,5% | 142,4 gwei | +| 6 | 36M | 12,5% | 160,2 gwei | +| 7 | 36M | 12,5% | 180,2 gwei | +| 8 | 36M | 12,5% | 202,7 gwei | + +Na tabela acima, um exemplo é demonstrado usando 36 milhões como o limite de gás. Seguindo este exemplo, para criar uma transação no bloco de número 9, uma carteira informará ao usuário com certeza que a **taxa base máxima** a ser adicionada ao próximo bloco é `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 | +| Número do bloco | Gás incluído | Aumento da taxa | Taxa base atual | +| --------------------------------------------------- | --------------------------------------------------: | --------------: | --------------------------------------------------: | +| 30 | 36M | 12,5% | 2705,6 gwei | +| ... | ... | 12,5% | ... | +| 50 | 36M | 12,5% | 28531,3 gwei | +| ... | ... | 12,5% | ... | +| 100 | 36M | 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. +A taxa de prioridade (gorjeta) incentiva os validadores a maximizar o número de transações em um bloco, limitado apenas pelo limite de gás do bloco. Sem gorjetas, um validador racional poderia incluir menos — ou até mesmo zero — transações sem qualquer penalidade direta da camada de execução ou da camada de consenso, já que as recompensas de staking são independentes de quantas transações estão em um bloco. Além disso, as gorjetas permitem que os usuários superem as ofertas de outros por prioridade dentro do mesmo bloco, sinalizando efetivamente a urgência. ### Taxa máxima {#maxfee} @@ -87,9 +89,13 @@ Para executar uma transação na rede, os usuários podem especificar um limite ### Tamanho do bloco {#block-size} -Cada bloco tem um tamanho alvo de 30 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 60 milhões de gás (2x o tamanho do bloco alvo). O protocolo atinge um tamanho de bloco de equilíbrio de 30 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/). +Cada bloco tem um tamanho alvo de metade do limite de gás atual, mas o tamanho dos blocos aumentará ou diminuirá de acordo com a demanda da rede, até que o limite do bloco seja atingido (2x o tamanho do bloco alvo). O protocolo atinge um tamanho médio de bloco de equilíbrio no alvo através do processo de _tâtonnement_. 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. -### Calculando taxas de gás na prática {#calculating-fees-in-practice} +A quantidade pela qual a taxa base é ajustada é proporcional ao quão longe o tamanho do bloco atual está do alvo. Este é um cálculo linear de -12,5% para um bloco vazio, 0% no tamanho alvo, até +12,5% para um bloco que atinge o limite de gás. O limite de gás pode flutuar ao longo do tempo com base na sinalização do validador, bem como por meio de atualizações de rede. Você pode [ver as alterações no limite de gás ao longo do tempo aqui](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths). + +[Mais sobre blocos](/developers/docs/blocks/) + +### Calculando as 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. @@ -97,42 +103,49 @@ Você pode explicitamente declarar o quanto está disposto a pagar para que sua 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). +Embora uma transação inclua um limite, qualquer gás não utilizado em uma transação é devolvido ao usuário (p. ex., `taxa máxima - (taxa base + gorjeta)` é devolvido). -![Diagrama que mostra como o gás não utilizado é reembolsado](../transactions/gas-tx.png) _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagrama mostrando como o gás não utilizado é reembolsado](../transactions/gas-tx.png) +_Diagrama adaptado de [Ethereum EVM illustrated](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. +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 que envolvem [contratos inteligentes](/developers/docs/smart-contracts/) exigem mais trabalho computacional, 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 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, menor do limite mínimo de gás de 20.000 para uma transferência do ETH, a transação falhará. Será rejeitado antes de ser em bloco. Por outro lado, se uma transação estava sem gás durante a execução (por exemplo, um contrato inteligente usa todo o gás em processo), o EVM cancelará alterações, mas todo o gás ainda será 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} +## Iniciativas para reduzir os custos de gás {#initiatives-to-reduce-gas-costs} + +As [atualizações de escalabilidade](/roadmap/) do Ethereum devem, em última análise, resolver alguns dos problemas da taxa de gás, o que, por sua vez, permitirá que a plataforma processe milhares de transações por segundo e escale globalmente. -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. -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). +[Mais sobre 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._ +- [Etherscan](https://etherscan.io/gastracker) _Estimador de preço do gás da transação_ +- [Blockscout](https://eth.blockscout.com/gas-tracker) _Estimador de preço do gás de transação de código aberto_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _Monitore e acompanhe os preços do gás do Ethereum e da L2 para reduzir as taxas de transação e economizar dinheiro_ +- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Extensão do Chrome para estimativa de gás que suporta tanto transações legadas do Tipo 0 quanto transações do Tipo 2 EIP-1559._ +- [Cryptoneur Gas Fees Calculator](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, 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_ +- [Plataforma de Gás da Blocknative](https://www.blocknative.com/gas) _API de estimativa de gás alimentada pela plataforma global de dados do mempool da Blocknative_ +- [Gas Network](https://gas.network) Oráculos de Gás na Cadeia. Suporte para mais de 35 redes. ## 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) -- [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). +- [O Gás do Ethereum Explicado](https://defiprime.com/gas) +- [Reduzindo o consumo de gás dos seus Contratos Inteligentes](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [Estratégias de Otimização de Gás para Desenvolvedores](https://www.alchemy.com/overviews/solidity-gas-optimization) +- [Documentação do EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). +- [Recursos sobre o EIP-1559 de Tim Beiko](https://hackmd.io/@timbeiko/1559-resources) +- [EIP-1559: Separando Mecanismos de Memes](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) diff --git a/public/content/translations/pt-br/developers/docs/ides/index.md b/public/content/translations/pt-br/developers/docs/ides/index.md index e2ee2caa51f..c79ad51ec72 100644 --- a/public/content/translations/pt-br/developers/docs/ides/index.md +++ b/public/content/translations/pt-br/developers/docs/ides/index.md @@ -1,43 +1,43 @@ --- title: Ambientes de Desenvolvimento Integrado (IDEs) -description: +description: "Aprenda sobre IDEs baseados na rede e desktop para desenvolvimento do Ethereum, incluindo Remix, código VS e plugins populares." 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. +Quando se trata de configurar um [ambiente de desenvolvimento integrado (IDE)](https://wikipedia.org/wiki/Integrated_development_environment), programar aplicações na Ethereum é semelhante 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. +Se você deseja mexer no código antes de [configurar um ambiente de desenvolvimento local](/developers/local-environment/), estes aplicativos da web são feitos sob medida para o desenvolvimento de contratos inteligentes da 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_** +**[Remix](https://remix.ethereum.org/)** - **_IDE baseado 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_** +**[ChainIDE](https://chainide.com/)** - **_Uma IDE multichain baseada em 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_** +**[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 de primeira classe à rede de teste_** - [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_** +**[EthFiddle](https://ethfiddle.com/)** - **_IDE baseado na Web que permite escrever, compilar e depurar seu contrato inteligente_** - [Gitter](https://gitter.im/loomnetwork/ethfiddle) -## Aplicativos IDEs {#desktop-ides} +## IDEs de desktop {#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/). +A maioria dos IDEs estabelecidos possuem plugins integrados para melhorar a experiência de desenvolvimento em Ethereum. No mínimo, eles fornecem realce de sintaxe para [linguagens de contratos inteligentes](/developers/docs/smart-contracts/languages/). -**Visual Studio Code -** **_IDE profissional multiplataforma com suporte oficial da Ethereum._** +**Visual Studio Code -** **_IDE profissional multiplataforma com suporte oficial da Ethereum_** - [Visual Studio Code](https://code.visualstudio.com/) -- [Amostras de código](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) +- [Exemplos 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) **IDEs de JetBrains (IntelliJ IDEA etc.) -** **_Ferramentas essenciais para desenvolvedores de software e equipes_** @@ -46,19 +46,19 @@ A maioria dos IDEs estabelecidos possuem plugins integrados para melhorar a expe - [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_** +**Remix Desktop -** **_Experimente o Remix IDE em 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 +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Linguagem Solidity do Ethereum para Visual Studio Code +- [Solidity + Hardhat para VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Suporte para Solidity e Hardhat pela equipe do Hardhat +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Formatador de código usando o 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_ +- [IDEs da Ethereum](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- Lista da Alchemy de IDEs da Ethereum_ -_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/index.md b/public/content/translations/pt-br/developers/docs/index.md index f2a2066354c..438e104595c 100644 --- a/public/content/translations/pt-br/developers/docs/index.md +++ b/public/content/translations/pt-br/developers/docs/index.md @@ -1,12 +1,12 @@ --- -title: Documentação sobre o desenvolvimento do Ethereum -description: Introduzindo a documentação sobre o desenvolvimento da rede Ethereum. +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). +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 pode ser editada via GitHub – se você não tiver certeza de como fazer, [siga estas instruções](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). ## Módulos de desenvolvimento {#development-modules} diff --git a/public/content/translations/pt-br/developers/docs/intro-to-ether/index.md b/public/content/translations/pt-br/developers/docs/intro-to-ether/index.md index 3b5239ff2c0..55451923c8a 100644 --- a/public/content/translations/pt-br/developers/docs/intro-to-ether/index.md +++ b/public/content/translations/pt-br/developers/docs/intro-to-ether/index.md @@ -1,6 +1,6 @@ --- -title: Introdução ao Ether -description: Introdução de um desenvolvedor à criptomoeda ETHER. +title: "Introdução técnica ao ether" +description: "Introdução de um desenvolvedor à criptomoeda ETHER." lang: pt-br --- @@ -18,35 +18,35 @@ A primeira criptomoeda foi o Bitcoin, criado por Satoshi Nakamoto. Desde o lanç ## 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. +**Ether (ETH)** é a criptomoeda usada para muitas coisas na rede Ethereum. Fundamentalmente, é a única forma de pagamento aceitável para taxas de transação e, após [A Fusão](/roadmap/merge), o ether é necessário para validar e propor blocos na Mainnet. O Ether também é usado como forma principal de garantia nos mercados de empréstimo de [DeFi](/defi), como uma unidade de conta nos mercados de NFT, como pagamento recebido por prestação de serviços ou venda de bens do mundo real, e muito mais. -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. +O Ethereum permite que os desenvolvedores criem [**aplicativos descentralizados (dapps)**](/developers/docs/dapps), que compartilham um pool de poder computacional. 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. +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. Esses 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 computacional necessário para executar a transação e da demanda de toda a rede por poder computacional 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 confundir](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) Ethereum e ether — quando as pessoas se referem ao "preço do Ethereum", estão descrevendo o preço do ether. +É [comum confundir](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) Ethereum e ether — quando as pessoas se referem ao "preço do Ethereum", elas estão descrevendo o preço do ether. -## Como cunhar ether {#minting-ether} +## Mintagem de 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} +## Queima de 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. +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://eth.blockscout.com/block/22580057) podem queimar mais ether do que cunham, 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. +A queima da taxa base dificulta a capacidade de um produtor de bloco 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 básica para alguns usuários off-chain, levando a 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. +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), basearão todos os cálculos em Wei. Gwei, abreviado de giga-wei, é frequentemente usado para descrever os custos de gás no Ethereum. @@ -55,24 +55,24 @@ Gwei, abreviado de giga-wei, é frequentemente usado para descrever os custos de | Wei | 10-18 | Implementações técnicas | | Gwei | 10-9 | Taxas de gás legíveis por humanos | -## Como transferir ether {#transferring-ether} +## Transferência de 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. +Cada transação no Ethereum contém um campo `value`, que especifica a quantidade de ether a ser transferida, denominada em wei, para ser enviada 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. +Quando o endereço do destinatário é um [contrato inteligente](/developers/docs/smart-contracts/), esse ether transferido pode ser usado para pagar pelo gás quando o contrato inteligente executa seu código. [Mais sobre transações](/developers/docs/transactions/) -## Como consultar saldos de ether {#querying-ether} +## Consulta 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. +Os usuários podem consultar o saldo de ether de qualquer [conta](/developers/docs/accounts/) inspecionando o campo `balance` da conta, que mostra as posses 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. +[Etherscan](https://etherscan.io) e [Blockscout](https://eth.blockscout.com) são ferramentas populares para inspecionar saldos de endereços por meio de aplicativos baseados na web. Por exemplo, [esta página do Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) mostra o saldo da Ethereum Foundation. 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. +- [Definindo ether e Ethereum](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [Whitepaper do Ethereum](/whitepaper/): A proposta original para o Ethereum. Este documento inclui uma descrição do ether e os motivos subjacentes à sua criação. +- [Calculadora de Gwei](https://www.alchemy.com/gwei-calculator): Use esta calculadora de 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/intro-to-ethereum/index.md b/public/content/translations/pt-br/developers/docs/intro-to-ethereum/index.md index e614c273198..ebd0f797c09 100644 --- a/public/content/translations/pt-br/developers/docs/intro-to-ethereum/index.md +++ b/public/content/translations/pt-br/developers/docs/intro-to-ethereum/index.md @@ -1,10 +1,10 @@ --- -title: Introdução à Ethereum -description: Uma introdução do desenvolvedor de dapps aos conceitos principais do Ethereum. +title: "Introdução técnica ao 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} +## O que é uma cadeia de blocos? {#what-is-a-blockchain} Uma blockchain é melhor descrita como um banco de dados público atualizado e compartilhado entre muitos computadores em uma rede. @@ -14,15 +14,15 @@ Uma blockchain é melhor descrita como um banco de dados público atualizado e c 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. +O Ethereum usa 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. +Se você quiser ver como os dados da cadeia de blocos recebem hash e são subsequentemente anexados ao histórico de referências de bloco, não deixe de conferir [esta demonstração](https://andersbrownworth.com/blockchain/blockchain) de Anders Brownworth e assistir ao vídeo que a acompanha abaixo. Assista a Anders explicando hashes em cadeias de blocos: -## O que é o Ethereum? {#what-is-ethereum} +## O que é a 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. @@ -34,19 +34,19 @@ Os mecanismos criptográficos garantem que, uma vez que as transações são ver ## 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. +**O 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 ETH também é usado para fornecer segurança criptoeconômica à rede de três maneiras principais: 1) é usado como um meio de recompensar os validadores que propõem blocos ou denunciam o comportamento desonesto de outros validadores; 2) é colocado em stake 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 os 'votos' para blocos recém-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. +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. Chamamos os programas carregados e executados pela rede de "contratos inteligentes". -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. +Em termos gerais, 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. @@ -54,13 +54,13 @@ Assim, com contratos inteligentes, os desenvolvedores podem criar e implantar ar ## Terminologia {#terminology} -### Blockchain {#blockchain} +### Cadeia de blocos {#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. +**O 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/) @@ -98,19 +98,27 @@ O volume de transações é muito alto, portanto, as transações são "autoriza [Mais sobre blocos](/developers/docs/blocks/) -### Smart Contracts {#smart-contracts} +### Contratos inteligentes {#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/). +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 os desenvolvedores podem escrever aplicativos executáveis arbitrários na EVM (jogos, marketplaces, instrumentos financeiros, etc.) ao publicar contratos inteligentes, estes também são frequentemente chamados de [dapps, ou Aplicativos 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)) +- [Afinal, como o Ethereum funciona?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**Observação**: este recurso ainda é valioso, mas esteja ciente de que é anterior a [The Merge](/roadmap/merge) e, portanto, ainda se refere ao mecanismo de prova de trabalho do Ethereum; na verdade, o Ethereum agora é protegido usando [prova de participação](/developers/docs/consensus-mechanisms/pos)) -_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione-o!_ +### Você é o tipo de pessoa que aprende mais com recursos visuais? {#visual-learner} + +Essa série de vídeo oferece uma exploração completa de tópicos fundamentais: + + + +[Playlist de Fundamentos do Ethereum](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) + +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## 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_ +- [Guia do desenvolvedor para o Ethereum, parte 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Uma exploração do Ethereum muito amigável para iniciantes, usando Python e web3.py_ diff --git a/public/content/translations/pt-br/developers/docs/mev/index.md b/public/content/translations/pt-br/developers/docs/mev/index.md index 2ea3af8b45f..2601987a1ef 100644 --- a/public/content/translations/pt-br/developers/docs/mev/index.md +++ b/public/content/translations/pt-br/developers/docs/mev/index.md @@ -1,32 +1,32 @@ --- -title: Valor máximo extraível (MEV) -description: Uma introdução ao valor máximo extraível (MEV) +title: "Valor máximo extraível (MEV)" +description: "Uma introdução ao valor máximo extraível (MEV)" lang: pt-br --- Valor Máximo Extraível (MEV, na sigla em inglês) expressa o valor máximo que pode ser extraído da produção de blocos que excede a recompensa padrão do bloco e sua taxa de gás através da inclusão, exclusão e alteração da ordem de transações em um determinado bloco. -## Valor máximo extraível {#miner-extractable-value} +## Valor máximo extraível {#maximal-extractable-value} -O valor máximo extraível foi aplicado pela primeira vez no contexto de [prova de trabalho](/developers/docs/consensus-mechanisms/pow/) e inicialmente referido como "valor extraível do minerador". Isto porque na prova de trabalho, os mineradores controlam a inclusão, exclusão e ordenação das transações. No entanto, desde a transição para a prova de participação por meio do [The Merge (A Fusão)](/roadmap/merge), os validadores têm sido responsáveis por essas funções, e a mineração não faz mais parte do protocolo Ethereum. Como os métodos de extração de valor ainda existem, o termo "valor máximo extraível" agora é usado. +O valor máximo extraível foi aplicado pela primeira vez no contexto de [prova de trabalho](/developers/docs/consensus-mechanisms/pow/) e, inicialmente, referido como "valor extraível do minerador". Isto porque na prova de trabalho, os mineradores controlam a inclusão, exclusão e ordenação das transações. No entanto, desde a transição para prova de participação através do [The Merge](/roadmap/merge), os validadores têm sido responsáveis por essas funções, e a mineração não faz mais parte do protocolo Ethereum. Como os métodos de extração de valor ainda existem, o termo "valor máximo extraível" agora é usado. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Certifique-se de estar familiarizado com [transações](/developers/docs/transactions/), [blocos](/developers/docs/blocks/), [prova de participação](/developers/docs/consensus-mechanisms/pos) e [gás](/developers/docs/gas/). Conhecer outros detalhes como [dapps](/apps/) ou [DeFi](/defi/) também seria útil. +Certifique-se de que está familiarizado com [transações](/developers/docs/transactions/), [blocos](/developers/docs/blocks/), [prova de participação](/developers/docs/consensus-mechanisms/pos) e [gás](/developers/docs/gas/). A familiaridade com [dapps](/apps/) e [DeFi](/defi/) também é útil. -## Extração via MEV {#mev-extraction} +## Extração de MEV {#mev-extraction} Em teoria, o MEV é revertido inteiramente para os validadores porque eles são a única parte que pode garantir a execução de uma oportunidade lucrativa de MEV. Na prática, porém, uma grande parte do MEV é extraída por participantes independentes da rede chamados "buscadores". Os buscadores executam algoritmos complexos nos dados da blockchain para detectar oportunidades de MEV lucrativas e usam bots para enviar automaticamente essas transações rentáveis para a rede. Os validadores recebem uma parte do valor total do MEV de qualquer maneira, porque os pesquisadores estão dispostos a pagar altas taxas de gás (que vão para o validador) em troca de maior probabilidade de inclusão de suas transações lucrativas em um bloco. Assumindo que os buscadores são economicamente racionais, a taxa de gás que um buscador está disposto a pagar será uma quantia de até 100% do MEV do buscador (porque se a taxa de gás fosse maior, o buscador perderia dinheiro). -Com isso, para algumas oportunidades de MEV altamente competitivas, como [arbitragem DEX](#mev-examples-dex-arbitrage), os buscadores podem ter que pagar 90% ou até mais de sua receita total de MEV, em taxas de gás para o validador, porque muitas pessoas querem executar a mesma operação de arbitragem lucrativa. Isto porque a única maneira de garantir que a sua transação de arbitragem seja executada é submetendo a transação com o preço de gás mais elevado. +Com isso, para algumas oportunidades de MEV altamente competitivas, como a [arbitragem de DEX](#mev-examples-dex-arbitrage), os pesquisadores podem ter que pagar 90% ou até mais de sua receita total de MEV em taxas de gás para o validador, porque muitas pessoas querem executar a mesma operação de arbitragem lucrativa. Isto porque a única maneira de garantir que a sua transação de arbitragem seja executada é submetendo a transação com o preço de gás mais elevado. -### Redução do consumo de gás dos contratos (gas golfing) {#mev-extraction-gas-golfing} +### Gas golfing {#mev-extraction-gas-golfing} Esta dinâmica fez do "gas-golfing" — o fato de programar as transações para que elas usem a menor quantidade de gás possível — una vantagem competitiva, porque ela permite que os buscadores fixem um preço de gás superior sem deixar de manter as taxas de gás constantes (já que as taxas de gás = preço do gás \* gás usado). -Algumas técnicas de "gas-golfing" conhecidas incluem: o uso de endereços que começam com uma longa série de zeros (por exemplo, [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)), já que consomem menos espaço (e, portanto, gás); e deixar pequenos saldos de token de [ERC-20](/developers/docs/standards/tokens/erc-20/) em contratos, já que é mais caro inicializar um slot de armazenamento (o que acontece se o saldo for 0) que atualizá-lo. Encontrar mais técnicas para reduzir o uso de gás é uma área ativa de pesquisa entre pesquisadores. +Algumas técnicas de gas golf conhecidas incluem: usar endereços que começam com uma longa sequência de zeros (ex.: [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)), pois ocupam menos espaço (e, portanto, gás) para armazenar; e deixar pequenos saldos de token [ERC-20](/developers/docs/standards/tokens/erc-20/) em contratos, pois custa mais gás para inicializar um slot de armazenamento (o que ocorre se o saldo for 0) do que para atualizar um slot de armazenamento. Encontrar mais técnicas para reduzir o uso de gás é uma área ativa de pesquisa entre pesquisadores. ### Frontrunners generalizados {#mev-extraction-generalized-frontrunners} @@ -40,23 +40,23 @@ Flashbots é um projeto independente que estende clientes de execução com um s O MEV surge na blockchain de diferentes maneiras. -### Arbitragem DEX {#mev-examples-dex-arbitrage} +### Arbitragem de DEX {#mev-examples-dex-arbitrage} -A arbitragem em [exchanges descentralizadas](/glossary/#dex) (DEX) é a oportunidade mais simples e mais conhecida de MEV. Por conseguinte, é também a mais competitiva. +A arbitragem em [corretora descentralizada](/glossary/#dex) (DEX) é a oportunidade de MEV mais simples e mais conhecida. Por conseguinte, é também a mais competitiva. Isso funciona assim: se dois DEXes estão oferecendo um token a dois preços diferentes, alguém pode comprar o token na DEX com preços mais baixos e vendê-lo nas DEX com preços mais altos em uma única transação atômica. Graças ao mecanismo da blockchain, está é sem dúvidas uma arbitragem sem risco. -[Aqui está um exemplo](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) de uma transação de arbitragem lucrativa onde um buscador transformou 1.00 ETH em 1.045 ETH aproveitando os diferentes preços do par ETH/DAI no Uniswap vs. Sushiswap. +[Aqui está um exemplo](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) de uma transação de arbitragem lucrativa em que um pesquisador transformou 1.000 ETH em 1.045 ETH, aproveitando os diferentes preços do par ETH/DAI na Uniswap vs. Sushiswap. ### Liquidações {#mev-examples-liquidations} As liquidações do protocolo de empréstimo oferecem outra oportunidade conhecida de MEV. -Protocolos de empréstimo como Maker e Aave exigem que os usuários depositem algumas garantias (por exemplo, ETH). Essa garantia depositada é então usada para emprestar a outros usuários. +Protocolos de empréstimo como Maker e Aave exigem que os usuários depositem alguma garantia (ex.: ETH). Esse colateral depositado é então usado para emprestar a outros usuários. -Os usuários podem então pedir emprestado ativos e tokens de outros, dependendo do que eles precisarem (por exemplo, você pode pedir emprestado MKR, se quiser votar em uma proposta de governança do MakerDAO) até um certo percentual de suas garantias depositadas. Por exemplo, se a quantia emprestada for um máximo de 30%, um usuário que depositar 100 DAI no protocolo poderá emprestar até 30 DAI de outro ativo. O protocolo determina a porcentagem exata do poder de empréstimo. +Os usuários podem então tomar emprestado ativos e tokens de outros, dependendo do que precisam (ex.: você pode tomar emprestado MKR se quiser votar em uma proposta de governança do MakerDAO) até uma certa porcentagem da garantia depositada. Por exemplo, se a quantia emprestada for um máximo de 30%, um usuário que depositar 100 DAI no protocolo poderá emprestar até 30 DAI de outro ativo. O protocolo determina a porcentagem exata do poder de empréstimo. -O valor das garantias de quem pede o emprestado flutua, assim como sua capacidade de pedir empréstimo. Se, por causa das flutuações de mercado, o valor dos ativos emprestados excede, por exemplo, 30% do valor de suas garantias (novamente, a porcentagem exata é determinada pelo protocolo), o protocolo normalmente permite que qualquer pessoa liquide a garantia, pagando imediatamente os mutuantes (isso é semelhante a como [chamada de margem](https://www.investopedia.com/terms/m/margincall.asp) funciona nas finanças tradicionais). Se liquidado, o mutuário geralmente tem de pagar uma taxa de liquidação elevada, parte da qual vai para o liquidador. É aí que se encontra a oportunidade de MEV. +O valor das garantias de quem pede o emprestado flutua, assim como sua capacidade de pedir empréstimo. Se, devido às flutuações do mercado, o valor dos ativos emprestados exceder, digamos, 30% do valor da sua garantia (novamente, a porcentagem exata é determinada pelo protocolo), o protocolo normalmente permite que qualquer pessoa liquide a garantia, pagando instantaneamente aos credores (isso é semelhante a como as [chamadas de margem](https://www.investopedia.com/terms/m/margincall.asp) funcionam nas finanças tradicionais). Se liquidado, o mutuário geralmente tem de pagar uma taxa de liquidação elevada, parte da qual vai para o liquidador. É aí que se encontra a oportunidade de MEV. Os buscadores competem para analisar os dados da blockchain o mais rápido possível para determinar quais mutuários podem ser liquidados e ser o primeiro a enviar uma transação de liquidação e coletar a taxa de liquidação para si mesmos. @@ -66,89 +66,89 @@ Sandwich trading é outro método comum de extração MEV. Para usar o método sandwich, um buscador observará o mempool para encontrar grandes negociações DEX. Por exemplo, suponha que alguém queira comprar 10.000 UNI com DAI na Uniswap. Uma transação desta magnitude causará um impacto significativo no par UNI/DAI, ocasionando aumento significativo no preço da UNI em relação ao DAI. -Um buscador pode calcular o efeito de preço aproximado desta grande negociação no par UNI/DAI e executar uma ordem de compra ideal imediatamente _antes_ da grande negociação, comprando UNI mais barato e, em seguida, executar uma ordem de venda imediatamente _após_ a grande negociação, vendendo-a pelo preço mais alto causado pelo grande pedido. +Um pesquisador pode calcular o efeito aproximado no preço dessa grande negociação no par UNI/DAI e executar uma ordem de compra ideal imediatamente _antes_ da negociação grande, comprando UNI barato e, em seguida, executar uma ordem de venda imediatamente _após_ a negociação grande, vendendo por um preço mais alto causado pela ordem grande. -No entanto, o método sandwich é mais arriscado, pois não é atômico (ao contrário da arbitragem DEX, como descrito acima) e é propenso a um [ataque "salmonela"](https://github.com/Defi-Cartel/salmonella). +O sanduíche, no entanto, é mais arriscado, pois não é atômico (ao contrário da arbitragem de DEX, conforme descrito acima) e está propenso a um [ataque de salmonela](https://github.com/Defi-Cartel/salmonella). -### MEV com NFT {#mev-examples-nfts} +### MEV de NFT {#mev-examples-nfts} O MEV no espaço de NFT é um fenômeno emergente e não é necessariamente lucrativo. No entanto, uma vez que as transações NFT acontecem na mesma blockchain compartilhada por todas as outras transações Ethereum, buscadores podem usar técnicas similares como as usadas em oportunidades de MEV tradicionais também no mercado NFT. -Por exemplo, se há o lançamento de um NFT popular e um buscador quer um determinado NFT ou um determinado conjunto de NFTs, ele pode programar uma transação de tal forma a ser o primeiro a comprar a NFT ou ele pode comprar todo o conjunto de NFTs em uma única transação. Ou se um NFT estiver [listado por um preço baixo de maneira equivocada](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), um buscador pode se adiantar por meio de frontrun a outros compradores e adquiri-lo por baixo custo. +Por exemplo, se há o lançamento de um NFT popular e um buscador quer um determinado NFT ou um determinado conjunto de NFTs, ele pode programar uma transação de tal forma a ser o primeiro a comprar a NFT ou ele pode comprar todo o conjunto de NFTs em uma única transação. Ou se um NFT for [listado por engano a um preço baixo](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), um pesquisador pode aplicar frontrun em outros compradores e adquiri-lo por um valor baixo. -Um exemplo proeminente de NFT com MEV ocorreu quando um buscador gastou US$ 7 milhões para [comprar](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) cada Cryptopunk ao preço mínimo. Um pesquisador de blockchain [explicou no Twitter](https://twitter.com/IvanBogatyy/status/1422232184493121538) como o comprador trabalhou com um provedor de MEV para manter a compra em segredo. +Um exemplo proeminente de MEV de NFT ocorreu quando um pesquisador gastou 7 milhões de dólares para [comprar](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) todos os Cryptopunks ao preço mínimo. Um pesquisador de blockchain [explicou no Twitter](https://twitter.com/IvanBogatyy/status/1422232184493121538) como o comprador trabalhou com um provedor de MEV para manter sua compra em segredo. ### A cauda longa {#mev-examples-long-tail} Arbitragem DEX, liquidações e o método sandwich trading são todos oportunidades de MEV muito conhecidas e são improváveis de serem lucrativas para novos buscadores. No entanto, há uma longa cauda de oportunidades de MEV menos conhecidas. MEV com NFT é, indiscutivelmente, uma dessas oportunidades. -Os buscadores que estão apenas começando talvez consigam ter mais sucesso procurando MEV nesta cauda mais longa. O [quadro de trabalhos MEV](https://github.com/flashbots/mev-job-board) do Flashbot enumera algumas oportunidades emergentes. +Os buscadores que estão apenas começando talvez consigam ter mais sucesso procurando MEV nesta cauda mais longa. O [quadro de vagas de MEV](https://github.com/flashbots/mev-job-board) da Flashbots lista algumas oportunidades emergentes. ## Efeitos do MEV {#effects-of-mev} Nem tudo sobre o MEV é negativo. Há consequências positivas e negativas com respeito ao MEV no Ethereum. -### As vantagens {#effects-of-mev-the-good} +### O lado bom {#effects-of-mev-the-good} Muitos projetos DeFi dependem de atores economicamente racionais para assegurar a utilidade e a estabilidade dos seus protocolos. Por exemplo, a arbitragem DEX garante que os usuários obtenham os melhores preços corretos por seus totens, e os protocolos de empréstimo dependem de liquidações rápidas quando os mutuários caem abaixo das proporções de garantia para garantir que os mutuários recebam de volta. Sem buscadores racionais procurando e corrigindo as ineficiências econômicas e aproveitando os incentivos econômicos dos protocolos, os protocolos de DeFI e dApps podem, em geral, não ser tão robustos como são hoje. -### As desvantagens {#effects-of-mev-the-bad} +### O lado ruim {#effects-of-mev-the-bad} Na camada de aplicativo, algumas formas de MEV, como o método "sandwich trading", resultam em uma experiência inequivocamente pior para os usuários. Usuários que sofrem o método "sandwich trading" enfrentam maior slippage (derrapagem) e uma pior execução nas suas transações. Na camada de rede, os frontrunners generalizados e os leilões de preço do gás nos quais eles costumam participar (quando dois ou mais frontrunners competem para que sua transação seja incluída no bloco seguinte, aumentando progressivamente o preço do gás das suas próprias transações) resultam em congestionamento da rede e em elevados preços do gás para todos os outros que tentam realizar transações regulares. -Além do que está acontecendo _nos_ blocos, o MEV pode ter efeitos prejudiciais _entre_ os blocos. Se o MEV disponível em um bloco excede significativamente a recompensa do bloco padrão, os validadores podem ser incentivados a reorganizar os blocos e capturar o MEV para si mesmos, causando reorganização da blockchain e instabilidade do consenso. +Além do que está acontecendo _dentro_ dos blocos, o MEV pode ter efeitos deletérios _entre_ os blocos. Se o MEV disponível em um bloco excede significativamente a recompensa do bloco padrão, os validadores podem ser incentivados a reorganizar os blocos e capturar o MEV para si mesmos, causando reorganização da blockchain e instabilidade do consenso. -Essa possibilidade de reorganização da blockchain foi [previamente explorada na blockchain Bitcoin](https://dl.acm.org/doi/10.1145/2976749.2978408). Como a recompensa de bloco do Bitcoin é reduzida pela metade e as recompensas de transação representam uma parte cada vez maior da recompensa do bloco, surgem situações nas quais é mais economicamente racional para os mineradores desistirem da recompensa do próximo bloco e, em vez disso, minarem novamente blocos passados com taxas mais elevadas. Com o crescimento do MEV, o mesmo tipo de situação poderia ocorrer com o Ethereum, ameaçando a integridade da blockchain. +Essa possibilidade de reorganização da blockchain foi [previamente explorada na blockchain do Bitcoin](https://dl.acm.org/doi/10.1145/2976749.2978408). Como a recompensa de bloco do Bitcoin é reduzida pela metade e as recompensas de transação representam uma parte cada vez maior da recompensa do bloco, surgem situações nas quais é mais economicamente racional para os mineradores desistirem da recompensa do próximo bloco e, em vez disso, minarem novamente blocos passados com taxas mais elevadas. Com o crescimento do MEV, o mesmo tipo de situação poderia ocorrer com o Ethereum, ameaçando a integridade da blockchain. ## Estado do MEV {#state-of-mev} -A extração MEV teve um grande crescimento no início de 2021, o que resultou em preços de gás extremamente elevados nos primeiros meses do ano. O surgimento do relé MEV de Flashbots reduziu a efetividade dos frontrunners generalizados e tirou os leilões de preço de gás da cadeia, baixando os preços do gás para os utilizadores comuns. +A extração MEV teve um grande crescimento no início de 2021, o que resultou em preços de gás extremamente elevados nos primeiros meses do ano. O surgimento do relay de MEV da Flashbots reduziu a eficácia dos piorneiros generalizados e levou os leilões de preço do gás para offchain, diminuindo os preços do gás para os usuários comuns. Enquanto muitos buscadores ainda estão ganhando um bom dinheiro com o MEV, à medida que as oportunidades se tornam mais conhecidas e mais e mais buscadores competem pela mesma oportunidade, os validadores irão capturar cada vez mais receita total do MEV (porque o mesmo tipo de leilão de gás descrito originalmente acima também ocorre em Flashbots, embora de forma particular, e os validadores irão capturar a receita de gás resultante). O MEV também não é exclusivo da Ethereum, e conforme as oportunidades se tornam mais competitivas no Ethereum, os buscadores estão migrando para blockchains alternativas, como a Binance Smart Chain, onde oportunidades de MEV semelhantes às que estão na Ethereum existem com menos concorrência. -Por outro lado, a transição da prova de trabalho para prova de participação e o esforço contínuo para escalar o Ethereum usando rollups mudam todo o panorama do MEV de maneiras que ainda não estão claras. Ainda não se sabe bem de que maneira ter proponentes de bloco garantidos conhecidos com pouca antecedência altera a dinâmica da extração de MEV em comparação com o modelo probabilístico na prova de trabalho ou como isso será interrompido quando [a eleição de líder secreto único](https://ethresear.ch/t/secret-non-single-leader-election/11789) e [a tecnologia de validador distribuído](/staking/dvt/) forem implementados. Da mesma forma, resta saber quais são as oportunidades de MEV existentes quando a maioria das atividades do usuário é transferida do Ethereum para seus rollups e fragmentos de camada 2. +Por outro lado, a transição da prova de trabalho para prova de participação e o esforço contínuo para escalar o Ethereum usando rollups mudam todo o panorama do MEV de maneiras que ainda não estão claras. Ainda não se sabe bem como ter proponentes de bloco garantidos, conhecidos com um pouco de antecedência, altera a dinâmica da extração de MEV em comparação com o modelo probabilístico na prova de trabalho, ou como isso será interrompido quando a [eleição de líder secreto único](https://ethresear.ch/t/secret-non-single-leader-election/11789) e a [tecnologia de validador distribuído](/staking/dvt/) forem implementadas. Da mesma forma, resta saber quais são as oportunidades de MEV existentes quando a maioria das atividades do usuário é transferida do Ethereum para seus rollups e fragmentos de camada 2. ## MEV na prova de participação (PoS) do Ethereum {#mev-in-ethereum-proof-of-stake} Conforme explicado, o MEV tem implicações negativas para a experiência geral do usuário e para a segurança da camada de consenso. Mas a transição do Ethereum para um consenso de prova de participação (denominado "A Fusão") introduz potencialmente novos riscos relacionados ao MEV: -### Centralização do validador {#validator-centralization} +### Centralização de validadores {#validator-centralization} -No Ethereum pós-fusão, os validadores (tendo feito depósitos de segurança de 32 ETH) chegam a um consenso sobre a validade dos blocos adicionados à Beacon Chain. Como 32 ETH podem estar fora do alcance de muitos, [entrar em um staking pool](/staking/pools/) pode ser uma opção mais viável. No entanto, uma distribuição saudável de [stakers individuais](/staking/solo/) é ideal, pois mitiga a centralização dos validadores e melhora a segurança do Ethereum. +No Ethereum pós-fusão, os validadores (tendo feito depósitos de segurança de 32 ETH) chegam a um consenso sobre a validade dos blocos adicionados à Beacon Chain. Como 32 ETH podem estar fora do alcance de muitos, [juntar-se a um pool de staking](/staking/pools/) pode ser uma opção mais viável. No entanto, uma distribuição saudável de [stakers individuais](/staking/solo/) é ideal, pois mitiga a centralização de validadores e melhora a segurança do Ethereum. -No entanto, acredita-se que a extração MEV seja capaz de acelerar a centralização de validadores. Isso se deve em parte porque, como os validadores [ganham menos por propor blocos](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) do que os mineradores atualmente, a extração de MEV pode em muito [influenciar os ganhos do validador](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) após o The Merge (A Fusão). +No entanto, acredita-se que a extração MEV seja capaz de acelerar a centralização de validadores. Isso ocorre em parte porque, como os validadores [ganham menos por propor blocos](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) do que os mineradores anteriormente, a extração de MEV tem [influenciado muito os ganhos dos validadores](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) desde o [The Merge](/roadmap/merge/). -Staking pools maiores provavelmente terão mais recursos para investir em otimizações necessárias para capturar oportunidades de MEV. Quanto mais MEV essas pools extraem, mais recursos eles têm para melhorar suas capacidades de extração MEV (e aumentar a receita geral), criando essencialmente [economias de escala](https://www.investopedia.com/terms/e/economiesofscale.asp#). +Staking pools maiores provavelmente terão mais recursos para investir em otimizações necessárias para capturar oportunidades de MEV. Quanto mais MEV esses pools extraem, mais recursos eles têm para melhorar suas capacidades de extração de MEV (e aumentar a receita geral), criando essencialmente [economias de escala](https://www.investopedia.com/terms/e/economiesofscale.asp#). Com menos recursos à sua disposição, os stakers individuais podem ser incapazes de lucrar com oportunidades de MEV. Isso pode aumentar a pressão sobre validadores independentes para se unirem a staking pools poderosas para aumentar os ganhos, reduzindo a descentralização no Ethereum. -### Mempools autorizados {#permissioned-mempools} +### Mempools permissionados {#permissioned-mempools} -Em resposta aos ataques "sandwiching" e "frontrunning", os traders podem começar a realizar negócios off-chain com validadores para privacidade de transação. Em vez de enviar uma potencial transação MEV para o mempool público, o trader a envia diretamente ao validador, que a inclui em um bloco e divide os lucros com o trader. +Em resposta aos ataques de "sandwiching" e "frontrunning", os traders podem começar a conduzir acordos off-chain com validadores para privacidade de transações. Em vez de enviar uma potencial transação MEV para o mempool público, o trader a envia diretamente ao validador, que a inclui em um bloco e divide os lucros com o trader. "Dark pools" são uma versão maior deste arranjo e funcionam como mempools autorizados só de acesso, abertas para usuários dispostos a pagar determinadas taxas. Esta tendência diminuiria a ausência de permissão e falta de confiança no Ethereum, e potencialmente transformaria a blockchain em um mecanismo "pay-to-play" que favorece a maior oferta. Mempools autorizados também acelerariam os riscos de centralização descritos na seção anterior. Grandes pools que executam vários validadores provavelmente se beneficiarão ao oferecer privacidade de transação a traders e usuários, aumentando as receitas MEV deles. -A luta contra esses problemas relacionados ao MEV no Ethereum pós-Fusão é uma área central de pesquisa. Até hoje, duas soluções propostas para reduzir o impacto negativo do MEV na descentralização e na segurança do Ethereum, depois da Fusão são **Separação Proponente-Construtor (PBS)** e **Builder API**. +A luta contra esses problemas relacionados ao MEV no Ethereum pós-Fusão é uma área central de pesquisa. Até o momento, duas soluções propostas para reduzir o impacto negativo do MEV na descentralização e segurança do Ethereum após o The Merge são a [**Separação Propositor-Construtor (PBS)**](/roadmap/pbs/) e a [**Builder API**](https://github.com/ethereum/builder-specs). -### Separação Proponente/Construtor {#proposer-builder-separation} +### Separação Propositor-Construtor {#proposer-builder-separation} -Em ambas prova de trabalho e prova de participação, um nó que cria um bloco o propõe para ser adicionado à cadeia para outros nós que participam do consenso. Um novo bloco se torna parte da cadeia canônica depois que outro minerador constrói com base nele (na prova de trabalho) ou recebe atestados da maioria dos validadores (na prova de participação). +Em ambas prova de trabalho e prova de participação, um nó que cria um bloco o propõe para ser adicionado à cadeia para outros nós que participam do consenso. Um novo bloco se torna parte da cadeia canônica depois que outro minerador cria com base nele (em PoW) ou recebe atestados da maioria dos validadores (em PoS). -A combinação de funções de produtor de bloco e de proponente de bloco é o que introduz a maioria dos problemas relacionados com o MEV descritos anteriormente. Por exemplo, nós de consenso são incentivados a desencadear reorganizações da cadeia em ataques time-bandit para maximizar os ganhos MEV. +A combinação de funções de produtor de bloco e de proponente de bloco é o que introduz a maioria dos problemas relacionados com o MEV descritos anteriormente. Por exemplo, os nós de consenso são incentivados a acionar reorganizações da cadeia em [ataques time-bandit](https://www.mev.wiki/attack-examples/time-bandit-attack) para maximizar os ganhos de MEV. -A [Separação Proponente/Construtor](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) foi criada para mitigar o impacto do MEV, especialmente na camada de consenso. A principal característica do PBS é a separação entre o produtor de bloco e as regras do proponente de bloco. Os validadores ainda são responsáveis por propor e votar nos blocos, mas uma nova classe de entidades especializadas, chamada de **construtores de blocos**, é encarregada de ordenar transações e construir blocos. +A [Separação Propositor-Construtor](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) foi projetada para mitigar o impacto do MEV, especialmente na camada de consenso. A principal característica do PBS é a separação entre o produtor de bloco e as regras do proponente de bloco. Os validadores ainda são responsáveis por propor e votar em blocos, mas uma nova classe de entidades especializadas, chamadas **construtores de blocos**, tem a tarefa de ordenar transações e construir blocos. Em PBS, um construtor de blocos cria um pacote de transações e faz um lance para sua inclusão em um bloco da Beacon Chain (como o “payload de execução”). O validador selecionado para propor o próximo bloco verifica então os diferentes lances e escolhe o pacote com a taxa mais alta. O PBS cria essencialmente um mercado de leilão, no qual os construtores negociam com os validadores vendendo o espaço no bloco. -O design de PBS atual usa um [esquema commit-reveal](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) no qual os construtores só publicam um compromisso criptográfico com o conteúdo de um bloco (header do bloco), juntamente com seus lances. Após aceitar o lance vencedor, o proponente cria uma proposta de bloco assinado que inclui o cabeçalho do bloco. O construtor do bloco deve publicar o corpo completo do bloco após ver a proposta do bloco assinado, e também deve receber [atestações](/glossary/#attestation) suficientes dos validadores antes de ser finalizado. +Os designs atuais do PBS usam um [esquema de commit-reveal](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) no qual os construtores publicam apenas um compromisso criptográfico com o conteúdo de um bloco (cabeçalho do bloco) juntamente com suas propostas. Após aceitar o lance vencedor, o proponente cria uma proposta de bloco assinado que inclui o cabeçalho do bloco. Espera-se que o construtor de blocos publique o corpo completo do bloco depois de ver a proposta de bloco assinada, e também deve receber [atestados](/glossary/#attestation) suficientes dos validadores antes de ser finalizado. #### Como a separação proponente-construtor atenua o impacto do MEV? {#how-does-pbs-curb-mev-impact} @@ -156,15 +156,15 @@ O protocolo de separação proponente-construtor reduz o efeito do MEV sobre o c Isso não exclui totalmente os validadores das receitas relacionadas ao MEV, já que os construtores devem dar lances altos para conseguir que seus blocos sejam aceitos pelos validadores. No entanto, com validadores não mais focados diretamente na otimização de renda MEV, a ameaça de ataques time-bandit diminui. -A separação proponente-construtor também reduz os riscos de centralização do MEV. Por exemplo, o uso de um esquema commit-reveal remove a necessidade de os construtores confiarem nos validadores para não roubarem a oportunidade MEV ou expô-la a outros construtores. Isso reduz a barreira para os stakers individuais se beneficiarem do MEV, caso contrário os construtores tenderiam a favorecer grandes pools com reputação off-chain e a conduzir acordos off-chain com eles. +A separação proponente-construtor também reduz os riscos de centralização do MEV. Por exemplo, o uso de um esquema commit-reveal remove a necessidade de os construtores confiarem nos validadores para não roubarem a oportunidade MEV ou expô-la a outros construtores. Isso reduz a barreira para que os stakers solo se beneficiem do MEV, caso contrário, os construtores tenderiam a favorecer grandes pools com reputação off-chain e a conduzir acordos off-chain com eles. De forma similar, os validadores não têm que confiar que os construtores não vão reter os corpos de blocos ou publicar blocos inválidos porque o pagamento é incondicional. A taxa do validador ainda processa mesmo que o bloco proposto esteja indisponível ou seja declarado inválido por outros validadores. No último caso, o bloco é simplesmente descartado, forçando o construtor de blocos a perder todas as taxas de transação e a receita MEV. -### Builder API {#builder-api} +### API de Construtor {#builder-api} -Embora a separação proponente-construtor prometa reduzir os efeitos da extração do MEV, a sua implementação requer alterações no protocolo de consenso. Especificamente, a regra de [escolha de fork](/developers/docs/consensus-mechanisms/pos/#fork-choice) na Beacon Chain precisaria ser atualizada. A [Builder API](https://github.com/ethereum/builder-specs) é uma solução temporária destinada a fornecer uma implementação funcional da separação proponente-construtor, embora com hipóteses mais confiáveis. +Embora a separação proponente-construtor prometa reduzir os efeitos da extração do MEV, a sua implementação requer alterações no protocolo de consenso. Especificamente, a regra de [escolha de bifurcação](/developers/docs/consensus-mechanisms/pos/#fork-choice) na Beacon Chain precisaria ser atualizada. A [API de Construtor](https://github.com/ethereum/builder-specs) é uma solução temporária destinada a fornecer uma implementação funcional da separação propositor-construtor, embora com maiores premissas de confiança. -A Builder API é uma versão modificada da [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) usada por clientes da camada de consenso para solicitar payloads de execução de clientes da camada de execução. Conforme descrito na [especificação do validador honesto](https://github.com/ethereum/consensus-specs/blob/master/specs/bellatrix/validator.md), validadores selecionados para funções de proposta de bloco solicitam um pacote de transação de um cliente de execução conectado, que eles incluem no bloco proposto da Beacon Chain. +A API de Construtor é uma versão modificada da [API de Engine](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) usada por clientes da camada de consenso para solicitar cargas de execução de clientes da camada de execução. Conforme descrito na [especificação do validador honesto](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md), os validadores selecionados para as tarefas de proposição de blocos solicitam um pacote de transações de um cliente de execução conectado, que eles incluem no bloco proposto da Beacon Chain. A Builder API também atua como um middleware entre validadores e clientes da camada de execução; mas é diferente porque permite aos validadores na Beacon Chain originar blocos de entidades externas (em vez de construir um bloco localmente usando um cliente de execução). @@ -178,15 +178,16 @@ Veja abaixo uma resumo geral de como a Builder API funciona: 4. O construtor que executa a Builder API deverá responder com a carga completa de execução após ver a proposta de bloco cega. Isso permite que o validador crie um bloco Beacon "assinado" que eles propagam por toda a rede. -5. Ainda é esperado que um validador usando a Builder API construa um bloco localmente caso o construtor de blocos não responda prontamente, para que não percam as recompensas de proposta de bloco. No entanto, o validador não pode criar outro bloco usando as transações agora reveladas ou outro conjunto, pois equivaleria a _equívoco_ (assinar dois blocos dentro do mesmo slot), o que é uma infração passível de advertência. +5. Ainda é esperado que um validador usando a Builder API construa um bloco localmente caso o construtor de blocos não responda prontamente, para que não percam as recompensas de proposta de bloco. No entanto, o validador não pode criar outro bloco usando as transações agora reveladas ou outro conjunto, pois isso equivaleria a _equivocação_ (assinar dois blocos no mesmo slot), que é uma ofensa passível de slashing. -Uma implementação de exemplo da Builder API é [MEV Boost](https://github.com/flashbots/mev-boost), uma melhoria no mecanismo de leilão [Flashbots](https://docs.flashbots.net/flashbots-auction/overview/) projetada para limitar as externalidades negativas de MEV no Ethereum. O leilão Flashbots permite que os mineradores em prova de trabalho externalizem o trabalho de construção de blocos lucrativos a partes especializadas chamadas de **buscadores**. +Um exemplo de implementação da API de Construtor é o [MEV Boost](https://github.com/flashbots/mev-boost), uma melhoria no [mecanismo de leilão da Flashbots](https://docs.flashbots.net/Flashbots-auction/overview) projetada para conter as externalidades negativas do MEV no Ethereum. O leilão da Flashbots permite que validadores em prova de participação terceirizem o trabalho de construção de blocos lucrativos para partes especializadas chamadas **pesquisadores**. +![Um diagrama mostrando o fluxo de MEV em detalhes](./mev.png) -Os buscadores procuram oportunidades de MEV lucrativas e enviam pacotes de transação para os mineradores, juntamente com uma [oferta de preço selada](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) para inclusão no bloco. O minerador executando mev-geth, uma versão bifurcada do cliente go-ethereum (Geth) só precisa escolher o pacote com mais lucro e minerá-lo como parte do novo bloco. Para proteger os mineradores de transações de spam e inválidas, os pacotes de transações passam por **retransmissores** (relayers) para validação antes de chegar aos mineradores. +Os pesquisadores procuram oportunidades lucrativas de MEV e enviam pacotes de transações para os propositores de bloco juntamente com uma [proposta de preço selado](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) para inclusão no bloco. O validador que executa o mev-geth, uma versão bifurcada do cliente go-ethereum (Geth), só precisa escolher o pacote com mais lucro e incluí-lo como parte do novo bloco. Para proteger os propositores de bloco (validadores) de spam e transações inválidas, os pacotes de transações passam por **retransmissores** para validação antes de chegar ao propositor. -O MEV Boost mantém o mesmo funcionamento do leilão original de Flashbots, embora com novos recursos projetados para a mudança à prova de participação do Ethereum. Os buscadores ainda consideram transações MEV lucrativas para inclusão em blocos, mas uma nova classe de partes especializadas, chamada de **construtores**, é responsável pela agregação de transações e pacotes em blocos. Um construtor aceita ofertas de preço seladas pelos buscadores e executa otimizações para encontrar o pedido mais lucrativo. +O MEV Boost mantém o mesmo funcionamento do leilão original de Flashbots, embora com novos recursos projetados para a mudança à prova de participação do Ethereum. Os pesquisadores ainda encontram transações de MEV lucrativas para inclusão em blocos, mas uma nova classe de partes especializadas, chamadas **construtores**, é responsável por agregar transações e pacotes em blocos. Um construtor aceita ofertas de preço seladas pelos buscadores e executa otimizações para encontrar o pedido mais lucrativo. -O retransmissor ainda é responsável por validar pacotes de transações antes de passá-los para o proponente. No entanto, o MEV Boost introduz **escrows** responsáveis por fornecer [disponibilidade de dados](/developers/docs/data-availability/) ao armazenar corpos de blocos enviados por construtores e cabeçalhos de bloco enviados por validadores. Aqui, um validador conectado a um relay pede por payloads de execução disponíveis e usa o algoritmo de ordenação MEV Boost para selecionar o cabeçalho de payload com as maiores ofertas + valores MEV. +O retransmissor ainda é responsável por validar pacotes de transações antes de passá-los para o proponente. No entanto, o MEV Boost introduz **escrows** responsáveis por fornecer [disponibilidade de dados](/developers/docs/data-availability/), armazenando os corpos dos blocos enviados pelos construtores e os cabeçalhos dos blocos enviados pelos validadores. Aqui, um validador conectado a um relay pede por payloads de execução disponíveis e usa o algoritmo de ordenação MEV Boost para selecionar o cabeçalho de payload com as maiores ofertas + valores MEV. #### Como a Builder API atenua o impacto do MEV? {#how-does-builder-api-curb-mev-impact} @@ -202,19 +203,19 @@ Alguns projetos, como MEV Boost, usam a Builder API como parte de uma estrutura ## Recursos relacionados {#related-resources} -- [Documentação sobre Flashbots (links em inglês)](https://docs.flashbots.net/) -- [Flashbots GitHub](https://github.com/flashbots/pm) -- [mevboost.org](https://www.mevboost.org/) - _Rastreador com estatísticas em tempo real para relays MEV-Boost e construtores de blocos_ +- [Documentação da Flashbots](https://docs.flashbots.net/) +- [GitHub da Flashbots](https://github.com/flashbots/pm) +- [mevboost.org](https://www.mevboost.org/) - _Rastreador com estatísticas em tempo real para relays e construtores de blocos do MEV-Boost_ ## Leitura adicional {#further-reading} -- [Valor extraível da mineração (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/) -- [MEV e Mim](https://www.paradigm.xyz/2021/02/mev-and-me) -- [O Ethereum é uma Floresta Sombria](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) -- [Escapando da Floresta Sombria](https://samczsun.com/escaping-the-dark-forest/) -- [Flashbots: Superando a crise MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) -- [Tópicos sobre MEV de @bertcmiller](https://twitter.com/bertcmiller/status/1402665992422047747) -- [MEV-Boost: Arquitetura Flashbots pronta para a Fusão](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [O que é o Valor Extraível do Minerador (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [MEV e Eu](https://www.paradigm.xyz/2021/02/mev-and-me) +- [Ethereum é uma Floresta Escura](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [Escapando da Floresta Escura](https://samczsun.com/escaping-the-dark-forest/) +- [Flashbots: Aplicando frontrunning na crise do MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [Threads sobre MEV de @bertcmiller](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-Boost: Arquitetura Flashbots pronta para o Merge](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) - [O que é MEV Boost](https://www.alchemy.com/overviews/mev-boost) -- [Por que executar mev-boost?](https://writings.flashbots.net/writings/why-run-mevboost/) -- [O Guia do Mochileiro sobre o Ethereum](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) +- [Por que executar o mev-boost?](https://writings.flashbots.net/writings/why-run-mevboost/) +- [O Guia do Mochileiro para o Ethereum](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/pt-br/developers/docs/networking-layer/index.md b/public/content/translations/pt-br/developers/docs/networking-layer/index.md index 15a879a1ca6..84e6399cf40 100644 --- a/public/content/translations/pt-br/developers/docs/networking-layer/index.md +++ b/public/content/translations/pt-br/developers/docs/networking-layer/index.md @@ -1,6 +1,6 @@ --- -title: Camada da Rede -description: Introdução à camada de rede Ethereum +title: Camada de rede +description: "Introdução à camada de rede Ethereum" lang: pt-br sidebarDepth: 2 --- @@ -13,7 +13,7 @@ Clientes de execução transmitem transações na rede ponto a ponto na camada d ## Pré-requisitos {#prerequisites} -Alguns conhecimentos dos [nós e clientes](/developers/docs/nodes-and-clients/) do Ethereum serão úteis para entender esta página. +Algum conhecimento sobre [nós e clientes](/developers/docs/nodes-and-clients/) do Ethereum será útil para entender esta página. ## A camada de execução {#execution-layer} @@ -27,33 +27,33 @@ Ambas as pilhas funcionam em paralelo. A pilha de descoberta alimenta novos part ### Descoberta {#discovery} -Descoberta é o processo de encontrar outros nós na rede. Isso é inicializado usando um pequeno conjunto de bootnodes (nós cujos endereços são [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) dentro do cliente para que possam ser encontrados imediatamente e conectar o cliente aos pares). Estes bootnodes (nós de inicialização) existem apenas para introduzir um novo nó a um conjunto de pares. Esse é o único objetivo deles; eles não participam de tarefas normais do cliente como sincronizar a cadeia e são usados somente na primeira vez que um cliente é ativado. +Descoberta é o processo de encontrar outros nós na rede. Isso é inicializado usando um pequeno conjunto de bootnodes (nós cujos endereços são [codificados](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) no cliente, para que possam ser encontrados imediatamente e conectar o cliente aos pares). Estes bootnodes (nós de inicialização) existem apenas para introduzir um novo nó a um conjunto de pares. Esse é o único objetivo deles; eles não participam de tarefas normais do cliente como sincronizar a cadeia e são usados somente na primeira vez que um cliente é ativado. -O protocolo usado para as interações de node-bootnode (nós de inicialização) é uma forma modificada de [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) que usa uma [tabela de hash distribuída](https://en.wikipedia.org/wiki/Distributed_hash_table) para compartilhar listas de nós. Cada nó tem uma versão desta tabela contendo as informações necessárias para se conectar aos seus pares mais próximos. Essa 'proximidade' não é geográfica. A distância é definida pela semelhança do ID de nós. A tabela de cada nó é atualizada regularmente como um recurso de segurança. Por exemplo, no [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), os nós do protocolo de descoberta também podem enviar 'anúncios' que exibem os subprotocolos que o cliente suporta, permitindo que os pares negociem sobre os protocolos que ambos podem usar para se comunicar. +O protocolo usado para as interações nó-bootnode é uma forma modificada do [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) que usa uma [tabela de hash distribuída](https://en.wikipedia.org/wiki/Distributed_hash_table) para compartilhar listas de nós. Cada nó tem uma versão desta tabela contendo as informações necessárias para se conectar aos seus pares mais próximos. Essa 'proximidade' não é geográfica. A distância é definida pela semelhança do ID de nós. A tabela de cada nó é atualizada regularmente como um recurso de segurança. Por exemplo, no [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), os nós do protocolo de descoberta também podem enviar 'anúncios' que exibem os subprotocolos que o cliente suporta, permitindo que os pares negociem sobre os protocolos que ambos podem usar para se comunicar. -A descoberta começa com um jogo de PING-PONG. Um PING-PONG bem-sucedido "liga" o novo nó a um bootnode (nó de inicialização). A mensagem inicial que alerta um bootnode sobre a existência de um novo nó entrando na rede é um `PING`. Este `PING` inclui informações em hash sobre o novo nó, o bootnode e um carimbo de data/hora de expiração. O bootnode recebe o `PING` e retorna um `PONG` contendo o hash `PING`. Se os hashes `PING` e `PONG` corresponderem, então a conexão entre o novo nó e o bootnode será verificada e diz-se que eles têm "vínculo". +A descoberta começa com um jogo de PING-PONG. Um PING-PONG bem-sucedido "liga" o novo nó a um bootnode (nó de inicialização). A mensagem inicial que alerta um bootnode sobre a existência de um novo nó entrando na rede é um `PING`. Este `PING` inclui informações com hash sobre o novo nó, o bootnode e um carimbo de data/hora de expiração. O bootnode recebe o `PING` e retorna um `PONG` contendo o hash do `PING`. Se os hashes de `PING` e `PONG` corresponderem, a conexão entre o novo nó e o bootnode é verificada e diz-se que eles estão "vinculados". -Uma vez vinculado, o novo nó pode enviar uma solicitação `FIND-NEIGHBOURS` para o bootnode. Os dados retornados pelo bootnode incluem uma lista de peers aos quais o novo nó pode se conectar. Se os nós não estiverem vinculados, a solicitação `FIND-NEIGHBOURS` falhará, então o novo nó não poderá entrar na rede. +Uma vez vinculado, o novo nó pode enviar uma solicitação `FIND-NEIGHBOURS` para o bootnode. Os dados retornados pelo bootnode incluem uma lista de peers aos quais o novo nó pode se conectar. Se os nós não estiverem vinculados, a solicitação `FIND-NEIGHBOURS` falhará, e o novo nó não conseguirá entrar na rede. Uma vez que o novo nó recebe uma lista de vizinhos do bootnode, ele inicia uma troca de PING-PONG com cada um deles. PING-PONGs bem-sucedidos unem o novo nó com seus vizinhos, permitindo a troca de mensagens. ``` -start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours +iniciar cliente --> conectar ao bootnode --> vincular ao bootnode --> encontrar vizinhos --> vincular aos vizinhos ``` Os clientes de execução estão usando atualmente o protocolo de descoberta [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) e há um esforço ativo para migrar para o protocolo [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5). -#### ENR: Registros de Nó Ethereum {#enr} +#### ENR: Registros de Nós do Ethereum {#enr} -O [Registro de Nó Ethereum (ENR)](/developers/docs/networking-layer/network-addresses/) é um objeto que contém três elementos básicos: uma assinatura (hash do conteúdo do registro feito de acordo com algum esquema de identidade acordado), um número de sequência que rastreia as alterações no registro e uma lista arbitrária de pares chave:valor. Este é um formato moderno que permite uma troca mais fácil de informações de identificação entre novos pares e é o formato de [endereço de rede](/developers/docs/networking-layer/network-addresses) preferido dos nós Ethereum. +O [Registro de Nó Ethereum (ENR)](/developers/docs/networking-layer/network-addresses/) é um objeto que contém três elementos básicos: uma assinatura (hash do conteúdo do registro feito de acordo com algum esquema de identidade acordado), um número de sequência que rastreia as alterações no registro e uma lista arbitrária de pares chave:valor. Este é um formato à prova de futuro que permite uma troca mais fácil de informações de identificação entre novos pares e é o formato de [endereço de rede](/developers/docs/networking-layer/network-addresses) preferido para os nós do Ethereum. -#### Por que a descoberta é construída no UDP? {#why-udp} +#### Por que a descoberta é construída no UDP? Por que UDP? {#why-udp} O UDP não suporta nenhuma verificação de erros, reenvio de pacotes com falha ou abertura e fechamento de conexões dinamicamente. Em vez disso, ele apenas dispara um fluxo contínuo de informações em um destino, independentemente de ter sido recebido com sucesso. Essa funcionalidade mínima também se traduz em sobrecarga mínima, tornando esse tipo de conexão muito rápida. Para descoberta, onde um nó simplesmente quer tornar sua presença conhecida, para depois estabelecer uma conexão formal com um par, o UDP é suficiente. No entanto, para o restante da pilha de rede, o UDP não é adequado. A troca de informações entre nós é bastante complexa e, portanto, precisa de um protocolo mais completo que possa suportar reenvio, verificação de erros etc. A sobrecarga adicional associada ao TCP vale a funcionalidade adicional. Portanto, a maioria da pilha P2P opera sobre TCP. ### DevP2P {#devp2p} -O DevP2P é em si uma pilha inteira de protocolos que o Ethereum implementa para estabelecer e manter a rede ponto a ponto. Depois que novos nós entram na rede, suas interações são regidas por protocolos na pilha [DevP2P](https://github.com/ethereum/devp2p). Todos eles ficam em cima do TCP e incluem o protocolo de transporte RLPx, o protocolo de fio e vários subprotocolos. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) é o protocolo que controla o início, a autenticação e a manutenção de sessões entre nós. O RLPx codifica mensagens usando RLP (Prefixo de Comprimento Recursivo), que é um método muito eficiente de codificação de dados em uma estrutura mínima para envio entre nós. +O DevP2P é em si uma pilha inteira de protocolos que o Ethereum implementa para estabelecer e manter a rede ponto a ponto. Depois que novos nós entram na rede, suas interações são regidas por protocolos na pilha [DevP2P](https://github.com/ethereum/devp2p). Todos eles ficam em cima do TCP e incluem o protocolo de transporte RLPx, o protocolo de fio e vários subprotocolos. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) é o protocolo que rege o início, a autenticação e a manutenção de sessões entre nós. O RLPx codifica mensagens usando RLP (Prefixo de Comprimento Recursivo), que é um método muito eficiente de codificação de dados em uma estrutura mínima para envio entre nós. Uma sessão RLPx entre dois nós começa com um acerto criptográfico inicial. Isso envolve o nó enviando uma mensagem de autenticação que é então verificada pelo par. Na verificação bem-sucedida, o para gera uma mensagem de confirmação de autenticação para retornar ao nó inicializador. Este é um processo de troca de chaves que permite que os nós se comuniquem de forma privada e segura. Um aperto de mão criptográfico bem-sucedido aciona ambos os nós para enviar uma mensagem "hello" um ao outro "na rede". O protocolo de transmissão é iniciado por uma troca bem-sucedida de mensagens de saudação. @@ -73,19 +73,19 @@ Junto com as mensagens de saudação, o protocolo de transmissão também pode e #### Protocolo de transmissão {#wire-protocol} -Uma vez que os pares estão conectados e uma sessão RLPx foi iniciada, o protocolo de transmissão define como os pares se comunicam. Inicialmente, o protocolo de transmissão definiu três tarefas principais: sincronização de cadeia, propagação de bloco e troca de transação. No entanto, uma vez que o Ethereum mudou para a prova de participação, a propagação do bloco e a sincronização da cadeia tornaram-se parte da camada de consenso. A troca de transações ainda é da responsabilidade dos clientes de execução. A troca de transações refere-se à troca de transações pendentes entre nós para que os construtores de blocos possam selecionar algumas delas para inclusão no próximo bloco. Informações detalhadas sobre essas tarefas estão disponíveis [aqui](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Os clientes que oferecem suporte a esses subprotocolos os expõem por meio do [JSON-RPC](/developers/docs/apis/json-rpc/). +Uma vez que os pares estão conectados e uma sessão RLPx foi iniciada, o protocolo de transmissão define como os pares se comunicam. Inicialmente, o protocolo de transmissão definiu três tarefas principais: sincronização de cadeia, propagação de bloco e troca de transação. No entanto, uma vez que o Ethereum mudou para a prova de participação, a propagação do bloco e a sincronização da cadeia tornaram-se parte da camada de consenso. A troca de transações ainda é da responsabilidade dos clientes de execução. A troca de transações refere-se à troca de transações pendentes entre nós para que os construtores de blocos possam selecionar algumas delas para inclusão no próximo bloco. Informações detalhadas sobre essas tarefas estão disponíveis [aqui](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Clientes que suportam esses subprotocolos os expõem através do [JSON-RPC](/developers/docs/apis/json-rpc/). -#### les (subprotocolo ethereum leve) {#les} +#### les (subprotocolo leve do Ethereum) {#les} -Este é um protocolo mínimo para sincronizar clientes leves. Esse protocolo raramente é usado porque são necessários nós completos para fornecer dados a clientes leves sem serem incentivados. O comportamento padrão dos clientes de execução é não transmitir dados de clientes leves sobre subprotocolos ethereum leve (les). Mais informações estão disponíveis nas [especificações](https://github.com/ethereum/devp2p/blob/master/caps/les.md). +Este é um protocolo mínimo para sincronizar clientes leves. Esse protocolo raramente é usado porque são necessários nós completos para fornecer dados a clientes leves sem serem incentivados. O comportamento padrão dos clientes de execução não é servir dados de clientes leves por meio do les. Mais informações estão disponíveis na [especificação](https://github.com/ethereum/devp2p/blob/master/caps/les.md) do les. -#### Captura {#snap} +#### Snap {#snap} -O [protocolo de captura](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) é uma extensão opcional que permite que pares troquem instantâneos de estados recentes, permitindo que os pares verifiquem dados de conta e armazenamento sem precisar baixar nós intermediários da árvore Merkle. +O [protocolo snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) é uma extensão opcional que permite que os pares troquem snapshots de estados recentes, permitindo que os pares verifiquem os dados da conta e do armazenamento sem ter que baixar os nós intermediários da árvore de Merkle. #### Wit (protocolo de testemunha) {#wit} -O [protocolo de testemunha](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) é uma extensão opcional que permite a troca de testemunhas de estado entre os pares, ajudando a sincronizar os clientes com a ponta da cadeia. +O [protocolo de testemunha](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) é uma extensão opcional que permite a troca de testemunhas de estado entre pares, ajudando a sincronizar os clientes com a ponta da cadeia. #### Whisper {#whisper} @@ -97,11 +97,11 @@ Os clientes de consenso participam de uma rede ponto a ponto separada com uma es ### Descoberta {#consensus-discovery} -Semelhante aos clientes de execução, os clientes de consenso usam [discv5](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) sobre UDP para encontrar pares. A implementação da camada de consenso do discv5 difere daquela dos clientes de execução apenas porque inclui um adaptador conectando o discv5 em uma pilha [libP2P](https://libp2p.io/), descontinuando o DevP2P. As sessões RLPx da camada de execução foram descontinuadas a favor do handshake (acerto) de canal seguro de ruído da libP2P. +Semelhante aos clientes de execução, os clientes de consenso usam o [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) sobre UDP para encontrar pares. A implementação da camada de consenso do discv5 difere da dos clientes de execução apenas por incluir um adaptador que conecta o discv5 a uma pilha [libP2P](https://libp2p.io/), descontinuando o DevP2P. As sessões RLPx da camada de execução foram descontinuadas a favor do handshake (acerto) de canal seguro de ruído da libP2P. ### ENRs {#consensus-enr} -O ENR para nós de consenso inclui a chave pública do nó, endereço IP, portas UDP e TCP e dois campos específicos de consenso: o campo de bits (bitfield) da sub-rede de atestado e a chave `eth2`. O primeiro torna mais fácil para os nós encontrarem pares que participam de sub-redes de gossip de atestado específicas. A chave `eth2` contém informações sobre qual versão do fork Ethereum o nó está usando, garantindo que os pares estejam se conectando ao Ethereum correto. +O ENR para nós de consenso inclui a chave pública do nó, o endereço IP, as portas UDP e TCP e dois campos específicos do consenso: o campo de bits da sub-rede de atestado e a chave `eth2`. O primeiro torna mais fácil para os nós encontrarem pares que participam de sub-redes de gossip de atestado específicas. A chave `eth2` contém informações sobre qual versão da bifurcação do Ethereum o nó está usando, garantindo que os pares estejam se conectando ao Ethereum correto. ### libP2P {#libp2p} @@ -109,9 +109,9 @@ A pilha libP2P suporta todas as comunicações após a descoberta. Os clientes p ### Gossip {#gossip} -O domínio gossip inclui todas as informações que precisam se espalhar rapidamente pela rede. Isso inclui blocos de sinalização, provas, atestados, saídas e cortes. Isso é transmitido usando libP2P gossipsub v1 e depende de vários metadados armazenados localmente em cada nó, incluindo o tamanho máximo de cargas de gossip para receber e transmitir. Informações detalhadas sobre o domínio gossip estão disponíveis [aqui](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). +O domínio gossip inclui todas as informações que precisam se espalhar rapidamente pela rede. Isso inclui blocos de sinalização, provas, atestados, saídas e cortes. Isso é transmitido usando libP2P gossipsub v1 e depende de vários metadados armazenados localmente em cada nó, incluindo o tamanho máximo de cargas de gossip para receber e transmitir. Informações detalhadas sobre o domínio gossip estão disponíveis [aqui](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). -### Pedido-Resposta {#request-response} +### Solicitação-resposta {#request-response} O domínio de pedido-resposta contém protocolos para clientes que solicitam informações específicas de seus pares. Os exemplos incluem pedidos de blocos Beacon específicos que correspondam a determinados hashes raiz ou dentro de um intervalo de slots. As respostas são sempre retornadas como bytes codificados em SSZ compactados rapidamente. @@ -119,25 +119,25 @@ O domínio de pedido-resposta contém protocolos para clientes que solicitam inf SSZ significa serialização simples. Ela usa deslocamentos fixos que facilitam a decodificação de partes individuais de uma mensagem codificada sem ter que decodificar toda a estrutura, o que é muito útil para o cliente de consenso, pois pode capturar com eficiência informações específicas de mensagens codificadas. Ele também é projetado especificamente para integração com protocolos Merkle, com ganhos de eficiência relacionados para Merkleization (transformação resultante de árvores de Merkle). Como todos os hashes na camada de consenso são raízes de Merkle, isso resulta em uma melhoria significativa. A SSZ também garante representações únicas de valores. -## Conexão a execução e consensos de clientes {#connecting-clients} +## Conectando os clientes de execução e de consenso {#connecting-clients} Ambos os clientes de consenso e execução executam em paralelo. Eles precisam estar conectados para que o cliente de consenso possa fornecer instruções ao cliente de execução, e o cliente de execução possa passar pacotes de transações para o cliente de consenso para incluir nos blocos Beacon. A comunicação entre os dois clientes pode ser realizada usando uma conexão RPC local. Uma API conhecida como ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) define as instruções enviadas entre os dois clientes. Como ambos os clientes estão atrás de uma única identidade de rede, eles compartilham um ENR (registro de nó Ethereum) que contém uma chave separada para cada cliente (chave eth1 e chave eth2). Um resumo do fluxo de controle é mostrado abaixo, com a pilha de rede relevante entre colchetes. -### Quando o cliente de consenso não é produtor de bloco: {#when-consensus-client-is-not-block-producer} +### Quando o cliente de consenso não é o produtor do bloco: {#when-consensus-client-is-not-block-producer} - O cliente de consenso recebe um bloco através do protocolo gossip do bloco (consenso p2p) -- O cliente de consenso pré-valida o bloco, ou seja, garante que chegou de um remetente válido com metadados corretos +- O cliente de consenso pré-valida o bloco, ou seja, garante que ele chegou de um remetente válido com os metadados corretos. - As transações no bloco são enviadas para a camada de execução como um payload (carga de dados) de execução (conexão RPC local) -- A camada de execução executa as transações e valida o estado no cabeçalho do bloco (ou seja, verifica a correspondência de hashes) +- A camada de execução executa as transações e valida o estado no cabeçalho do bloco (ou seja, verifica se os hashes correspondem). - A camada de execução passa os dados de validação de volta para a camada de consenso, bloco agora considerado validado (conexão RPC local) - A camada de consenso adiciona bloco no nício de sua própria blockchain e o atesta, transmitindo o atestado pela rede (consenso p2p) -### Quando o cliente de consenso é produtor de blocos: {#when-consensus-client-is-block-producer} +### Quando o cliente de consenso é o produtor de blocos: {#when-consensus-client-is-block-producer} - O cliente de consenso recebe o aviso de que é o próximo produtor de bloco (consenso p2p) -- A camada de consenso chama o método `create block` no cliente de execução (RPC local) +- A camada de consenso chama o método `create block` no cliente de execução (RPC local). - A camada de execução acessa o mempool da transação que foi preenchido pelo protocolo gossip de transação (execução p2p) - O cliente de execução agrupa as transações em um bloco, executa as transações e gera um hash de bloco - O cliente de consenso pega as transações e bloqueia o hash do cliente de execução e o adiciona ao bloco beacon (RPC local) @@ -146,10 +146,18 @@ Um resumo do fluxo de controle é mostrado abaixo, com a pilha de rede relevante Uma vez que o bloco tenha sido atestado por validadores suficientes, ele é adicionado ao cabeçalho da cadeia, justificado e finalmente finalizado. -![Diagrama da camada de rede do cliente de consenso Ethereum](cons_client_net_layer.png) ![Diagrama da camada de rede do cliente de execução Ethereum](exe_client_net_layer.png) +![](cons_client_net_layer.png) +![](exe_client_net_layer.png) -Esquema da camada de rede para clientes de consenso e execução, de [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) +Esquema da camada de rede para clientes de consenso e de execução, de [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) -## Leitura Adicional {#further-reading} +## Leitura adicional {#further-reading} -[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [Especificações de rede da camada de consenso](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#enr-structure) [Kademlia para Discv5](https://vac.dev/kademlia-to-discv5) [Paper Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [Introdução ao Ethereum p2p](https://p2p.paris/en/talks/intro-ethereum-networking/) [Relacionamento eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [Fusão e vídeo com detalhes do cliente eth2](https://www.youtube.com/watch?v=zNIrIninMgg) +[DevP2P](https://github.com/ethereum/devp2p) +[LibP2p](https://github.com/libp2p/specs) +[Especificações de rede da camada de consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) +[De Kademlia para discv5](https://vac.dev/kademlia-to-discv5) +[Artigo sobre o Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) +[Introdução à rede P2P do Ethereum](https://p2p.paris/en/talks/intro-ethereum-networking/) +[Relação ETH1/ETH2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) +[Vídeo com detalhes sobre a The Merge e clientes ETH2](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/pt-br/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/pt-br/developers/docs/networking-layer/network-addresses/index.md index ccbbc951b6f..3fd183cb432 100644 --- a/public/content/translations/pt-br/developers/docs/networking-layer/network-addresses/index.md +++ b/public/content/translations/pt-br/developers/docs/networking-layer/network-addresses/index.md @@ -1,19 +1,19 @@ --- -title: Endereço de rede -description: Uma introdução aos endereços de rede +title: "Endereço de rede" +description: "Uma introdução aos endereços de rede" lang: pt-br sidebarDepth: 2 --- Nós Ethereum precisam se identificar com algumas informações básicas para se conectar a pares. Para garantir que qualquer para potencial possa interpretar esta informação, ela é transmitida em um dos três formatos padronizados que qualquer nó Ethereum pode entender: multiaddr, enode ou Ethereum Node Records (ENRs). ENRs são o padrão atual para endereços de rede Ethereum. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -É necessário ter algum entendimento sobre a [camada de rede](/developers/docs/networking-layer/)do Ethereum para entender esta página. +É necessário ter algum entendimento sobre a [camada de rede](/developers/docs/networking-layer/) do Ethereum para entender esta página. ## Multiaddr {#multiaddr} -O formato original do endereço de nó Ethereum era o 'multiaddr' (abreviação de 'multi-endereços'). O Multiaddr é um formato universal desenhado para redes peer-to-peer. Os endereços são representados como pares chave-valor com chaves e valores separados por uma barra. Por exemplo, o multiaddr para um nó com endereço IPv4 `192.168.22.27` escutando a porta TCP `33000` será: +O formato original do endereço de nó Ethereum era o 'multiaddr' (abreviação de 'multi-endereços'). O Multiaddr é um formato universal desenhado para redes peer-to-peer. Os endereços são representados como pares chave-valor com chaves e valores separados por uma barra. Por exemplo, o multiaddr para um nó com endereço IPv4 `192.168.22.27` escutando a porta TCP `33000` tem a seguinte aparência: `/ip4/192.168.22.27/tcp/33000` @@ -23,17 +23,17 @@ Para um nó Ethereum, o multiaddr contém o node-ID (um hash de sua chave públi ## Enode {#enode} -Um enode é uma maneira de identificar um nó Ethereum usando um formato de endereço de URL. O ID hexadecimal do nó é codificado na porção do nome de usuário do URL separado do host usando um sinal @. O nome de host só pode ser dado como um endereço IP; nomes DNS não são permitidos. A porta na seção hostname é a porta de escuta TCP. Se as portas TCP e UDP (descoberta) são diferentes, a porta UDP é especificada como um parâmetro de consulta "discport" +Um enode é uma maneira de identificar um nó Ethereum usando um formato de endereço de URL. O ID hexadecimal do nó é codificado na porção do nome de usuário do URL separado do host usando um sinal @. O nome de host só pode ser dado como um endereço IP; nomes DNS não são permitidos. A porta na seção hostname é a porta de escuta TCP. Se as portas TCP e UDP (descoberta) são diferentes, a porta UDP é especificada como um parâmetro de consulta "discport". -No exemplo a seguir, o URL do nó descreve um nó com endereço IP `10.3.58.`, porta TCP `30303` e porta de descoberta UDP `30301`. +No exemplo a seguir, a URL do nó descreve um nó com endereço IP `10.3.58.6`, porta TCP `30303` e porta de descoberta UDP `30301`. `enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` -## Registros de Nó Ethereum {#enr} +## Registros de Nós Ethereum (ENRs) {#enr} -Registros de Nó Ethereum (ENRs, pela sigla em inglês) são um formato padronizado para endereços de rede no Ethereum. Eles substituem multiaddrs e enodes. Estes são especialmente úteis porque permitem um maior intercâmbio de informações entre nós. O ENR contém uma assinatura, um número de sequência e campos detalhando o esquema de identidade usado para gerar e validar assinaturas. O ENR também pode ser populado com dados arbitrários organizados como pares de valor-chave. Estes pares chave-valor contêm o endereço IP do nó e as informações sobre os subprotocolos que o nó pode usar. Os clientes de consenso usam uma [estrutura ENR específica](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#enr-structure) para identificar nós de inicialização e também incluem um campo `eth2` contendo informações sobre o atual fork do Ethereum e o atestado da sub-rede gossip (isso conecta o nó a um determinado conjunto de pares cujas atestações são agregadas juntos). +Registros de Nó Ethereum (ENRs, pela sigla em inglês) são um formato padronizado para endereços de rede no Ethereum. Eles substituem multiaddrs e enodes. Estes são especialmente úteis porque permitem um maior intercâmbio de informações entre nós. O ENR contém uma assinatura, um número de sequência e campos detalhando o esquema de identidade usado para gerar e validar assinaturas. O ENR também pode ser populado com dados arbitrários organizados como pares de valor-chave. Estes pares chave-valor contêm o endereço IP do nó e as informações sobre os subprotocolos que o nó pode usar. Os clientes de consenso usam uma [estrutura ENR específica](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) para identificar os nós de inicialização e também incluem um campo `eth2` que contém informações sobre a bifurcação atual do Ethereum e a sub-rede de gossip de atestados (que conecta o nó a um conjunto específico de pares cujos atestados são agregados). -## Leitura Adicional {#further-reading} +## Leitura adicional {#further-reading} -- [EIP-778: Registros de Nó Ethereum (ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [EIP-778: Registros de Nós Ethereum (ENR)](https://eips.ethereum.org/EIPS/eip-778) - [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/pt-br/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/pt-br/developers/docs/networking-layer/portal-network/index.md index 5223a43bb84..355585576f1 100644 --- a/public/content/translations/pt-br/developers/docs/networking-layer/portal-network/index.md +++ b/public/content/translations/pt-br/developers/docs/networking-layer/portal-network/index.md @@ -1,6 +1,6 @@ --- title: A Rede Portal -description: Uma visão geral da Rede Portal - uma rede em desenvolvimento para dar suporte a clientes com poucos recursos. +description: "Uma visão geral da Rede Portal - uma rede em desenvolvimento para dar suporte a clientes com poucos recursos." lang: pt-br --- @@ -12,23 +12,23 @@ A Rede Portal é um novo desenho de rede para o Ethereum que visa resolver o pro Mais sobre [nós e clientes](/developers/docs/nodes-and-clients/) -## Por que nós precisamos da Rede Portal {#why-do-we-need-portal-network} +## Por que precisamos da Portal Network {#why-do-we-need-portal-network} Os nódulos da Ethereum armazenam sua própria cópia total ou parcial do blockchain Ethereum. Esta cópia local é usada para validar transações e garantir que o nódulo está seguindo a cadeia correta. Este dado armazenado localmente permite aos nódulos verificarem de maneira independente que os dados de chegada são válidos e corretos sem precisar acreditar em nenhuma outra entidade. Esta cópia local do blockchain, além de seu estado associado e do recebimento de dados tomam muito espaço no disco rígido do nódulo. Por exemplo, um disco rígido de 2TB é recomendado para rodar um nó utilizando [Geth](https://geth.ethereum.org) pareado com um cliente de consenso. Usando sincronização instantânea, que armazena apenas dados da cadeia de um conjunto de blocos relativamente recente, Geth tipicamente ocupa cerca de 650GB de espaço em disco, mas cresce cerca de 14GB/semana (você pode podar o nó de volta a 650GB periodicamente). -Isto significa que rodar nódulos pode ser caro, porque uma grande quantidade de espaço em disco tem de ser dedicada ao Ethereum. Há diversas soluções para este problema no roadmap do Ethereum, incluindo [expiração de histórico](/roadmap/statelessness/#history-expiry), [expiração de estado](/roadmap/statelessness/#state-expiry) e [falta de estado](/roadmap/statelessness/). Entretanto, ainda há muito até que eles sejam implementados. Há também [nódulos leves](/developers/docs/nodes-and-clients/light-clients/) que não gravam suas próprias cópias dos dados da cadeia, eles solicitam os dados que eles precisam dos nódulos completos. Entretanto, isso significa que nódulos leves tem que acreditar em nódulos completos para fornecer dados honestos e também estressa os nódulos completos que tem que servir os dados para as necessidades dos nódulos leves. +Isto significa que rodar nódulos pode ser caro, porque uma grande quantidade de espaço em disco tem de ser dedicada ao Ethereum. Existem várias soluções para esse problema no planejamento do Ethereum, incluindo [expiração de histórico](/roadmap/statelessness/#history-expiry), [expiração de estado](/roadmap/statelessness/#state-expiry) e [ausência de estado](/roadmap/statelessness/). Entretanto, ainda há muito até que eles sejam implementados. Existem também [nós leves](/developers/docs/nodes-and-clients/light-clients/) que não salvam sua própria cópia dos dados da cadeia, eles solicitam os dados de que precisam de nós completos. Entretanto, isso significa que nódulos leves tem que acreditar em nódulos completos para fornecer dados honestos e também estressa os nódulos completos que tem que servir os dados para as necessidades dos nódulos leves. A Rede Portal visa fornecer uma maneira alternativa para nós leves terem seus dados que sem requerer confiança ou adicionar significantemente ao trabalho que tem de ser feito pelos nós completos. Isto será feito com a introdução de uma nova maneira dos nós Ethereum compartilharem dados através da rede. ## Como a Rede Portal funciona? {#how-does-portal-network-work} -Nós Ethereum tem protocolos estritos que definem como eles se comunicam com os outros. Clientes de execução se comunicam usando um conjunto de sub-protocolos conhecidos como [DevP2P](/developers/docs/networking-layer/#devp2p), enquanto clientes de consenso usam uma pilha diferente de sub-protocolos chamada [libP2P](/developers/docs/networking-layer/#libp2p). Eles definem os tipos de dados que podem ser passados entre nós. +Nós Ethereum tem protocolos estritos que definem como eles se comunicam com os outros. Clientes de execução se comunicam usando um conjunto de subprotocolos conhecido como [DevP2P](/developers/docs/networking-layer/#devp2p), enquanto os clientes de consenso usam uma pilha diferente de subprotocolos chamada [libP2P](/developers/docs/networking-layer/#libp2p). Eles definem os tipos de dados que podem ser passados entre nós. ![devP2P e libP2P](portal-network-devp2p-libp2p.png) -Os nós podem também servir dados específicos através da [API JSON-RPC](/developers/docs/apis/json-rpc/), que é como apps e carteiras trocam informações com os nós Ethereum. Entretanto, nenhum destes são protocolos ideias para servir dados para clientes leves. +Os nós também podem servir dados específicos através da [API JSON-RPC](/developers/docs/apis/json-rpc/), que é como os aplicativos e carteiras trocam informações com os nós do Ethereum. Entretanto, nenhum destes são protocolos ideias para servir dados para clientes leves. Clientes leves não podem atualmente requisitar pedaços específicos da cadeia de dados pelo DevP2P ou libP2P, porque estes protocolos são desenhados somente para habilitar sincronização de cadeias e transmissão de blocos e transações. Clientes leves não querem fazer o download desta informação, porque deixariam de ser 'leves'. @@ -36,7 +36,7 @@ A API JSON-RPC não é a escolha ideal para requisições de dados de clientes l A meta da Rede Portal é repensar todo o desenho, construindo especificamente para leveza, fora das limitações de desenho dos clientes Ethereum existentes. -A ideia central da Rede Portal é pegar os melhores bits da pilha da rede atual habilitando informações necessárias pelos clientes leves, como dados históricos e a identidade da cabeça atual da cadeia para ser servida através de um estilo DevP2P peso leve ponto-a-ponto em uma rede descentralizada, usando um [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (similar à Bittorrent). +A ideia principal da Portal Network é aproveitar as melhores partes da pilha de rede atual, permitindo que informações necessárias para clientes leves, como dados históricos e a identidade do cabeçalho atual da cadeia, sejam servidas através de uma rede descentralizada ponto a ponto leve, no estilo DevP2P, usando uma [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (semelhante ao Bittorrent). A ideia é adicionar pequenas partes do histórico de dados total do Ethereum e algumas responsabilidades específicas de nós para cada nó. Então, requisições são servidas procurando os nós que armazenam o dado específico que foi requisitado e recuperando-o deles. @@ -57,27 +57,33 @@ Os benefícios deste desenho de rede são: - minimizar ou zerar a sincronia - Acessível a dispositivos com recursos limitados (\<1 GB de RAM, \<100 MB de espaço em disco, 1 CPU) -O diagrama abaixo mostra as funções dos clientes existentes que podem ser entregues pela Rede Portal, habilitando ao usuários acessar estas funções em dispositivos com muito poucos recursos. +A tabela abaixo mostra as funções dos clientes existentes que podem ser oferecidas pela Portal Network, permitindo que os usuários acessem essas funções em dispositivos com pouquíssimos recursos. -![tabela rede portal](portal-network-table2.png) +### The Portal Networks -## Diversidade de cliente por padrão {#client-diversity-as-default} +| Beacon light client | State network | Propagação de Transações | History network | +| ------------------- | ---------------------------- | ------------------------ | --------------- | +| Beacon chain light | Account and contract storage | Lightweight mempool | Headers | +| Protocol data | | | Block bodies | +| | | | Receipts | -Os desenvolvedores da Rede Portal também fizeram com que o design assumido construísse três clientes separados na Rede Portal desde o primeiro dia. +## Diversidade de clientes por padrão {#client-diversity-as-default} + +Os desenvolvedores da Portal Network também fizeram a escolha de design de construir quatro clientes da Portal Network separados desde o primeiro dia. Os clientes da Rede Portal são: - [Trin](https://github.com/ethereum/trin): escrito em Rust -- [Fluffy](https://nimbus.team/docs/fluffy.html): escrito em Nim +- [Fluffy](https://fluffy.guide): escrito em Nim - [Ultralight](https://github.com/ethereumjs/ultralight): escrito em Typescript -- [Shisui](https://github.com/GrapeBaBa/shisui): escrito em Go +- [Shisui](https://github.com/zen-eth/shisui): escrito em Go Ter várias implementações de clientes independentes melhora a resiliência e descentralização da rede Ethereum. Se um cliente enfrenta problemas de vulnerabilidades, outros clientes podem continuar a operar tranquilamente, evitando o ponto único de falha. Adicionalmente, diversidade na implementação de clientes fomenta inovação e competição, conduzindo melhorias e reduzindo risco de monocultura dentro do ecossistema. -## Leitura adicional {#futher-reading} +## Leitura adicional {#further-reading} -- [A Rede Portal (Piper Merriam na Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA). -- [O desacordo da Rede Portal](https://discord.gg/CFFnmE7Hbs) -- [O website da Rede Portal](https://www.ethportal.net/) +- [A Portal Network (Piper Merriam na Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA). +- [Discord da Portal Network](https://discord.gg/CFFnmE7Hbs) +- [Site da Portal Network](https://www.ethportal.net/) diff --git a/public/content/translations/pt-br/developers/docs/networks/index.md b/public/content/translations/pt-br/developers/docs/networks/index.md index 31fafe90f64..5c2d50d1d21 100644 --- a/public/content/translations/pt-br/developers/docs/networks/index.md +++ b/public/content/translations/pt-br/developers/docs/networks/index.md @@ -1,6 +1,6 @@ --- title: Redes -description: Uma visão geral das redes Ethereum e onde obter ether (ETH) da rede de testes para testar seu aplicativo. +description: "Uma visão geral das redes Ethereum e onde obter ether (ETH) da rede de testes para testar seu aplicativo." lang: pt-br --- @@ -10,19 +10,19 @@ Sua conta Ethereum funcionará nas diferentes redes, mas o saldo da sua conta e ## 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. +Você deve entender os [conceitos básicos 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 experimentar. ## 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} +### Mainnet do 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} +### Redes de teste do 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. @@ -34,19 +34,15 @@ ETH em redes de teste (testnets) supostamente não tem valor real; entretanto, t #### 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 Hoodi. Sepolia é uma rede para desenvolvedores de contrato e aplicativos para testar seus aplicativos. A rede Hoodi permite que os desenvolvedores de protocolo testem atualizações de rede e permite que os participantes façam testes usando validadores. +As duas redes de teste públicas que os desenvolvedores do cliente estão mantendo atualmente são Sepolia e Hoodi. Sepolia é uma rede para desenvolvedores de contrato e aplicativos para testar seus aplicativos. A rede Hoodi permite que desenvolvedores de protocolo testem atualizações de rede e que stakers testem validadores em execução. #### 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 +**Sepolia é a rede de teste padrão recomendada para desenvolvimento de aplicativos**. A rede Sepolia usa um conjunto de validadores permissionado controlado por equipes de clientes e de testes. ##### Recursos -- [Website](https://sepolia.dev/) +- [Site](https://sepolia.dev/) - [GitHub](https://github.com/eth-clients/sepolia) - [Otterscan](https://sepolia.otterscan.io/) - [Etherscan](https://sepolia.etherscan.io) @@ -54,22 +50,22 @@ As duas redes de testes públicas que os desenvolvedores dos clientes estão atu ##### Faucets -- [Faucet do QuickNode Sepolia](https://faucet.quicknode.com/drip) +- [Faucet da Sepolia da Alchemy](https://www.alchemy.com/faucets/ethereum-sepolia) +- [Faucet da Sepolia da Chain Platform](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) +- [Faucet da Sepolia da Chainstack](https://faucet.chainstack.com/sepolia-testnet-faucet) +- [Faucet do Ecossistema Ethereum](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [Faucet da Sepolia ethfaucet.com](https://ethfaucet.com/networks/ethereum) +- [Faucet da Sepolia do Google Cloud Web3](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) - [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-testnet-faucet) -- [Faucet do ecossistema Ethereum](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [Faucet da Sepolia da Infura](https://www.infura.io/faucet) +- [Faucet PoW](https://sepolia-faucet.pk910.de/) +- [Faucet da Sepolia do QuickNode](https://faucet.quicknode.com/ethereum/sepolia) #### Hoodi {#hoodi} -_Nota: [a rede de testes Goerli está obsoleta](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) e foi substituída por Hoodi. Considere migrar seus aplicativos para a Sepolia._ - -Hoodi é a rede de testes usada para testar a validação e staking. A rede Hoodi 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 Hoodi. +Hoodi é uma testnet para testes de validação e staking. A rede Hoodi está aberta para usuários que desejam executar um validador na rede de testes. Os participantes que desejam testar atualizações de protocolo antes de implantá-las na rede principal devem usar o Hoodi. -- Conjunto de validadores abertos, com o qual os participantes podem testar atualizações de rede +- Conjunto de validadores abertos, onde participantes podem testar atualizações da rede - Estado grande, útil para testar interações complexas de contratos inteligentes - Mais longo para sincronizar e requer mais armazenamento para executar um nó @@ -77,48 +73,102 @@ Hoodi é a rede de testes usada para testar a validação e staking. A rede Hood - [Site](https://hoodi.ethpandaops.io/) - [GitHub](https://github.com/eth-clients/hoodi) -- [Explorer](https://explorer.hoodi.ethpandaops.io/) -- [Checkpoint Sync](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Explorador](https://explorer.hoodi.ethpandaops.io/) +- [Sincronização de Checkpoint](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Otterscan](https://hoodi.otterscan.io/) +- [Etherscan](https://hoodi.etherscan.io/) ##### Faucets -- [Faucet Hoodi](https://hoodi.ethpandaops.io/) +- [Faucet da Hoodi da Chain Platform](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) +- [Faucet da Hoodi](https://hoodi.ethpandaops.io/) +- [Faucet PoW](https://hoodi-faucet.pk910.de/) + +#### Ephemery {#ephemery} + +Ephemery é um tipo exclusivo de rede de testes que é totalmente reiniciada todo mês. O estado de execução e consenso retorna ao estado de gênese a cada 28 dias, o que significa que tudo o que acontece na rede de teste é efêmero. Isso o torna ideal para testes de curto prazo, bootstrap rápido de nós e aplicativos do tipo "olá, mundo" que não precisam de permanência. + +- Estado sempre novo, testes de curto prazo de validadores e aplicativos +- Inclui apenas o conjunto básico de contratos +- Conjunto de validadores abertos e fácil acesso a grandes quantias de fundos +- Menores requisitos de nó e sincronização mais rápida, <5GB em média + +##### Recursos + +- [Site](https://ephemery.dev/) +- [GitHub](https://github.com/ephemery-testnet/ephemery-resources) +- [Chat da comunidade](https://matrix.to/#/#staker-testnet:matrix.org) +- [Blockscout](https://explorer.ephemery.dev/) +- [Otterscan](https://otter.bordel.wtf/) +- [Explorador da Beacon](https://beaconlight.ephemery.dev/) +- [Sincronização de Checkpoint](https://checkpoint-sync.ephemery.ethpandaops.io) +- [Plataforma de lançamento](https://launchpad.ephemery.dev/) -Para iniciar um Validador na rede de testes Hoodi, use a [plataforma de lançamento Hoodi](https://hoodi.launchpad.ethereum.org/en/). +#### Faucets -### Redes de testes de camada 2 {#layer-2-testnets} +- [Faucet Bordel](https://faucet.bordel.wtf/) +- [Faucet PoW Pk910](https://ephemery-faucet.pk910.de/) + +#### Holesky (obsoleta) {#holesky} + +A rede de teste Holesky está obsoleta a partir de setembro de 2025. Operadores de staking e provedores de infraestrutura devem usar Hoodi para testes de validadores. + +- [Anúncio de Desligamento da Rede de Teste Holesky](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _Blog da EF, 1 de setembro de 2025_ +- [Atualizações das Redes de Teste Holesky e Hoodi](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) - _Blog da EF, 18 de março de 2025_ + +### Redes de teste 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 Sepolia {#arbitrum-sepolia} -Uma rede de testes para [Arbitrum](https://arbitrum.io/). +Uma rede de teste para o [Arbitrum](https://arbitrum.io/). + +##### Recursos + +- [Etherscan](https://sepolia.arbiscan.io/) +- [Blockscout](https://sepolia-explorer.arbitrum.io/) ##### Faucets -- [Faucet do Chainlink](https://faucets.chain.link/arbitrum-sepolia) -- [Faucet do Alchemy](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Faucet da Arbitrum Sepolia da Alchemy](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Faucet da Arbitrum Sepolia da Chainlink](https://faucets.chain.link/arbitrum-sepolia) +- [Faucet da Arbitrum Sepolia ethfaucet.com](https://ethfaucet.com/networks/arbitrum) +- [Faucet da Arbitrum Sepolia do QuickNode](https://faucet.quicknode.com/arbitrum/sepolia) #### Optimistic Sepolia {#optimistic-sepolia} -Uma rede de testes para [Optimism](https://www.optimism.io/). +Uma rede de teste para o [Optimism](https://www.optimism.io/). + +##### Recursos + +- [Etherscan](https://sepolia-optimistic.etherscan.io/) +- [Blockscout](https://optimism-sepolia.blockscout.com/) ##### Faucets -- [Faucet do Chainlink](https://faucets.chain.link/optimism-sepolia) -- [Faucet do Alchemy](https://www.alchemy.com/faucets/optimism-sepolia) +- [Faucet da Alchemy](https://www.alchemy.com/faucets/optimism-sepolia) +- [Faucet da Chainlink](https://faucets.chain.link/optimism-sepolia) +- [Faucet da Optimism Sepolia ethfaucet.com](https://ethfaucet.com/networks/optimism) +- [Faucet da rede de teste](https://docs.optimism.io/builders/tools/build/faucets) #### Starknet Sepolia {#starknet-sepolia} -Uma rede de teste para [Starknet](https://www.starknet.io). +Uma rede de teste para a [Starknet](https://www.starknet.io). + +##### Recursos + +- [Starkscan](https://sepolia.starkscan.co/) ##### Faucets -- [Faucet do Alchemy](https://www.alchemy.com/faucets/starknet-sepolia) +- [Faucet da Alchemy](https://www.alchemy.com/faucets/starknet-sepolia) +- [Faucet da Starknet Sepolia do Blast](https://blastapi.io/faucets/starknet-sepolia-eth) +- [Faucet da Starknet](https://starknet-faucet.vercel.app/) ## 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. +Uma rede Ethereum é uma rede privada se seus nós não estiverem conectados a uma rede pública (ou seja, a Mainnet ou uma rede de teste). Neste contexto, privado significa apenas reservado ou isolado, em vez de protegido ou seguro. ### Redes de desenvolvimento {#development-networks} @@ -132,12 +182,35 @@ O processo de consenso é controlado por um conjunto predefinido de nódulos con Se uma rede pública Ethereum é como a internet pública, uma rede de consórcio é como uma intranet privada. +## Por que as redes de teste do Ethereum recebem nomes de estações de metrô? {#why-naming} + +Muitas redes de teste do Ethereum recebem nomes de estações de metrô ou de trem do mundo real. Essa tradição de nomenclatura começou cedo e reflete as cidades globais onde os contribuidores viveram ou trabalharam. É simbólico, memorável e prático. Assim como as redes de teste são isoladas da mainnet do Ethereum, as linhas de metrô funcionam separadamente do tráfego da superfície. + +### Redes de teste legadas e de uso comum {#common-and-legacy-testnets} + +- **Sepolia** - Um bairro conectado por metrô em Atenas, Grécia. Atualmente usada para testes de contratos inteligentes e dApps. +- **Hoodi** - Nomeada em homenagem à estação de metrô Hoodi em Bengaluru, Índia. Usada para testes de validadores e de atualização de protocolo. +- **Goerli** _(obsoleta)_ - Nomeada em homenagem a Görlitzer Bahnhof em Berlim, Alemanha. +- **Rinkeby** _(obsoleta)_ - Nomeada em homenagem a um subúrbio de Estocolmo com uma estação de metrô. +- **Ropsten** _(obsoleta)_ - Refere-se a uma área e antigo terminal de balsa/metrô em Estocolmo. +- **Kovan** _(obsoleta)_ - Nomeada em homenagem a uma estação MRT de Singapura. +- **Morden** _(obsoleta)_ - Nomeada em homenagem a uma estação do metrô de Londres. A primeira rede de teste pública do Ethereum. + +### Outras redes de teste especializadas {#other-testnets} + +Algumas redes de teste foram criadas para testes de curto prazo ou específicos de atualização e não são necessariamente temáticas de metrô: + +- **Holesky** _(obsoleta)_ - Nomeada em homenagem à estação Holešovice em Praga. Usada para testes de validadores; obsoleta em 2025. +- **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(todas obsoletas)_ e **Ephemery** - Construídas especificamente para simulações de atualização como A Fusão, Xangai ou experimentos de validadores. Alguns nomes são regionais ou temáticos, em vez de baseados em metrô. + +O uso de nomes de estações de metrô ajuda os desenvolvedores a identificar e lembrar rapidamente as redes de teste sem precisar depender de IDs de cadeia numéricos. Isso também reflete a cultura do Ethereum: prática, global e centrada no ser humano. + ## 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_ +- [Chainlist](https://chainlist.org/) _lista de redes EVM para conectar carteiras e provedores aos IDs de cadeia e de rede apropriados_ +- [Cadeias baseadas em EVM](https://github.com/ethereum-lists/chains) _repositório do GitHub com metadados de cadeias que alimenta o 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/) +- [Proposta: Ciclo de vida previsível da rede de teste do Ethereum](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) +- [A Evolução das Redes de Teste do Ethereum](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/pt-br/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/archive-nodes/index.md index ee85cd86aab..f87427b6af7 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/archive-nodes/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -1,6 +1,6 @@ --- -title: Nó de arquivo Ethereum -description: Uma visão geral dos nós de arquivo +title: "Nó de arquivo Ethereum" +description: "Uma visão geral dos nós de arquivo" lang: pt-br sidebarDepth: 2 --- @@ -9,21 +9,21 @@ Um nó de arquivo é uma instância de um cliente Ethereum configurado para cons ## 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/). +Você deve entender o conceito de um [nó Ethereum](/developers/docs/nodes-and-clients/), [sua arquitetura](/developers/docs/nodes-and-clients/node-architecture/), [estratégias de sincronização](/developers/docs/nodes-and-clients/#sync-modes), práticas de [executá-los](/developers/docs/nodes-and-clients/run-a-node/) e [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: +Para compreender a importância de um nó de arquivo, vamos esclarecer o conceito de "estado". O Ethereum pode ser chamado de uma _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. +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 estado mais recente da rede, mas armazena em cache apenas alguns dos estados passados, por exemplo, o estado associado aos últimos 128 blocos, para que possa lidar com as reorganizações da cadeia e fornecer acesso rápido aos 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. +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. Estados que existiram antes de um bloco recente (por exemplo, 128 blocos antes do cabeçalho) são efetivamente descartados. 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. @@ -35,10 +35,10 @@ O uso regular do Ethereum, como envio de transações, implantação de contrato 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 era o saldo de ETH da conta 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: +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 servem respostas imediatamente. Este é um recurso útil para certas partes da infraestrutura, por exemplo: - Provedores de serviços como exploradores de blocos - Pesquisadores @@ -46,35 +46,36 @@ Conforme explicado acima, um nó completo precisaria gerar esses dados pela exec - 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. +Existem vários [serviços](/developers/docs/nodes-and-clients/nodes-as-a-service/) gratuitos que também permitem o 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. +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 estão otimizados para este 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). +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 os [principais recursos](https://github.com/ledgerwatch/erigon#key-features) do Erigon, a abordagem mais prática é usar a implementação do cliente [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. +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. 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. 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. +Todos os dados precisam caber em um único volume, portanto, os discos precisam ser unidos, por exemplo, com [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) ou LVM. 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 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. +Para maior estabilidade e segurança na prevenção da corrupção acidental do banco de dados, especialmente em uma configuração profissional, considere o uso de [memória ECC](https://en.wikipedia.org/wiki/ECC_memory) se o seu sistema for compatível. 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_ +- [Nó completo Ethereum vs Nó de arquivamento](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode, setembro de 2022_ +- [Construindo seu próprio nó de arquivamento 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 (scrape 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/) +- [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/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/bootnodes/index.md index 20511b0ae30..172fee784da 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/bootnodes/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/bootnodes/index.md @@ -1,6 +1,6 @@ --- -title: Introdução aos bootnodes Ethereum -description: As informações básicas de que você precisa para entender os bootnodes +title: "Introdução aos bootnodes Ethereum" +description: "As informações básicas de que você precisa para entender os bootnodes" lang: pt-br --- @@ -8,7 +8,7 @@ Quando um novo nó se junta à rede Ethereum, ele precisa se conectar aos nós q ## 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): +A maioria dos clientes tem uma lista de bootnodes embutida, mas você também pode querer executar seu próprio bootnode, ou usar um que não faz 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://@:" @@ -16,9 +16,9 @@ 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. +Bootnodes são nós completos que não estão por trás de um NAT ([Traduçã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ó. +Quando você inicia um nó, ele deve registrar 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. @@ -26,6 +26,6 @@ Para ter um bom bootnode, recomenda-se aumentar o número máximo de pares que p ## 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. +Uma lista de bootnodes integrados no 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/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/client-diversity/index.md index 6afc3cddb5d..27b79d91ec1 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/client-diversity/index.md @@ -1,6 +1,6 @@ --- title: Diversidade dos clientes -description: Uma explicação de alto nível sobre a importância da diversidade de clientes do Ethereum. +description: "Uma explicação de alto nível sobre a importância da diversidade de clientes do Ethereum." lang: pt-br sidebarDepth: 2 --- @@ -9,7 +9,7 @@ O comportamento de um nó Ethereum é controlado pelo software do cliente que el ## 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. +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 de [consenso](/glossary/#consensus-layer) são definidas no glossário. ## Por que existem vários clientes? {#why-multiple-clients} @@ -25,13 +25,13 @@ Um bug em um cliente individual é um risco menor para a rede ao representar uma ### 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. +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 tem poucas chances de ser bem-sucedido, pois é improvável que outros clientes sejam exploráveis da mesma forma e a cadeia canônica permanece incorrupta. 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 de Xangai em 2016 foi possível porque os invasores conseguiram 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). + 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, levando a um grande conjunto de validadores que ficariam 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. @@ -39,45 +39,66 @@ Embora estes sejam cenários improváveis, o ecossistema Ethereum pode mitigar s 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} +## Diversidade atual de clientes {#current-client-diversity} -![Gráfico de pizza mostrando a diversidade do cliente](./client-diversity.png) _Dados do diagrama de [ethernodes.org](https://ethernodes.org) e [clientdiversity.org](https://clientdiversity.org/)_ +### Clientes de Execução {#execution-clients-breakdown} -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. +### Clientes de Consenso {#consensus-clients-breakdown} -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. +Este diagrama pode estar desatualizado — acesse [ethernodes.org](https://ethernodes.org) e [clientdiversity.org](https://clientdiversity.org) para obter informações atualizadas. -## Use um cliente minoritário {#use-minority-client} +Os dois gráficos de pizza acima mostram um panorama da diversidade atual de clientes para as camadas de execução e de consenso (no momento da redação, em outubro de 2025). A diversidade de clientes melhorou ao longo dos anos, e a camada de execução viu uma redução no domínio do [Geth](https://geth.ethereum.org/), com o [Nethermind](https://www.nethermind.io/nethermind-client) em segundo lugar, o [Besu](https://besu.hyperledger.org/) em terceiro e o [Erigon](https://github.com/ledgerwatch/erigon) em quarto, com outros clientes compreendendo menos de 3% da rede. O cliente mais comumente usado na camada de consenso — [Lighthouse](https://lighthouse.sigmaprime.io/) — está bem próximo do segundo mais usado. [Prysm](https://prysmaticlabs.com/#projects) e [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) representam ~31% e ~14%, respectivamente, e outros clientes são raramente usados. -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. +Os dados da camada de execução foram obtidos de [supermajority.info](https://supermajority.info/) em 26 de outubro de 2025. 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 às vezes confunde alguns dos clientes minoritários (veja mais detalhes [aqui](https://twitter.com/sproulM_/status/1440512518242197516)). No diagrama acima, essas classificações ambíguas são tratadas com um rótulo do tipo ou/ou (p. ex., Nimbus/Teku). No entanto, é claro que a maior parte da rede está executando o Prysm. Apesar de serem apenas capturas, os valores no diagrama fornecem uma boa noção geral do estado atual da diversidade do cliente. -### Clientes de execução {#execution-clients} +Dados atualizados sobre a diversidade de clientes para a camada de consenso estão agora disponíveis em [clientdiversity.org](https://clientdiversity.org/). -[Besu](https://www.hyperledger.org/use/besu) - -[Nethermind](https://downloads.nethermind.io/) - -[Erigon](https://github.com/ledgerwatch/erigon) +## Camada de execução {#execution-layer} -[Go-Ethereum](https://geth.ethereum.org/) +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) representa atualmente 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. -### Clientes de consenso {#consensus-clients} +## Use um cliente minoritário {#use-minority-client} -[Nimbus](https://nimbus.team/) +Endereçar a diversidade do cliente requer mais do que usuários individuais para escolher clientes minoritários – requer pools de 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. -[Lighthouse](https://github.com/sigp/lighthouse) +### Clientes de execução {#execution-clients} -[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) -[Lodestar](https://github.com/ChainSafe/lodestar) +### Clientes de consenso {#consensus-clients} -[Prysm](https://prysm.offchainlabs.com/docs/) +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) 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/). @@ -88,7 +109,9 @@ Vários painéis fornecem estatísticas de diversidade de cliente em tempo real **Camada de consenso:** - [Rated.network](https://www.rated.network/) -- [clientdiversity.org](https://clientdiversity.org/) **Camada de execução:** +- [clientdiversity.org](https://clientdiversity.org/) + +**Camada de execução:** - [supermajority.info](https://supermajority.info//) - [Ethernodes](https://ethernodes.org/) @@ -96,14 +119,14 @@ Vários painéis fornecem estatísticas de diversidade de cliente em tempo real ## 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) +- [Ethereum Merge: Use 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 Fiest, 24 de março de 2022_ +- [Importância da diversidade de clientes](https://our.status.im/the-importance-of-client-diversity/) +- [Lista de serviços de nós Ethereum](https://ethereumnodes.com/) +- [Os "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/) +- [Execute um nó Ethereum](/run-a-node/) - [Nós e clientes](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/pt-br/developers/docs/nodes-and-clients/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/index.md index 7b84fb8b028..ef65a88db65 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/index.md @@ -1,6 +1,6 @@ --- -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. +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 --- @@ -9,9 +9,9 @@ O Ethereum é uma rede distribuída de computadores (conhecidos como nós) execu ## 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/). +Você deve entender o conceito de uma rede ponto a ponto e os [fundamentos da EVM](/developers/docs/evm/) antes de se aprofundar e executar sua própria instância de um cliente Ethereum. Dê uma olhada em 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). +Se você é novo no tópico de nós, recomendamos primeiro conferir nossa introdução amigável sobre [como executar um nó do Ethereum](/run-a-node). ## O que são nós e clientes? {#what-are-nodes-and-clients} @@ -20,40 +20,44 @@ Um "nó" é qualquer instância de software do cliente Ethereum que esteja conec - 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/). +Estes clientes trabalham juntos para manter rastreabilidade da cabeça da cadeia Ethereum e permitir usuários interagir com a rede Ethereum. O design modular com várias peças de software trabalhando juntas é chamado de [complexidade encapsulada](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Essa abordagem tornou mais fácil executar [A Fusão](/roadmap/merge) de forma transparente, facilita a manutenção e o desenvolvimento do software do cliente e permite a reutilização de clientes individuais, por exemplo, no [ecossistema de camada 2](/layer-2/). -![Execução de acoplamento e clientes de consenso](./eth1eth2client.png) Diagrama simplificado de uma execução associada e de um cliente de consenso. +![Clientes de execução e de consenso acoplados](./eth1eth2client.png) +Diagrama simplificado de um cliente de execução e de consenso acoplado. -### Diversidade dos clientes {#client-diversity} +### Diversidade de 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. +Tanto os [clientes de execução](/developers/docs/nodes-and-clients/#execution-clients) quanto os [clientes de consenso](/developers/docs/nodes-and-clients/#consensus-clients) existem em uma variedade de linguagens de programação desenvolvidas por equipes diferentes. -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. +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/). +Saiba mais sobre a [diversidade de clientes](/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) +- Originalmente, o [Livro Amarelo do Ethereum](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](/ethereum-forks/) +- [EIPs](https://eips.ethereum.org/) implementados em várias [melhorias da rede](/ethereum-forks/) -### Rastreamento de nós na rede {#network-overview} +### Rastreando 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 +- [Mapa de nós](https://etherscan.io/nodetracker) da Etherscan +- [Ethernodes](https://ethernodes.org/) da Bitfly +- [Nodewatch](https://www.nodewatch.io/) da Chainsafe, rastreando nós de consenso +- [Monitoreth](https://monitoreth.io/) - da MigaLabs, uma ferramenta de monitoramento de rede distribuída +- [Relatórios Semanais de Saúde da Rede](https://probelab.io) - da ProbeLab, usando o [rastreador Nebula](https://github.com/dennis-tra/nebula) e outras ferramentas ## 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. +Se você quiser [executar seu próprio nó](/developers/docs/nodes-and-clients/run-a-node/), deve entender que existem diferentes tipos de nó que consomem dados de maneiras diferentes. 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. +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. Existem diferentes classes de nó completo - alguns começam a partir do bloco gênese e verificam cada bloco em todo o histórico da cadeia de blocos. Outros começam a verificação a partir de um bloco mais recente que consideram válido (p. ex., o 'snap sync' do Geth). Independentemente de onde a verificação começa, os nós completos mantêm apenas uma cópia local de dados relativamente recentes (normalmente os 128 blocos mais recentes), permitindo que dados mais antigos sejam 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. @@ -64,60 +68,61 @@ Nós completos fazem uma validação bloco-a-bloco do blockchain, incluindo baix 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. +- Armazena tudo o que é mantido no nó completo e constrói um arquivo de estados históricos. É necessário se você quiser consultar algo como um saldo de conta no bloco #4.000.000, ou simplesmente testar de forma confiável seu próprio conjunto de transações sem validá-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). +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. +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, não podem ser validadores), mas podem acessar a cadeia de blocos do Ethereum com a mesma funcionalidade e garantias de segurança que 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. +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 potenciais 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. +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/), [Helios](https://github.com/a16z/helios) e [LodeStar](https://lodestar.chainsafe.io/) estão atualmente muito focados 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} +### Benefícios 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 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 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. +- Você pode fornecer seus próprios [endpoints de 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 (ou seja, frontrunning). +- Você pode colocar ETH diretamente para proteger a rede e ganhar recompensas. Veja [staking solo](/staking/solo/) para começar. -![Como você acessar o Ethereum através do seu aplicativo e nós](./nodes.png) +![Como você acessa o Ethereum por meio de seu aplicativo e nós](./nodes.png) ### 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. +- No caso de um ataque que supere as defesas criptoeconômicas da [prova de participação](/developers/docs/consensus-mechanisms/pos/#what-is-pos), uma recuperação social pode ser realizada por nós completos que escolherem 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. +- Nós completos fornecem acesso a dados do blockchain para clientes leves que dependem disso. Nós leves não armazenam toda a cadeia de blocos, em vez disso, eles verificam dados por meio das [raízes de estado nos cabeçalhos de bloco](/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} +## Executar 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. +Para uma introdução amigável para iniciantes, visite 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/). +Se você for um usuário mais técnico, mergulhe em mais detalhes e opções sobre como [criar 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/). +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 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. @@ -125,20 +130,20 @@ Por outro lado, se você executar um cliente, você pode compartilhá-lo com que ## 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. +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 mais [diversa](/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. +Essa tabela resume os diferentes clientes. Todos eles passam nos [testes de cliente](https://github.com/ethereum/tests) e são mantidos ativamente para se manterem atualizados com as melhorias da rede. -| 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 | +| Client | Linguagem de programação | Sistemas operacionais | Redes | Estratégias de sincronização | State pruning | +| ------------------------------------------------------------------------------------------- | ------------------------ | --------------------- | -------------------------------- | ---------------------------------------------------------------------------------- | ----------------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Rede Principal, Sepolia, Holesky | [Snap](#snap-sync), [Completa](#full-sync) | Arquivo, Removido | +| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Rede Principal, Sepolia, Holesky | [Snap](#snap-sync) (sem servir), Rápida, [Completa](#full-sync) | Arquivo, Removido | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Rede Principal, Sepolia, Holesky | [Snap](#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 | [Completa](#full-sync) | Arquivo, Removido | +| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Rede Principal, Sepolia, Holesky | [Completa](#full-sync) | Arquivo, Removido | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | Linux, Windows, macOS | Sepolia, Holesky | [Completa](#full-sync) | Removido | -Para saber mais sobre redes suportadas, leia sobre as [redes Ethereum](/developers/docs/networks/). +Para saber mais sobre as redes compatíveis, 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. @@ -156,7 +161,7 @@ Erigon, anteriormente conhecido como Turbo-Geth, começou como uma bifurcação 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/). +Saiba mais sobre o Geth em sua [documentação](https://geth.ethereum.org/docs/). ### Nethermind {#nethermind} @@ -166,7 +171,7 @@ Nethermind é uma implementação do Ethereum criada com a pilha de tecnologia C - 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. +O Nethermind também tem [documentação detalhada](https://docs.nethermind.io), forte suporte para desenvolvedores, uma comunidade online e suporte 24/7 disponível para usuários premium. ### Reth {#reth} @@ -174,7 +179,7 @@ O Reth (abreviação de Rust Ethereum) é uma implementação de nó completo do 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). +Saiba mais consultando o [Reth Book](https://reth.rs/) ou o [repo GitHub do Reth](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth). ### Em desenvolvimento {#execution-in-development} @@ -184,37 +189,38 @@ Esses clientes ainda estão em estágios iniciais de desenvolvimento e ainda nã 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 +Saiba mais sobre ele lendo sua [documentação](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) ## 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). +Existem vários clientes de consenso (anteriormente conhecidos como clientes 'Eth2') para dar suporte às [melhorias de consenso](/roadmap/beacon-chain/). Eles são responsáveis por toda a lógica relacionada ao consenso, incluindo o algoritmo de escolha de bifurcação, o processamento de atestações e o gerenciamento de recompensas e penalidades da [prova de participação](/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://prysm.offchainlabs.com/docs/) | 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 | +| Client | Linguagem de programação | Sistemas operacionais | Redes | +| ------------------------------------------------------------- | ------------------------ | --------------------- | ------------------------------------------------------ | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Holesky, Pyrmont, Sepolia e mais | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Beacon Chain, Holesky, Sepolia e mais | +| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Holesky, Sepolia e mais | +| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Holesky, Pyrmont, Sepolia e mais | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Holesky, Sepolia e mais | +| [Grandine](https://docs.grandine.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Holesky, Sepolia 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/) +A documentação pode ser encontrada no [Lighthouse Book](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/) +Mais informações podem ser encontradas no [site do 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/) +Saiba mais na [documentação do Nimbus](https://nimbus.guide/) ### Prysm {#prysm} @@ -226,17 +232,23 @@ Visite a [documentação do Prysm](https://prysm.offchainlabs.com/docs/) para sa 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 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 segurança da chave de assinatura e proteção contra slashing. 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/). +### Grandine {#grandine} + +Grandine é uma implementação de cliente de consenso, escrita em Rust sob a licença GPL-3.0. É mantido pela Equipe Central da Grandine e é rápido, de alto desempenho e leve. Ele atende a uma ampla gama de stakers, desde stakers solo utilizando dispositivos de baixa capacidade, como o Raspberry Pi, até grandes instituições que operam dezenas de milhares de validadores. + +A documentação pode ser encontrada no [Grandine Book](https://docs.grandine.io/) + ## 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} +### Modos de sincronização da 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. @@ -247,7 +259,7 @@ Uma sincronização completa faz o download de todos os blocos (incluindo cabeç - 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. +[Nós de arquivo](#archive-node) realizam uma sincronização completa para construir (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} @@ -256,14 +268,14 @@ Assim como uma sincronização completa, uma sincronização rápida baixa todos - 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} +#### Sincronização Snap {#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). +[Mais sobre a sincronização Snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). #### Sincronização leve {#light-sync} @@ -272,30 +284,30 @@ O modo cliente leve baixa todos os cabeçalhos de bloco, dados de bloco e verifi - 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! +**OBS.:** a sincronização leve ainda não funciona com o Ethereum de prova de participação - novas versões da sincronização leve devem 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} +### Modos de sincronização da 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. +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 importar blocos beacon _otimisticamente_ sem verificá-los totalmente, encontrar o cabeçalho mais recente e, em seguida, 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/master/sync/optimistic.md) +[Mais sobre a sincronização otimista](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) -#### Sincronização de ponto de verificação {#checkpoint-sync} +#### Sincronização de checkpoint {#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). +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. É baseada em suposições de [subjetividade fraca](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) que permitem sincronizar a Beacon Chain a partir de um checkpoint recente de subjetividade fraca, em vez do bloco gênese. Sincronizações de checkpoint tornam o tempo de sincronização inicial significativamente mais rápido, com suposições de confiança semelhantes às da sincronização a partir do [bloco 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) +Mais sobre [sincronização de checkpoint](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_ +- [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 de 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} @@ -304,4 +316,4 @@ Mais sobre [sincronização do ponto de verificação](https://notes.ethereum.or ## 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)._ +- [Transforme seu Raspberry Pi 4 em um nó validador simplesmente gravando a imagem no cartão MicroSD – Guia de instalação](/developers/tutorials/run-node-raspberry-pi/) _– Grave a imagem no seu Raspberry Pi 4, conecte um cabo de ethernet, conecte o disco SSD e ligue o dispositivo para transformar o Raspberry Pi 4 em um nó completo do Ethereum, 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/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/light-clients/index.md index 5ed3da6c93c..ef90a8aeed8 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/light-clients/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/light-clients/index.md @@ -1,6 +1,6 @@ --- title: Clientes leves -description: Introdução aos clientes leves Ethereum. +description: "Introdução aos clientes leves Ethereum." lang: pt-br --- @@ -12,7 +12,7 @@ Um nó leve é um nó executando um software de cliente leve. Em vez de manter c ## 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. +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. A forma como 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. @@ -32,7 +32,7 @@ O principal benefício de clientes leves é permitir que mais pessoas acessem o 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! +Uma extensão disso é a habilitação de dispositivos de **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 que você possui o NFT do serviço de aluguel e, em caso afirmativo, destrava uma bicicleta para você sair pedalando! 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. @@ -42,20 +42,20 @@ Os clientes leves também poderiam ser usados para atualizar carteiras Ethereum. 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 +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): cliente de consenso leve em TypeScript +- [Helios](https://github.com/a16z/helios): cliente leve de execução e consenso combinado em Rust +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): modo leve para cliente de execução (em desenvolvimento) em Go +- [Nimbus](https://nimbus.guide/el-light-client.html): cliente de consenso leve em 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. +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, mas no futuro os dados poderão ser solicitados de maneira mais descentralizada usando uma rede dedicada como a [Portal Network](https://www.ethportal.net/) que poderia servir os dados para clientes leves usando um protocolo de gossip 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. +Outros itens do [roteiro](/roadmap/), como árvores Verkle e a [ausência de estado](/roadmap/statelessness/), acabarão por equiparar as garantias de segurança dos clientes leves às dos 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/) +- [Zsolt Felfodhi sobre os clientes leves Geth](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Etan Kissling sobre a rede de clientes leves](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Etan Kissling sobre clientes leves após A Fusão](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Piper Merriam: O caminho sinuoso para clientes leves funcionais](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/pt-br/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/node-architecture/index.md index 4c0b0546fc6..360ef33aac3 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/node-architecture/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/node-architecture/index.md @@ -1,26 +1,28 @@ --- -title: Arquitetura do nó -description: Introdução de como os nós Ethereum são organizados. +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). +Um nó do 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). Para um nó propor um novo bloco, ele também deve executar um [cliente validador](#validators). -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). +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 do Ethereum. No entanto, desde a implementação da [prova de participação](/developers/docs/consensus-mechanisms/pow/), o cliente de execução deve ser usado juntamente com outra parte do software chamada [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. ![Diagrama da arquitetura do nó Ethereum mostrando camadas de execução e consenso](node-architecture-text-background.png) -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). +_Tem várias opções para a execução do cliente, incluindo Erigon, Nethermind e Besu_. + +Para esta estrutura de dois clientes funcionar, os clientes consensuais devem passar os pacotes de transição ao cliente de execução. O cliente de execução realiza as transações localmente para validar que as transações não violem nenhuma regra do Ethereum e que a atualização proposta para o estado do Ethereum esteja correta. Quando um node é selecionado para ser um produtor de blocos sua instância de cliente de consenso solicita pacotes de transações do cliente de execução para incluir no novo bloco e executa-los para atualizar o estado global. O cliente de consenso aciona o cliente de execução por meio de uma conexão RPC local usando a [Engine API](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 é responsável pela validação, manuseio e disseminação de transações, juntamente com o gerenciamento de estado e o suporte à máquina virtual ethereum ([EVM](/developers/docs/evm/)). Ele **não** é responsável pela construção de blocos, pela transmissão de blocos ou pelo 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 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 de transações é feita no computador embutido do cliente de execução, conhecido como a [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. +O cliente de execução também oferece uma interface de usuário para o Ethereum por meio de [métodos RPC](/developers/docs/apis/json-rpc) que permitem aos usuários consultar a blockchain do 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 é: @@ -35,23 +37,23 @@ O cliente de consenso não participa do atestado ou da proposta de blocos — is ## 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. +Fazer o stake e executar o software de validação torna um nó elegível para ser selecionado para propor um novo bloco. 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. Ele também permite que um nó acumule recompensas ou perca ETH por meio de penalidades ou cortes. -[Mais sobre staking](/staking/). +[Mais sobre participação](/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 | | +| 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 controle da aleatoriedade acumulada no RANDAO (um algoritmo que fornece aleatoriedade verificável para seleção de validadores e outras operações de consenso) | 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) +- [Proposta de bloco](/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/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index c3c8158aab5..ac64c92f23a 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -1,23 +1,23 @@ --- -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. +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. +Executar seu próprio [nó Ethereum](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) pode ser desafiador, especialmente ao começar ou durante uma escalada rápida. Há [vários serviços](#popular-node-services) que executam infraestruturas de nós otimizadas para você, para que possa se concentrar no desenvolvimento de seu aplicativo 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/). +Se você ainda não entende o que são nós e clientes, confira [Nós e clientes](/developers/docs/nodes-and-clients/). -## Participantes {#stakoooooooooooooors} +## Stakers {#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. +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 d'[A Fusão](/roadmap/merge), era possível executar apenas um cliente de consenso e usar um provedor centralizado para dados de execução; isso não é mais possível — um staker 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/). +[Leia mais sobre como executar 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. @@ -25,13 +25,13 @@ Os serviços descritos nesta página são para nós não participantes. 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. +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. Eles geralmente incluem acesso a [redes de teste da Ethereum](/developers/docs/networks/#ethereum-testnets) além da Mainnet. 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. +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 de arquivo, além de métodos específicos do cliente em uma única API. É importante notar que os serviços de nós não armazenam nem devem armazenar suas chaves ou informações privadas. @@ -45,14 +45,14 @@ Executar seus próprios nós pode ser muito caro, quer seja de armazenamento, la 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). +Leia mais sobre os [benefícios de executar 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/) + - [Documentação](https://www.alchemy.com/docs/) - 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 @@ -64,9 +64,22 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - 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 +- [**Allnodes**](https://www.allnodes.com/) + - [Documentação](https://docs.allnodes.com/) + - Recursos + - Sem limites de taxa com o token PublicNode criado na página do portfólio da Allnodes. + - Endpoints RPC gratuitos com foco em privacidade (mais de 100 blockchains) no [PublicNode](https://www.publicnode.com) + - Nós dedicados sem limites de taxa para mais de 90 blockchains + - Nós de arquivo dedicados para mais de 30 blockchains + - Disponível em 3 regiões (EUA, UE, Ásia) + - Snapshots para mais de 100 blockchains no [PublicNode](https://www.publicnode.com/snapshots) + - Suporte técnico 24/7 com SLA de disponibilidade de 99.90%-99.98% (depende do plano). + - Valor do pagamento por hora + - Pague com cartão de crédito, PayPal ou Cripto + +- [**All That Node**](https://allthatnode.com/) + - [Documentação](https://docs.allthatnode.com/) + - Recursos - 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 @@ -125,14 +138,14 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - [**BlockPI**](https://blockpi.io/) - [Documentação](https://docs.blockpi.io/) - Recursos - - Estrutura de nós robusta & distribuída + - Estrutura de nós robusta e 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 + - Suporte direto e suporte técnico - [**Chainbase**](https://www.chainbase.com/) - [Documentação](https://docs.chainbase.com) @@ -150,46 +163,46 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Arquivos compartilhados de nós - Suporte ao GraphQL - Pontos de extremidade RPC e WSS - - Nós dedicados completos e arquivados + - Nós dedicados 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 -- [**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 +- [**dRPC**](https://drpc.org/) + - [Documentação](https://drpc.org/docs) + - NodeCloud: Infraestrutura RPC plug-n-play a partir de US$ 10 — velocidade total, sem limites + - Recursos do NodeCloud: + - Suporte de API para 185 redes + - Pool distribuído de mais de 40 provedores + - Cobertura global com nove (9) geo-clusters + - Sistema de balanceamento de carga com tecnologia de IA + - Preço fixo pré-pago — sem aumentos, sem expiração, sem fidelidade + - Chaves ilimitadas, ajustes granulares de chaves, funções de equipe, proteção de front-end + - Taxa fixa de métodos de 20 unidades de computação (CUs) por método + - [Lista de chains de endpoints públicos](https://drpc.org/chainlist) + - [Calculadora de preços](https://drpc.org/pricing#calculator) + - NodeCore: stack de código aberto para organizações que desejam controle total - [**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 + - 40K solicitações diárias grátis - Número ilimitado de chaves de API - Alta velocidade de conexão em 1GB/segundo - - Rastrear+Arquivar + - Rastreamento+Arquivar - Análises avançadas - Atualizações automatizadas - Suporte técnico - [**InfStones**](https://infstones.com/) - Recursos - - Opção de nível gratuito + - Opção de nível livre - Dimensione conforme suas necessidades - Análise - Painel - - Terminais de API únicos + - Pontos de extremidade de API únicos - Nós completos dedicados - Tempo de sincronização rápido para implantações dedicadas - Suporte direto 24/7 @@ -198,7 +211,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - [**Infura**](https://infura.io/) - [Documentação](https://infura.io/docs) - Recursos - - Opção de nível gratuito + - Opção de nível livre - Dimensione conforme suas necessidades - Dados de arquivos pagos - Suporte direto @@ -209,18 +222,18 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - 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) + - Clientes e algoritmos personalizáveis (Geth, Quorum & Besu || PoA, IBFT & 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) + - Ampla coleção de serviços "offchain" 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.) + - Configuração dinâmica de tempo de execução (por exemplo, adição de integrações em nuvem, alteração de entradas de nós, 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 @@ -247,7 +260,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Dimensione conforme suas necessidades - Painel - SDK único do Ethereum - - Terminais de API únicos + - Pontos de extremidade de API únicos - Suporte técnico direto - [**NodeReal MegaNode**](https://nodereal.io/) @@ -259,6 +272,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Comece gratuitamente - [**NOWNodes**](https://nownodes.io/) + - [Documentação](https://documenter.getpostman.com/view/13630829/TVmFkLwy) - Recursos - Acesso a mais de 50 nós da blockchain - Chave de API gratuita @@ -269,15 +283,16 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Nós compartilhados, de arquivo, de cópia de segurança e dedicados - [**Pocket Network**](https://www.pokt.network/) - - [Documentos](https://docs.pokt.network/) + - [Documentação](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) + - [Endpoints 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 + - Nó de arquivamento, Nó de arquivamento com rastreamento e Suporte a nó de rede de teste + - Diversidade do cliente do nó da Mainnet (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) @@ -286,12 +301,12 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - 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) + - Painel e análises do [Pocket Portal](https://bit.ly/ETHorg_POKTportal) - [**QuickNode**](https://www.quicknode.com) - - [Documentos](https://www.quicknode.com/docs/) + - [Documentação](https://www.quicknode.com/docs/) - Recursos - - Suporte técnico 24/7 e comunidade de desenvolvedores do Discord + - Suporte técnico 24/7 e comunidade de desenvolvedores no 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) @@ -303,13 +318,13 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Adequado para desenvolvedores e empresas - [**Rivet**](https://rivet.cloud/) - - [Documentos](https://rivet.readthedocs.io/en/latest/) + - [Documentação](https://rivet.readthedocs.io/en/latest/) - Recursos - - Opção de nível gratuito + - Opção de nível livre - Dimensione conforme suas necessidades - [**SenseiNode**](https://senseinode.com) - - [Documentos](https://docs.senseinode.com/) + - [Documentação](https://docs.senseinode.com/) - Recursos - Nós dedicados e compartilhados - Painel @@ -317,7 +332,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Clientes Prysm e Lighthouse - [**SettleMint**](https://console.settlemint.com/) - - [Documentos](https://docs.settlemint.com/) + - [Documentação](https://docs.settlemint.com/) - Recursos - Avaliação gratuita - Dimensione conforme suas necessidades @@ -331,7 +346,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Suporte direto - [**Tenderly**](https://tenderly.co/web3-gateway) - - [Documentos](https://docs.tenderly.co/web3-gateway/web3-gateway) + - [Documentação](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 @@ -346,9 +361,9 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Suporte técnico dedicado via chat, e-mail e Discord - [**Tokenview**](https://services.tokenview.io/) - - [Documentos](https://services.tokenview.io/docs?type=nodeService) + - [Documentação](https://services.tokenview.io/docs?type=nodeService) - Recursos - - Suporte técnico 24/7 & comunidade Telegram de desenvolvedores + - Suporte técnico 24/7 e comunidade de desenvolvedores no Telegram - 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 @@ -358,7 +373,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Suporte externo para requisitos extras de comportamento - [**Watchdata**](https://watchdata.io/) - - [Documentos](https://docs.watchdata.io/) + - [Documentação](https://docs.watchdata.io/) - Recursos - Confiabilidade dos dados - Conexão ininterrupta sem tempo de inatividade @@ -370,7 +385,7 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - Velocidades de processamento altas - [**ZMOK**](https://zmok.io/) - - [Documentos](https://docs.zmok.io/) + - [Documentação](https://docs.zmok.io/) - Recursos - Front-running como serviço - Mempool de transações globais com métodos de pesquisa/filtragem @@ -379,26 +394,25 @@ Segue uma lista de alguns dos fornecedores de nós para Ethereum mais populares. - O melhor preço garantido por chamada de API - [**Zeeve**](https://www.zeeve.io/) - - [Documentos](https://www.zeeve.io/docs/) + - [Documentação](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 + - Mais de 30 protocolos e integrações compatíveis, 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/) +- [Lista de serviços de nós Ethereum](https://ethereumnodes.com/) ## Tópicos relacionados {#related-topics} -- [ Nós e clientes](/developers/docs/nodes-and-clients/) +- [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 de introdução ao desenvolvimento da 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/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/pt-br/developers/docs/nodes-and-clients/run-a-node/index.md index 021644d17c2..c272a88025c 100644 --- a/public/content/translations/pt-br/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/translations/pt-br/developers/docs/nodes-and-clients/run-a-node/index.md @@ -1,33 +1,33 @@ --- -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. +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. +Observe que, após [A Fusão](/roadmap/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/). +Você deve entender o que é um nó Ethereum e por que é importante executar um cliente. Isto é 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). +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ó do Ethereum](/run-a-node). -## Escolhendo um método {#choosing-approach} +## Escolhendo uma abordagem {#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). +Para escolher entre as implementações de cliente, veja todos os [clientes de execução](/developers/docs/nodes-and-clients/#execution-clients) e [clientes de consenso](/developers/docs/nodes-and-clients/#consensus-clients) prontos para a Mainnet 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. +Decida se quer 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. +Depois de preparar o ambiente, instale os clientes escolhidos com uma [interface amigável 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). +Quando o nó estiver em execução e sincronizando, você estará pronto para [usá-lo](#using-the-node), mas certifique-se de ficar de olho na sua [manutenção](#operating-the-node). ![Configuração do cliente](./diagram.png) @@ -35,7 +35,8 @@ Quando o nó estiver em execução e sincronização, você estará pronto para #### 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: +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 @@ -48,11 +49,11 @@ Os clientes Ethereum são capazes de executar em computadores de grau de consumo - 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. +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 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/network-types) mostram uma grande parte dos nós executados na nuvem, o que pode se tornar um único ponto de falha. +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. [Estimativas](https://www.ethernodes.org/networkType/cl/Hosting) mostram que uma grande parte dos nós é executada na nuvem, o que poderia 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. @@ -64,11 +65,11 @@ Os requisitos de hardware diferem conforme o cliente, mas geralmente não são t 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 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 sobrando 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. +Certifique-se também de que sua conexão com a internet não seja limitada por 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 @@ -90,19 +91,19 @@ Todos os clientes dão suporte aos principais sistemas operacionais: Linux, MacO 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+ | +| Client | Tamanho do disco (sincronização rápida) | Tamanho do disco (arquivo completo) | +| ---------- | ---------------------------------------------------------- | ------------------------------------------------------ | +| Besu | + de 800 GB | + 12 TB | +| Erigon | N/D | + de 2,5 TB | +| Geth | + de 500 GB | + 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) +- 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). +Para clientes de consenso, o requisito de espaço também depende da implementação do cliente e dos recursos habilitados (p. ex., slasher de validador), mas geralmente conte com outros 200 GB necessários para dados de 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} +#### 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. @@ -111,29 +112,30 @@ A opção mais fácil para executar um nó com seu próprio hardware é usando f #### 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. +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. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) fornece imagens fáceis de executar de vários clientes de execução e 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} +## Iniciando o 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} +### Configuração guiada {#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. +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNode não vem apenas com uma máquina 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. +- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) - A maneira mais rápida e fácil de configurar um nó completo. Ferramenta de configuração linear e gerenciamento de nó TUI. Gratuito. Código aberto. Bons públicos para Ethereum por solistas. Apoio de ARM64 e AMD64. +- [eth-docker](https://eth-docker.net/) - Configuração automatizada usando Docker focada em staking fácil e seguro, requer conhecimento básico de terminal e Docker, recomendado para usuários um pouco mais avançados. +- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) - Iniciador para instalar clientes em um servidor remoto via conexão SSH com um guia de configuração da GUI, centro de controle e muitos outros recursos. +- [NiceNode](https://www.nicenode.xyz/) - Iniciador 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ó 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} +### Configuração manual de clientes {#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. @@ -141,7 +143,7 @@ Conforme explicado anteriormente, configurar seu próprio nó Ethereum exigirá #### 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. +Primeiro, você precisa obter o software de sua preferência de [cliente de execução](/developers/docs/nodes-and-clients/#execution-clients) e [cliente de consenso](/developers/docs/nodes-and-clients/#consensus-clients). 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. @@ -157,17 +159,17 @@ Aqui estão as páginas de lançamento dos clientes, nas quais você pode encont - [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. +Também vale a pena notar 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/run/getting-started/installation#build-from-source/) (não fornece um binário pré-compilado, apenas uma imagem do Docker ou para ser compilado a partir da fonte) +- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source) (Não fornece um binário pré-compilado, apenas uma imagem Docker ou para ser construído a partir do código-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. +A [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity/) é fundamental para nós de consenso que executam 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). @@ -175,7 +177,7 @@ A [diversidade de clientes](/developers/docs/nodes-and-clients/client-diversity/ 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/). +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: @@ -189,15 +191,15 @@ sha256sum teku-22.6.1.tar.gz 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. +Vamos começar com opções que podem influenciar significativamente o desempenho do cliente e o uso de dados. [Modos de sincronização](/developers/docs/nodes-and-clients/#sync-modes) representam diferentes métodos de baixar e validar 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 poda (pruning) permite excluir dados desatualizados, ou seja, remover nós da árvore de estado que são inacessíveis a partir de 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. +Outras opções básicas de configuração são, por exemplo, escolher uma rede - Mainnet ou redes de teste, habilitar o endpoint 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} +#### Iniciando o cliente de execução {#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: @@ -211,34 +213,34 @@ Execute seu cliente primeiro em uma rede de testes para garantir que tudo esteja 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. +Os clientes de execução e de consenso se comunicam por meio de um ponto de extremidade autenticado especificado na [API do Motor (Engine API)](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/): +Esse token é gerado automaticamente pelo software cliente, mas, em alguns casos, talvez você precise fazer isso sozinho. Você pode gerá-lo usando [OpenSSL](https://www.openssl.org/): ```sh openssl rand -hex 32 > jwtsecret ``` -#### Iniciando a execução do cliente {#running-an-execution-client} +#### Executando um cliente de execução {#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 + - Você pode, em vez disso, escolher [uma das redes de teste](/developers/docs/networks/) para testes preliminares de 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 +- Define o caminho para `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. +> Observe que as barras invertidas `` nos exemplos são apenas para fins de formatação; os sinalizadores 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. +Este exemplo inicia o Besu na Mainnet, armazena dados da blockchain no formato padrão em `/data/ethereum`, habilita o JSON-RPC e o Engine RPC para conectar o cliente de consenso. A Engine API é autenticada com o token `jwtsecret` e somente chamadas de `localhost` são permitidas. ```sh besu --network=mainnet \ @@ -256,11 +258,11 @@ O Besu também vem com uma opção de inicializador, que fará uma série de per besu --Xlauncher ``` -A [documentação do Besu](https://besu.hyperledger.org/public-networks/get-started/start-node/) contém opções adicionais e detalhes de configuração. +A [documentação do Besu](https://besu.hyperledger.org/public-networks/get-started/start-node/) contém opções e detalhes de configuração adicionais. ##### 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`. +Este exemplo inicia o Erigon na Mainnet, armazena dados da blockchain em `/data/ethereum`, habilita o JSON-RPC, define quais namespaces são permitidos e habilita a autenticação para conectar o cliente de consenso que é definido pelo caminho `jwtsecret`. ```sh erigon --chain mainnet \ @@ -269,11 +271,11 @@ erigon --chain mainnet \ --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. +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. Certifique-se de que `datadir` aponta para um disco com espaço livre suficiente ou veja o sinalizador `--prune` que pode reduzir 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`. +Este exemplo inicia o Geth na Mainnet, armazena os dados da blockchain em `/data/ethereum`, habilita o JSON-RPC e define quais namespaces são permitidos. Também habilita a autenticação para conectar o cliente de consenso, o que requer o caminho para `jwtsecret` e também uma opção que define quais conexões são permitidas, em nosso exemplo apenas de `localhost`. ```sh geth --mainnet \ @@ -284,7 +286,7 @@ geth --mainnet \ --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). +Verifique 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 o Geth com um cliente de consenso](https://geth.ethereum.org/docs/getting-started/consensus-clients). ##### Executando o Nethermind @@ -296,13 +298,13 @@ Nethermind.Runner --config mainnet \ --JsonRpc.JwtSecretFile=/path/to/jwtsecret ``` -Os documentos do Nethermind oferecem um [guia completo](https://docs.nethermind.io/get-started/running-node/) sobre como executar o Nethermind com o cliente de consenso. +A documentação do Nethermind oferece um [guia completo](https://docs.nethermind.io/get-started/running-node/) sobre como executar o Nethermind com um 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`. +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 que é definido pelo caminho `jwtsecret`, com somente chamadas de `localhost` sendo permitidas. ```sh reth node \ @@ -311,23 +313,23 @@ reth node \ --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. +Veja [Configurando o 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 e detalhes de configuração adicionais. -#### Iniciando um cliente de consenso {#starting-the-consensus-client} +#### Iniciando o 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. +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 usa 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). +Ao iniciar um nó Beacon em uma rede de teste, você pode economizar um tempo de sincronização significativo usando um endpoint público para [Sincronização de Ponto de verificação (Checkpoint sync)](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). +Antes de executar o Lighthouse, saiba mais sobre como instalá-lo e configurá-lo no [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html). ```sh lighthouse beacon_node \ @@ -344,16 +346,17 @@ Instale o software Lodestar compilando-o ou baixando a imagem do Docker. Saiba m ```sh lodestar beacon \ - --rootDir="/data/ethereum" \ + --dataDir="/data/ethereum" \ --network=mainnet \ --eth1.enabled=true \ - --execution.urls="http://127.0.1:8551" \ + --execution.urls="http://127.0.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: +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 \ @@ -365,7 +368,7 @@ nimbus_beacon_node \ ##### 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://prysm.offchainlabs.com/docs/install-prysm/install-with-script/). +O Prysm vem com um script que permite uma instalação automática fácil. Detalhes podem ser encontrados na [documentação do Prysm](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/). ```sh ./prysm.sh beacon-chain \ @@ -384,51 +387,51 @@ teku --network mainnet \ --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/). +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 as [APIs do nó Beacon](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. +Executar seu próprio validador permite o [staking individual](/staking/solo/), o método de maior impacto e sem necessidade de confiança para apoiar a rede Ethereum. No entanto, isso requer um depósito de 32 ETH. Para executar um validador em seu próprio nó com uma quantia menor, um pool descentralizado com operadores de nós sem permissão, como o [Rocket Pool](https://rocketpool.net/node-operators), pode ser do seu interesse. -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/). +A maneira mais fácil de começar com o staking e a geração de chaves de validador é usar a [Plataforma de Lançamento de Staking da Rede de Teste Hoodi](https://hoodi.launchpad.ethereum.org/), que permite testar sua configuração [executando nós na Hoodi](https://notes.ethereum.org/@launchpad/hoodi). Quando estiver pronto para a Mainnet, você poderá repetir essas etapas usando a [Plataforma de Lançamento de Staking 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. +Consulte a [página de staking](/staking) para ter uma visão geral sobre as opções de staking. ### 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: +Os clientes de execução oferecem [endpoints 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/) +- Anexando um console fornecido (por exemplo, `geth attach`) +- Implementando-os em aplicativos usando bibliotecas 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. +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 uma visão geral, [leia a documentação do 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 endpoint RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), o que tem fortes 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. +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 o [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} +#### Acessando 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. +A porta padrão para o JSON-RPC do cliente de execução é `8545`, mas você pode modificar as portas dos endpoints 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 querer 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. +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. Aproveitar uma camada intermediária também pode permitir que os desenvolvedores configurem um certificado para conexões `https` seguras com a 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. +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 endpoint publicamente acessível é hospedar o nó em seu próprio serviço onion do [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. +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. 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. +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 2 ou 3 da OSI usando o protocolo SSL/TLS padrão da indústria, suporta métodos flexíveis de autenticação de cliente baseados em certificados, cartões inteligentes e/ou credenciais de nome 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 da 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} +#### Mantendo um 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: @@ -436,17 +439,17 @@ Seu nó não precisa estar online o tempo todo, mas você deve mantê-lo online - 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. +_Isso não se aplica aos nós validadores da camada de consenso._ Deixar seu nó offline afetará todos os serviços que dependem dele. Se você estiver executando um nó para fins de _staking_, deve tentar minimizar o tempo de inatividade o máximo possível. -#### Criando serviços de clientes {#creating-client-services} +#### Criando serviços de cliente {#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. +Considere criar um serviço para executar seus clientes automaticamente na inicialização. Por exemplo, em servidores Linux, uma boa prática seria criar um serviço, por exemplo, com `systemd`, que executa o cliente com a configuração adequada, sob um usuário com privilégios limitados e reinicia 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](/ethereum-forks/), verifique se você está executando as versões corretas do cliente. +Você precisa manter o software do seu cliente atualizado com os patches de segurança, recursos e [EIPs](/eips/) mais recentes. Especialmente antes de [bifurcações permanentes (hard forks)](/ethereum-forks/), certifique-se de que 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. +> Antes de atualizações importantes da rede, a EF publica um post em seu [blog](https://blog.ethereum.org). Você pode [se inscrever nesses anúncios](https://blog.ethereum.org/category/protocol#subscribe) para receber uma notificação por e-mail quando 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. @@ -454,27 +457,28 @@ Cada implementação de cliente tem uma cadeia de caracteres de versão legível #### 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. +Executar seu próprio nó permite que você use serviços que exigem acesso direto ao cliente RPC do Ethereum. São serviços construídos sobre o Ethereum, como [soluções de camada 2](/developers/docs/scaling/#layer-2-scaling), backend para carteiras, exploradores de blocos, ferramentas de desenvolvedor 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`. +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. Além do Grafana, você pode usar as ferramentas que seu sistema operacional oferece, como `htop` ou `uptime`, para fazer isso. ## 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_ +- [Guias de Staking do Ethereum](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat, atualizado com frequência_ +- [Guia | Como configurar um validador para staking de Ethereum na mainnet](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew, atualizado com frequência_ +- [Guias do ETHStaker sobre como executar validadores em redes de teste](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, atualizado regularmente_ +- [Aplicativo de exemplo AWS Blockchain Node Runner para nós Ethereum](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) - _AWS, atualizado com frequência_ +- [FAQ da Fusão para operadores de nós](https://notes.ethereum.org/@launchpad/node-faq-merge) - _Julho de 2022_ +- [Analisando os requisitos de hardware para ser um nó Ethereum totalmente validado](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 de 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ó Hyperledger Besu na Mainnet do Ethereum: benefícios, requisitos e configuração](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 a 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/) +- [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/developers/docs/oracles/index.md b/public/content/translations/pt-br/developers/docs/oracles/index.md index c9a684095b1..da2b0e6bc82 100644 --- a/public/content/translations/pt-br/developers/docs/oracles/index.md +++ b/public/content/translations/pt-br/developers/docs/oracles/index.md @@ -1,64 +1,64 @@ --- -title: Oráculos -description: Oráculos fornecem contratos inteligentes Ethereum com acesso a dados do mundo real, desbloqueando mais casos de uso e maior valor para os usuários. +title: "Oráculos" +description: "Oráculos fornecem contratos inteligentes Ethereum com acesso a dados do mundo real, desbloqueando mais casos de uso e maior valor para os usuários." lang: pt-br --- -Oráculos são feeds de dados que trazem dados de fontes de dados fora da blockchain (off-chain) e os colocam na blockchain (on-chain) para uso em contratos inteligentes. Isso é necessário porque os contratos inteligentes executados no Ethereum não podem acessar informações armazenadas fora da rede blockchain. +Oráculos são aplicações que produzem data feeds que fazem dados offchain disponíveis aos contratos inteligentes. Isso é necessário porque os contratos inteligentes baseados em Ethereum não podem, por padrão, acessar informações armazenadas fora da rede blockchain. -Dar aos contratos inteligentes a capacidade de executar usando entradas de dados fora da cadeia aumenta o valor dos aplicativos descentralizados. Por exemplo, os mercados de previsão descentralizados dependem de oráculos para fornecer informações sobre os resultados com os quais podem validar as previsões do usuário. Suponha que Alice aposte 20 ETH em quem se tornará o próximo presidente americano. Nesse caso, o dapp do mercado de previsão precisa de um oráculo para confirmar os resultados das eleições e determinar se Alice é elegível para um pagamento. +Dar aos contratos inteligentes a capacidade de utilizar dados offchain amplia a utilidade e o valor das aplicações descentralizadas. Por exemplo, os onchain prediction markets dependem de oráculos para fornecer resultados que eles utilizam para validar as previsões aos usuários. Suponha que Alice aposte 20 ETH em quem se tornará o próximo presidente americano. Nesse caso, o dapp do mercado de previsão precisa de um oráculo para confirmar os resultados das eleições e determinar se Alice é elegível para um pagamento. ## Pré-requisitos {#prerequisites} -Esta página assume que o leitor está familiarizado com os fundamentos do Ethereum, incluindo [nós](/developers/docs/nodes-and-clients/), [mecanismos de consenso](/developers/docs/consensus-mechanisms/) e a [EVM](/developers/docs/evm/). Você também deve ter uma boa compreensão de [contratos inteligentes](/developers/docs/smart-contracts/) e [anatomia de contratos inteligentes](/developers/docs/smart-contracts/anatomy/), especialmente de [eventos](/glossary/#events). +Esta página pressupõe que o leitor esteja familiarizado com os fundamentos do Ethereum, incluindo [nós](/developers/docs/nodes-and-clients/), [mecanismos de consenso](/developers/docs/consensus-mechanisms/) e a [EVM](/developers/docs/evm/). Você também deve ter um bom conhecimento de [contratos inteligentes](/developers/docs/smart-contracts/) e da [anatomia de contratos inteligentes](/developers/docs/smart-contracts/anatomy/), especialmente [eventos](/glossary/#events). ## O que é um oráculo blockchain? {#what-is-a-blockchain-oracle} -Oráculos são aplicativos que fornecem, verificam e transmitem informações externas (ou seja, informações armazenadas fora da cadeia) para contratos inteligentes em execução na blockchain. Além de “puxar” dados off-chain e transmiti-los no Ethereum, os oráculos também podem “enviar” informações da blockchain para sistemas externos. Um exemplo deste último poderia ser um oráculo que desbloqueia um bloqueio de contrato inteligente assim que o usuário envia a taxa por meio de uma transação Ethereum. +Oráculos são aplicações que obtêm, verificam e transmitem informações externas (ou seja, informações armazenadas fora da cadeia) para contratos inteligentes em execução na cadeia de blocos. Além de 'puxar' dados off-chain e transmiti-los no Ethereum, oráculos também podem 'empurrar' informações da blockchain para sistemas externos, por exemplo, destravando um bloqueio inteligente assim que o usuário envia uma taxa por meio de uma transação Ethereum. -Oráculos atuam como uma "ponte" conectando contratos inteligentes em blockchains a provedores de dados off-chain. Sem os oráculos, os aplicativos de contratos inteligentes só poderiam acessar dados on-chain. Um oráculo fornece um mecanismo para acionar funções de contrato inteligente usando dados off-chain. +Sem oráculo, um contrato inteligente estaria totalmente limitado aos dados on-chain. -Oráculos diferem com base na fonte de dados (uma ou várias fontes), modelos de confiança (centralizados ou descentralizados) e arquitetura do sistema (leitura imediata, publicação-assinatura e solicitação-resposta). Também podemos distinguir entre oráculos baseados em se eles recuperam dados externos para uso por contratos em cadeia (oráculos de entrada), enviam informações da blockchain para os aplicativos fora de cadeia (oráculos de saída) ou executam tarefas computacionais fora de cadeia (oráculos computacionais). +Oráculos diferem com base na fonte de dados (uma ou várias fontes), modelos de confiança (centralizados ou descentralizados) e arquitetura do sistema (leitura imediata, publicação-assinatura e solicitação-resposta). Também podemos distinguir oráculos baseados em se eles recuperam dados externos por contratos onchain (oráculos de entrada), enviam informações do blockchain para as aplicações offchain (oráculos de saída) ou executam tarefas computacionais offchain (oráculos computacionais). ## Por que os contratos inteligentes precisam de oráculos? {#why-do-smart-contracts-need-oracles} -A maioria dos desenvolvedores vê os contratos inteligentes como simples pedaços de código rodando em endereços específicos na blockchain. No entanto uma visão mais geral [dos contratos inteligentes](/smart-contracts/) é que eles são programas de software autoexecutáveis capazes de forçar acordos entre as partes uma vez que as condições específicas sejam cumpridas, o que explica o termo "contratos inteligentes". +Muitos desenvolvedores veem os contratos inteligentes como código executado em endereços específicos na blockchain. No entanto, uma [visão mais geral dos contratos inteligentes](/smart-contracts/) é que eles são programas de software autoexecutáveis capazes de aplicar acordos entre as partes assim que condições específicas forem atendidas - daí o termo “contratos inteligentes”. -Mas usar contratos inteligentes para aplicar acordos entre pessoas não é fácil, uma vez que o Ethereum é determinístico. Um [sistema determinístico](https://en.wikipedia.org/wiki/Deterministic_algorithm) é aquele que sempre produz os mesmos resultados dado um estado inicial e uma entrada em particular – não há aleatoriedade ou variação no processo de computar as saídas das entradas. +Mas usar contratos inteligentes para aplicar acordos entre pessoas não é fácil, uma vez que o Ethereum é determinístico. Um [sistema determinístico](https://en.wikipedia.org/wiki/Deterministic_algorithm) é aquele que sempre produz os mesmos resultados, dado um estado inicial e uma entrada específica, o que significa que não há aleatoriedade ou variação no processo de computação das saídas a partir das entradas. -Para alcançar a execução determinística, as blockchains limitam os nós para alcançar consenso sobre questões binárias simples (verdadeiro/falso) usando _somente_ dados armazenados na própria blockchain. Exemplos de tais perguntas incluem: +Para alcançar a execução determinística, as cadeias de blocos limitam os nós a alcançar um consenso sobre questões binárias simples (verdadeiro/falso) usando _somente_ dados armazenados na própria cadeia de blocos. Exemplos de tais perguntas incluem: - “O proprietário da conta (identificado por uma chave pública) assinou esta transação com a chave privada emparelhada?” - “Esta conta tem fundos suficientes para cobrir a transação?” - “Esta transação é válida no contexto deste contrato inteligente?” etc. -Se blockchains recebessem informações de fontes externas (ou seja, do mundo real), seria impossível alcançar o determinismo, impedindo que os nós concordassem com a validade das mudanças no estado da blockchain. Tomemos, por exemplo, um contrato inteligente que executa uma transação baseada na taxa de câmbio atual ETH-USD obtida de uma API de preço tradicional. Esse número provavelmente mudaria frequentemente (sem mencionar que a API poderia ser depreciada ou hackeada), o que significa que os nós que executam o mesmo código de contrato chegariam a resultados diferentes. +Se blockchains recebessem informações de fontes externas (ou seja, do mundo real), seria impossível alcançar o determinismo, impedindo que os nós concordassem com a validade das mudanças no estado da blockchain. Tomemos, por exemplo, um contrato inteligente que executa uma transação baseada na taxa de câmbio atual ETH-USD obtida de uma API de preço tradicional. Essa informação provavelmente mudará com frequência (sem mencionar que a API pode ser descontinuada ou hackeada), o que significa que os nós executando o mesmo código de contrato chegariam a resultados diferentes. -Para uma blockchain pública, como a Ethereum, com milhares de nós em todo o mundo processando transações, o determinismo é crítico. Sem nenhuma autoridade central servindo como fonte da verdade, é esperado que os nós devam chegar ao mesmo estado após aplicar as mesmas transações. Um caso em que o nó A executa um código de um contrato inteligente e obtém "3" como resultado, enquanto o nó B obtém "7" após executar a mesma transação causaria a quebra do consenso e eliminaria o valor do Ethereum como uma plataforma de computação descentralizada. +Para uma blockchain pública como o Ethereum, com milhares de nós ao redor do mundo processando transações, o determinismo é crucial. Sem uma autoridade central servindo como fonte da verdade, os nós precisam de mecanismos para chegar ao mesmo estado após aplicar as mesmas transações. Um caso em que o nó A executa um código de um contrato inteligente e obtém "3" como resultado, enquanto o nó B obtém "7" após executar a mesma transação causaria a quebra do consenso e eliminaria o valor do Ethereum como uma plataforma de computação descentralizada. -O cenário descrito anteriormente também destaca o problema de projetar blockchains para extrair informações de fontes externas. Os oráculos, no entanto, resolvem esse problema pegando informações de fontes off-chain e armazenando-as na blockchain para consumo de contratos inteligentes. Como as informações armazenadas na cadeia são inalteráveis e disponíveis publicamente, os nós do Ethereum podem usar com segurança os dados off-chain importados do oráculo para calcular as mudanças de estado sem quebrar o consenso. +Esse cenário também destaca o problema de projetar blockchains para obter informações de fontes externas. Oráculos, no entanto, resolvem este problema pegando informações off-chain e armazenando-as no blockchain por contratos inteligentes. As informações armazenadas onchain são inalteráveis e disponíveis publicamente, por isso os nós do Ethereum podem usar com segurança os dados off-chain importados por oráculo para calcular as mudanças de estado sem quebrar o consenso. -Para fazer isso, um oráculo é normalmente composto de um contrato inteligente executado on-chain e alguns componentes off-chain. O contrato on-chain recebe solicitações de dados de outros contratos inteligentes, que ele passa para o componente off-chain (chamado nó oráculo). Esse nó oráculo pode consultar fontes de dados – usando interfaces de programação de aplicativos (APIs), por exemplo – e enviar transações para armazenar os dados solicitados no armazenamento do contrato inteligente. +Por isto, um oráculo é normalmente composto de um contrato inteligente executado on-chain e alguns componentes off-chain. O contrato on-chain recebe pedido de dados de outros contratos inteligentes e ele passa os pedidos para off-chain (chamado nó de oráculo). Esse nó oráculo pode consultar fontes de dados – usando interfaces de programação de aplicativos (APIs), por exemplo – e enviar transações para armazenar os dados solicitados no armazenamento do contrato inteligente. -Essencialmente, um oráculo da blockchain preenche a lacuna de informações entre a blockchain e o ambiente externo, criando “contratos inteligentes híbridos”. Um contrato inteligente híbrido é aquele que funciona baseado em uma combinação de código de contrato on-chain e infraestrutura off-chain. Os mercados de previsão descentralizados, descritos na introdução, são um excelente exemplo de contratos inteligentes híbridos. Outros exemplos podem incluir contratos inteligentes de seguro de colheitas que pagam quando um conjunto de oráculos determina que certos fenômenos climáticos ocorreram. +Essencialmente, um oráculo da blockchain preenche a lacuna de informações entre a blockchain e o ambiente externo, criando “contratos inteligentes híbridos”. Um contrato inteligente híbrido é a combinação de código de contrato on-chain e infraestrutura off-chain. Mercados de previsão descentralizados são um excelente exemplo de contratos inteligentes híbridos. Outros exemplos podem incluir contratos inteligentes de seguro de colheitas que pagam quando um conjunto de oráculos determina que certos fenômenos climáticos ocorreram. -## Qual é o problema do oráculo? {#the-oracle-problem} +## Qual é o problema do oráculo? O problema do oráculo {#the-oracle-problem} -É fácil fornecer aos contratos inteligentes acesso a dados off-chain, contando com uma entidade (ou várias entidades) para introduzir informações extrínsecas à blockchain, armazenando os dados no corpo de uma transação. Mas isso traz novos problemas: +Os oráculos resolvem um problema importante, mas também introduzem algumas complicações, por ex.,: - Como verificamos que as informações injetadas foram extraídas da fonte correta ou não foram adulteradas? - Como garantimos que esses dados estejam sempre disponíveis e atualizados regularmente? -O chamado “problema do oráculo” demonstra os problemas que surgem com o uso de oráculos da blockchain para enviar entradas para contratos inteligentes. É fundamental garantir que os dados de um oráculo estejam corretos ou a execução do contrato inteligente produzirá resultados errados. Também é importante a necessidade da falta de confiança - ter que "confiar" nos operadores do oráculo para fornecer informações precisas de forma confiável rouba dos contratos inteligentes suas qualidades mais importantes. +O chamado “problema do oráculo” demonstra os problemas que surgem com o uso de oráculos da blockchain para enviar entradas para contratos inteligentes. Dados de um oráculo devem estar corretos para um contrato inteligente executar corretamente. Além disso, ter que "confiar" em operadores de oráculos para prover informação precisa mitiga o aspecto "incerto" dos contratos inteligentes. -Diferentes oráculos diferem na sua abordagem para resolver o problema do oráculo, e exploramos estas abordagens mais tarde. Embora nenhum oráculo seja perfeito, os méritos de um oráculo devem ser medidos com base em como ele lida com os seguintes desafios: +Diferentes oráculos oferecem diferentes soluções para o problema do oráculo, algo que veremos depois. Os oráculos são geralmente avaliados de acordo com a capacidade deles de lidar com os seguintes desafios: -1. **Exatidão**: um oráculo não deve fazer com que contratos inteligentes acionem mudanças de estado com base em dados inválidos off-chain. Por esse motivo, um oráculo deve garantir a _autenticidade_ e a _integridade_ dos dados – autenticidade significa que os dados foram obtidos da fonte correta, enquanto a integridade significa que os dados permaneceram intactos (ou seja, não foram alterados) antes de serem enviados on-chain. +1. **Correção**: Um oráculo não deve fazer com que contratos inteligentes acionem alterações de estado com base em dados inválidos fora da cadeia. Um oráculo deve garantir a _autenticidade_ e a _integridade_ dos dados. Autenticidade significa que os dados foram obtidos da fonte correta, enquanto integridade significa que os dados permaneceram intactos (ou seja, não foram alterados) antes de serem enviados para a cadeia. -2. **Disponibilidade**: um oráculo não deve atrasar ou impedir os contratos inteligentes de executar ações e acionar alterações de estado. Essa qualidade exige que os dados de um oráculo estejam _disponíveis mediante solicitação_ sem interrupção. +2. **Disponibilidade**: Um oráculo não deve atrasar ou impedir que contratos inteligentes executem ações e acionem alterações de estado. Isso significa que os dados de um oráculo devem estar _disponíveis sob demanda_ sem interrupção. -3. **Compatibilidade de incentivos**: um oráculo deve incentivar provedores de dados off-chain a enviar informações corretas para contratos inteligentes. A compatibilidade de incentivo envolve _atribuição_ e _responsabilidade_. A atribuição permite correlacionar um pedaço da informação externa ao seu provedor, enquanto a responsabilidade vincula os provedores de dados às informações que eles fornecem, de modo que podem ser recompensados ou penalizados com base na qualidade das informações fornecidas. +3. **Compatibilidade de incentivos**: Um oráculo deve incentivar os provedores de dados fora da cadeia a enviar informações corretas para contratos inteligentes. A compatibilidade de incentivos envolve _atribuibilidade_ e _responsabilização_. A capacidade de atribuição permite vincular uma parte da informação externa para o provedor dela, enquanto responsabilidade liga provedores de dados às informações fornecidas, de forma que sejam recompensados ou penalizados baseado na qualidade da informação provida. ## Como funciona um serviço de oráculo na blockchain? {#how-does-a-blockchain-oracle-service-work} @@ -66,7 +66,7 @@ Diferentes oráculos diferem na sua abordagem para resolver o problema do orácu Usuários são entidades (ou seja, contratos inteligentes) que precisam de informação externa à blockchain para completar ações específicas. O fluxo de trabalho básico de um serviço oráculo começa com o usuário enviando uma requisição de dados para o contrato oracle. Os pedidos de dados geralmente respondem a algumas ou todas as seguintes perguntas: -1. Que fontes podem os nós off-chain consultar para conseguir as informações solicitadas? +1. What sources can offchain nodes consult for the requested information? 2. Como os informantes processam informações de fontes de dados e extraem pontos de dados úteis? @@ -76,41 +76,41 @@ Usuários são entidades (ou seja, contratos inteligentes) que precisam de infor 5. Qual método deve ser implementado na filtragem de submissões e agregações dos relatórios em um único valor? -### Contrato de oráculo {#oracle-contract} +### Contrato do oráculo {#oracle-contract} -O contrato de um oráculo é o componente on-chain para o serviço do oráculo: ele escuta solicitações de dados de outros contratos, retransmite consultas de dados para nós oráculos e transmite dados retornados para contratos de clientes. Este contrato também pode executar alguma computação sobre os pontos de dados retornados para produzir um valor agregado que envia ao contrato solicitante. +O contrato de oráculo é componente onchain por serviço de oráculo. Esse aguarda requisitos de dados de outros contratos, encaminha consultas de dados para nós oráculos e transmite os dados retornados para os contratos dos clientes. Este contrato também pode realizar alguns cálculos nos dados retornados para produzir um valor agregado a ser enviado para o contrato solicitante. -O contrato oráculo expõe algumas funções que os contratos do cliente chamam ao fazer uma solicitação de dados. Ao receber uma nova consulta, o contrato inteligente emitirá um [evento de log](/developers/docs/smart-contracts/anatomy/#events-and-logs) com detalhes da solicitação de dados. Isso notifica os nós off-chain inscritos no log (geralmente usando algo como o comando JSON-RPC `eth_subscribe`), que procedem a recuperar os dados definidos no evento de log. +O contrato oráculo expõe algumas funções que os contratos do cliente chamam ao fazer uma solicitação de dados. Ao receber uma nova consulta, o contrato inteligente emitirá um [evento de log](/developers/docs/smart-contracts/anatomy/#events-and-logs) com detalhes da solicitação de dados. Isso notifica os nós fora da cadeia inscritos no log (geralmente usando algo como o comando JSON-RPC `eth_subscribe`), que então recuperam os dados definidos no evento de log. -Abaixo está um [exemplo de contrato oráculo](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) por Pedro Costa. Este é um serviço simples de oráculo que pode consultar APIs off-chain mediante solicitação de outros contratos inteligentes e armazenar as informações solicitadas na blockchain: +Abaixo está um [exemplo de contrato de oráculo](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) por Pedro Costa. É um serviço de oráculo consultar APIs off-chain e armazenar as informações no blockchain: ```solidity pragma solidity >=0.4.21 <0.6.0; contract Oracle { - Request[] requests; //list of requests made to the contract - uint currentId = 0; //increasing request id - uint minQuorum = 2; //minimum number of responses to receive before declaring final result - uint totalOracleCount = 3; // Hardcoded oracle count + Request[] requests; //lista de solicitações feitas ao contrato + uint currentId = 0; //id da solicitação crescente + uint minQuorum = 2; //número mínimo de respostas a serem recebidas antes de declarar o resultado final + uint totalOracleCount = 3; // Contagem de oráculos codificada - // defines a general api request + // define uma solicitação de API geral struct Request { - uint id; //request id - string urlToQuery; //API url - string attributeToFetch; //json attribute (key) to retrieve in the response - string agreedValue; //value from key - mapping(uint => string) answers; //answers provided by the oracles - mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted) + uint id; //id da solicitação + string urlToQuery; //URL da API + string attributeToFetch; //atributo json (chave) a ser recuperado na resposta + string agreedValue; //valor da chave + mapping(uint => string) answers; //respostas fornecidas pelos oráculos + mapping(address => uint) quorum; //oráculos que consultarão a resposta (1=oráculo não votou, 2=oráculo votou) } - //event that triggers oracle outside of the blockchain + //evento que aciona o oráculo fora da cadeia de blocos event NewRequest ( uint id, string urlToQuery, string attributeToFetch ); - //triggered when there's a consensus on the final result + //acionado quando há um consenso sobre o resultado final event UpdatedRequest ( uint id, string urlToQuery, @@ -127,23 +127,23 @@ contract Oracle { uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); Request storage r = requests[length-1]; - // Hardcoded oracles address + // Endereço dos oráculos codificado r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; - // launch an event to be detected by oracle outside of blockchain + // lança um evento a ser detectado pelo oráculo fora da cadeia de blocos emit NewRequest ( currentId, _urlToQuery, _attributeToFetch ); - // increase request id + // aumenta o id da solicitação currentId++; } - //called by the oracle to record its answer + //chamado pelo oráculo para registrar sua resposta function updateRequest ( uint _id, string memory _valueRetrieved @@ -151,18 +151,18 @@ contract Oracle { Request storage currRequest = requests[_id]; - //check if oracle is in the list of trusted oracles - //and if the oracle hasn't voted yet + //verifica se o oráculo está na lista de oráculos confiáveis + //e se o oráculo ainda não votou if(currRequest.quorum[address(msg.sender)] == 1){ - //marking that this address has voted + //marcando que este endereço votou currRequest.quorum[msg.sender] = 2; - //iterate through "array" of answers until a position if free and save the retrieved value + //itera através do "array" de respostas até que uma posição esteja livre e salva o valor recuperado uint tmpI = 0; bool found = false; while(!found) { - //find first empty slot + //encontra o primeiro espaço vazio if(bytes(currRequest.answers[tmpI]).length == 0){ found = true; currRequest.answers[tmpI] = _valueRetrieved; @@ -172,8 +172,8 @@ contract Oracle { uint currentQuorum = 0; - //iterate through oracle list and check if enough oracles(minimum quorum) - //have voted the same answer has the current one + //itera através da lista de oráculos e verifica se há oráculos suficientes (quórum mínimo) + //votaram na mesma resposta que a atual for(uint i = 0; i < totalOracleCount; i++){ bytes memory a = bytes(currRequest.answers[i]); bytes memory b = bytes(_valueRetrieved); @@ -196,63 +196,59 @@ contract Oracle { } ``` -### Nós oráculos {#oracle-nodes} +### Nós de oráculo {#oracle-nodes} -O nó oráculo é o componente off-chain de serviço do oráculo: ele extrai as informações de fontes externas, como APIs hospedadas em servidores de terceiros, e as coloca on-chain para consumo por contratos inteligentes. Os nós oráculos escutam eventos do contrato oráculo on-chain e prosseguem para completar a tarefa descrita no log. +O nó de oráculo é o componente off-chain do serviço de oráculo. Ele extrai informações externas e as coloca onchain para serem usadas por contratos inteligentes. Os nós de oráculo seguem contratos de oráculo on-chain para completar a tarefa no log. -Uma tarefa comum para nós oráculos é enviar uma solicitação [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) para um serviço de API, analisar a resposta para extrair dados relevantes, formatar em uma saída legível para blockchain e enviá-la on-chain incluindo-a em uma transação para o contrato do oráculo. Também é possível que seja solicitado ao nó oráculo atestar a validade e a integridade das informações enviadas usando “provas de autenticidade”, que veremos mais adiante. +Uma tarefa comum para nós de oráculo é enviar uma solicitação [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) para um serviço de API, analisar a resposta para extrair dados relevantes, formatá-la em uma saída legível pela cadeia de blocos e enviá-la para a cadeia, incluindo-a em uma transação para o contrato do oráculo. Também é possível que seja solicitado ao nó oráculo atestar a validade e a integridade das informações enviadas usando “provas de autenticidade”, que veremos mais adiante. -Os oráculos computacionais também dependem de nós off-chain para executar tarefas computacionais intensivas, o qual seria impraticável de executar on-chain, devido aos custos de gás e aos limites de tamanho do bloco. Por exemplo, o nó oráculo pode ser encarregado de gerar uma figura verificável aleatória (por exemplo, para jogos baseados em blockchain). +Oráculos computacionais também dependem de nós off-chain para executar tarefas computacionais que seriam impraticáveis de realizar on-chain, devido aos custos de gás e aos limites de tamanho dos blocos. Por exemplo, o nó oráculo pode ser encarregado de gerar uma figura verificável aleatória (por exemplo, para jogos baseados em blockchain). -## Padrões de projeto em oráculos {#oracle-design-patterns} +## Padrões de design de oráculos {#oracle-design-patterns} -Oráculos vêm em diferentes tipos, incluindo _leitura imediata_, _publicação-assinatura_ e _solicitação-resposta_, com os dois últimos sendo os mais populares entre os contratos inteligentes do Ethereum. Abaixo está uma breve descrição dos dois tipos de serviços de oráculos: +Os oráculos vêm em diferentes tipos, incluindo _leitura imediata_, _publicação-assinatura_ e _solicitação-resposta_, sendo os dois últimos os mais populares entre os contratos inteligentes do Ethereum. Aqui descrevemos brevemente os modelos de "publicação-assinatura" e "solicitação-resposta". -### Publicação-assinatura de oráculos {#publish-subscribe-oracles} +### Oráculos de publicação-assinatura {#publish-subscribe-oracles} -Um serviço de oráculo baseado em um mecanismo de publicação-assinatura expõe um “feed de dados” que outros contratos podem ler regularmente para obter informações. Neste caso, espera-se que os dados mudem com frequência, portanto, os contratos do cliente devem ouvir as atualizações dos dados no armazenamento do oráculo. Um excelente exemplo é um oráculo que fornece informações sobre o último preço ETH-USD para os usuários. +Este tipo de oráculo expõe um “feed de dados” que outros contratos podem ler regularmente para obter informações. Neste caso, espera-se que os dados mudem com frequência, portanto, os contratos do cliente devem ouvir as atualizações dos dados no armazenamento do oráculo. Um exemplo é um oráculo que fornece as informações mais recentes sobre o preço ETH-USD aos usuários. -### Solicitação-resposta de oráculos {#request-response-oracles} +### Oráculos de solicitação-resposta {#request-response-oracles} -Uma configuração de solicitação-resposta permite que o contrato do cliente solicite dados arbitrários diferentes daqueles fornecidos por um oráculo de publicação-assinatura. Oráculos de solicitação-resposta são ideais nas seguintes condições: +Uma configuração de solicitação-resposta permite que o contrato do cliente solicite dados arbitrários diferentes daqueles fornecidos por um oráculo de publicação-assinatura. Os oráculos de solicitação-resposta são ideais quando o conjunto de dados é muito grande para ser guardado no armazenamento de um contrato inteligente e/ou os usuários precisarão apenas de uma pequena parte dos dados em qualquer momento. -- O conjunto de dados é muito grande para ser armazenado em um contrato inteligente +Embora mais complexos do que os modelos de publicação-assinatura, os oráculos de solicitação-resposta são basicamente o que descrevemos na seção anterior. O oráculo vai ter um componente on-chain que recebe uma solicitação de dados e a passa para nó off-chain para processamento. -- Os usuários só precisarão de uma pequena parte dos dados a qualquer momento +Os usuários que requerem dados devem pagar as informações off-chain. O contrato do cliente também deve fornecer fundos para cobrir os custos de gás incorridos pelo contrato do oráculo ao retornar a resposta por meio de uma função de callback (função de retorno da chamada) na solicitação. -Embora mais complexos do que os modelos de publicação-assinatura, os oráculos de solicitação-resposta são basicamente o que descrevemos na seção anterior. O oráculo terá um componente on-chain que recebe uma solicitação de dados e a passa para um nó off-chain para processamento. - -Os usuários que iniciam consultas de dados devem cobrir o custo de obter informações da fonte off-chain. O contrato do cliente também deve fornecer fundos para cobrir os custos de gás incorridos pelo contrato do oráculo ao retornar a resposta por meio de uma função de callback (função de retorno da chamada) na solicitação. - -## Tipos de oráculos {#types-of-oracles} +## Oráculos centralizados vs. descentralizados {#types-of-oracles} ### Oráculos centralizados {#centralized-oracles} -Um oráculo centralizado é controlado por uma única entidade responsável por agregar informações off-chain e atualizar os dados do contrato do oráculo conforme solicitado. Os oráculos centralizados são eficientes uma vez que dependem de uma única fonte de verdade. Eles podem até ser preferíveis nos casos em que os conjuntos de dados proprietários são publicados diretamente pelo proprietário com uma assinatura amplamente aceita. No entanto, usar um oráculo centralizado traz vários problemas. +Oráculo centralizado é controlado por uma única entidade responsável por agregar informações off-chain e atualizar os dados de contrato de oráculo conforme solicitado. Os oráculos centralizados são eficientes uma vez que dependem de uma única fonte de verdade. Eles podem funcionar melhor em casos em que conjuntos de dados proprietários são publicados diretamente pelo proprietário com uma assinatura amplamente aceita. No entanto, eles também trazem benefícios: -#### Garantias de baixa exatidão {#low-correctness-guarantees} +#### Baixas garantias de correção {#low-correctness-guarantees} -Com oráculos centralizados, não há como confirmar se as informações prestadas estão corretas ou não. O provedor oracle pode ser "conceituado", mas isso não elimina a possibilidade de alguém se tornar desonesto ou um hacker adulterar o sistema. Se o oráculo se tornar corrompido, os contratos inteligentes serão executados com base em dados ruins. +Com oráculos centralizados, não há como confirmar se as informações prestadas estão corretas ou não. Até mesmo provedores "respeitáveis" podem se tornar desonestos ou ser hackeados. Se o oráculo se tornar corrompido, os contratos inteligentes serão executados com base em dados ruins. #### Baixa disponibilidade {#poor-availability} -Os oráculos centralizados não garantem sempre disponibilizar dados off-chain para outros contratos inteligentes. Se o provedor decidir desligar o serviço ou um hacker sequestrar o componente off-chain do oráculo, seu contrato inteligente correrá o risco de um ataque de negação de serviço (DoS). +Os oráculos centralizados não garantem sempre disponibilizar dados off-chain por outros contratos inteligentes. Se o provedor decidir desligar o serviço ou um hacker sequestrar componente off-chain de oráculo, seu contrato inteligente terá o risco de DoS. -#### Incentivo insuficiente de compatibilidade {#poor-incentive-compatibility} +#### Baixa compatibilidade de incentivos {#poor-incentive-compatibility} -Oráculos centralizados muitas vezes têm incentivos mal projetados ou inexistentes para que o provedor de dados envie informações precisas/inalteradas. Pagar o oráculo por seus serviços pode encorajar um comportamento honesto, mas isso pode não ser suficiente. Com contratos inteligentes controlando enormes quantidades de valor, a recompensa pela manipulação de dados do oráculo é maior do que nunca. +Oráculos centralizados muitas vezes têm incentivos mal projetados ou inexistentes para que o provedor de dados envie informações precisas/inalteradas. Pagar um oráculo pela exatidão dele não garante honestidade. Esse problema aumenta à medida que a quantidade de valor controlado pelos contratos inteligentes aumenta. ### Oráculos descentralizados {#decentralized-oracles} -Os oráculos descentralizados são concebidos para superar as limitações dos oráculos centralizados, eliminando pontos únicos de fracasso. Um serviço oráculo descentralizado inclui vários participantes em uma rede peer-to-peer que formam consenso sobre dados off-chain antes de enviá-los para um contrato inteligente. +Os oráculos descentralizados são concebidos para superar as limitações dos oráculos centralizados, eliminando pontos únicos de fracasso. Um serviço de oráculo descentralizado inclui vários participantes em rede peer-to-peer que formam consenso sobre dados off-chain antes de os enviar por contrato inteligente. Um oráculo descentralizado deveria (idealmente) ser sem permissão, sem confiança e livre de administração por uma parte central; na realidade, a descentralização entre os oráculos é um espectro. Existem redes de oráculos semidescentralizadas onde qualquer um pode participar, mas com um "proprietário" que aprova e remove nós com base no desempenho histórico. Redes oráculas totalmente descentralizadas também existem: elas geralmente são executadas como blockchains autônomas e possuem mecanismos de consenso definidos para coordenar nós e punir o comportamento errado. O uso de oráculos descentralizados vem com os seguintes benefícios: -### Garantias de alta exatidão {#high-correctness-guarantees} +### Altas garantias de correção {#high-correctness-guarantees} -Oráculos descentralizados tentam alcançar a exatidão dos dados utilizando diferentes abordagens. Isso inclui o uso de provas de autenticidade e integridade das informações retornadas e a exigência de que várias entidades concordem coletivamente com a validade dos dados off-chain. +Oráculos descentralizados tentam alcançar a exatidão dos dados utilizando diferentes abordagens. Isto inclui provas de autenticidade e integridade das informações retornadas e a exigência de que várias entidades concordem coletivamente com a validade dos dados off-chain. #### Provas de autenticidade {#authenticity-proofs} @@ -260,15 +256,15 @@ As provas de autenticidade são mecanismos de criptografia que permitem a verifi Exemplos de provas de autenticidade incluem: -**Provas de Transport Layer Security (TLS)**: os nós oráculos geralmente recuperam dados de fontes externas usando uma conexão HTTP segura baseada no protocolo Transport Layer Security (TLS). Alguns oráculos descentralizados usam provas de autenticidade para verificar as sessões TLS (ou seja, confirmar a troca de informações entre um nó e um servidor específico) e confirmar que o conteúdo da sessão não foi alterado. +**Provas de Transport Layer Security (TLS)**: Os nós de oráculo geralmente recuperam dados de fontes externas usando uma conexão HTTP segura com base no protocolo Transport Layer Security (TLS). Alguns oráculos descentralizados usam provas de autenticidade para verificar as sessões TLS (ou seja, confirmar a troca de informações entre um nó e um servidor específico) e confirmar que o conteúdo da sessão não foi alterado. -**Atestados de ambiente de execução confiável (TEE)**: um [ambiente de execução confiável](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) é um ambiente computacional reservado em área restrita isolado dos processos operacionais de seu sistema host. TEEs garantem que qualquer código de aplicativo ou dados armazenados/usados no ambiente de computação mantenham integridade, confidencialidade e imutabilidade. Os usuários também podem gerar um atestado para provar que uma instância do aplicativo está em execução no ambiente de execução confiável. +**Atestados do Ambiente de Execução Confiável (TEE)**: Um [ambiente de execução confiável](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) é um ambiente computacional em área restrita que é isolado dos processos operacionais do seu sistema anfitrião. TEEs garantem que qualquer código de aplicativo ou dados armazenados/usados no ambiente de computação mantenham integridade, confidencialidade e imutabilidade. Os usuários também podem gerar um atestado para provar que uma instância do aplicativo está em execução no ambiente de execução confiável. Certas classes de oráculos descentralizados exigem que os operadores de nós oráculos forneçam atestados TEE. Isto confirma para um usuário que o operador do nó está executando uma instância de cliente oráculo em um ambiente de execução confiável. TEEs impedem que processos externos alterem ou leiam o código e os dados de um aplicativo, portanto, estes atestados provam que o nó oráculo manteve as informações intactas e confidenciais. -#### Validação de informações baseadas em consenso {#consensus-based-validation-of-information} +#### Validação de informações baseada em consenso {#consensus-based-validation-of-information} -Os oráculos centralizados dependem de uma única fonte de verdade ao fornecer dados para contratos inteligentes, que introduz a possibilidade de publicar informações imprecisas. Oráculos descentralizados resolvem este problema confiando em vários nós oráculos para consultar informações off-chain. Ao comparar dados de múltiplas fontes, os oráculos descentralizados reduzem o risco de passar informações inválidas para contratos on-chain. +Os oráculos centralizados dependem de uma única fonte de verdade ao fornecer dados para contratos inteligentes, que introduz a possibilidade de publicar informações imprecisas. Oráculos descentralizados resolvem este problema confiando em vários nós de oráculo por consultar informações off-chain. Comparando dados de múltiplas fontes, os oráculos descentralizados reduzem o risco de passar informações inválidas para contratos on-chain. Oráculos descentralizados, entretanto, devem lidar com discrepâncias nas informações recuperadas de múltiplas fontes off-chain. Para minimizar diferenças nas informações e garantir que os dados passados para o contrato do oráculo reflitam a opinião coletiva dos nós do oráculo, os oráculos descentralizados usam os seguintes mecanismos: @@ -278,33 +274,33 @@ Algumas redes oráculos descentralizadas exigem que os participantes votem ou ap Os nós cujas respostas se desviam da maioria são penalizados, tendo seus tokens distribuídos para outros que fornecem valores mais corretos. Forçar os nós a fornecer uma caução antes de proporcionar dados incentiva respostas honestas, pois se supõe que eles são atores econômicos racionais com intenção de maximizar os retornos. -O staking/votação também protege oráculos descentralizados de "ataques Sybil", em que agentes maliciosos criam várias identidades para driblar o sistema de consenso. No entanto, o staking não pode impedir o "freeloading" (nós de oráculo copiando informações dos outros) e a "validação tardia" (nós de oráculos seguindo a maioria sem verificar eles mesmos as informações). +O staking/votação também protege os oráculos descentralizados de [ataques Sybil](/glossary/#sybil-attack), em que agentes mal-intencionados criam várias identidades para manipular o sistema de consenso. No entanto, o staking não pode impedir o "freeloading" (nós de oráculo copiando informações dos outros) e a "validação tardia" (nós de oráculos seguindo a maioria sem verificar eles mesmos as informações). ##### Mecanismos de ponto Schelling -O [ponto de Schelling]() é um conceito da teoria dos jogos que assume que várias entidades encontrarão sempre por padrão uma solução comum para um problema na ausência de qualquer comunicação. Os mecanismos do ponto de Schelling são frequentemente utilizados em redes descentralizadas de oráculos para permitir que os nós cheguem a consenso sobre as respostas às solicitações de dados. +O [ponto de Schelling](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\)) é um conceito da teoria dos jogos que pressupõe que várias entidades sempre adotarão uma solução comum para um problema na ausência de qualquer comunicação. Os mecanismos do ponto de Schelling são frequentemente utilizados em redes descentralizadas de oráculos para permitir que os nós cheguem a consenso sobre as respostas às solicitações de dados. -Um exemplo inicial é o [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed), uma proposta de feed de dados (oráculo), na qual os participantes submetem respostas para "escalar" perguntas (perguntas cujas respostas são descritas por magnitude, por exemplo, "qual é o preço do ETH?"), juntamente com um depósito. Os usuários que fornecem valores entre o 25º e 75º [percentil](https://en.wikipedia.org/wiki/Percentile) são recompensados, enquanto aqueles cujos valores se desviam amplamente da mediana são penalizados. +Uma ideia inicial para isso foi o [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/), um feed de dados proposto onde os participantes enviam respostas para perguntas "escalares" (perguntas cujas respostas são descritas por magnitude, por exemplo, "qual é o preço do ETH?"), juntamente com um depósito. Os usuários que fornecem valores entre o 25º e o 75º [percentil](https://en.wikipedia.org/wiki/Percentile) são recompensados, enquanto aqueles cujos valores se desviam muito do valor mediano são penalizados. -Embora o SchellingCoin não exista hoje, uma série de oráculos descentralizados, principalmente [Oráculos do Maker Protocol](https://docs.makerdao.com/smart-contract-modules/oracle-module), usam o mecanismo schelling-point para melhorar a precisão dos dados do oráculo. Cada Maker Oracle consiste de uma rede off-chain P2P de nós ("relayers" e "feeds") que submetem preços de mercado para ativos colaterais e um contrato on-chain "Medianizer" que calcula a mediana de todos os valores fornecidos. Quando o período de atraso especificado acaba, esta mediana se torna o novo preço de referência para o ativo associado. +Embora o SchellingCoin não exista hoje, vários oráculos descentralizados — notavelmente os [Oráculos do Protocolo Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module) — usam o mecanismo de ponto de Schelling para melhorar a precisão dos dados do oráculo. Cada Maker Oracle tem uma rede off-chain P2P de nós ("relayers" e "feeds") que submetem market prices para colaterais e um contrato on-chain "Medianizer" que calcula a mediana de todos os valores fornecidos. Quando o período de atraso especificado acaba, esta mediana se torna o novo preço de referência para o ativo associado. -Outros exemplos de oráculos que usam mecanismos de ponto de Schelling incluem [Chainlink Off-Chain Reporting](https://docs.chain.link/docs/off-chain-reporting/) e Witnet. Em ambos os sistemas, as respostas de nós oráculos da rede peer-to-peer são agregadas em um único valor agregado, como uma média ou mediana. Os nós são recompensados ou punidos de acordo com o grau de exatidão ou imprecisão de suas respostas com relação ao valor agregado. +Outros exemplos de oráculos que usam mecanismos de ponto de Schelling incluem o [Chainlink Offchain Reporting](https://docs.chain.link/architecture-overview/off-chain-reporting) e o [Witnet](https://witnet.io/). Em ambos os sistemas, as respostas de nós oráculos da rede peer-to-peer são agregadas em um único valor agregado, como uma média ou mediana. Os nós são recompensados ou punidos de acordo com o grau de exatidão ou imprecisão de suas respostas com relação ao valor agregado. -Os mecanismos de ponto de Schelling são atrativos porque minimizam a pegada on-chain (apenas uma transação precisa ser enviada) enquanto garantem a descentralização. O último é possível porque os nós devem aprovar a lista de respostas submetidas antes que ela seja introduzida no algoritmo que produz o valor médio/mediano. +O Schelling point é atrativo porque minimiza o espaço ocupado on-chain (apenas uma transação precisa ser enviada) enquanto garante a descentralização. O último é possível porque os nós devem aprovar a lista de respostas submetidas antes que ela seja introduzida no algoritmo que produz o valor médio/mediano. ### Disponibilidade {#availability} -Serviços de oráculo descentralizados garantem uma elevada disponibilidade de dados off-chain para contratos inteligentes. Isso é conseguido através da descentralização tanto da fonte de informação off-chain como dos nós responsáveis pela transferência da informação on-chain. +Serviços de oráculo descentralizados garantem disponibilidade de dados off-chain por contratos inteligentes. Isto é o resultado da descentralização da fonte de informação off-chain e dos nós responsáveis pela transferência da informação on-chain. -Isto garante tolerância a falhas, uma vez que o contrato do oráculo pode depender de vários nós (que também dependem de múltiplas fontes de dados) para executar consultas a partir de outros contratos. A descentralização no nível de origem _e_ operador de nó é crucial — uma rede de nós oráculos servindo informações recuperadas da mesma fonte irá enfrentar o mesmo problema que um oráculo centralizado. +Isto garante tolerância a falhas, uma vez que o contrato do oráculo pode depender de vários nós (que também dependem de múltiplas fontes de dados) para executar consultas a partir de outros contratos. A descentralização no nível da fonte _e_ do operador de nó é crucial — uma rede de nós de oráculo servindo informações recuperadas da mesma fonte enfrentará o mesmo problema que um oráculo centralizado. -Também é possível que os oráculos baseados em stake consigam cortar operadores de nó que não respondam rapidamente a solicitações de dados. Isto incentiva significativamente os nós oráculos a investirem em infraestruturas tolerantes a falhas e fornecerem dados em tempo hábil. +Também é possível que os stake-based oráculos consigam cortar operadores de nó que não respondam rapidamente a solicitações de dados. Isto incentiva significativamente os nós oráculos a investirem em infraestruturas tolerantes a falhas e fornecerem dados em tempo hábil. -### Boa compatibilidade com incentivos {#good-incentive-compatibility} +### Boa compatibilidade de incentivos {#good-incentive-compatibility} -Oráculos descentralizados implementam vários designs de incentivo para evitar o comportamento [bizantino](https://en.wikipedia.org/wiki/Byzantine_fault) entre os nós oráculos. Especificamente, eles alcançam a _atribuibilidade_ e _responsabilidade_: +Oráculos descentralizados implementam vários projetos de incentivo para evitar o comportamento [bizantino](https://en.wikipedia.org/wiki/Byzantine_fault) entre os nós do oráculo. Especificamente, eles alcançam _atribuibilidade_ e _responsabilização_: -1. Nós oráculos descentralizados são frequentemente obrigados a assinar os dados que eles fornecem em resposta a solicitações de dados. Essa informação ajuda a avaliar o desempenho histórico de nós oráculos, para que os usuários possam filtrar nós oráculos não confiáveis ao fazer solicitações de dados. Um exemplo é o [Sistema de Reputação de Algoritmos](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) da Witnet. +1. Nós oráculos descentralizados são frequentemente obrigados a assinar os dados que eles fornecem em resposta a solicitações de dados. Essa informação ajuda a avaliar o desempenho histórico de nós oráculos, para que os usuários possam filtrar nós oráculos não confiáveis ao fazer solicitações de dados. Um exemplo é o [Sistema de Reputação Algorítmica](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) do Witnet. 2. Os oráculos descentralizados, conforme explicado anteriormente, podem exigir que os nós façam stake confiando somente na verdade dos dados que eles submetem. Se a reivindicação é confirmada, esse staking pode ser restituído juntamente com recompensas por um serviço honesto. Mas também pode ser reduzido no caso de a informação ser incorreta, o que impões certa responsabilização. @@ -312,13 +308,15 @@ Oráculos descentralizados implementam vários designs de incentivo para evitar Os seguintes são casos de uso comuns para oráculos no Ethereum: -### Como recuperar dados financeiros {#retrieving-financial-data} +### Recuperando dados financeiros {#retrieving-financial-data} -As aplicações de [finanças descentralizadas](/defi/) (DeFi) permitem conceder empréstimos, pedir empréstimos e fazer trading de ativos. Tudo isso peer-to-peer. Isto muitas vezes requer obter diferentes informações relacionadas a finanças, incluindo dados de taxa de exchanges (para calcular o valor fiat de criptomoedas ou comparar preços de dois tokens) e dados de mercados de capital (para calcular o valor de ativos tokenizados, tais como ouro ou dólar americano). +Aplicações de [finanças descentralizadas](/defi/) (DeFi) permitem empréstimos, recebimentos e negociação de ativos peer-to-peer. Isso geralmente requer a obtenção de diferentes informações financeiras, incluindo dados de taxa de câmbio (para calcular o valor fiduciário de criptomoedas ou comparar preços de tokens) e dados de mercados de capitais (para calcular o valor de ativos tokenizados, como ouro ou dólar americano). -Se você planeja criar um protocolo de crédito DeFi, por exemplo, você precisará consultar os preços atuais de mercado dos ativos (por exemplo, ETH) depositados como garantia. Isso é para que o seu contrato inteligente possa determinar o valor dos ativos colaterais e determinar o quanto eles podem pedir emprestado no sistema. +Um protocolo de empréstimo DeFi, por exemplo, precisa consultar os preços de mercado atuais para ativos (por exemplo, ETH) depositados como garantia. Isso permite que o contrato determine o valor dos ativos colaterais e determine quanto ele pode tomar emprestado do sistema. -Os "oráculos de preços" populares (como costumam ser chamados) em DeFi incluem Chainlink Price Feeds, o protocolo composto [Open Price Feed](https://compound.finance/docs/prices), [Time-Weighted Average Prices (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) da Uniswap e [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module). É aconselhável entender as advertências que vêm com esses oráculos de preço antes de integrá-los no seu projeto. Este [artigo](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) fornece uma análise detalhada do que deve ser considerado ao planejar usar qualquer um dos oráculos de preço mencionados. +Os “oráculos de preços” populares (como são frequentemente chamados) no DeFi incluem os Feeds de Preços da Chainlink, o [Open Price Feed](https://compound.finance/docs/prices) do Protocolo Compound, os [Preços Médios Ponderados no Tempo (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) da Uniswap e os [Oráculos da Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module). + +Os construtores devem entender as ressalvas que acompanham esses oráculos de preços antes de integrá-los ao seu projeto. Este [artigo](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) fornece uma análise detalhada do que considerar ao planejar usar qualquer um dos oráculos de preço mencionados. Abaixo é um exemplo de como obter o preço ETH mais recente em seu contrato inteligente usando um feed de preço da Chainlink: @@ -357,69 +355,80 @@ contract PriceConsumerV3 { } ``` -### Geração aleatória verificável {#generating-verifiable-randomness} +### Gerando aleatoriedade verificável {#generating-verifiable-randomness} -Certas aplicações da blockchain, como jogos baseados em blockchain ou esquemas de loteria, requerem um alto nível de imprevisibilidade e aleatoriedade para funcionar efetivamente. No entanto, a execução determinística de blockchains elimina qualquer fonte de aleatoriedade. +Certas aplicativos blockchain, como jogos baseados em blockchain ou esquemas de loteria, requerem um alto nível de imprevisibilidade e aleatoriedade para funcionar efetivamente. Entretanto, a execução determinística de blockchains elimina a aleatoriedade. -A abordagem habitual é usar funções criptográficas pseudoaleatórias, como o `blockhash`, mas isso é passível de [manipulação por outros atores](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.), nomeadamente mineradores resolvendo o algoritmo de prova de trabalho. Além disso, a [mudança para a prova de participação](/roadmap/merge/) do Ethereum significa que os desenvolvedores não podem mais confiar em `blockhash` para obter aleatoriedade on-chain (no entanto, o [mecanismo RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) da Beacon Chain fornece uma fonte alternativa de aleatoriedade). +A abordagem original era usar funções criptográficas pseudoaleatórias, como `blockhash`, mas estas podiam ser [manipuladas por mineradores](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) resolvendo o algoritmo de prova de trabalho. Além disso, a [mudança do Ethereum para prova de participação](/roadmap/merge/) significa que os desenvolvedores não podem mais confiar no `blockhash` para aleatoriedade na cadeia. O [mecanismo RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) da Beacon Chain fornece uma fonte alternativa de aleatoriedade. -É possível gerar o valor aleatório off-chain e enviá-lo on-chain, mas fazer isso impõe requisitos de confiança elevados aos usuários. Eles devem acreditar que o valor foi verdadeiramente gerado através de mecanismos imprevisíveis e não foi alterado em trânsito. +É possível gerar valor aleatório off-chain e enviá-lo on-chain, mas fazer isso requer confiança elevada aos usuários. Eles devem acreditar que o valor foi verdadeiramente gerado através de mecanismos imprevisíveis e não foi alterado em trânsito. -Oráculos projetados para computação off-chain resolvem esse problema gerando com segurança resultados aleatórios off-chain que eles emitem on-chain juntamente com provas criptográficas que atestam a imprevisibilidade do processo. Um exemplo é [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (função aleatória verificável), que é um gerador de números aleatórios (RNG, pela sigla em inglês) com prova verificável e inviolável útil para a construção de contratos inteligentes confiáveis para aplicações que dependem de resultados imprevisíveis. +Os oráculos por computação off-chain resolvem este problema. Gerando com segurança resultados aleatórios off-chain, eles os emitem on-chain juntamente com provas criptográficas que atestam a imprevisibilidade do processo. Um exemplo é o [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (Função Aleatória Verificável), que é um gerador de números aleatórios (RNG) comprovadamente justo e à prova de adulteração, útil para criar contratos inteligentes confiáveis para aplicações que dependem de resultados imprevisíveis. -### Como obter resultados para eventos {#getting-outcomes-for-events} +### Obtendo resultados para eventos {#getting-outcomes-for-events} -Com oráculos, é fácil criar contratos inteligentes que respondam a eventos do mundo real. Os serviços de oráculo tornam isso possível, permitindo que os contratos se conectem a APIs externas através de componentes off-chain e consumam informações dessas fontes de dados. Por exemplo, o dapp de previsão mencionado anteriormente pode solicitar um oráculo para retornar resultados eleitorais de uma fonte confiável off-chain (por exemplo, a Associated Press). +Com oráculos, é fácil criar contratos inteligentes que respondam a eventos do mundo real. Os serviços de oráculo tornam isto possível permitindo que os contratos se conectem a APIs externas através de componentes off-chain e consumam informações dessas fontes de dados. Por exemplo, o dapp por previsão pode solicitar um oráculo por retornar resultados eleitorais de uma fonte confiável off-chain (por exemplo, Associated Press). -O uso de oráculos para recuperar dados baseados em resultados do mundo real permite outros novos casos de uso, incluindo aplicações de seguro descentralizadas. Um contrato inteligente de seguro que será pago aos usuários precisará de informações precisas (por exemplo, dados meteorológicos, relatórios de desastres, etc.) para funcionar eficazmente. +Usar oráculos para recuperar dados com base em resultados do mundo real permite outros novos casos de uso; por exemplo, um produto de seguro descentralizado precisa de informações precisas sobre clima, desastres, etc. para funcionar de forma eficaz. -### Como automatizar contratos inteligentes {#automating-smart-contracts} +### Automatizando contratos inteligentes {#automating-smart-contracts} -Contrariamente às descrições populares, os contratos inteligentes não funcionam automaticamente. Uma conta de propriedade externa (EOA, pela sigla em inglês), ou outra conta de contrato, deve acionar as funções certas para executar o código do contrato. Na maioria dos casos, a maior parte das funções do contrato são públicas e podem ser invocadas pelas EOAs e por outros contratos. +Os contratos inteligentes não são executados automaticamente; em vez disso, uma conta de propriedade externa (EOA), ou outra conta de contrato, deve acionar as funções corretas para executar o código do contrato. Na maioria dos casos, a maior parte das funções do contrato são públicas e podem ser invocadas pelas EOAs e por outros contratos. -Mas também existem _funções privadas_ dentro de um contrato que são inacessíveis a outros; estas são geralmente essenciais para a funcionalidade geral do dapp. Exemplos potenciais incluem uma função `mintERC721Token()` que minta periodicamente novas NFT para os usuários, uma função para a atribuição de pagamentos em um mercado de previsões, ou uma função para desbloquear tokens em stake em uma DEX. +Mas também existem _funções privadas_ dentro de um contrato que são inacessíveis para outros; mas que são críticas para a funcionalidade geral de um dapp. Exemplos incluem uma função `mintERC721Token()` que periodicamente cria novos NFTs para usuários, uma função para conceder pagamentos em um mercado de previsão ou uma função para desbloquear tokens em staking em uma DEX. Os desenvolvedores precisarão acionar essas funções em intervalos para manter o aplicativo executando sem problemas. No entanto, isso pode fazer com que os desenvolvedores passem mais tempo em tarefas corriqueiras, e é por isso que a automação da execução de contratos inteligentes é atraente. -Algumas redes descentralizadas de oráculos oferecem serviços de automação, que permitem que nós de oráculos off-chain acionem funções de contrato inteligente de acordo com parâmetros definidos pelo usuário. Normalmente, isso requer "registrar" o contrato-alvo com o serviço oráculo, fornecendo fundos para pagar o operador do oráculo, e especificar as condições ou horários para disparar o contrato. +Algumas redes descentralizadas de oráculo oferecem serviços de automação, que permitem que nós de oráculo off-chain abrirem funções de contrato inteligente de acordo com parâmetros definidos por usuário. Normalmente, isso requer "registrar" o contrato-alvo com o serviço oráculo, fornecendo fundos para pagar o operador do oráculo, e especificar as condições ou horários para disparar o contrato. -Um exemplo é a [Keeper Network](https://chain.link/keepers) da rede Chainlink, que fornece opções para que os contratos inteligentes terceirizem tarefas de manutenção regulares de maneira minimizada e descentralizada. Leia a [documentação oficial do Keeper](https://docs.chain.link/docs/chainlink-keepers/introduction/) para obter informações sobre como tornar seu contrato compatível com o Keeper e usar o serviço Upkeep. +A [Keeper Network](https://chain.link/keepers) da Chainlink fornece opções para que contratos inteligentes terceirizem tarefas de manutenção regulares de uma maneira descentralizada e com confiança minimizada. Leia a [documentação oficial do Keeper](https://docs.chain.link/docs/chainlink-keepers/introduction/) para obter informações sobre como tornar seu contrato compatível com o Keeper e usar o serviço Upkeep. -## Usar oráculos da blockchain {#use-blockchain-oracles} +## Como usar oráculos de cadeia de blocos {#use-blockchain-oracles} Existem vários aplicativos de oráculos que você pode integrar no seu dapp Ethereum: -**[Chainlink](https://chain.link/)**: _a rede Chainlink de oráculos descentralizados fornece entradas, saídas e computação à prova de adulteração para suportar contratos inteligentes avançados em qualquer blockchain._ +**[Chainlink](https://chain.link/)** - _As redes de oráculos descentralizados da Chainlink fornecem entradas, saídas e cálculos à prova de violação para dar suporte a contratos inteligentes avançados em qualquer cadeia de blocos._ + +**[RedStone Oracles](https://redstone.finance/)** - _A RedStone é um oráculo modular descentralizado que fornece feeds de dados otimizados para o gás._ Ela oferece price feeds por ativos emergentes, como os LSTs, LRTs e resultado da participação de Bitcoin._ + +**[Chronicle](https://chroniclelabs.org/)** - _A Chronicle supera as limitações atuais de transferência de dados na cadeia, desenvolvendo oráculos verdadeiramente escaláveis, econômicos, descentralizados e verificáveis._ + +**[Witnet](https://witnet.io/)** - _Witnet é um oráculo sem permissão, descentralizado e resistente à censura que ajuda os contratos inteligentes a reagir a eventos do mundo real com fortes garantias criptoeconômicas._ + +**[Oráculo da UMA](https://uma.xyz)** - _O oráculo otimista da UMA permite que contratos inteligentes recebam rapidamente qualquer tipo de dados para diferentes aplicações, incluindo seguros, derivativos financeiros e mercados de previsão._ + +**[Tellor](https://tellor.io/)** - _Tellor é um protocolo de oráculo transparente e sem permissão para que seu contrato inteligente obtenha facilmente quaisquer dados sempre que precisar._ -**[Witnet](https://witnet.io/)**: _Witnet é um óraculo sem permissão, descentralizado e resistente à censura, que ajuda os contratos inteligentes a reagir a eventos do mundo real com fortes garantias criptoeconômicas._ +**[Band Protocol](https://bandprotocol.com/)** - _O Band Protocol é uma plataforma de oráculo de dados de cadeia cruzada que agrega e conecta dados do mundo real e APIs a contratos inteligentes._ -**[UMA Oracle](https://uma.xyz)** – _UMA é um oráculo otimista que permite contratos de receber, rapidamente, qualquer tipo de dados para diferentes aplicações, incluindo seguros, derivativos financeiros e mercados de previsão._ +**[Pyth Network](https://pyth.network/)** - _A rede Pyth é uma rede de oráculos financeiros de primeira parte, projetada para publicar dados contínuos do mundo real na cadeia em um ambiente autossustentável, descentralizado e resistente a adulterações._ -**[Tellor](https://tellor.io/)**: _Tellor é um protocolo de oráculo transparente e sem permissão para que seu contrato inteligente obtenha facilmente quaisquer dados sempre que precisar._ +**[API3 DAO](https://www.api3.org/)** - _A API3 DAO está fornecendo soluções de oráculos primários que oferecem maior transparência, segurança e escalabilidade da fonte em uma solução descentralizada para contratos inteligentes_ -**[Band Protocol](https://bandprotocol.com/)**: _Band Protocol é uma plataforma de dados de oráculos cross-chain que agrega e conecta dados do mundo real e APIs a contratos inteligentes._ +**[Supra](https://supra.com/)** - Um conjunto de ferramentas verticalmente integrado de soluções de cadeia cruzada que interligam todas as cadeias de blocos, públicas (L1s e L2s) ou privadas (empresariais), fornecendo feeds de preços de oráculos descentralizados que podem ser usados para casos de uso na cadeia e fora da cadeia. -**[Rede Pyth](https://pyth.network/)** — _A rede Pyth é uma rede de oráculos financeiros internos projetada para publicar dados contínuos do mundo real em cadeia em um ambiente autossustentável, descentralizado e inviolável._ +**[Gas Network](https://gas.network/)** - Uma plataforma de oráculo distribuída que fornece dados de preços de gás em tempo real em toda a cadeia de blocos. Ao trazer dados dos principais provedores de dados de preços de gás para a cadeia, a Gas Network está ajudando a impulsionar a interoperabilidade. A Gas Network oferece suporte a dados para mais de 35 cadeias, incluindo a Rede Principal Ethereum e muitas L2s líderes. -## Leitura Adicional {#further-reading} +## Leitura adicional {#further-reading} **Artigos** -- [O que é um oráculo blockchain?](https://chain.link/education/blockchain-oracles) - _Chainlink_ (todos os links em inglês) -- [O que é um oráculo blockchain?](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) - _Patrick Collins_ -- [Oráculos descentralizados: um panorama abrangente](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) – _Julien Thevenard_ -- [Como implementar um oráculo blockchain no Ethereum](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ -- [Por que os contratos inteligentes não podem fazer chamadas à API?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) - _StackExchange_ -- [Você quer usar um oráculo para preços](https://samczsun.com/so-you-want-to-use-a-price-oracle/) -_samczsun_ +- [O que é um oráculo de cadeia de blocos?](https://chain.link/education/blockchain-oracles) — _Chainlink_ +- [O que é um oráculo de cadeia de blocos?](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Patrick Collins_ +- [Oráculos descentralizados: uma visão geral abrangente](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Julien Thevenard_ +- [Implementando um Oráculo de Cadeia de Blocos na Ethereum](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ +- [Por que contratos inteligentes não podem fazer chamadas de API?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_ +- [Então você quer usar um oráculo de preços](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_ **Vídeos** -- [Oráculos e a expansão da utilidade da blockchain](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ +- [Oráculos e a expansão da utilidade da cadeia de blocos](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ **Tutoriais** -- [Como obter o preço atual do Ethereum em Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) - _Chainlink_ +- [Como buscar o preço atual do Ethereum em Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_ +- [Consumindo dados de oráculos](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ **Exemplos de projetos** -- [Projeto Chainlink inicial completo para Ethereum em Solidity](https://github.com/hackbg/chainlink-fullstack) - _HackBG_ +- [Projeto inicial completo da Chainlink para Ethereum em Solidity](https://github.com/hackbg/chainlink-fullstack) — _HackBG_ diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/dart/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/dart/index.md index f4b1b45db48..480360f6bed 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/dart/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/dart/index.md @@ -5,24 +5,29 @@ lang: pt-br incomplete: true --- -## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity} +## Começando com contratos inteligentes e a 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. Escrevendo um contrato inteligente em [Solidity](https://soliditylang.org/) - 2. 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 a um vídeo, acesse [Criando seu primeiro app blockchain com Flutter](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), que dura 1 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 da WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - este vídeo 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) -- [Curso Bootcamp para Desenvolvedores de Blockchain Móvel com Solidity e Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - playlist de cursos para desenvolvedores de blockchain móvel full stack +- [Flutter e Blockchain – Dapp Olá Mundo](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) mostra todas as etapas para começar: + 1. Escrevendo um contrato inteligente em [Solidity](https://soliditylang.org/) + 2. Escrevendo uma interface de usuário no Dart +- [Construindo um dapp móvel com Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) é bem mais curto, o que pode ser melhor + se você já conhece o básico +- Se preferir aprender assistindo a um vídeo, pode assistir a [Construa seu primeiro aplicativo blockchain com Flutter](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), que tem cerca de uma hora de duração +- Se você for impaciente, talvez prefira [Construindo um aplicativo descentralizado de blockchain com Flutter e Dart na Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s), que dura apenas cerca de vinte minutos +- [Integrando o MetaMask no aplicativo Flutter com o Web3Modal da WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - este vídeo curto mostra as etapas para integrar o MetaMask em seus aplicativos Flutter com a biblioteca [Web3Modal](https://pub.dev/packages/web3modal_flutter) da WalletConnect +- [Curso Bootcamp para Desenvolvedor de Blockchain Móvel com Solidity e Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - playlist do curso para desenvolvedor 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 mantidas para Dart que usam a [API JSON-RPC](/developers/docs/apis/json-rpc/) para o Ethereum. +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 mantidas para Dart para usar a +[API JSON-RPC](/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) +1. [Web3dart de pwa.ir](https://pub.dev/packages/web3dart) +2. [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). +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. +[Você pode ver a lista completa aqui](https://pub.dev/dart/packages?q=ethereum). diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/delphi/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/delphi/index.md index 4d0abe5f506..949230dfb27 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/delphi/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/delphi/index.md @@ -1,6 +1,6 @@ --- title: Ethereum para desenvolvedores Delphi -description: Aprenda a desenvolver para o Ethereum usando a linguagem de programação Delphi +description: "Aprenda a desenvolver para o Ethereum usando a linguagem de programação Delphi" lang: pt-br incomplete: true --- @@ -11,46 +11,48 @@ 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. +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. 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} +## Começando com contratos inteligentes e a 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/). +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) +- [Blockchain 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 a Compilar e Implantar o Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -## Referências e Links para Iniciantes {#beginner-references-and-links} +## 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) +- [Conectando o Delphi a uma blockchain local (em memória)](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [Conectando o Delphi à rede principal da Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) +- [Conectando o Delphi a 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) +- [Um contrato inteligente de 3 minutos e Delphi - Parte 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [Um contrato inteligente de 3 minutos e Delphi - Parte 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) -## Artigos intermediários {#intermediate-articles} +## 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) +- [Gerando uma assinatura de mensagem assinada pela Ethereum em Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [Transferindo 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} +## Padrões de uso avançados {#advanced-use-patterns} -- [Delphi e nomes de serviço Ethereum (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [Delphi e o Ethereum Name Service (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) +- [Delphi e a Floresta Escura da Ethereum](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [Troca de 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/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/dot-net/index.md index 70bd887d3e5..2e7c010c661 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/dot-net/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/dot-net/index.md @@ -5,82 +5,84 @@ lang: pt-br incomplete: true --- -Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em .NET +Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseadas 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. +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. 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} +## Começando com contratos inteligentes e a 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/). +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) +- [Blockchain 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 a Compilar e Implantar o 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) +- [Nethereum, Primeiros Passos](https://docs.nethereum.com/en/latest/getting-started/) +- [Instalando o Solidity no VS Code](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) +- [O 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 Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [Criando uma interface entre .NET e contratos inteligentes da blockchain Ethereum com 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 blockchain](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Gravando transações da Ethereum em um banco de dados SQL usando Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [Veja como implantar facilmente contratos inteligentes da Ethereum usando C# e VisualStudio](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) +- [Playground](http://playground.nethereum.com/) - Interaja com a Ethereum e aprenda a usar o Nethereum pelo navegador. + - Consultar saldo da conta [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - Consultar saldo do contrato inteligente ERC20 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) + - Transferir 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} +## 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/) +- [Lista de exemplos/pasta de trabalho do Nethereum](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [Implante suas próprias Testchains de desenvolvimento](https://github.com/Nethereum/Testchains) +- [Plugin de geração de código para Solidity do VSCode](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unity e Ethereum: por que e como](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [Crie uma Web API ASP.NET Core para dapps da Ethereum](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [Usando o Nethereum Web3 para implementar um sistema de rastreamento da cadeia de suprimentos](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Processamento de blocos com Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), com [amostra do C# Playground](http://playground.nethereum.com/csharp/id/1025) +- [Transmissão por WebSocket com Nethereum](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) +- [Quorum 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/) +- [Arquitetura de referência 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} +## 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)_ +- [Nethereum Playground](http://playground.nethereum.com/) - _Compile, crie e execute trechos de código do Nethereum no navegador_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Codegen do Nethereum com interface do usuário em Blazor_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _Um explorador de blockchain leve e uma carteira simples de SPA em .NET Wasm_ +- [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 por metadados_ +- [Nethermind](https://github.com/NethermindEth/nethermind) - _Um cliente Ethereum .NET Core para Linux, Windows, MacOS_ +- [eth-utils](https://github.com/ethereum/eth-utils/) – _funções utilitárias para trabalhar com bases de código relacionadas à Ethereum_ +- [TestChains](https://github.com/Nethereum/TestChains) - _Devchains .NET pré-configuradas para resposta rápida (PoA)_ Procurando por mais recursos? Confira [ethereum.org/developers](/developers/). -## Colaboradores comunitários .NET {#dot-net-community-contributors} +## Contribuidores da comunidade .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)! +No Nethereum, costumamos nos encontrar no [Gitter](https://gitter.im/Nethereum/Nethereum), onde todos são bem-vindos para fazer/responder perguntas, obter ajuda ou simplesmente relaxar. Sinta-se à vontade para fazer um PR ou abrir uma issue no [repositório GitHub do Nethereum](https://github.com/Nethereum), ou simplesmente navegar pelos muitos projetos paralelos/de amostra que temos. Você também pode nos encontrar no [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). +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. Não hesite em abrir um PR ou levantar qualquer problema no [repositório do Nethermind no GitHub](https://github.com/NethermindEth/nethermind). ## Outras listas agregadas {#other-aggregated-lists} -[Site Oficial Nethereum](https://nethereum.com/) -[Site Oficial Nethermind](https://nethermind.io/) +[Site oficial do Nethereum](https://nethereum.com/) +[Site oficial do Nethermind](https://nethermind.io/) diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/elixir/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/elixir/index.md index d5792e6d1d6..9b699629701 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/elixir/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/elixir/index.md @@ -7,7 +7,7 @@ incomplete: false Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseadas em Elixir. -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íves de serem censurados. +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. ## Começando com contratos inteligentes e a linguagem Solidity {#getting-started-with-smart-contracts-and-solidity} @@ -49,7 +49,7 @@ Confira [ethereum.org/learn](/learn/) ou [ethereum.org/developers](/developers/) - [exw3](https://github.com/hswick/exw3) - _Cliente RPC Ethereum de alto nível para Elixir_ - [mana](https://github.com/mana-ethereum/mana) - _Implementação de nó completo do Ethereum escrita em Elixir_ -Procurando por mais recursos? Confira [nossa página para Desenvolvedores](/developers/). +Procurando mais recursos? Confira [nossa página para Desenvolvedores](/developers/). ## Contribuidores da comunidade Elixir {#elixir-community-contributors} diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/golang/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/golang/index.md index 9a6d1a947b1..42d201a88da 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/golang/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/golang/index.md @@ -5,80 +5,82 @@ lang: pt-br incomplete: true --- -Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseados no Go +Aprenda a desenvolver para o Ethereum usando projetos e ferramentas baseados em 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. +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} +## Começando com contratos inteligentes e a 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/). +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) +- [Blockchain 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 a Compilar e Implantar o Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Tutorial de Contratos](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) ## Artigos e livros para iniciantes {#beginner-articles-and-books} - [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_ +- [Use Golang para se conectar ao Ethereum](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Implantar contratos inteligentes da Ethereum usando Golang](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Um Guia Passo a Passo 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: Desenvolvimento Ethereum com Go](https://goethereumbook.org/) - _Desenvolva aplicações Ethereum com Go_ -## Artigos e documentos de nível Intermediário {#intermediate-articles-and-docs} +## Artigos e documentos intermediários {#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_ +- [Documentação do Go Ethereum](https://geth.ethereum.org/docs/) - _A documentação da implementação oficial do 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, provas múltiplas e processamento de transações_ +- [Erigon e Ethereum sem estado](https://youtu.be/3-Mn7OckSus?t=394) - _Conferência da Comunidade Ethereum de 2020 (EthCC 3)_ +- [Erigon: otimizando clientes Ethereum](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _Devcon 4, 2018_ - [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) +- [Trabalhe com a Rede Privada Ethereum com Golang e Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Teste de unidade de contratos Solidity no Ethereum com Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Referência rápida para usar o Geth como uma 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) +- [Aplicações de Blockchain como Serviço usando Ethereum e Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [Armazenamento Distribuído IPFS e Swarm em Aplicações de Blockchain 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: bindings Go para 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} +## Projetos e ferramentas 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_ +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Implementação oficial em Go do protocolo da Ethereum_ +- [Análise de Código do Go Ethereum](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Revisão e análise 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_ +- [Golem](https://github.com/golemfactory/golem) - _O Golem está criando um mercado global para poder de computação_ +- [Quorum](https://github.com/jpmorganchase/quorum) - _Uma implementação permissionada da Ethereum com suporte à privacidade de dados_ +- [Prysm](https://github.com/prysmaticlabs/prysm) - _Implementação em Go do Ethereum 'Serenity' 2.0_ +- [Eth Tweet](https://github.com/yep/eth-tweet) - _Twitter descentralizado: um serviço de microblogging executado na blockchain Ethereum_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Implementação e extensão em Golang da especificação do Plasma Mínimo Viável_ +- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Um pool de mineração Ethereum de código aberto_ +- [Carteira HD Ethereum](https://github.com/miguelmota/go-ethereum-hdwallet) - _Derivações de Carteira HD Ethereum em Go_ +- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Suporte para vários tipos de redes Ethereum_ +- [Cliente Leve Geth](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Implementação Geth do Subprotocolo Leve Ethereum_ +- [SDK Ethereum para Golang](https://github.com/everFinance/goether) - _Uma implementação simples de carteira Ethereum e utilitários em Golang_ +- [SDK Covalent para Golang](https://github.com/covalenthq/covalent-api-sdk-go) - _Acesso eficiente a dados de 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} +## Contribuidores 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) +- [Slack dos Gophers](https://invite.slack.golangbridge.org/) - [canal #ethereum](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) +- [Gitter do Ethereum](https://gitter.im/ethereum/home) +- [Gitter do Cliente Leve 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) +- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: Uma Lista Definitiva de Ferramentas para Desenvolvedores Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Fonte no GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/index.md index 2f2aba6889e..9652e265d60 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/index.md @@ -1,10 +1,11 @@ --- -title: Linguagens de programação -description: +title: "Linguagens de programação" +description: "Descobrir recursos de desenvolvimento Ethereum para várias línguas de programação, incluindo JavaScript, Python, Go, Rust e muito mais." 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. +Um equívoco comum é que os desenvolvedores precisam escrever [contratos inteligentes](/developers/docs/smart-contracts/) para construir no Ethereum. Isso é falso. +Uma das belezas da rede e da comunidade Ethereum é que você pode [participar](/community/) em praticamente qualquer 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. @@ -12,19 +13,21 @@ Ethereum e sua comunidade abraçam código aberto. Você pode encontrar projetos 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 Elixir](/developers/docs/programming-languages/elixir/) -- [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/) +- [Ethereum para desenvolvedores de Dart](/developers/docs/programming-languages/dart/) +- [Ethereum para desenvolvedores de Delphi](/developers/docs/programming-languages/delphi/) +- [Ethereum para desenvolvedores de .NET](/developers/docs/programming-languages/dot-net/) +- [Ethereum para desenvolvedores de Elixir](/developers/docs/programming-languages/elixir/) +- [Ethereum para desenvolvedores de Go](/developers/docs/programming-languages/golang/) +- [Ethereum para desenvolvedores de Java](/developers/docs/programming-languages/java/) +- [Ethereum para desenvolvedores de JavaScript](/developers/docs/programming-languages/javascript/) +- [Ethereum para desenvolvedores de Python](/developers/docs/programming-languages/python/) +- [Ethereum para desenvolvedores de Ruby](/developers/docs/programming-languages/ruby/) +- [Ethereum para desenvolvedores de 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 criar um link para recursos ou indicar uma comunidade virtual para uma linguagem de programação adicional, poderá solicitar uma nova página [abrindo uma issue](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. +Se você quer apenas escrever código para interagir com a blockchain usando uma linguagem atualmente não suportada, +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/developers/docs/programming-languages/java/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/java/index.md index 283176e1fc5..7cc8f901153 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/java/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/java/index.md @@ -5,59 +5,62 @@ lang: pt-br incomplete: true --- -Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Java +Aprenda a desenvolver para Ethereum usando projetos e ferramentas baseadas 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. +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. -## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity} +## Começando com contratos inteligentes e a linguagem Solidity {#getting-started-with-smart-contracts-and-solidity} -**Dê seus primeiros passos para integrar Java com Ethereum ** +**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/) +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) +- [Blockchain 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 a Compilar e Implantar o Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -## Trabalhando com clientes Ethereum {#working-with-ethereum-clients} +## 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 +Aprenda a usar o [Web3J](https://github.com/web3j/web3j) e o Hyperledger Besu, dois dos principais clientes Java para 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. +- [Gerenciar 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 Contrato Inteligente](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [Interagindo com um Contrato Inteligente da Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [Escutando Eventos de Contratos Inteligentes da Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [Usando Besu (Pantheon), o cliente Java Ethereum com Linux](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [Executando um nó Hyperledger Besu (Pantheon) em testes de integração Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Folha de dicas do Web3j](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c) + +Aprenda a usar o [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) +- [Swap no 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 de 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} +## 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) +- [Gerenciar tokens ERC20 em Java com Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) +- [Gerenciadores de transação do Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) -## Padrões de uso avançados {#advanced-use-patterns} +## 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) +- [Usando o Eventeum para criar um cache de dados de contratos inteligentes 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} +## Projetos e ferramentas Java {#java-projects-and-tools} -- [Web3J (Biblioteca para Interagir com Clientes Ethereum)](https://github.com/web3j/web3j) +- [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) +- [Eventeum (ouvinte de eventos)](https://github.com/ConsenSys/eventeum) +- [Mahuta (Ferramentas de desenvolvimento para IPFS)](https://github.com/ConsenSys/mahuta) -Procurando por mais recursos? Leia [ethereum.org/developers.](/developers/) +Procurando por mais recursos? Confira [ethereum.org/developers.](/developers/) -## Colaboradores da comunidade Java {#java-community-contributors} +## Contribuidores da comunidade Java {#java-community-contributors} - [IO Builders](https://io.builders) - [Kauri](https://kauri.io) diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/javascript/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/javascript/index.md index 3fe8201fb9c..cc51948647e 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/javascript/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/javascript/index.md @@ -4,35 +4,36 @@ description: Aprenda a desenvolver para Ethereum utilizando projetos e ferrament 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. +O JavaScript está entre as linguagens mais populares no ecossistema Ethereum. De fato, existe uma [equipe](https://github.com/ethereumjs) dedicada a trazer o máximo de Ethereum para o JavaScript possível. -Existem oportunidades para escrever JavaScript (ou algo parecido) em [todos os níveis de pilhas](/developers/docs/ethereum-stack/). +Existem oportunidades para escrever JavaScript (ou algo próximo) em [todos os níveis da pilha](/developers/docs/ethereum-stack/). -## Interagir com Ethereum {#interact-with-ethereum} +## Interagir com o 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/). +Se você deseja escrever em JavaScript para consultar a blockchain, enviar transações e muito mais, a maneira mais conveniente de fazer isso é usando uma [biblioteca de API JavaScript](/developers/docs/apis/javascript/). Estas APIs permitem que os desenvolvedores interajam facilmente com os [nós na 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. +- [Web3.js](https://web3js.readthedocs.io) +- [Ethers.js](https://ethers.org) – _inclui implementação de carteira Ethereum e utilitários em JavaScript e TypeScript._ +- [viem](https://viem.sh) – _uma Interface TypeScript para o Ethereum que fornece primitivas de baixo nível e sem estado para interagir com o Ethereum._ +- [Drift](https://ryangoree.github.io/drift/) – _uma meta-biblioteca TypeScript com cache, hooks e mocks de teste integrados para um desenvolvimento Ethereum sem esforço em várias bibliotecas web3._ -### Smart Contracts {#smart-contracts} +### Contratos inteligentes {#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. +Se você é um desenvolvedor JavaScript e quer escrever seu próprio contrato inteligente, talvez queira se familiarizar com o [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/). +Mais sobre [contratos inteligentes](/developers/docs/smart-contracts/). -## Entender o protocolo {#understand-the-protocol} +## Entenda o protocolo {#understand-the-protocol} -### A Máquina Virtual da Ethereum {#the-ethereum-virtual-machine} +### A máquina virtual 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. +Existe uma implementação em JavaScript da [máquina virtual 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: @@ -46,17 +47,15 @@ Isso ajudará você a entender coisas como "qual é a estrutura de dados de uma 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) +**Confira a EVM** +[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) ### 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) +**Confira o cliente** +[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) ## Outros projetos {#other-projects} @@ -64,10 +63,10 @@ Há também muitas outras coisas acontecendo na terra da Ethereum JavaScript, in - 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. +- uma implementação da `merkle-patricia-tree` – uma estrutura de dados descrita no Yellow Paper do 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/python/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/python/index.md index 3f1f12b822e..2c0c122da67 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/python/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/python/index.md @@ -5,86 +5,97 @@ lang: pt-br incomplete: true --- -Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Python +Aprenda a desenvolver para o Ethereum usando 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. +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} +## Começando com contratos inteligentes e a 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/). +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) +- [Blockchain 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 a Compilar e Implantar o Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Relatório O estado do Python na blockchain em 2023](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) -## Artigos para Iniciantes {#beginner-articles} +## 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) +- [Visão geral do web3.py](https://web3py.readthedocs.io/en/latest/overview.html) +- [Tour pelo Ecossistema Python da Ethereum](https://snakecharmers.ethereum.org/python-ecosystem/) +- [Um Guia do Desenvolvedor (Python) para Ethereum](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [Digno de prêmio: um guia de hackathon de Python para Ethereum](https://snakecharmers.ethereum.org/prize-worthy/) +- [Uma introdução aos contratos inteligentes com Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Como desenvolver um contrato Ethereum usando Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Introdução ao Web3.py · Ethereum para desenvolvedores Python](https://www.dappuniversity.com/articles/web3-py-intro) +- [Como chamar uma função de contrato inteligente usando 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} +## Artigos Intermediários {#intermediate-articles} -- [Desenvolvimento de Dapp para programadores Python](https://www.youtube.com/watch?v=tE-8bG35VNw) -- [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/) +- [Amigos do web3.py: introdução ao Ape](https://snakecharmers.ethereum.org/intro-to-ape/) +- [Desenvolvimento de Dapp para Programadores Python](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) +- [Criando uma Interface Python para Ethereum: Parte 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [Contratos inteligentes da Ethereum em Python: um guia (quase) completo](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) ## 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/) +- [Padrões do web3.py: inscrições de evento em tempo real](https://snakecharmers.ethereum.org/subscriptions/) +- [Padrões do web3.py: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/) +- [Compilando, implantando e chamando contratos inteligentes da Ethereum usando Python](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [Analisar contratos inteligentes em Solidity com o Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [Tutorial de Fintech em Blockchain: empréstimos e recebimento de empréstimos com Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) -## Projetos e ferramentas em Python {#python-projects-and-tools} +## Artigos Arquivados + +- [Implante seu próprio Token ERC20 com Python e Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [Usando o Brownie e o Python para implantar Contratos Inteligentes](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [Criando NFTs no OpenSea com o Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) + +## Projetos e ferramentas 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/signinwithethereum/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))_ +- [Web3.py](https://github.com/ethereum/web3.py) – _biblioteca Python para interagir com a Ethereum_ +- [Vyper](https://github.com/ethereum/vyper/) – _linguagem de contrato inteligente pythônica para a EVM_ +- [Ape](https://github.com/ApeWorX/ape) – _A ferramenta de desenvolvimento de contratos inteligentes para Pythonistas, cientistas de dados e profissionais de segurança_ +- [py-evm](https://github.com/ethereum/py-evm) – _implementação da Máquina Virtual Ethereum_ +- [eth-tester](https://github.com/ethereum/eth-tester) – _ferramentas para testar aplicativos baseados em Ethereum_ +- [eth-utils](https://github.com/ethereum/eth-utils/) – _funções utilitárias para trabalhar com bases de código relacionadas à Ethereum_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) – _wrapper Python em torno do compilador solc Solidity com suporte a 0.5.x_ +- [pymaker](https://github.com/makerdao/pymaker) – _API em Python para contratos Maker_ +- [siwe](https://github.com/signinwithethereum/siwe-py) – _Sign in with Ethereum (siwe) para Python_ +- [Web3 DeFi para integrações com 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, verificação de vulnerabilidades e navegação de código (servidor de linguagem - [Ferramentas para Solidity](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_ +- [Trinity](https://github.com/ethereum/trinity) – _cliente Python do Ethereum_ +- [Mamba](https://github.com/arjunaskykok/mamba) – _framework para escrever, compilar e implantar contratos inteligentes escritos na linguagem Vyper_ +- [Brownie](https://github.com/eth-brownie/brownie) – _framework Python para implantar, testar e interagir com contratos inteligentes da Ethereum_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) – _implementação da pilha P2P da Ethereum_ +- [py-wasm](https://github.com/ethereum/py-wasm) – _implementação em Python do interpretador Web Assembly_ Procurando por mais recursos? Confira [ethereum.org/developers](/developers/). -## Projetos usando as ferramentas Python {#projects-using-python-tooling} +## Projetos que usam 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 Venture DAO](https://alphaventuredao.io/), da Alpha Homora fame, usa [Brownie para testar e implantar contratos inteligentes](https://github.com/AlphaFinanceLab/alpha-staking-contract) +- [Yearn Finance](https://yearn.finance/) e [repositório de contratos do Yearn Vault](https://github.com/yearn/yearn-vaults) +- [Curve](https://www.curve.finance/) e [repositório de contratos inteligentes da Curve](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/) e [contratos inteligentes que usam o conjunto de ferramentas do Brownie](https://github.com/Badger-Finance/badger-system) +- O [Sushi](https://sushi.com/) usa [Python no gerenciamento e na implantação de seus contratos de aquisição](https://github.com/sushiswap/sushi-vesting-protocols) +- A [Alpha Finance](https://alphafinance.io/), famosa pelo Alpha Homora, usa o [Brownie para testar e implantar contratos inteligentes](https://github.com/AlphaFinanceLab/alpha-staking-contract) -## Comunidade de discussão Python {#python-community-contributors} +## Discussão da comunidade 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ões sobre a programação de contratos inteligentes com Vyper +- [Discord da Comunidade Python da Ethereum](https://discord.gg/9zk7snTfWe) para discussão sobre o Web3.py e outras estruturas Python +- [Discord do Vyper](https://discord.gg/SdvKC79cJk) para discussão sobre programação de contratos inteligentes em Vyper -## Demais listas agregadas {#other-aggregated-lists} +## Outras listas agregadas {#other-aggregated-lists} -A wiki Vyper tem uma [Lista incrível de recursos sobre Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) \ No newline at end of file +A wiki do Vyper tem uma [lista incrível de recursos para o 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/developers/docs/programming-languages/ruby/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/ruby/index.md index bdc3eddfb5f..a6b60411901 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/ruby/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/ruby/index.md @@ -9,52 +9,53 @@ incomplete: false 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} +## Começando com contratos inteligentes e a 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/). +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) +- [Blockchain 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 a Compilar e Implantar o Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -## Artigos para Iniciantes {#beginner-articles} +## 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) +- [Finalmente entendendo as contas da Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Finalmente autenticando usuários do Rails com a MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) - [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} +## 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) +- [Aplicativo de cadeia de blocos com Ruby](https://www.nopio.com/blog/blockchain-app-ruby/) +- [Use o Ruby, conectado ao Ethereum, para executar o Contrato Inteligente](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) -## Projetos e ferramentas Ruby {#ruby-projects-and-tools} +## Projetos e ferramentas para Ruby {#ruby-projects-and-tools} -### Ativos {#active} +### Ativo {#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/signinwithethereum/siwe-ruby) - _Implementação Ruby de Login com Ethereum_ -- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _Gem do Rails que adiciona rotas de login local da SIWE_ -- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _Exemplo SIWE usando Ruby on Rails com controlador_ -- [omniauth-siwe](https://github.com/signinwithethereum/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_ +- [keccak.rb](https://github.com/q9f/keccak.rb) - _O hash Keccak (SHA3) usado pelo Ethereum_ +- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Implementação em Ruby do Sign-In with Ethereum_ +- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _Gem do Rails que adiciona rotas de login local do SIWE_ +- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _Exemplo de SIWE usando Ruby on Rails com um controlador personalizado_ +- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _Estratégia OmniAuth para Sign In With Ethereum (SIWE)_ +- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _Estratégia OmniAuth para autenticação via propriedade de NFT_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _Modelo do Ethereum on Rails que permite conectar a MetaMask ao Ruby on Rails_ + +### Arquivado / Não é mais mantido {#archived--no-longer-maintained} + +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _Chamando métodos RPC de um 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 do Ethereum para Ruby on Rails_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _Cliente Ruby Ethereum que usa a interface JSON-RPC para enviar transações, criar e interagir com contratos, bem como um kit de ferramentas útil para trabalhar com o 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/). +Procurando por mais recursos? Confira [nossa página para Desenvolvedores](/developers/). -## Colaboradores da comunidade Ruby {#ruby-community-contributors} +## Contribuidores 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. +O [grupo Ethereum Ruby no Telegram](https://t.me/ruby_eth) é o lar de uma comunidade em rápido crescimento e o recurso dedicado para discussões sobre quaisquer dos projetos acima e tópicos relacionados. diff --git a/public/content/translations/pt-br/developers/docs/programming-languages/rust/index.md b/public/content/translations/pt-br/developers/docs/programming-languages/rust/index.md index 778eeb53457..fe36a3fef86 100644 --- a/public/content/translations/pt-br/developers/docs/programming-languages/rust/index.md +++ b/public/content/translations/pt-br/developers/docs/programming-languages/rust/index.md @@ -5,57 +5,61 @@ lang: pt-br incomplete: true --- -Aprenda a desenvolver para Ethereum utilizando projetos e ferramentas baseados em Rust +Aprenda a desenvolver para Ethereum usando 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. +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. -## Introdução aos contratos inteligentes e linguagem Solidity {#getting-started-with-smart-contracts-and-solidity} +## Começando com contratos inteligentes e a 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/). +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) +- [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 a Compilar e Implantar o Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -## Artigos para Iniciantes {#beginner-articles} +## Artigos para iniciantes {#beginner-articles} -- [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) +- [O Cliente Ethereum Rust](https://openethereum.github.io/) \* **Observação: 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 cautela e, de preferência, mude para outra implementação de cliente. +- [Enviando Transação para o Ethereum Usando Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) +- [Um tutorial passo a passo sobre como escrever contratos em Rust Wasm para a Kovan](https://github.com/paritytech/pwasm-tutorial) -## Artigos para intermediários {#intermediate-articles} +## Artigos Intermediários {#intermediate-articles} -## Padrões de utilização avançada {#advanced-use-patterns} +## Padrões de uso avançados {#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) +- [biblioteca de externos pwasm_ethereum para interagir com redes do tipo Ethereum](https://github.com/openethereum/pwasm-ethereum) -- [Construir uma blockchain no Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) +- [Crie um bate-papo descentralizado usando JavaScript e Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) -## Projetos e ferramentas em Rust {#rust-projects-and-tools} +- [Crie um aplicativo de tarefas descentralizado usando Vue.js & Rust](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) -- [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/foundey-rs/foundry) — _Conjunto de ferramentas para o desenvolvimento de aplicativos Ethereum_ -- [Alloy](https://alloy.rs) - _Bibliotecas de alto desempenho, bem testadas e documentadas para interagir com Ethereum e outras cadeias baseadas em EVM._ +- [Construa uma cadeia de blocos em Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) + +## Projetos e ferramentas Rust {#rust-projects-and-tools} + +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Coleção de externos para interagir com rede do tipo 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 de WebAssembly_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Referência da API do OASIS_ +- [Solaris](https://github.com/paritytech/sol-rs) - _Ferramenta de teste de unidade de contratos inteligentes Solidity usando o EVM nativo do cliente Parity._ +- [SputnikVM](https://github.com/rust-blockchain/evm) - _Implementação da Máquina Virtual Ethereum em Rust_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Contrato inteligente Wavelet em Rust_ +- [Foundry](https://github.com/foundry-rs/foundry) - _Kit de ferramentas para desenvolvimento de aplicativos Ethereum_ +- [Alloy](https://alloy.rs) - _Bibliotecas de alto desempenho, bem testadas e documentadas para interagir com o 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 +- [SewUp](https://github.com/second-state/SewUp) - _Uma biblioteca para ajudar você a construir seu contrato webassembly do Ethereum com Rust, assim como desenvolver em um backend comum_ +- [Substreams](https://github.com/streamingfast/substreams) - _Tecnologia de indexação de dados de cadeia de blocos paralelizada_ +- [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/) +Procurando por mais recursos? Confira [ethereum.org/developers.](/developers/) -## Colaboradores da comunidade Rust {#rust-community-contributors} +## Contribuidores da comunidade Rust {#rust-community-contributors} - [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) - [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) diff --git a/public/content/translations/pt-br/developers/docs/scaling/index.md b/public/content/translations/pt-br/developers/docs/scaling/index.md index 827cb3d1d66..0ca69ae8865 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/index.md @@ -1,52 +1,52 @@ --- -title: Dimensionamento -description: Uma introdução às diferentes opções de dimensionamento atualmente em desenvolvimento pela comunidade Ethereum. +title: Escalabilidade +description: "Uma introdução às diferentes opções de dimensionamento atualmente em desenvolvimento pela comunidade Ethereum." lang: pt-br sidebarDepth: 3 --- -## Visão geral do dimensionamento {#scaling-overview} +## Visão geral da escalabilidade {#scaling-overview} À medida que o número de usuários do Ethereum aumenta, a blockchain atinge certas limitações de capacidade. Isso tem elevado os custos de utilização da rede, criando a necessidade de "soluções de dimensionamento". Existem várias soluções sendo pesquisadas, testadas e implementadas que adotam diferentes abordagens para atingir metas semelhantes. -O principal objetivo da escalabilidade é aumentar a velocidade das transações (finalidade mais rápida) e a capacidade de transações (maior número de transações por segundo) sem sacrificar a descentralização ou a segurança. Na camada 1 da blockchain de Ethereum, a alta demanda leva a transações mais lentas e a [preços de gás](/developers/docs/gas/) inviáveis. Aumentar a capacidade da rede em termos de velocidade e taxa de transferência é fundamental para uma adoção significativa e massiva do Ethereum. +O principal objetivo da escalabilidade é aumentar a velocidade de transação (finalidade mais rápida) e a taxa de transferência de transações (maior número de transações por segundo), sem sacrificar a descentralização ou a segurança. Na blockchain de camada 1 da Ethereum, a alta demanda leva a transações mais lentas e [preços de gás](/developers/docs/gas/) inviáveis. Aumentar a capacidade da rede em termos de velocidade e taxa de transferência é fundamental para uma adoção significativa e massiva do Ethereum. Embora a velocidade e a taxa de transferência sejam importantes, é essencial que tais soluções de dimensionamento habilitadas para tais fins permaneçam descentralizadas e seguras. Manter a barreira de entrada baixa para os operadores de nó é fundamental para prevenir uma progressão rumo a um poder de computação centralizado e inseguro. -Conceitualmente, primeiro classificamos o dimensionamento como dimensionamento on-chain ou dimensionamento off-chain. +Conceptually we first categorize scaling as either onchain scaling or offchain scaling. ## Pré-requisitos {#prerequisites} Você deveria ter um bom entendimento de todos os tópicos fundamentais. Implementar soluções de dimensionamento é um conceito avançado, já que a tecnologia é menos testada e continua a ser pesquisada e desenvolvida. -## Dimensionamento on-chain {#on-chain-scaling} +## Escalabilidade na cadeia {#onchain-scaling} -A escalabilidade em cadeia requer mudanças no protocolo do Ethereum ([Mainnet](/glossary/#mainnet) de camada 1). A solução de fragmentação da blockchain era aguardada há muito tempo para escalar o Ethereum. Isso implicava dividir a blockchain em partes discretas (fragmentos), que seriam verificadas por subconjuntos de validadores. No entanto, a técnica de escalabilidade principal adotada foi a de escalar por rollups de camada 2. Ela é suportada pela adição de uma nova forma mais barata de dados anexados aos blocos Ethereum, que foi especialmente criada para tornar os rollups baratos para os usuários. +A escalabilidade na cadeia exige alterações no protocolo Ethereum (camada 1 da [Mainnet](/glossary/#mainnet)). A solução de fragmentação da blockchain era aguardada há muito tempo para escalar o Ethereum. Isso implicava dividir a blockchain em partes discretas (fragmentos), que seriam verificadas por subconjuntos de validadores. No entanto, a técnica de escalabilidade principal adotada foi a de escalar por rollups de camada 2. Ela é suportada pela adição de uma nova forma mais barata de dados anexados aos blocos Ethereum, que foi especialmente criada para tornar os rollups baratos para os usuários. -### Fragmentação {#sharding} +### Sharding {#sharding} -Fragmentação é o processo de dividir um banco de dados. Subconjuntos de validadores seriam responsáveis por seus próprios fragmentos, em vez de manter o controle de todo o Ethereum. A fragmentação esteve no [planejamento](/roadmap/) do Ethereum por muito tempo, com a intenção de ser enviada para prova de participação antes do The Merge (A Fusão). No entanto, o rápido desenvolvimento de [rollups de camada 2](#layer-2-scaling) e a invenção do [Danksharding](/roadmap/danksharding) (adicionando blobs de dados do rollup para blocos do Ethereum que podem ser verificados eficientemente pelos validadores) têm levado a comunidade Ethereum a preferir o dimensionamento centrado por rollup em vez do dimensionamento por fragmentação. Isso também ajudará a manter a lógica de consenso do Ethereum mais simples. +Fragmentação é o processo de dividir um banco de dados. Subconjuntos de validadores seriam responsáveis por seus próprios fragmentos, em vez de manter o controle de todo o Ethereum. O sharding esteve no [roadmap](/roadmap/) da Ethereum por um longo tempo e foi planejado para ser lançado antes do The Merge para prova de participação. No entanto, o rápido desenvolvimento de [rollups de camada 2](#layer-2-scaling) e a invenção do [Danksharding](/roadmap/danksharding) (adicionando blobs de dados de rollup a blocos da Ethereum que podem ser verificados de forma muito eficiente por validadores) levou a comunidade Ethereum a favorecer a escalabilidade centrada em rollups em vez da escalabilidade por sharding. Isso também ajudará a manter a lógica de consenso do Ethereum mais simples. -## Dimensionamento off-chain {#off-chain-scaling} +## Escalabilidade fora da cadeia {#offchain-scaling} -As soluções off-chain são implementadas separadamente da rede principal da camada 1. Ou seja, elas não requerem alterações no protocolo Ethereum existente. Algumas soluções, conhecidas como soluções de “camada 2”, obtêm sua segurança diretamente do consenso da camada 1 do Ethereum, por exemplo, os [rollups otimistas](/developers/docs/scaling/layer-2-rollups/), os [rollups de conhecimento zero](/developers/docs/scaling/zk-rollups/) ou os [canais de estado](/developers/docs/scaling/state-channels/). Outras soluções envolvem a criação de novas cadeias em várias formas, que obtêm sua segurança separadamente da Mainnet (Rede principal), como [cadeias laterais](#sidechains), [validiums](#validium) ou [cadeias Plasma](#plasma). Essas soluções se comunicam com a Mainnet (Rede principal), mas obtêm sua segurança de forma diferente para alcançar uma variedade de objetivos. +Os offchain solutions são separados do layer 1 Mainnet. Algumas soluções, conhecidas como soluções de "camada 2", derivam sua segurança diretamente do consenso da camada 1 do Ethereum, como os [optimistic rollups](/developers/docs/scaling/optimistic-rollups/), [rollups de conhecimento zero](/developers/docs/scaling/zk-rollups/) ou [canais de estado](/developers/docs/scaling/state-channels/). Outras soluções envolvem a criação de novas cadeias em várias formas que derivam sua segurança separadamente da Mainnet, como [sidechains](#sidechains), [validiums](#validium) ou [plasma chains](#plasma). Essas soluções se comunicam com a Mainnet, mas derivam sua segurança de forma diferente para atingir uma variedade de objetivos. -### Dimensionamento da camada 2 {#layer-2-scaling} +### Escalabilidade da Camada 2 {#layer-2-scaling} -Esta categoria de soluções off-chain obtém sua segurança da Mainnet (Rede principal) do Ethereum. +Esta categoria de offchain solutions obtém segurança da Rede principal do Ethereum. A camada 2 é um termo coletivo de soluções projetadas para ajudar a dimensionar os aplicativos, gerenciando transações fora da rede principal (camada 1) do Ethereum, aproveitando o robusto modelo de segurança descentralizada da Mainnet (Rede principal). A velocidade das transações é reduzida quando a rede está ocupada, o que pode tornar a experiência do usuário ruim para certos tipos de dapps. À medida que a rede fica mais movimentada, os preços do gás aumentam, pois os remetentes de transações tendem a oferecer mais para processar sua transação antes das dos outros. Isso pode tornar o uso do Ethereum bem mais caro. -A maioria das soluções de camada 2 são centralizadas em torno de um servidor ou cluster de servidores, cada um dos quais pode ser referenciado como um nó, validador, operador, sequenciador, produtor de bloco, ou um termo semelhante. Dependendo da implementação, esses nós da camada 2 podem ser executados pelos indivíduos, empresas ou entidades que os usam, por um operador de terceiros ou por um grande grupo de indivíduos (semelhante à Mainnet). Em geral, as transações são submetidas a esses nós de camada 2, em vez de serem enviadas diretamente para a camada 1 (Mainnet). Para algumas soluções, a instância da camada 2 agrupa-os em grupos antes de ancorá-los na camada 1, na qual ficam protegidos e não podem ser alterados. Os pormenores de como isso é feito variam significativamente entre diferentes tecnologias de camada 2 e implementações. +A maioria das soluções de camada 2 orbitam ao redor de um servidor, ou cluster de servidores, cada um dos quais pode ser referenciado como um nó, como um validador, como um operador, como um sequenciador de transações, como um produtor de blocos ou como algo semelhante. Dependendo da implementação, esses nós da camada 2 podem ser executados pelos indivíduos, empresas ou entidades que os usam, por um operador de terceiros ou por um grande grupo de indivíduos (semelhante à Mainnet). Em geral, ao invés de serem enviadas diretamente para a camada 1 (rede principal), as transações são submetidas a esses nós da camada 2. Para algumas soluções, o camada 2 agrupa-os antes de os transmitir ao camada 1, no qual ficam protegidos e não podem ser alterados. Os pormenores de como isso é feito variam significativamente entre diferentes tecnologias de camada 2 e implementações. Uma instância específica da camada 2 pode ser aberta e compartilhada por muitos aplicativos, ou pode ser implantada por um projeto e dedicada a dar suporte apenas ao seu aplicativo. #### Por que a camada 2 é necessária? {#why-is-layer-2-needed} - O aumento da quantidade de transações por segundo melhora significativamente a experiência de usuário e reduzem o congestionamento da rede na rede principal do Ethereum. -- As transações são agrupadas em única transação na rede principal do Ethereum, reduzindo assim as taxas de gás, tornando o Ethereum mais inclusivo e acessível para os usuários sem importar o lugar. +- As transações são agrupadas em uma única transação para a Mainnet da Ethereum, reduzindo as taxas de gás para os usuários e tornando a Ethereum mais inclusiva e acessível para pessoas em todos os lugares. - Quaisquer atualizações de dimensionamento não devem ser feitas às custas da descentralização ou da segurança – a camada 2 se baseia na rede principal do Ethereum. -- Existem redes de camada 2 específicas de aplicativos que trazem seu próprio conjunto de melhorias ao trabalhar com ativos em escala. +- Existem redes de camada 2 específicas para aplicativos que trazem seu próprio conjunto de eficiências ao trabalhar com ativos em escala. [Mais sobre a camada 2](/layer-2/). @@ -56,26 +56,26 @@ Os rollups executam a transação fora da camada 1 e, em seguida, os dados são Existem dois tipos de rollups com diferentes modelos de segurança: -- **Optimistic rollups**: assumem que as transações são válidas por padrão e só executam computação através de uma [**prova de fraude**](/glossary/#fraud-proof), caso alguém levante alguma objeção. [Mais sobre optimistic-rollups](/developers/docs/scaling/optimistic-rollups/). -- **Rollups de conhecimento zero**: executam a computação off-chain e enviam uma [**prova de validade**](/glossary/#validity-proof) para a cadeia. [Mais sobre rollups de conhecimento zero](/developers/docs/scaling/zk-rollups/). +- **Optimistic rollups**: presumem que as transações são válidas por padrão e só executam a computação, por meio de uma [**prova de fraude**](/glossary/#fraud-proof), no caso de uma contestação. [Mais sobre Optimistic rollups](/developers/docs/scaling/optimistic-rollups/). +- **Rollups de conhecimento zero**: executam a computação fora da cadeia e enviam uma [**prova de validade**](/glossary/#validity-proof) para a cadeia. [Mais sobre rollups de conhecimento zero](/developers/docs/scaling/zk-rollups/). -#### Canais de Estado {#channels} +#### State channels {#channels} -Os canais de estado utilizam contratos multisig para permitir que os participantes realizem transações de forma rápida e livre off-chain para, em seguida, liquidar a finalidade com a Mainnet. Isso minimiza o congestionamento, as taxas e os atrasos na rede. Atualmente, existem dois tipos de canais: canais de estado e canais de pagamento. +Os canais de estado utilizam multisig contracts para permitir que os participantes realizarem transações de forma rápida e livre off-chain por final settlement à rede principal. Isso minimiza o congestionamento, as taxas e os atrasos na rede. Atualmente, existem dois tipos de canais: canais de estado e canais de pagamento. -Aprenda mais sobre [canais de estado](/developers/docs/scaling/state-channels/). +Saiba mais sobre [canais de estado](/developers/docs/scaling/state-channels/). -### Correntes paralelas {#sidechains} +### Sidechains {#sidechains} -Uma sidechain (cadeia paralela) é uma blockchain independente e compatível com EVM que roda em paralelo à Mainnet (Rede principal). As sidechains são compatíveis com o Ethereum através de pontes bidirecionais e são executadas conforme as regras de consenso escolhidas e os parâmetros do bloco. +Uma sidechain é uma blockchain independente, compatível com a EVM, que funciona em paralelo à Mainnet. Elas são compatíveis com a Ethereum por meio de pontes bidirecionais e funcionam sob suas próprias regras de consenso e parâmetros de bloco. Saiba mais sobre [Sidechains](/developers/docs/scaling/sidechains/). ### Plasma {#plasma} -A cadeia plasma é uma blockchain separada que é ancorada à cadeia principal do Ethereum e usa provas de fraude (como os [rollups otimistas](/developers/docs/scaling/optimistic-rollups/)) para arbitrar litígios. +Uma plasma chain é uma blockchain separada que é ancorada à cadeia principal da Ethereum e usa provas de fraude (como os [optimistic rollups](/developers/docs/scaling/optimistic-rollups/)) para arbitrar disputas. -Aprenda mais sobre o [Plasma](/developers/docs/scaling/plasma/). +Saiba mais sobre o [Plasma](/developers/docs/scaling/plasma/). ### Validium {#validium} @@ -85,7 +85,7 @@ Saiba mais sobre o [Validium](/developers/docs/scaling/validium/). ## Por que tantas soluções de dimensionamento são necessárias? {#why-do-we-need-these} -- O fato de ter múltiplas soluções pode ajudar a reduzir o congestionamento geral de qualquer parte da rede e também a impedir pontos únicos de falha. +- Várias soluções podem ajudar a reduzir o congestionamento geral em qualquer parte da rede e também evitar pontos únicos de falha. - O todo é maior que a soma de suas partes. Diferentes soluções podem existir e ainda funcionar em harmonia, provocando um efeito exponencial na velocidade futura das transações e na quantidade de dados transferidos. - Nem todas as soluções exigem diretamente o uso do algoritmo de consenso do Ethereum, e algumas alternativas podem oferecer benefícios que, de outro modo, seriam difíceis de obter. @@ -93,20 +93,21 @@ Saiba mais sobre o [Validium](/developers/docs/scaling/validium/). -_Observe que a explicação no vídeo usa o termo “Camada 2" para se referir a todas as soluções de escalabilidade off-chain, enquanto nós diferenciamos a “Camada 2" como uma solução off-chain que deriva sua segurança a partir do consenso da Mainnet (Rede principal) de camada 1._ +_Vídeo usa o termo “Camada 2" para se referir a todas as soluções de escalabilidade off-chain, enquanto nós diferenciamos o “Camada 2" como solução offchain que obtém segurança do consenso da layer 1 Mainnet._ ## Leitura adicional {#further-reading} -- [Um cronograma do Ethereum centrado em rollups](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ -- [Análises atualizadas sobre o dimensionamento da camada 2 para Ethereum](https://www.l2beat.com/) -- [Avaliando as soluções de dimensionamento da camada 2 de Ethereum: um esquema de comparação](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [Um roteiro da Ethereum centrado em rollups](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ +- [Análises atualizadas sobre soluções de escalabilidade de camada 2 para a Ethereum](https://www.l2beat.com/) +- [Avaliando as soluções de escalabilidade de camada 2 da Ethereum: uma estrutura de comparação](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) - [Um guia incompleto sobre rollups](https://vitalik.eth.limo/general/2021/01/05/rollup.html) -- [Ethereum com tecnologia de ZK-Rollups: campeões do mundo](https://hackmd.io/@canti/rkUT0BD8K) -- [Optimistic Rollups vs ZK Rollups](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) -- [Por que os rollups, junto com as fragmentações dos dados, são a única solução sustentável para atingir alto dimensionamento](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [ZK-Rollups com tecnologia da Ethereum: os melhores do mundo](https://hackmd.io/@canti/rkUT0BD8K) +- [Optimistic Rollups vs. ZK Rollups](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [Por que rollups + data shards são a única solução sustentável para alta escalabilidade](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) - [Que tipo de camada 3 faz sentido?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) -- [Disponibilidade de dados ou: como os rollups aprenderam a parar de se preocupar e amar o Ethereum](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) +- [Disponibilidade de Dados ou: Como os Rollups Aprenderam a Parar de Se Preocupar e Amar o Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [O Guia Prático para Rollups da Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) -_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/pt-br/developers/docs/scaling/optimistic-rollups/index.md index a514f55028d..2492160aba9 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/optimistic-rollups/index.md @@ -1,52 +1,52 @@ --- title: Optimistic Rollups -description: Uma introdução aos optimistic rollups, uma solução de dimensionamento usada pela comunidade Ethereum. +description: "Uma introdução aos optimistic rollups, uma solução de dimensionamento usada pela comunidade Ethereum." lang: pt-br --- -Os optimistic rollups são protocolos de camada 2 (L2) projetados para aumentar a taxa de transferência da camada base do Ethereum. Eles reduzem a computação na cadeia principal do Ethereum ao processar transações off-chain, oferecendo uma melhora significativa na velocidade de processamento. Diferentemente de outras soluções de dimensionamento, como [sidechains](/developers/docs/scaling/sidechains/), os optimistic rollups têm a sua segurança derivada da rede principal, pois publicam os resultados de suas transações on-chain. Os optimistic rollups também se diferem de [plasma chains](/developers/docs/scaling/plasma/). Estes também verificam transações no Ethereum com provas de fraude, mas fazem o armazenamento de dados em outro lugar. +Os optimistic rollups são protocolos de camada 2 (L2) projetados para aumentar a taxa de transferência da camada base do Ethereum. Eles reduzem a computação na cadeia principal do Ethereum processando transações offchain, oferecendo melhorias significativas nas velocidades de processamento. Diferentemente de outras soluções de escalabilidade, como [sidechains](/developers/docs/scaling/sidechains/), os optimistic rollups obtêm segurança da Rede Principal publicando resultados de transações na cadeia, ou [plasma chains](/developers/docs/scaling/plasma/), que também verificam transações no Ethereum com provas de fraude, mas armazenam os dados da transação em outro lugar. Como a computação é a parte lenta e cara de usar o Ethereum, os optimistic rollups podem oferecer uma melhora de dimensionamento de 10 a 100 vezes superior. Os optimistic rollups também gravam transações no Ethereum como `calldata` ou em [blobs](/roadmap/danksharding/), reduzindo os custos de gás para os usuários. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Você deve ter lido e compreendido nossas páginas sobre [dimensionamento do Ethereum](/developers/docs/scaling/) e [camada 2](/layer-2/). +Você deve ter lido e entendido nossas páginas aos [Ethereum scaling](/developers/docs/scaling/) e [layer 2](/layer-2/). ## O que é um optimistic rollup? {#what-is-an-optimistic-rollup} -Um optimistic rollup é uma maneira de dimensionara o Ethereum que evolve mover a computação e o armazenamento do estado off-chain. Optimistic rollups executam transações fora do Ethereum, mas publicam dados de transações na rede principal, como `calldata` ou em [blobs](/roadmap/danksharding/). +Um optimistic rollup é uma abordagem para dimensionar o Ethereum que envolve mover a computação e o armazenamento de estado para offchain. Os optimistic rollups executam transações fora do Ethereum, mas publicam dados de transação na Rede Principal como `calldata` ou em [blobs](/roadmap/danksharding/). -Os operadores de optimistic rollups agrupam várias transações off-chain em grandes lotes antes de as enviarem ao Ethereum. Esta abordagem permite dividir os custos entre várias transações em cada lote, reduzindo as taxas para os usuários finais. Os optimistic rollups também usam técnicas de compactação para reduzir a quantidade de dados publicados no Ethereum. +Operadores de optimistic rollup agrupam diversas transações offchain em grandes lotes antes de enviá-las ao Ethereum. Esta abordagem permite dividir os custos entre várias transações em cada lote, reduzindo as taxas para os usuários finais. Os optimistic rollups também usam técnicas de compactação para reduzir a quantidade de dados publicados no Ethereum. -Estes rollups são considerados "otimistas", pois assumem que as transações feitas off-chain são válidas e não publicam provas de validade para os lotes de transações publicados on-chain. Isso separa os optimistic rollups dos [zero-knowledge rollups](/developers/docs/scaling/zk-rollups) que publicam provas criptográficas [de validade](/glossary/#validity-proof) para transações realizadas off-chain. +Os optimistic rollup são considerados "otimistas" porque assumem que as transações offchain são válidas e não publicam provas de validade para lotes de transações postados onchain. Isso separa os optimistic rollups dos [rollups de conhecimento zero](/developers/docs/scaling/zk-rollups) que publicam [provas de validade](/glossary/#validity-proof) criptográficas para transações fora da cadeia. -Em vez disso, os optimistic rollups dependem de um esquema de comprovação de fraude para detectar casos em que as transações não são calculadas corretamente. Depois que um lote é enviado ao Ethereum, existe uma janela de tempo (chamada de período de disputa) em que qualquer pessoa pode questionar os resultados de uma transação de rollup computando uma [comprovação de fraude](/glossary/#fraud-proof). +Em vez disso, os optimistic rollups dependem de um esquema de comprovação de fraude para detectar casos em que as transações não são calculadas corretamente. Depois que um lote de rollup é enviado no Ethereum, há uma janela de tempo (chamada de período de desafio) durante a qual qualquer pessoa pode desafiar os resultados de uma transação de rollup, computando uma [prova de fraude](/glossary/#fraud-proof). Se a comprovação de fraude for bem-sucedida, o protocolo do rollup executa novamente as transações e atualiza o estado do rollup de forma adequada. O outro efeito de uma comprovação de fraude bem-sucedida é que o sequenciador responsável por incluir em um bloco a transação incorreta é penalizado. Se o lote de rollup permanecer sem desafio (ou seja, se todas as transações foram executadas corretamente) após o período de disputa expirar, ele será considerado válido e aceito no Ethereum. Outros podem continuar a construir sobre um bloco não confirmado do rollup, mas com uma ressalva: as transações serão revertidas se baseadas em uma transação executada incorretamente publicada anteriormente. -## Como os optimistic rollups interagem com o Ethereum? {#optimistic-rollups-and-Ethereum} +## Como os optimistic rollups interagem com o Ethereum? Optimistic rollups e o Ethereum {#optimistic-rollups-and-Ethereum} -Os optimistic rollups são [soluções de dimensionamento off-chain](/developers/docs/scaling/#off-chain-scaling) criadas para operar sobre o Ethereum. Cada optimistic rollup é gerenciado por um conjunto de contratos inteligentes implementados na rede Ethereum. Os optimistic rollups processam transações fora da rede principal do Ethereum, mas publicam transações off-chain (em lotes) em um contrato de rollup on-chain. Como na blockchain do Ethereum, esse registro de transações é imutável e compõe a cadeia do optimistic rollup. +Os optimistic rollups são [soluções de escalabilidade fora da cadeia](/developers/docs/scaling/#offchain-scaling) desenvolvidas para operar sobre o Ethereum. Cada optimistic rollup é gerenciado por um conjunto de contratos inteligentes implementados na rede Ethereum. Os Optimistic rollups processam transações fora da cadeia principal do Ethereum, mas lançam transações offchain (em lotes) em um contrato de rollup onchain. Como na blockchain do Ethereum, esse registro de transações é imutável e compõe a cadeia do optimistic rollup. A arquitetura de um optimistic rollup compreende as seguintes partes: -**Contratos on-chain**: a operação do optimistic rollup é controlada por contratos inteligentes em execução no Ethereum. Isso inclui contratos que armazenam blocos de rollup, monitoram atualizações de estado e rastreiam depósitos de usuário. Neste sentido o Ethereum serve como camada de base ou "camada 1" para os optimistic rollups. +**Contratos na cadeia**: a operação do optimistic rollup é controlada por contratos inteligentes em execução no Ethereum. Isso inclui contratos que armazenam blocos de rollup, monitoram atualizações de estado e rastreiam depósitos de usuário. Neste sentido o Ethereum serve como camada de base ou "camada 1" para os optimistic rollups. -**Máquina virtual (VM) off-chain**: embora os contratos gerenciando o protocolo de optimistic rollup executem no Ethereum, o protocolo de rollup executa a computação e o armazenamento de estado em outra máquina virtual separada da [Máquina Virtual do Ethereum (EVM, pela sigla em inglês)](/developers/docs/evm/). A VM off-chain é onde os aplicativos se encontram e as mudanças de estado são executadas; ela serve como a segunda camada ou "camada 2" para um optimistic rollup. +**Máquina virtual fora da cadeia (VM)**: embora os contratos que gerenciam o protocolo de optimistic rollup sejam executados no Ethereum, o protocolo de rollup realiza a computação e o armazenamento de estado em outra máquina virtual, separada da [Máquina Virtual Ethereum](/developers/docs/evm/). A VM offchain é onde os aplicativos ficam e as mudanças de estado são executadas; ela serve como a camada superior ou "layer 2" para um optimistic rollup. -Como os optimistic rollups são projetados para executar programas escritos ou compilados para a EVM, a máquina virtual off-chain acaba incorporando muitas especificações de design da EVM. Além disso, as comprovações de fraude computadas on-chain permitem que o Ethereum imponha a validade das mudanças de estado computadas na máquina virtual off-chain. +Assim como os optimistic rollups são projetados para executar programas escritos ou compilados para a EVM, a VM offchain incorpora muitas especificações de design da EVM. Além disso, as provas de fraude computadas na cadeia permitem que a rede Ethereum imponha a validade das alterações de estado computadas na VM fora da cadeia. -Os optimistic rollups são descritos como "soluções de dimesionamento híbrido", pois ao mesmo tempo que existem como protocolos separados, as propriedades de segurança deles são derivadas do Ethereum. Entre outras coisas, o Ethereum garante a exatidão da computação off-chain de um rollup e a disponibilidade de dados por trás desta. Isso torna os optimistic rollups mais seguros do que os protocolos de dimensionamento off-chain puros (por exemplo, [sidechains](/developers/docs/scaling/sidechains/)) que não dependem do Ethereum para sua segurança. +Os optimistic rollups são descritos como "soluções de dimesionamento híbrido", pois ao mesmo tempo que existem como protocolos separados, as propriedades de segurança deles são derivadas do Ethereum. Entre outras coisas, o Ethereum garante a correção do cálculo offchain de um rollup e a disponibilidade de dados por trás do cálculo. Isso torna os optimistic rollups mais seguros do que os protocolos de escalabilidade puramente fora da cadeia (p. ex., [sidechains](/developers/docs/scaling/sidechains/)) que não dependem do Ethereum para segurança. Os optimistic rollups dependem da rede principal do Ethereum para o seguinte: ### Disponibilidade de dados {#data-availability} -Conforme mencionado, os optimistic rollups publicam dados de transações no Ethereum como `calldata` ou [blobs](/roadmap/danksharding/). Como a execução na cadeia do rollup é baseada em transações enviadas, qualquer pessoa pode usar essa informação – ancorada na camada base do Ethereum – para executar o estado do rollup e verificar a exatidão das transições de estado. +Conforme mencionado, os optimistic rollups publicam dados de transação no Ethereum como `calldata` ou em [blobs](/roadmap/danksharding/). Como a execução na cadeia do rollup é baseada em transações enviadas, qualquer pessoa pode usar essa informação – ancorada na camada base do Ethereum – para executar o estado do rollup e verificar a exatidão das transições de estado. -A [disponibilidade de dados](/developers/docs/data-availability/) é fundamental porque, sem acesso a dados do estado, os desafiantes não podem criar provas de fraude para disputar operações de rollup inválidas. Com o Ethereum fornecendo disponibilidade de dados, o risco de os operadores de um rollup escaparem impunes de atos maliciosos (por exemplo, enviar blocos inválidos) é reduzido. +A [disponibilidade de dados](/developers/docs/data-availability/) é crítica, pois sem acesso aos dados de estado, os desafiantes não podem construir provas de fraude para contestar operações de rollup inválidas. Com o Ethereum fornecendo disponibilidade de dados, o risco de os operadores de um rollup escaparem impunes de atos maliciosos (por exemplo, enviar blocos inválidos) é reduzido. ### Resistência à censura {#censorship-resistance} @@ -56,7 +56,7 @@ Os optimistic rollups também contam com o Ethereum para resistência à censura - Os operadores de rollup podem impedir que os usuários retirem fundos depositados no contrato de rollup, através da retenção dos dados de estado necessários para provas de propriedade da Merkle. A retenção de dados de estado também pode ocultar o estado do rollup dos usuários e impedi-los de interagir com o rollup. -Os optimistic rollup resolvem esse problema forçando os operadores a publicar dados associados a atualizações de estado no Ethereum. A publicação de dados rollup on-chain (na cadeia) tem os seguintes benefícios: +Os optimistic rollup resolvem esse problema forçando os operadores a publicar dados associados a atualizações de estado no Ethereum. A publicação de dados de rollup onchain tem os seguintes benefícios: - Se um operador de optimistic rollup ficar offline ou parar de produzir lotes de transações, outro nó poderá usar os dados disponíveis para reproduzir o último estado do rollup e continuar a produção de blocos. @@ -68,45 +68,45 @@ Os optimistic rollup resolvem esse problema forçando os operadores a publicar d Outro papel que o Ethereum desempenha no contexto de optimistic rollup é o de uma camada de liquidação. Uma camada de liquidação ancora todo o ecossistema blockchain, estabelece segurança e proporciona finalidade objetiva caso ocorra uma disputa em outra cadeia (optimistic rollups neste caso) que exija arbitragem. -A rede principal do Ethereum fornece um hub para optimistic rollups, para verificar provas de fraude e resolver disputas. Além disso, as transações realizadas no rollup são apenas finais, _depois_ que o bloco de rollup é aceito no Ethereum. Uma vez que uma transação de rollup é confirmada na camada base do Ethereum, ela não pode ser revertida (exceto no caso altamente improvável de uma reorganização em cadeia). +A rede principal do Ethereum fornece um hub para optimistic rollups, para verificar provas de fraude e resolver disputas. Além disso, as transações realizadas no rollup só são finalizadas _depois_ que o bloco do rollup é aceito no Ethereum. Uma vez que uma transação de rollup é confirmada na camada base do Ethereum, ela não pode ser revertida (exceto no caso altamente improvável de uma reorganização em cadeia). ## Como funcionam os optimistic rollups? {#how-optimistic-rollups-work} -### Execução e agregação das transações {#transaction-execution-and-aggregation} +### Execução e agregação de transações {#transaction-execution-and-aggregation} Os usuários enviam transações para “operadores”, que são nós responsáveis pelo processamento de transações no optimistic rollup. Também conhecido como “validador” ou “agregador”, o operador agrega as transações, compacta os dados subjacentes e publica o bloco no Ethereum. -Embora qualquer pessoa possa se tornar um validador, os validadores do optimistic rollup devem fornecer um vínculo antes de produzir blocos, como um [sistema de prova de participação](/developers/docs/consensus-mechanisms/pos/). Esse vínculo pode ser compido se o validador postar um bloco inválido ou se basear em um bloco antigo, mas inválido (mesmo que seu bloco seja válido). Dessa forma, os optimistic rollups utilizam incentivos criptoeconômicos para garantir que os validadores ajam honestamente. +Embora qualquer um possa se tornar um validador, os validadores de optimistic rollup devem fornecer uma caução antes de produzir blocos, de forma muito parecida com um [sistema de prova de participação](/developers/docs/consensus-mechanisms/pos/). Esse vínculo pode ser compido se o validador postar um bloco inválido ou se basear em um bloco antigo, mas inválido (mesmo que seu bloco seja válido). Dessa forma, os optimistic rollups utilizam incentivos criptoeconômicos para garantir que os validadores ajam honestamente. Espera-se que outros validadores na cadeia de optimistic rollup executem as transações enviadas usando sua cópia do estado do rollup. Se o estado final de um validador for diferente do estado proposto pelo operador, ele poderá iniciar um desafio e computar uma prova de fraude. Alguns optimistic rollups podem renunciar a um sistema validador sem permissão e usar um único “sequenciador” para executar a cadeia. Como um validador, o sequenciador processa transações, produz blocos de rollup e envia transações de rollup para a cadeia L1 (Ethereum). -O sequenciador é diferente de um operador de rollup normal porque tem maior controle sobre a ordenação das transações. Além disso, o sequenciador tem acesso prioritário à cadeia de rollup e é a única entidade autorizada a submeter transações para o contrato on-chain. As transações de nós não sequenciadores ou usuários regulares são simplesmente enfileiradas em uma caixa de entrada separada até que o sequenciador as inclua em um novo lote. +O sequenciador é diferente de um operador de rollup normal porque tem maior controle sobre a ordenação das transações. Além disso, o sequenciador tem acesso prioritário à cadeia de rollup e é a única entidade autorizada a enviar transações ao contrato onchain. As transações de nós não sequenciadores ou usuários regulares são simplesmente enfileiradas em uma caixa de entrada separada até que o sequenciador as inclua em um novo lote. -#### Envio de blocos rollup para o Ethereum {#submitting-blocks-to-ethereum} +#### Enviando blocos de rollup para o Ethereum {#submitting-blocks-to-ethereum} -Como mencionado, o operador de um optimistic rollup agrupa as transações off-chain em um lote e o envia ao Ethereum para reconhecimento para notarização. Esse processo envolve compactar dados relacionados a transações e publicá-los no Ethereum como `calldata` ou em blobs. +Como mencionado, o operador de um optimistic rollups agrupa transações offchain em um lote e o envia ao Ethereum para reconhecimento para notarização. Esse processo envolve compactar dados relacionados a transações e publicá-los no Ethereum como `calldata` ou em blobs. -`calldata` é uma área não modificável e não persistente em um contrato inteligente que se comporta principalmente como [memória](/developers/docs/smart-contracts/anatomy/#memory). Enquanto `calldata` persiste na cadeia como parte do [histórico de logs](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs), ele não é armazenado como parte do estado do Ethereum. Como `calldata` não afeta nenhuma parte do estado do Ethereum, é mais barato do que o estado para armazenar dados na cadeia. +`calldata` é uma área não modificável e não persistente em um contrato inteligente que se comporta principalmente como a [memória](/developers/docs/smart-contracts/anatomy/#memory). Embora `calldata` persista na cadeia como parte dos [logs de histórico](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) da blockchain, não é armazenado como parte do estado do Ethereum. Como `calldata` não toca em nenhuma parte do estado do Ethereum, é mais barato do que o estado para armazenar dados na cadeia. A palavra-chave `calldata` também é usada no Solidity para passar argumentos para uma função de contrato inteligente em tempo de execução. `calldata` identifica a função que está sendo chamada durante uma transação e mantém as entradas para a função na forma de uma sequência arbitrária de bytes. -No contexto de optimistic rollups, `calldata` é usado para enviar dados de transação compactados para o contrato on-chain. O operador de rollup adiciona um novo lote chamando a função necessária no contrato de rollup e passando os dados compactados como argumentos de função. O uso de `calldata` reduz as taxas do usuário, pois a maioria dos custos incorridos pelos rollups vem do armazenamento de dados on-chain. +No contexto de optimistic rollups, `calldata` é usado para enviar dados de transação compactados para o contrato na cadeia. O operador de rollup adiciona um novo lote chamando a função necessária no contrato de rollup e passando os dados compactados como argumentos de função. O uso de `calldata` reduz as taxas do usuário, pois a maioria dos custos que os rollups incorrem vem do armazenamento de dados na cadeia. -Aqui está um [um exemplo](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) de um envio de rollup em lote para mostrar como esse conceito funciona. O sequenciador invocou o método `appendSequencerBatch()` e passou os dados da transação compactados como entradas usando `calldata`. +Aqui está [um exemplo](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) de um envio de lote de rollup para mostrar como este conceito funciona. O sequenciador invocou o método `appendSequencerBatch()` e passou os dados da transação compactados como entradas usando `calldata`. Alguns rollups agora usam blobs para postar lotes de transações no Ethereum. -Os blobs não são modificáveis ​​nem persistentes (assim como `calldata`), mas são removidos do histórico depois de 18 dias, aproximadamente. Para mais informações sobre blobs, consulte [Danksharding](/roadmap/danksharding). +Os blobs não são modificáveis e não são persistentes (assim como `calldata`), mas são removidos do histórico após ~18 dias. Para mais informações sobre blobs, consulte [Danksharding](/roadmap/danksharding). -### Compromissos com o estado {#state-commitments} +### Compromissos de estado {#state-commitments} -A qualquer momento, o estado do optimistic rollup (contas, saldos, código de contrato etc.) é organizado como uma [árvore Merkle](/whitepaper/#merkle-trees), chamada de "árvore de estado". A raiz dessa árvore Merkle (raiz do estado), que faz referência ao estado mais recente do rollup, é criptografada e armazenada no contrato rollup. Cada transição de estado na cadeia produz um novo estado de rollup, ao qual um operador se compromete calculando uma nova raiz de estado. +A qualquer momento, o estado do optimistic rollup (contas, saldos, código de contrato etc.) é organizado como uma [árvore de Merkle](/whitepaper/#merkle-trees) chamada de “árvore de estado”. A raiz dessa árvore Merkle (raiz do estado), que faz referência ao estado mais recente do rollup, é criptografada e armazenada no contrato rollup. Cada transição de estado na cadeia produz um novo estado de rollup, ao qual um operador se compromete calculando uma nova raiz de estado. -O operador é obrigado a enviar ambas as raízes de estado, antigas e novas, ao publicar lotes. Se a raiz do estado antigo corresponder à raiz do estado existente no contrato on-chain, o último será descartado e substituído pela nova raiz do estado. +O operador é obrigado a enviar ambas as raízes de estado, antigas e novas, ao publicar lotes. Se a raiz de estado antiga corresponder à raiz de estado existente no contrato onchain, esta última será descartada e substituída pela nova raiz de estado. -O operador de rollup também precisa confirmar uma raiz Merkle para o próprio lote de transações. Isso permite que qualquer pessoa comprove a inclusão de uma transação no lote (em L1) apresentando uma [prova Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). +O operador de rollup também precisa confirmar uma raiz Merkle para o próprio lote de transações. Isso permite que qualquer pessoa prove a inclusão de uma transação no lote (na L1), apresentando uma [prova de Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). Os compromissos de estado, especialmente raízes de estado, são necessários para provar a correção das mudanças de estado em um optimistic rollup. O contrato de rollup aceita novas raízes de estado de operadores imediatamente após serem publicadas, mas pode posteriormente excluir raízes de estado inválidas para restaurar o rollup ao seu estado correto. @@ -118,9 +118,9 @@ Se alguém contestar uma asserção, o protocolo de rollup iniciará o cálculo Os esquemas de prova interativa de rodada única refazem as transações disputadas na L1 para detectar asserções inválidas. O protocolo de rollup emula a reexecução da transação contestada na L1 (Ethereum) usando um contrato verificador, com a raiz do estado computada determinando quem vence o desafio. Se a alegação do desafiante sobre o estado correto do rollup estiver correto, o operador será penalizado ao ter seu vínculo cortado. -No entanto, a reexecução de transações na L1 para detectar fraudes requer a publicação de compromissos de estado para transações individuais e aumenta os rollups de dados que devem ser publicados on-chain. Refazer transações também implica custos de gás significativos. Por esses motivos, os optimistic rollups estão mudando para a prova interativa de múltiplas rodadas, que atinge o mesmo objetivo (ou seja, detectar operações de rollup inválidas) com mais eficiência. +No entanto, a reexecução de transações em L1 para detectar fraudes exige a publicação de compromissos de estado para transações individuais e aumenta os acúmulos de dados que devem ser publicados onchain. Refazer transações também implica custos de gás significativos. Por esses motivos, os optimistic rollups estão mudando para a prova interativa de múltiplas rodadas, que atinge o mesmo objetivo (ou seja, detectar operações de rollup inválidas) com mais eficiência. -#### Prova interativa de múltiplas rodadas {#multi-round-interactive-proving} +#### Comprovação interativa de múltiplas rodadas {#multi-round-interactive-proving} A prova interativa de múltiplas rodadas envolve um protocolo de vaivém entre o declarante e o desafiante supervisionado por um contrato de verificador L1, que finalmente decide a parte em questão. Depois que um nó L2 desafia uma asserção, o declarante é obrigado a dividir a asserção contestada em duas metades iguais. Cada asserção individual neste caso conterá tantos passos de computação quanto a outra. @@ -132,7 +132,7 @@ Algumas observações sobre este tipo de prova de fraude: 1. A prova de fraude interativa de múltiplas rodadas é considerada eficiente porque minimiza o trabalho que a cadeia L1 deve fazer na arbitragem de conflitos. Em vez de repetir a transação inteira, a cadeia L1 só precisa reexecutar uma etapa na execução dos rollups. -2. Os protocolos de bisseção reduzem a quantidade de dados postados on-chain (não há necessidade de publicar commits de estado para cada transação). Além disso, as transações de optimistic rollup não são restringidas pelo limite de gás do Ethereum. Por outro lado, os optimistic rollups reexecutando transações devem garantir que uma transação L2 tenha um limite de gás mais baixo para emular sua execução dentro de uma única transação Ethereum. +2. Os protocolos de bissecção reduzem a quantidade de dados publicados onchain (não há necessidade de publicar confirmações de estado para cada transação). Além disso, as transações de optimistic rollup não são restringidas pelo limite de gás do Ethereum. Por outro lado, os optimistic rollups reexecutando transações devem garantir que uma transação L2 tenha um limite de gás mais baixo para emular sua execução dentro de uma única transação Ethereum. 3. Parte do vínculo malicioso do declarante é atribuída ao desafiante, enquanto a outra parte é queimada. A queima evita a colisão entre validadores; se dois validadores conspirarem para iniciar desafios falsos, eles ainda perderão uma parte considerável de toda a participação (stake). @@ -140,39 +140,39 @@ Algumas observações sobre este tipo de prova de fraude: #### Por que as provas de fraude são importantes para os optimistic rollups {#fraud-proof-benefits} -As provas de fraude são importantes porque elas facilitam a _finalidade sem confiança_ em optimistic rollups. A finalidade sem confiança é uma qualidade dos optimistic rollups que garante que uma transação – desde que seja válida – será eventualmente confirmada. +As provas de fraude são importantes porque facilitam a _finalidade sem confiança_ nos optimistic rollups. A finalidade sem confiança é uma qualidade dos optimistic rollups que garante que uma transação – desde que seja válida – será eventualmente confirmada. Nós maliciosos podem tentar atrasar a confirmação de um bloco de rollup válido iniciando desafios falsos. No entanto, as provas de fraude eventualmente provarão a validade do bloco de rollup e fazer com que ele seja confirmado. -Isso também está relacionado a outra propriedade de segurança dos optimistic rollups: a validade da cadeia depende da existência de _um_ nó honesto. O nó honesto pode avançar na cadeia corretamente publicando asserções válidas ou disputando asserções inválidas. Seja qual for o caso, os nós maliciosos que entram em conflito com o nó honesto perderão suas participações (stakes) durante o processo de comprovação de fraude. +Isso também se relaciona com outra propriedade de segurança dos optimistic rollups: a validade da cadeia depende da existência de _um_ nó honesto. O nó honesto pode avançar na cadeia corretamente publicando asserções válidas ou disputando asserções inválidas. Seja qual for o caso, os nós maliciosos que entram em conflito com o nó honesto perderão suas participações (stakes) durante o processo de comprovação de fraude. ### Interoperabilidade L1/L2 {#l1-l2-interoperability} -Os optimistic rollups são projetados para interoperabilidade com a rede principal do Ethereum e permitem que os usuários passem mensagens e dados arbitrários entre as camadas L1 e L2. Eles também são compatíveis com o EVM, então você pode portar [dapps](/developers/docs/dapps/) existentes para optimistic rollups ou criar novos dapps usando ferramentas de desenvolvimento Ethereum. +Os optimistic rollups são projetados para interoperabilidade com a rede principal do Ethereum e permitem que os usuários passem mensagens e dados arbitrários entre as camadas L1 e L2. Eles também são compatíveis com a EVM, então você pode portar [dapps](/developers/docs/dapps/) existentes para optimistic rollups ou criar novos dapps usando as ferramentas de desenvolvimento do Ethereum. -#### 1. Movimento de Ativos {#asset-movement} +#### 1. Movimentação de ativos {#asset-movement} ##### Entrar no rollup -Para usar um optimistic rollup, os usuários depositam ETH, tokens ERC-20 e outros ativos aceitos no contrato [ponte](/developers/docs/bridges/) do rollup em L1. O contrato-ponte retransmitirá a transação para L2, onde uma quantidade equivalente de ativos é cunhada e enviada para o endereço escolhido pelo usuário no optimistic rollup. +Para usar um optimistic rollup, os usuários depositam ETH, tokens ERC-20 e outros ativos aceitos no contrato de [ponte](/developers/docs/bridges/) do rollup na L1. O contrato-ponte retransmitirá a transação para L2, onde uma quantidade equivalente de ativos é cunhada e enviada para o endereço escolhido pelo usuário no optimistic rollup. -As transações geradas pelo usuário (como um depósito L1 > L2) são geralmente enfileiradas até que o sequenciador as reenvie ao contrato de rollup. No entanto, para preservar a resistência à censura, os optimistic rollups permitem que os usuários enviem uma transação diretamente ao contrato de rollup on-chain, se ela tiver sido atrasada além do tempo máximo permitido. +As transações geradas pelo usuário (como um depósito L1 > L2) geralmente são enfileiradas até que o sequenciador as reenvie para o contrato de rollup. No entanto, para preservar a resistência à censura, os optimistic rollups permitem que os usuários enviem uma transação diretamente para o contrato de rollup onchain se ela tiver sido atrasada além do tempo máximo permitido. Alguns optimistic rollups adotam uma abordagem mais direta para evitar que os sequenciadores censurem os usuários. Aqui, um bloco é definido por todas as transações submetidas ao contrato L1 desde o bloco anterior (por exemplo, depósitos) além das transações processadas na cadeia de rollup. Se um sequenciador ignorar uma transação L1, ele publicará a raiz de estado errada (provavelmente); portanto, os sequenciadores não podem atrasar mensagens geradas pelo usuário uma vez publicadas na L1. ##### Sair do rollup -Sair de um optimistic rollup para o Ethereum é mais difícil devido ao esquema de provação de fraude. Se um usuário iniciar uma transação L2 > L1 para sacar fundos depositados em L1, eles deverão esperar até que o período de desafio – com duração de aproximadamente sete dias – termine. No entanto, o processo de retirada em si é bastante simples. +Sair de um optimistic rollup para o Ethereum é mais difícil devido ao esquema de provação de fraude. Se um usuário iniciar uma transação L2 > L1 para sacar fundos custodiados na L1, ele deverá esperar até que o período de desafio — que dura aproximadamente sete dias — termine. No entanto, o processo de retirada em si é bastante simples. Depois que o pedido de retirada é iniciado no rollup L2, a transação é incluída no próximo lote, enquanto os ativos do usuário no rollup são queimados. Uma vez que o lote é publicado no Ethereum, o usuário pode computar uma prova Merkle verificando a inclusão de sua transação de saída no bloco. Então, trata-se de esperar o período de atraso para finalizar a transação na L1 e retirar fundos para a rede principal. -Para evitar esperar uma semana antes de retirar fundos para o Ethereum, os usuários de optimistic rollups podem empregar um **provedor de liquidez** (LP). Um provedor de liquidez assume a propriedade de uma retirada na L2 pendente e paga ao usuário na L1 (em troca de uma taxa). +Para evitar esperar uma semana antes de sacar fundos para o Ethereum, os usuários de optimistic rollup podem empregar um **provedor de liquidez** (LP). Um provedor de liquidez assume a propriedade de uma retirada na L2 pendente e paga ao usuário na L1 (em troca de uma taxa). Os provedores de liquidez podem verificar a validade do pedido de retirada do usuário (executando a própria cadeia) antes de liberar fundos. Dessa forma, eles têm garantias de que a transação será confirmada eventualmente (ou seja, finalidade sem confiança). -#### 2. Compatibilidade EVM {#evm-compatibility} +#### 2. Compatibilidade com a EVM {#evm-compatibility} -Para os desenvolvedores, a vantagem dos optimistic rollups é sua compatibilidade — ou, melhor ainda, equivalência — com a [Máquina Virtual Ethereum (do inglês, Ethereum Virtual Machine, EVM)](/developers/docs/evm/). Os rollups compatíveis com a EVM cumprem as especificações do [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) e suportam a EVM no nível de bytecode. +Para os desenvolvedores, a vantagem dos optimistic rollups é a compatibilidade — ou, melhor ainda, a equivalência — com a [Máquina Virtual Ethereum (EVM)](/developers/docs/evm/). Os rollups compatíveis com a EVM cumprem as especificações do [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) e suportam a EVM no nível de bytecode. A compatibilidade com EVM em optimistic rollups tem os seguintes benefícios: @@ -182,7 +182,7 @@ ii. Desenvolvedores e equipes de projeto que usam optimistic rollups podem aprov O uso de ferramentas existentes é importante porque essas ferramentas foram amplamente auditadas, depuradas e melhoradas ao longo dos anos. Também elimina a necessidade de desenvolvedores Ethereum aprenderem a construir com uma pilha de desenvolvimento totalmente nova. -#### 3. Chamadas de contrato de cadeia cruzada {#cross-chain-contract-calls} +#### 3. Chamadas de contrato entre cadeias {#cross-chain-contract-calls} Usuários (contas de propriedade externa, da sigla EOA) interagem com contratos L2 enviando uma transação ao contrato de rollup ou fazendo com que um sequenciador ou validador faça isso por eles. Os optimistic rollups também permitem que contas de contrato Ethereum interajam com contratos L2 usando contratos de ponte para retransmitir mensagens e passar dados entre L1 e L2. Isso significa que você pode programar um contrato L1 na rede principal do Ethereum para invocar funções pertencentes a contratos em um optimistic rollup de L2. @@ -190,64 +190,64 @@ As chamadas de contrato de cadeia cruzada acontecem de forma assíncrona, o que Um exemplo de uma chamada de contrato de cadeia cruzada é o depósito de token descrito anteriormente. Um contrato em L1 deposita em caução os tokens do usuário e envia uma mensagem para um contrato L2 emparelhado para cunhar uma quantidade igual de tokens no rollup. -Como as chamadas de mensagens de cadeia cruzada resultam na execução do contrato, o remetente geralmente é obrigado a cobrir [custos de gás](/developers/docs/gas/) para computação. É aconselhável definir um limite de gás alto para evitar que a transação falhe na cadeia de destino. O cenário de ponte de token é um bom exemplo; se o lado L1 da transação (depositando os tokens) funcionar, mas o lado L2 (cunhando novos tokens) falhar devido ao baixo gás, o depósito se tornará irrecuperável. +Como as chamadas de mensagem entre cadeias resultam na execução do contrato, o remetente geralmente é obrigado a cobrir os [custos de gás](/developers/docs/gas/) para a computação. É aconselhável definir um limite de gás alto para evitar que a transação falhe na cadeia de destino. O cenário de ponte de token é um bom exemplo; se o lado L1 da transação (depositando os tokens) funcionar, mas o lado L2 (cunhando novos tokens) falhar devido ao baixo gás, o depósito se tornará irrecuperável. -Finalmente, devemos observar que as chamadas de mensagens L2 > L1 entre contratos precisam considerar os atrasos (chamadas L1 > L2 são normalmente executadas após alguns minutos). Isso ocorre porque as mensagens enviadas para a rede principal a partir do optimistic rollup não podem ser executadas até que a janela de desafio expire. +Finalmente, devemos observar que as chamadas de mensagem L2 > L1 entre contratos precisam levar em conta os atrasos (as chamadas L1 > L2 são normalmente executadas após alguns minutos). Isso ocorre porque as mensagens enviadas para a rede principal a partir do optimistic rollup não podem ser executadas até que a janela de desafio expire. ## Como funcionam as taxas de optimistic rollups? {#how-do-optimistic-rollup-fees-work} Os optimistic rollups usam um esquema de taxa de gás, muito parecido com o Ethereum, para denotar quanto os usuários pagam por transação. As taxas cobradas em optimistic rollups dependem dos seguintes componentes: -1. **Gravação de estado**: os optimistic rollups publicam dados de transações e cabeçalhos de bloco (consistindo no hash do cabeçalho do bloco anterior, raiz de estado, raiz de lote) no Ethereum como um `blob` ou "objeto binário grande". [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) apresentou uma solução econômica para incluir dados na cadeia. Um `blob` é um novo campo de transação que permite que rollups publiquem dados de transição de estado compactados no Ethereum L1. Ao contrário de `calldata`, que ficam permanentemente na cadeia, os blobs têm vida curta e podem ser removidos dos clientes após [4.096 épocas](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (aproximadamente 18 dias). Ao usar blobs para postar lotes de transações compactadas, os optimistic rollups podem reduzir significativamente o custo de gravação de transações na L1. +1. **Gravação de estado**: os optimistic rollups publicam dados de transação e cabeçalhos de bloco (compostos pelo hash do cabeçalho do bloco anterior, raiz do estado, raiz do lote) no Ethereum como um `blob`, ou "objeto binário grande". O [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduziu uma solução de baixo custo para incluir dados na cadeia. Um `blob` é um novo campo de transação que permite que os rollups publiquem dados de transição de estado compactados no Ethereum L1. Diferentemente do `calldata`, que permanece permanentemente na cadeia, os blobs são de curta duração e podem ser removidos dos clientes após [4096 épocas](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (aproximadamente 18 dias). Ao usar blobs para postar lotes de transações compactadas, os optimistic rollups podem reduzir significativamente o custo de gravação de transações na L1. -2. **Gás de blob usado**: transações que transportam blob empregam um mecanismo de taxa dinâmico semelhante ao introduzido pelo [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). A taxa de gás para transações do tipo 3 leva em consideração a taxa base para blobs, que é determinada pela rede com base na demanda de espaço de blobs e no uso de espaço de blobs da transação que está sendo enviada. +2. **Gás de blob usado**: as transações que transportam blobs empregam um mecanismo de taxa dinâmico semelhante ao introduzido pelo [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). A taxa de gás para transações do tipo 3 leva em consideração a taxa base para blobs, que é determinada pela rede com base na demanda de espaço de blobs e no uso de espaço de blobs da transação que está sendo enviada. -3. **Taxas do operador L2**: Este é o valor pago aos nódulos de rollup como compensação pelos custos computacionais decorrentes do processamento de transações, muito parecido com as taxas de Gas no Ethereum. Os nódulos de rollup cobram taxas de transação mais baixas, já que as L2s têm capacidades de processamento mais altas e não enfrentam os congestionamentos de rede, que forçam os validadores no Ethereum a priorizar transações com taxas mais altas. +3. **Taxas do operador da L2**: este é o valor pago aos nós do rollup como compensação pelos custos computacionais incorridos no processamento de transações, muito semelhante às taxas de gás no Ethereum. Os nódulos de rollup cobram taxas de transação mais baixas, já que as L2s têm capacidades de processamento mais altas e não enfrentam os congestionamentos de rede, que forçam os validadores no Ethereum a priorizar transações com taxas mais altas. -Os optimistic rollups aplicam vários mecanismos para reduzir as taxas para os usuários, incluindo transações em lote e compactando `calldata` para reduzir os custos de publicação de dados. Você pode verificar o [rastreador de taxas L2](https://l2fees.info/), para ter uma ideia geral real do custo de uso de optimistic rollups baseados em Ethereum. +Os optimistic rollups aplicam vários mecanismos para reduzir as taxas para os usuários, incluindo o processamento de transações em lote e a compressão de `calldata` para reduzir os custos de publicação de dados. Você pode consultar o [rastreador de taxas da L2](https://l2fees.info/) para ter uma visão geral em tempo real de quanto custa usar optimistic rollups baseados em Ethereum. ## Como os optimistic rollups dimensionam o Ethereum? {#scaling-ethereum-with-optimistic-rollups} -Conforme explicado, os optimistic rollups publicam dados de transações compactados no Ethereum para garantir a disponibilidade dos dados. A capacidade de compactar dados publicados on-chain é crucial para dimensionar a taxa de transferência no Ethereum com optimistic rollups. +Conforme explicado, os optimistic rollups publicam dados de transações compactados no Ethereum para garantir a disponibilidade dos dados. A capacidade de compactar dados publicados onchain é crucial para aumentar a produtividade no Ethereum com optimistic rollups. -A cadeia principal da Ethereum coloca limites sobre quantos blocos de dados podem conter, denominados em unidades de gás (o [tamanho médio do bloco](/developers/docs/blocks/#block-size) é de 15 milhões de gás). Embora isso restrinja quanto gás cada transação pode usar, também significa que podemos aumentar as transações processadas por bloco reduzindo os dados relacionados à transação, melhorando diretamenteo dimensionamento. +A cadeia principal do Ethereum impõe limites sobre a quantidade de dados que os blocos podem conter, denominados em unidades de gás (o [tamanho médio do bloco](/developers/docs/blocks/#block-size) é de 15 milhões de gás). Embora isso restrinja quanto gás cada transação pode usar, também significa que podemos aumentar as transações processadas por bloco reduzindo os dados relacionados à transação, melhorando diretamenteo dimensionamento. -Os optimistic rollups usam várias técnicas para obter a compressão de dados de transação e melhorar as taxas de TPS. Por exemplo, este [artigo](https://vitalik.eth.limo/general/2021/01/05/rollup.html) compara os dados que uma transação básica do usuário (enviando ether) gera na rede principal com a quantidade de dados que a mesma transação gera em um rollup: +Os optimistic rollups usam várias técnicas para obter a compressão de dados de transação e melhorar as taxas de TPS. Por exemplo, este [artigo](https://vitalik.eth.limo/general/2021/01/05/rollup.html) compara os dados que uma transação básica do usuário (enviando ether) gera na Rede Principal com a quantidade de dados que a mesma transação gera em um rollup: -| Parâmetro | Ethereum (L1) | Rollup (L2) | -| ---------- | ---------------------------- | ------------- | -| Nonce | ~3 | 0 | -| Gasprice | ~8 | 0-0.5 | -| Gás | 3 | 0-0.5 | -| Para | 21 | 4 | -| Valores | 9 | ~3 | -| Assinatura | ~68 (2 + 33 + 33) | ~0.5 | -| De | 0 (recuperado da assinatura) | 4 | -| **Total** | **~112 bytes** | **~12 bytes** | +| Parâmetro | Ethereum (L1) | Rollup (L2) | +| ---------- | ---------------------------------------------------- | ------------------------------------ | +| Nonce | ~3 | 0 | +| Gasprice | ~8 | 0-0.5 | +| Gás | 3 | 0-0.5 | +| Para | 21 | 4 | +| Valor | 9 | ~3 | +| Assinatura | ~68 (2 + 33 + 33) | ~0.5 | +| De | 0 (recuperado da assinatura) | 4 | +| **Total** | **\~112 bytes** | **\~12 bytes** | Fazer alguns cálculos aproximados sobre esses números pode ajudar a mostrar as melhorias de dimensionamento oferecidas por um optimistic rollup: -1. O tamanho-alvo para cada bloco é de 15 milhões de gás e custa 16 gás para verificar um byte de dados. Dividir o tamanho médio do bloco por 16 gás (15.000.000/16) mostra que o bloco médio pode conter **937.500 bytes de dados**. -2. Se uma transação de rollup básica usa 12 bytes, o bloco Ethereum médio pode processar **78.125 transações de rollup** (937.5000/12) ou **39 lotes de rollup** (se cada lote possuir uma média de 2.000 transações). -3. Se um novo bloco for produzido no Ethereum a cada 15 segundos, as velocidades de processamento do rollup serão de aproximadamente **5.208 transações por segundo**. Isso é feito dividindo o número de transações de rollup básicas que um bloco Ethereum pode manter, (**78.125**) pelo tempo médio de bloqueio (**15 segundos**). +1. O tamanho-alvo para cada bloco é de 15 milhões de gás e custa 16 gás para verificar um byte de dados. Dividir o tamanho médio do bloco por 16 de gás (15.000.000/16) mostra que o bloco médio pode conter **937.500 bytes de dados**. +2. Se uma transação de rollup básica usar 12 bytes, então o bloco médio do Ethereum pode processar **78.125 transações de rollup** (937.500/12) ou **39 lotes de rollup** (se cada lote contiver uma média de 2.000 transações). +3. Se um novo bloco é produzido no Ethereum a cada 15 segundos, então as velocidades de processamento do rollup chegariam a aproximadamente **5.208 transações por segundo**. Isso é feito dividindo o número de transações de rollup básicas que um bloco do Ethereum pode conter (**78.125**) pelo tempo médio do bloco (**15 segundos**). Esta é uma estimativa bastante otimista, uma vez que as transações de optimistic rollups não podem abranger um bloco inteiro no Ethereum. No entanto, pode dar uma ideia aproximada de quantos ganhos de dimensionamento os optimistic rollups podem proporcionar aos usuários do Ethereum (as implementações atuais oferecem até 2.000 TPS). -Espera-se que a introdução de [fragmentação (sharding) de dados](/roadmap/danksharding/) no Ethereum melhore o dimensionamento do rollup otimista. Como as transações de rollup devem compartilhar o espaço de blocos (blockspace) com outras transações não-rollup, sua capacidade de processamento é limitada pela taxa de transferência de dados na cadeia principal do Ethereum. Danksharding aumentará o espaço disponível para que cadeias L2 publiquem dados por bloco, usando armazenamento de “blob” impermanente e mais barato em vez de `CALLDATA`, que é permanente e caro. +Espera-se que a introdução da [fragmentação de dados](/roadmap/danksharding/) no Ethereum melhore a escalabilidade dos optimistic rollups. Como as transações de rollup devem compartilhar o espaço de blocos (blockspace) com outras transações não-rollup, sua capacidade de processamento é limitada pela taxa de transferência de dados na cadeia principal do Ethereum. O Danksharding aumentará o espaço disponível para as cadeias L2 publicarem dados por bloco, usando um armazenamento "blob" mais barato e não permanente, em vez do `CALLDATA` caro e permanente. ### Prós e contras dos optimistic rollups {#optimistic-rollups-pros-and-cons} -| Prós | Contras | -| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Prós | Contras | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Oferece grandes melhorias de dimensionamento sem sacrificar a segurança ou a falta de confiança. | Atrasos na finalização da transação devido a potenciais desafios de fraude. | -| Os dados da transação são armazenados na cadeia da camada 1, melhorando a transparência, segurança, resistência à censura e descentralização. | Operadores de rollup centralizados (sequenciadores) podem influenciar a ordenação de transações. | +| Os dados da transação são armazenados na cadeia da camada 1, melhorando a transparência, segurança, resistência à censura e descentralização. | Operadores de rollup centralizados (sequenciadores) podem influenciar a ordenação de transações. | | A comprovação de fraude garante uma finalidade sem confiança e permite que minorias honestas protejam a cadeia. | Se não houver nós honestos, um operador malicioso poderá roubar fundos publicando blocos inválidos e compromissos de estado. | -| A computação de provas de fraude está aberta ao nó L2 regular, ao contrário das provas de validade (usadas em ZK-rollups) que requerem hardware especial. | O modelo de segurança depende de pelo menos um nó honesto executando transações de rollup e enviando provas de fraude, para desafiar transições de estado inválidas. | -| Os rollups se beneficiam da "vida sem confiança" (qualquer um pode forçar a cadeia a avançar executando transações e publicando declarações) | Os usuários devem esperar que o período de desafio de uma semana expire antes de retirar os fundos de volta para o Ethereum. | -| Os optimistic rollups dependem de incentivos criptoeconômicos bem projetados para aumentar a segurança na cadeia. | Os rollups devem publicar todos os dados da transação on-chain, o que pode aumentar os custos. | -| A compatibilidade com EVM e Solidity permite aos desenvolvedores portar contratos inteligentes nativos do Ethereum para rollups ou usar ferramentas existentes para criar novos dapps. | | +| A computação de provas de fraude está aberta ao nó L2 regular, ao contrário das provas de validade (usadas em ZK-rollups) que requerem hardware especial. | O modelo de segurança depende de pelo menos um nó honesto executando transações de rollup e enviando provas de fraude, para desafiar transições de estado inválidas. | +| Os rollups se beneficiam da "vida sem confiança" (qualquer um pode forçar a cadeia a avançar executando transações e publicando declarações) | Os usuários devem esperar que o período de desafio de uma semana expire antes de retirar os fundos de volta para o Ethereum. | +| Os optimistic rollups dependem de incentivos criptoeconômicos bem projetados para aumentar a segurança na cadeia. | Os rollups devem publicar todos os dados de transações onchain, o que pode aumentar os custos. | +| A compatibilidade com EVM e Solidity permite aos desenvolvedores portar contratos inteligentes nativos do Ethereum para rollups ou usar ferramentas existentes para criar novos dapps. | | -### Uma explicação visual de optimistic rollups {#optimistic-video} +### Uma explicação visual dos optimistic rollups {#optimistic-video} Você é o tipo de pessoa que aprende mais com recursos visuais? Assista aos Finematics explicando os optimistic rollups: @@ -255,9 +255,11 @@ Você é o tipo de pessoa que aprende mais com recursos visuais? Assista aos Fin ## Leitura adicional sobre optimistic rollups -- [Como funcionam os optimistic rollups (o guia completo)](https://www.alchemy.com/overviews/optimistic-rollups) +- [Como os optimistic rollups funcionam (O guia completo)](https://www.alchemy.com/overviews/optimistic-rollups) - [O que é uma Blockchain Rollup? Uma introdução técnica](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) -- [O guia essencial do Arbitrum](https://www.bankless.com/the-essential-guide-to-arbitrum) -- [Como o optimistic rollup realmente funciona?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) -- [OVM: aprofundamento](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) -- [O que é a máquina virtual otimista?](https://www.alchemy.com/overviews/optimistic-virtual-machine) +- [O Guia Essencial para o Arbitrum](https://www.bankless.com/the-essential-guide-to-arbitrum) +- [O guia prático para os rollups do Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [O estado das provas de fraude nas L2s do Ethereum](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s) +- [Como o rollup da Optimism realmente funciona?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) +- [Análise aprofundada da OVM](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [O que é a Máquina Virtual Otimista?](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git a/public/content/translations/pt-br/developers/docs/scaling/plasma/index.md b/public/content/translations/pt-br/developers/docs/scaling/plasma/index.md index 4c6ae6a3d7e..b4756982798 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/plasma/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/plasma/index.md @@ -1,48 +1,48 @@ --- title: As cadeias Plasma -description: Uma introdução às cadeias plasma como uma solução de dimensionamento atualmente utilizada pela comunidade Ethereum. +description: "Uma introdução às cadeias plasma como uma solução de dimensionamento atualmente utilizada pela comunidade Ethereum." lang: pt-br incomplete: true sidebarDepth: 3 --- -Uma cadeia Plasma é uma blockchain separada ancorada à rede principal do Ethereum, mas executando transações off-chain com seu próprio mecanismo para validação de bloco. Cadeias Plasma são algumas vezes referenciadas como cadeias "filhas", essencialmente cópias menores da rede principal do Ethereum. As cadeias plasma usam [provas de fraude](/glossary/#fraud-proof) (como [optimistic rollups](/developers/docs/scaling/optimistic-rollups/)) para arbitrar conflitos. +A rede Plasma é uma blockchain separada ancorada à rede principal do Ethereum, mas executando transações off-chain com seu próprio mecanismo para validação de bloco. Cadeias Plasma são algumas vezes referenciadas como cadeias "filhas", essencialmente cópias menores da rede principal do Ethereum. As cadeias Plasma usam [provas de fraude](/glossary/#fraud-proof) (como os [optimistic rollups](/developers/docs/scaling/optimistic-rollups/)) para arbitrar disputas. As árvores Merkle permitem a criação de uma pilha sem fim dessas cadeias, que podem funcionar para descarregar a largura de banda das cadeias pai (incluindo a rede principal do Ethereum). No entanto, embora essas cadeias obtenham alguma segurança do Ethereum (por meio de provas de fraude), a segurança e eficiência que oferecem são afetadas por várias limitações de projeto. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Você deve ter um bom entendimento de todos os tópicos fundamentais e um entendimento mais geral sobre [Dimensionamento Ethereum](/developers/docs/scaling/). +Você deve ter um bom entendimento de todos os tópicos fundamentais e um entendimento de alto nível da [escalabilidade do Ethereum](/developers/docs/scaling/). ## O que é Plasma? -Plasma é uma estrutura para melhorar o dimensionamento em blockchains públicas como o Ethereum. Conforme descrito no [whitepaper do Plasma](http://plasma.io/plasma.pdf) original, cadeias Plasma são construídas sobre outra blockchain (chamada de "cadeia raiz"). Cada "cadeia filha" estende da cadeia raiz e geralmente é gerenciada por um contrato inteligente implantado na cadeia pai. +Plasma é uma estrutura para melhorar o dimensionamento em blockchains públicas como o Ethereum. Conforme descrito no [whitepaper original do Plasma](http://plasma.io/plasma.pdf), as cadeias Plasma são construídas sobre outra blockchain (chamada de "cadeia raiz"). Cada "cadeia filha" estende da cadeia raiz e geralmente é gerenciada por um contrato inteligente implantado na cadeia pai. -O contrato Plasma funciona, entre outras coisas, como uma [ponte](/developers/docs/bridges/) permitindo que os usuários movam ativos entre a rede principal do Ethereum e a cadeia plasma. Embora isso as torne semelhantes às [sidechains](/developers/docs/scaling/sidechains/), as cadeias plasma se beneficiam – pelo menos, até certo ponto – da segurança da rede principal do Ethereum. Isso é diferente das sidechains que são as únicas responsáveis pela segurança delas. +O contrato Plasma funciona, entre outras coisas, como uma [ponte](/developers/docs/bridges/) que permite aos usuários mover ativos entre a Rede Principal do Ethereum e a cadeia plasma. Embora isso as torne semelhantes às [sidechains](/developers/docs/scaling/sidechains/), as cadeias plasma se beneficiam — pelo menos, até certo ponto — da segurança da rede principal do Ethereum. Isso é diferente das sidechains que são as únicas responsáveis pela segurança delas. ## Como as cadeias Plasma funcionam? Os componentes básicos do framework Plasma são: -### Computação off-chain {#off-chain-computation} +### Computação fora da cadeia {#offchain-computation} -A velocidade de processamento atual do Ethereum é limitada a ~ 15-20 transações por segundo, reduzindo a possibilidade de dimensionamento de curto prazo para lidar com mais usuários. Esse problema existe principalmente porque o [mecanismo de consenso](/developers/docs/consensus-mechanisms/) de Ethereum requer muitos nós ponto a ponto para verificar cada atualização do estado da blockchain. +A velocidade de processamento atual do Ethereum é limitada a ~ 15-20 transações por segundo, reduzindo a possibilidade de dimensionamento de curto prazo para lidar com mais usuários. Este problema existe principalmente porque o [mecanismo de consenso](/developers/docs/consensus-mechanisms/) do Ethereum exige que muitos nós ponto a ponto verifiquem cada atualização do estado da blockchain. Embora o mecanismo de consenso de Ethereum seja necessário para segurança, ele pode não se aplicar a todos os casos de uso. Por exemplo, Alice pode não precisar de seus pagamentos diários a Bob, por uma xícara de café verificada por toda a rede Ethereum, pois existe alguma confiança entre ambas as partes. A cadeia Plasma supõe que a rede principal do Ethereum não precisa verificar todas as transações. Em vez disso, podemos processar transações fora da rede principal, liberando os nós da necessidade de validar cada transação. -A computação off-chain é necessária, pois as cadeias Plasma podem otimizar a velocidade e o custo. Por exemplo, uma cadeia plasma pode, na maioria das vezes, usar um único "operador" para gerenciar a ordenação e execução das transações. Com apenas uma entidade verificando transações, os tempos de processamento em uma cadeia plasma são mais rápidos que na rede principal do Ethereum. +A computação off-chain é necessária, pois as redes Plasma podem otimizar a velocidade e o custo. Por exemplo, uma cadeia plasma pode, na maioria das vezes, usar um único "operador" para gerenciar a ordenação e execução das transações. Com apenas uma entidade verificando transações, os tempos de processamento em uma cadeia plasma são mais rápidos que na rede principal do Ethereum. -### Compromissos com o estado {#state-commitments} +### Compromissos de estado {#state-commitments} -Enquanto cadeia Plasma executa transações off-chain, eles são estabelecidas na camada de execução principal do Ethereum, caso contrário as cadeias Plasma não podem se beneficiar das garantias de segurança do Ethereum. Mas finalizar transações off-chain sem saber o estado da cadeia plasma quebraria o modelo de segurança e permitiria a proliferação de transações inválidas. É por isso que o operador, entidade responsável pela produção de blocos na cadeia plasma, é obrigado a publicar periodicamente "compromissos de estado" no Ethereum. +Enquanto Plasma executa transações off-chain, eles são estabelecidas na camada de execução principal do Ethereum, caso contrário as redes Plasma não podem se beneficiar das garantias de segurança do Ethereum. Mas finalizar transações off-chain sem saber o estado da cadeia de plasma quebraria o modelo de segurança e permitiria a proliferação de transações inválidas. É por isso que o operador, entidade responsável pela produção de blocos na cadeia plasma, é obrigado a publicar periodicamente "compromissos de estado" no Ethereum. -Um [esquema de compromisso](https://en.wikipedia.org/wiki/Commitment_scheme) é uma técnica criptográfica para se comprometer com um valor ou declaração sem revelá-la a outra parte. Os compromissos são "vinculativos" no sentido de que você não pode alterar o valor ou a declaração depois de se comprometer com ele. Os compromissos de estado na cadeia Plasma assumem a forma de "raízes Merkle" (derivado de uma [árvore Merkle](/whitepaper/#merkle-trees)) o qual o operador envia em intervalos para o contrato Plasma na cadeia Ethereum. +Um [esquema de compromisso](https://en.wikipedia.org/wiki/Commitment_scheme) é uma técnica criptográfica para se comprometer com um valor ou declaração sem revelá-lo a outra parte. Os compromissos são "vinculativos" no sentido de que você não pode alterar o valor ou a declaração depois de se comprometer com ele. Os compromissos de estado no Plasma assumem a forma de "raízes Merkle" (derivadas de uma [árvore Merkle](/whitepaper/#merkle-trees)), que o operador envia em intervalos para o contrato Plasma na cadeia Ethereum. -As raízes Merkle são primitivas criptográficas que permitem a compactação de grandes quantidades de informações. Uma raiz Merkle (também chamada de "raiz de bloco" neste caso) poderia representar todas as transações em um bloco. As raízes Merkle também tornam mais fácil verificar se uma pequena parte de dados faz parte do conjunto de dados maior. Por exemplo, um usuário pode produzir uma [prova de Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) para provar a inclusão de uma transação em um bloco específico. +As raízes Merkle são primitivas criptográficas que permitem a compactação de grandes quantidades de informações. Uma raiz Merkle (também chamada de "raiz de bloco" neste caso) poderia representar todas as transações em um bloco. As raízes Merkle também tornam mais fácil verificar se uma pequena parte de dados faz parte do conjunto de dados maior. Por exemplo, um usuário pode produzir uma [prova Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) para provar a inclusão de uma transação em um bloco específico. -As raízes Merkle são importantes para fornecer informações sobre o estado off-chain para o Ethereum. Você pode pensar nas raízes de Merkle como "pontos salvos": o operador está dizendo, "Este é o estado da cadeia Plasma no ponto x no tempo, e esta é a raiz de Merkle como prova". O operador está se comprometendo com o _estado atual_ da cadeia plasma com uma raiz Merkle, por isso é chamado de "compromisso de estado". +As raízes de Merkle são importantes para fornecer informações sobre o estado offchain para o Ethereum. Você pode pensar nas raízes de Merkle como "pontos salvos": o operador está dizendo, "Este é o estado da cadeia Plasma no ponto x no tempo, e esta é a raiz de Merkle como prova". O operador está se comprometendo com o _estado atual_ da cadeia plasma com uma raiz Merkle, e é por isso que é chamado de "compromisso de estado". ### Entradas e saídas {#entries-and-exits} @@ -50,11 +50,11 @@ Para que os usuários do Ethereum aproveitem a cadeia Plasma, é necessário um Plasma usa um contrato principal em execução no Ethereum para processar entradas e saídas de usuários. Este contrato principal também é responsável por rastrear os compromissos do estado (explicado anteriormente) e punir o comportamento desonesto por meio de provas de fraude (mais sobre isso adiante). -#### Entrar na cadeia plasma {#entering-the-plasma-chain} +#### Entrando na cadeia plasma {#entering-the-plasma-chain} Para entrar na cadeia plasma, Alice (a usuária) terá que depositar ETH ou qualquer token ERC-20 no contrato plasma. A operadora de plasma, que observa os depósitos do contrato, recria uma quantia igual ao depósito inicial de Alice e o libera em seu endereço na cadeia plasma. Alice é obrigada a atestar o recebimento dos fundos na cadeia filha e pode então usar esses fundos para transações. -#### Sair da cadeia plasma {#exiting-the-plasma-chain} +#### Saindo da cadeia plasma {#exiting-the-plasma-chain} Sair da cadeia plasma é mais complexo do que entrar nela por várias razões. O maior delas é que, embora o Ethereum tenha informações sobre o estado da cadeia plasma, ele não pode verificar se as informações são verdadeiras ou não. Um usuário malicioso poderia fazer uma afirmação incorreta ("Eu tenho 1000 ETH") e fugir fornecendo provas falsas para sustentar a afirmação. @@ -62,17 +62,17 @@ Para evitar retiradas maliciosas, é introduzido um "período de desafio". Duran No entanto, normalmente os usuários são honestos e fazem reivindicações corretas sobre os fundos que possuem. Nesse cenário, Alice iniciará uma solicitação de retirada na cadeia raiz (Ethereum) enviando uma transação para o contrato de plasma. -Ela também deve fornecer uma prova Merkle verificando que, uma transação que criou seus fundos na cadeia Plasma foi incluída em um bloco. Isso é necessário para iterações de Plasma, como o [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html), que utiliza um modelo [Transação de Saída Não Gasta (Unspent Transaction Output, UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output). +Ela também deve fornecer uma prova Merkle verificando que, uma transação que criou seus fundos na cadeia Plasma foi incluída em um bloco. Isso é necessário para iterações do Plasma, como o [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html), que usam um modelo de [Saída de Transação Não Gasta (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output). -Outros, como [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html), representam fundos como [tokens não fungíveis](/developers/docs/standards/tokens/erc-721/) em vez de UTXOs. A retirada, neste caso, requer a prova de propriedade de tokens na cadeia Plasma. Isso é feito submetendo as duas últimas transações envolvendo o token e fornecendo uma prova Merkle verificando a inclusão dessas transações em um bloco. +Outros, como o [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html), representam fundos como [tokens não fungíveis](/developers/docs/standards/tokens/erc-721/) em vez de UTXOs. A retirada, neste caso, requer a prova de propriedade de tokens na cadeia Plasma. Isso é feito submetendo as duas últimas transações envolvendo o token e fornecendo uma prova Merkle verificando a inclusão dessas transações em um bloco. O usuário também deve adicionar um vínculo ao pedido de retirada como garantia de comportamento honesto. Se um desafiante provar que o pedido de retirada de Alice é inválido, seu vínculo é reduzido e parte dele vai para o desafiante como recompensa. Se o período de desafio decorrer sem que ninguém forneça uma prova de fraude, o pedido de retirada de Alice é considerado válido, permitindo que ela recupere os depósitos do contrato Plasma no Ethereum. -### Arbitragem de disputa {#dispute-arbitration} +### Arbitragem de disputas {#dispute-arbitration} -Como qualquer blockchain, as cadeias plasma precisam de um mecanismo para impor a integridade das transações, caso os participantes ajam maliciosamente (por exemplo, gastos duplos de fundos). Para isso, as cadeias plasma usam provas de fraude para arbitrar disputas sobre a validade das transições de estado e penalizar o mau comportamento. As provas de fraude são utilizadas como um mecanismo através do qual uma cadeia-filho do Plasma apresenta uma queixa à sua cadeia pai ou à cadeia raiz. +Como qualquer blockchain, as cadeias plasma precisam de um mecanismo para impor a integridade das transações, caso os participantes ajam maliciosamente (por exemplo, gasto duplo de fundos). Para isso, as cadeias plasma usam provas de fraude para arbitrar disputas sobre a validade das transições de estado e penalizar o mau comportamento. As provas de fraude são utilizadas como um mecanismo através do qual uma cadeia-filho do Plasma apresenta uma queixa à sua cadeia pai ou à cadeia raiz. Uma prova de fraude é simplesmente uma alegação de que uma determinada transição de estado é inválida. Um exemplo é se um usuário (Alice) tentar gastar os mesmos fundos duas vezes. Talvez ela tenha gasto o UTXO em uma transação com Bob e quer gastar o mesmo UTXO (que agora é de Bob) em outra transação. @@ -80,17 +80,17 @@ Para evitar a retirada, Bob construirá uma prova de fraude fornecendo evidênci Se o desafio de Bob é bem-sucedido, o pedido de retirada de Alice é cancelado. No entanto, essa abordagem depende da capacidade de Bob de observar a cadeia em busca de pedidos de retirada. Se Bob estiver offline, então a Alice poderá processar a retirada maliciosa, assim que o período de desafio terminar. -## O problema da saída em massa da cadeia Plasma {#the-mass-exit-problem-in-plasma} +## O problema de saída em massa no plasma {#the-mass-exit-problem-in-plasma} -O problema da saída em massa ocorre quando um grande número de usuários tenta retirar de uma cadeia de plasma ao mesmo tempo. Este problema existe por conta de um dos maiores problemas da cadeia Plasma: **indisponibilidade de dados**. +O problema da saída em massa ocorre quando um grande número de usuários tenta retirar de uma cadeia de plasma ao mesmo tempo. A existência deste problema está relacionada a um dos maiores problemas do Plasma: a **indisponibilidade de dados**. A disponibilidade de dados é a capacidade de verificar se as informações de um bloco proposto foram de fato publicadas na rede blockchain. Um bloco está "indisponível" se o produtor publicar o bloco em si, mas retiver os dados usados para criar o bloco. -Blocos devem estar disponíveis se os nós estão aptos a baixar o bloco e verificar a validade das transações. As blockchains garantem a disponibilidade de dados, forçando os produtores do bloco a publicar todos os dados da transação na cadeia. +Blocos devem estar disponíveis se os nós estão aptos a baixar o bloco e verificar a validade das transações. As blockchains garantem a disponibilidade dos dados forçando os produtores do bloco a publicar todos os dados de transações onchain. -A disponibilidade de dados também ajuda a proteger os protocolos de dimensionamento off-chain que se baseiam na camada base do Ethereum. Ao forçar os operadores nessas cadeias a publicar dados de transação no Ethereum, qualquer um pode desafiar blocos inválidos construindo provas de fraude que referenciam o estado correto da cadeia. +A disponibilidade de dados também ajuda a proteger protocolos de dimensionamento off-chain que se baseiam na camada base do Ethereum. Ao forçar os operadores nessas cadeias a publicar dados de transação no Ethereum, qualquer um pode desafiar blocos inválidos construindo provas de fraude que referenciam o estado correto da cadeia. -Cadeias Plasma armazenam principalmente dados de transação com o operador e **não publicam nenhum dado na rede principal** (ou seja, além de compromissos de estado periódicos). Isso significa que os usuários devem confiar no operador para fornecer dados de bloqueio, se precisarem criar provas de fraude que desafiem transações inválidas. Se esse sistema funcionar, então os usuários poderão sempre usar provas de fraude para proteger os fundos. +As cadeias Plasma armazenam principalmente dados de transação com o operador e **não publicam dados na Rede Principal** (ou seja, além dos compromissos de estado periódicos). Isso significa que os usuários devem confiar no operador para fornecer dados de bloqueio, se precisarem criar provas de fraude que desafiem transações inválidas. Se esse sistema funcionar, então os usuários poderão sempre usar provas de fraude para proteger os fundos. O problema começa quando o operador, e não apenas qualquer usuário, é a parte que age maliciosamente. Como o operador está no controle exclusivo da blockchain, ele tem mais incentivo para avançar as transições de estado inválido em uma escala maior, como o roubo de fundos pertencentes a usuários na cadeia plasma. @@ -98,35 +98,35 @@ Neste caso, a utilização do sistema clássico de prova de fraude não funciona Portanto, a solução mais otimista é tentar uma "saída em massa" dos usuários da cadeia Plasma. A saída em massa torna mais lento o plano do operador malicioso de roubar fundos e fornece alguma medida de proteção para os usuários. Os pedidos de retirada são ordenados com base em quando cada UTXO (ou token) foi criado, impedindo que operadores mal-intencionados se antecipem (front-running) aos usuários honestos. -No entanto, os nós ainda precisamos de uma maneira para verificar a validade dos pedidos de retirada durante uma saída em massa, para evitar que indivíduos oportunistas lucrem com o caos processando saídas inválidas. A solução é simples: exigir que os usuários postem o último **estado válido da cadeia** para retirar o dinheiro. +No entanto, os nós ainda precisamos de uma maneira para verificar a validade dos pedidos de retirada durante uma saída em massa, para evitar que indivíduos oportunistas lucrem com o caos processando saídas inválidas. A solução é simples: exigir que os usuários postem o último **estado válido da cadeia** para retirar seu dinheiro. Mas essa abordagem ainda tem problemas. Por exemplo, se todos os usuários em uma cadeia Plasma precisarem sair (o que é possível no caso de um operador malicioso), então todo o estado válido da cadeia Plasma deverá ser despejado na camada base do Ethereum de uma só vez. Com o tamanho arbitrário de cadeias Plasma (alto rendimento = mais dados) e as restrições nas velocidades de processamento do Ethereum, esta não é uma solução ideal. Embora os jogos de saída pareçam OK em teoria, as saídas em massa da vida real provavelmente desencadearão um congestionamento de rede no próprio Ethereum. Além de prejudicar a funcionalidade do Ethereum, uma saída em massa mal coordenada significa que, os usuários podem não conseguir retirar fundos antes que o operador drene todas as contas da cadeia Plasma. -## Prós e contras da cadeia Plasma {#pros-and-cons-of-plasma} +## Prós e contras do plasma {#pros-and-cons-of-plasma} -| Prós | Contras | -| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Oferece alta taxa de transferência e baixo custo por transação. | Não suporta computação geral (não pode executar contratos inteligentes). Apenas transferências básicas de tokens, swaps e alguns outros tipos de transação são suportados através da lógica preditiva. | -| Bom para transações entre usuários arbitrários (sem sobrecarga por par de usuário, se ambos estiverem estabelecidos na cadeia Pasma). | É necessário monitorar periodicamente a rede (exigência de vitalidade) ou delegar essa responsabilidade a outra pessoa para garantir a segurança de seus fundos. | -| As cadeias Plasma podem ser adaptadas a casos de uso específicos que não estão relacionados com a cadeia principal. Qualquer pessoa, incluindo empresas, pode personalizar contratos inteligentes de Plasma para fornecer infraestrutura dimensionável que funciona em diferentes contextos. | Refere-se a um ou mais operadores para armazenar dados e atender a pedido. | -| Reduz a carga na rede principal do Ethereum movendo a computação e o armazenamento off-chain. | As retiradas são adiadas por vários dias para permitir desafios. Para ativos fungíveis isso pode ser mitigado por provedores de liquidez, mas existe um custo de capital associado. | -| | Se muitos usuários tentarem sair simultaneamente, a rede principal do Ethereum poderá ficar congestionada. | +| Prós | Contras | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Oferece alta taxa de transferência e baixo custo por transação. | Não suporta computação geral (não pode executar contratos inteligentes). Apenas transferências básicas de tokens, swaps e alguns outros tipos de transação são suportados através da lógica preditiva. | +| Bom para transações entre usuários arbitrários (sem sobrecarga por par de usuário, se ambos estiverem estabelecidos na cadeia Pasma). | É necessário monitorar periodicamente a rede (exigência de vitalidade) ou delegar essa responsabilidade a outra pessoa para garantir a segurança de seus fundos. | +| As cadeias Plasma podem ser adaptadas a casos de uso específicos que não estão relacionados com a cadeia principal. Qualquer pessoa, incluindo empresas, pode personalizar contratos inteligentes de Plasma para fornecer infraestrutura dimensionável que funciona em diferentes contextos. | Refere-se a um ou mais operadores para armazenar dados e atender a pedido. | +| Reduz a carga na rede principal do Ethereum movendo a computação e o armazenamento para offchain. | As retiradas são adiadas por vários dias para permitir desafios. Para ativos fungíveis isso pode ser mitigado por provedores de liquidez, mas existe um custo de capital associado. | +| | Se muitos usuários tentarem sair simultaneamente, a rede principal do Ethereum poderá ficar congestionada. | -## Plasma versus protocolos dimensionáveis de camada 2 {#plasma-vs-layer-2} +## Plasma vs. protocolos de escalabilidade de camada 2 {#plasma-vs-layer-2} -Embora a cadeia Plasma já tenha sido considerada uma solução dimensionável e útil para o Ethereum, ela tem sido dispensada em favor de protocolos dimensionáveis da [camada 2 (L2)](/layer-2/). Soluções dimensionáveis L2 resolvem vários problemas da cadeia Plasma: +Embora o Plasma já tenha sido considerado uma solução de escalabilidade útil para o Ethereum, desde então foi abandonado em favor dos [protocolos de escalabilidade da camada 2 (L2)](/layer-2/). Soluções dimensionáveis L2 resolvem vários problemas da cadeia Plasma: ### Eficiência {#efficiency} -[Rollups de conhecimento zero](/developers/docs/scaling/zk-rollups) geram provas criptográficas da validade de cada lote de transações processado off-chain. Isso evita que usuários (e operadores) avancem em transições de estado inválido, eliminando a necessidade de períodos de desafio e jogos de saída. Isto também significa que os usuários não precisam monitorar a cadeia periodicamente para garantir seus fundos. +[Rollups de conhecimento zero](/developers/docs/scaling/zk-rollups) geram provas criptográficas da validade de cada lote de transações processadas off-chain. Isso evita que usuários (e operadores) avancem em transições de estado inválido, eliminando a necessidade de períodos de desafio e jogos de saída. Isto também significa que os usuários não precisam monitorar a cadeia periodicamente para garantir seus fundos. ### Suporte para contratos inteligentes {#support-for-smart-contracts} -Outro problema com o framework Plasma foi [a incapacidade de suportar a execução dos contratos inteligentes do Ethereum](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). Como resultado, a maioria das implementações da cadeia Plasma foram desenvolvidas principalmente para pagamentos simples ou o intercâmbio de tokens ERC-20. +Outro problema com o framework do plasma foi [a incapacidade de suportar a execução de contratos inteligentes do Ethereum](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). Como resultado, a maioria das implementações da cadeia Plasma foram desenvolvidas principalmente para pagamentos simples ou o intercâmbio de tokens ERC-20. -Por outro lado, os optimistic rollups são compatíveis com a [Ethereum Virtual Machine](/developers/docs/evm/) e podem executar [contratos inteligentes](/developers/docs/smart-contracts/) nativos do Ethereum, tornando-os uma solução de dimensionamento útil e _segura_ para [aplicativos descentralizados](/developers/docs/dapps/). De maneira similar, há planos em andamento para [criar uma implementação de conhecimento-zero da EVM (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) que permitiria aos ZK-rollups processar lógica arbitrária e executar contratos inteligentes. +Por outro lado, os optimistic rollups são compatíveis com a [Máquina Virtual Ethereum](/developers/docs/evm/) e podem executar [contratos inteligentes](/developers/docs/smart-contracts/) nativos do Ethereum, tornando-os uma solução útil e _segura_ para a escalabilidade de [aplicativos descentralizados](/developers/docs/dapps/). Da mesma forma, existem planos em andamento para [criar uma implementação de conhecimento zero da EVM (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) que permitiria que os ZK-rollups processassem lógica arbitrária e executassem contratos inteligentes. ### Indisponibilidade de dados {#data-unavailability} @@ -142,13 +142,14 @@ De maneira similar, os optimistic rollups impõem um período de atraso em retir Plasma, sidechains e sharding são bastante semelhantes porque todos estão ligados à rede principal do Ethereum de alguma forma. No entanto, o nível e a força dessas ligações variam, o que afeta as propriedades de segurança de cada solução de dimensionamento. -### Plasma vs sidechains {#plasma-vs-sidechains} +### Plasma vs. sidechains {#plasma-vs-sidechains} -Uma [sidechain](/developers/docs/scaling/sidechains/) é uma blockchain operada de maneira independente conectado à rede principal do Ethereum através de uma bridge bidirecional. [Bridges](/bridges/) permitem que os usuários troquem tokens entre as duas blockchains para realizar transações na sidechain, reduzindo o congestionamento na rede principal do Ethereum e melhorando o dimensionamento. As sidechains usam um mecanismo separado de consenso e são normalmente muito menores do que a rede principal do Ethereum. Como resultado, fazer bridge de ativos para essas cadeias implica um maior risco. Dada a falta de garantias de segurança herdadas da rede principal do Ethereum no modelo sidechain, os usuários arriscam a perder fundos em um ataque à sidechain. +Uma [sidechain](/developers/docs/scaling/sidechains/) é uma blockchain operada de forma independente e conectada à Rede Principal do Ethereum por meio de uma ponte bidirecional. [Pontes](/bridges/) permitem que os usuários troquem tokens entre as duas blockchains para realizar transações na sidechain, reduzindo o congestionamento na Rede Principal do Ethereum e melhorando a escalabilidade. +As sidechains usam um mecanismo separado de consenso e são normalmente muito menores do que a rede principal do Ethereum. Como resultado, fazer bridge de ativos para essas cadeias implica um maior risco. Dada a falta de garantias de segurança herdadas da rede principal do Ethereum no modelo sidechain, os usuários arriscam a perder fundos em um ataque à sidechain. Inversamente, as cadeias Plasma derivam sua segurança da rede principal. Isto as torna amplamente mais seguras do que as sidechains. Tanto as cadeias de sidechains como as de Plasma podem ter diferentes protocolos de consenso, mas a diferença é que as cadeias Plasma publicam raízes Merkle para cada bloco na rede principal do Ethereum. As raízes dos blocos são pequenos pedaços de informação que podemos utilizar para verificar informações sobre as transações que acontecem em uma cadeia Plasma. Se um ataque acontecer em uma cadeia Plasma, os usuários podem retirar com segurança seus fundos de volta à rede principal usando as provas adequadas. -### Plasma vs fragmentação (sharding) {#plasma-vs-sharding} +### Plasma vs. fragmentação {#plasma-vs-sharding} Tanto as cadeias plasma quanto as cadeias de fragmentos periodicamente publicam provas criptográficas na Mainnet (Rede principal) do Ethereum. No entanto, ambas têm propriedades de segurança diferentes. @@ -156,20 +157,20 @@ As cadeias de shard gravam "cabeçalhos de agrupamento" na rede principal conten A cadeia Plasma é diferente porque a rede principal só recebe informação mínima sobre o estado das cadeias filhas. Isto significa que rede principal não pode verificar eficazmente as transações realizadas em cadeias filhas, tornando-as menos seguras. -**Observe** que fragmentar a blockchain Ethereum não está mais no roteiro. Ela foi substituída por escalabilidade via rollups e [Danksharding](/roadmap/danksharding). +**Observação**: a fragmentação da blockchain do Ethereum não está mais no planejamento. Ela foi substituída pela escalabilidade via rollups e pelo [Danksharding](/roadmap/danksharding). -### Usar a cadeia Plasma {#use-plasma} +### Usar Plasma {#use-plasma} Vários projetos fornecem implementações da cadeia Plasma que você pode integrar aos seus dapps: -- [Polygon](https://polygon.technology/) (anteriormente Matic Network) +- [Polygon](https://polygon.technology/) (anteriormente Rede Matic) ## Leitura adicional {#further-reading} -- [Aprenda sobre a cadeia Plasma](https://www.learnplasma.org/en/) -- [Um lembrete rápido do que significa "segurança compartilhada" e por que é tão importante](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) -- [Sidechains vs Plasma vs Sharding](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) -- [Entenda a cadeia Plasma - parte 1: O básico](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) -- [A vida e a morte da cadeia Plasma](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) +- [Aprenda sobre Plasma](https://www.learnplasma.org/en/) +- [Um rápido lembrete do que significa "segurança compartilhada" e por que ela é tão importante](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [Sidechains vs. Plasma vs. Sharding](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) +- [Entendendo o Plasma, Parte 1: O Básico](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [A Vida e a Morte do Plasma](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) -_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/scaling/sidechains/index.md b/public/content/translations/pt-br/developers/docs/scaling/sidechains/index.md index 540b4c07f19..7c4462c7e13 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/sidechains/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/sidechains/index.md @@ -1,13 +1,13 @@ --- -title: Sidechains -description: Uma introdução às sidechains como solução de dimensionamento atualmente utilizada pela comunidade Ethereum +title: Cadeias laterais +description: "Uma introdução às sidechains como solução de dimensionamento atualmente utilizada pela comunidade Ethereum" lang: pt-br sidebarDepth: 3 --- -Uma sidechain é uma blockchain separada que se executa independente do Ethereum e está conectada à rede principal do Ethereum por uma bridge nos dois sentidos. As sidechains podem ter parâmetros de blocos separados e [algoritmos de consenso](/developers/docs/consensus-mechanisms/), que são geralmente projetados para um processamento eficiente de transações. Entretanto, usar uma sidechain tem vantagens e desvantagens, já que elas não herdam as propriedades de segurança do Ethereum. Ao contrário das [soluções de dimensionamento da camada 2](/layer-2/), as sidechains não publicam alterações no estado e dados de transação de volta à rede principal do Ethereum. +Uma sidechain é uma blockchain separada que se executa independente do Ethereum e está conectada à rede principal do Ethereum por uma bridge nos dois sentidos. As sidechains podem ter parâmetros de bloco e [algoritmos de consenso](/developers/docs/consensus-mechanisms/) separados, que são frequentemente projetados para o processamento eficiente de transações. Entretanto, usar uma sidechain tem vantagens e desvantagens, já que elas não herdam as propriedades de segurança do Ethereum. Diferentemente das [soluções de escalabilidade de camada 2](/layer-2/), as sidechains não publicam alterações de estado e dados de transação de volta para a Mainnet do Ethereum. -As sidechains também sacrificam alguma medida de descentralização ou segurança para alcançar alta vazão de dados ([trilema do dimensionamento](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). O Ethereum, no entanto, comprometeu-se a dimensionar sem comprometer a descentralização e a segurança, conforme descrito na sua [declaração de visão](/roadmap/) relacionada a atualizações. +As sidechains também sacrificam um certo grau de descentralização ou segurança para alcançar um alto rendimento ([trilema da escalabilidade](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). O Ethereum, no entanto, está comprometido com a escalabilidade sem comprometer a descentralização e a segurança. ## Como funcionam as sidechains? {#how-do-sidechains-work} @@ -23,38 +23,38 @@ Uma das qualidades que tornam as sidechains únicas (ou seja, diferentes do Ethe Como o Ethereum, as sidechains têm nós de validação que verificam e processam transações, produzem blocos e armazenam o estado da blockchain. Os validadores são também responsáveis por manterem o consenso em toda a rede e protegê-la contra ataques maliciosos. -#### Parâmetros do bloco {#block-parameters} +#### Parâmetros de bloco {#block-parameters} -O Ethereum coloca limites nos [tempos de bloco](/developers/docs/blocks/#block-time) (ou seja, o tempo que leva para produzir novos blocos) e os [tamanhos de blocos](/developers/docs/blocks/#block-size) (ou seja, a quantidade de dados contida por bloco denominada em gas). Inversamente, as sidechains muitas vezes adotam parâmetros diferentes, como tempos de bloco mais rápidos e limites de gás mais elevados, para alcançar altas transferências, transações rápidas e taxas baixas. +O Ethereum impõe limites aos [tempos de bloco](/developers/docs/blocks/#block-time) (ou seja, o tempo que leva para produzir novos blocos) e aos [tamanhos de bloco](/developers/docs/blocks/#block-size) (ou seja, a quantidade de dados contida por bloco, denominada em gás). Inversamente, as sidechains muitas vezes adotam parâmetros diferentes, como tempos de bloco mais rápidos e limites de gás mais elevados, para alcançar altas transferências, transações rápidas e taxas baixas. Embora isso tenha alguns benefícios, tem implicações críticas para a descentralização e segurança da rede. Parâmetros de bloco, como tempos de bloco rápidos e tamanhos grandes de blocos, aumentam a dificuldade de rodar um nó completo, deixando alguns "supernós" responsáveis pela segurança da cadeia. Em tal cenário, aumenta a possibilidade de colusão de validadores ou de uma tomada maliciosa da cadeia. -Para que as blockchains se dimensionem sem prejudicar a descentralização, executar um nó deve estar aberto a todos, e não necessariamente a terceiros com hardware especializado. É por isso que estão em curso esforços para garantir que todos possam [executar um nó completo](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) na rede Ethereum. +Para que as blockchains se dimensionem sem prejudicar a descentralização, executar um nó deve estar aberto a todos, e não necessariamente a terceiros com hardware especializado. É por isso que estão em andamento esforços para garantir que todos possam [executar um nó completo](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) na rede Ethereum. -### Compatibilidade com EVM {#evm-compatibility} +### Compatibilidade com a EVM {#evm-compatibility} -Algumas sidechains são compatíveis com EVM e podem executar contratos desenvolvidos para a [Ethereum Virtual Machine (EVM)](/developers/docs/evm/). As sidechains compatíveis com EVM suportam contratos inteligentes [escritos em Solidity](/developers/docs/smart-contracts/languages/), bem como outras linguagens de contratos inteligentes EVM, o que significa que contratos inteligentes escritos para a rede principal do Ethereum também funcionarão em sidechains compatíveis com EVM. +Algumas sidechains são compatíveis com a EVM e podem executar contratos desenvolvidos para a [Máquina Virtual do Ethereum (EVM)](/developers/docs/evm/). As sidechains compatíveis com a EVM suportam contratos inteligentes [escritos em Solidity](/developers/docs/smart-contracts/languages/), bem como outras linguagens de contratos inteligentes da EVM, o que significa que os contratos inteligentes escritos para a Mainnet do Ethereum também funcionarão em sidechains compatíveis com a EVM. -Isso significa que se você quer usar seu [dapp](/developers/docs/dapps/) na sidechain, é apenas uma questão de implantar seu [contrato inteligente](/developers/docs/smart-contracts/) nesta sidechain. A aparência e o comportamento dele se asemelham ao da rede principal. Você escreve contratos em Solidity e interage com a cadeia através da RPC da sidechain. +Isso significa que, se você quiser usar seu [dapp](/developers/docs/dapps/) em uma sidechain, basta implantar seu [contrato inteligente](/developers/docs/smart-contracts/) nessa sidechain. A aparência e o comportamento dele se asemelham ao da rede principal. Você escreve contratos em Solidity e interage com a cadeia através da RPC da sidechain. -Como as sidechains são compatíveis com EVM, elas são consideradas uma útil [solução de dimensionamento](/developers/docs/scaling/) para dapps nativos do Ethereum. Com o seu dapp em uma sidechain, os usuários podem aproveitar taxas de gás mais baixas e transações mais rápidas, especialmente se a rede principal estiver congestionada. +Como as sidechains são compatíveis com a EVM, elas são consideradas uma [solução de escalabilidade](/developers/docs/scaling/) útil para dapps nativos do Ethereum. Com o seu dapp em uma sidechain, os usuários podem aproveitar taxas de gás mais baixas e transações mais rápidas, especialmente se a rede principal estiver congestionada. No entanto, tal como foi explicado anteriormente, a utilização de uma sidechain envolve compromissos significativos. Cada sidechain é responsável pela sua segurança e não herda as propriedades de segurança do Ethereum. Isso aumenta a possibilidade de comportamentos maliciosos que possam afetar os usuários ou colocar seus fundos em risco. -### Movimento de ativos {#asset-movement} +### Movimentação de ativos {#asset-movement} -Para que uma blockchain separada se torne uma sidechain para a rede principal do Ethereum, ela precisa da capacidade de facilitar a transferência de ativos de e para a rede principal do Ethereum. Esta interoperabilidade com o Ethereum é alcançada usando uma bridge de blockchain. As [bridges](/bridges/) usam contratos inteligentes implementados na rede principal do Ethereum e uma sidechain para controlar a comunicação de fundos entre elas. +Para que uma blockchain separada se torne uma sidechain para a rede principal do Ethereum, ela precisa da capacidade de facilitar a transferência de ativos de e para a rede principal do Ethereum. Esta interoperabilidade com o Ethereum é alcançada usando uma bridge de blockchain. [As pontes](/bridges/) usam contratos inteligentes implantados na Mainnet do Ethereum e em uma sidechain para controlar a ponte de fundos entre elas. -Enquanto as bridges ajudam usuários a mover fundos entre o Ethereum e a sidechain, os ativos não são fisicamente movidos pelas duas cadeias. Em vez disso, os mecanismos que normalmente envolvem a mintagem (mint) e a queima (burn) são utilizados para transferir valor entre cadeias. Mais sobre [como as bridges funcionam](/developers/docs/bridges/#how-do-bridges-work). +Enquanto as bridges ajudam usuários a mover fundos entre o Ethereum e a sidechain, os ativos não são fisicamente movidos pelas duas cadeias. Em vez disso, os mecanismos que normalmente envolvem a mintagem (mint) e a queima (burn) são utilizados para transferir valor entre cadeias. Mais sobre [como as pontes funcionam](/developers/docs/bridges/#how-do-bridges-work). ## Prós e contras das sidechains {#pros-and-cons-of-sidechains} -| Prós | Contras | -| --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | -| A tecnologia que sustenta as sidechains está bem estabelecida e se beneficia de uma pesquisa abrangente e de melhorias na concepção. | As sidechains abrem mão de alguma medida de descentralização e confiabilidade por dimensionamento. | -| As sidechains suportam computação geral e oferecem compatibilidade com EVM (elas podem executar dapps nativos do Ethereum). | Uma sidechain utiliza um mecanismo separado de consenso e não se beneficia das garantias de segurança do Ethereum. | -| As sidechains usam diferentes modelos de consenso para processar transações com eficiência e taxas de transação mais baixas para os usuários. | As sidechains requerem suposições de confiança mais elevados (por exemplo, um quórum de validadores maliciosos da sidechain pode cometer fraude). | -| As sidechains compatíveis com EVM permitem que dapps expandam seu ecossistema. | | +| Prós | Contras | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| A tecnologia que sustenta as sidechains está bem estabelecida e se beneficia de uma pesquisa abrangente e de melhorias na concepção. | As sidechains abrem mão de alguma medida de descentralização e confiabilidade por dimensionamento. | +| As sidechains suportam computação geral e oferecem compatibilidade com EVM (elas podem executar dapps nativos do Ethereum). | Uma sidechain utiliza um mecanismo separado de consenso e não se beneficia das garantias de segurança do Ethereum. | +| As sidechains usam diferentes modelos de consenso para processar transações com eficiência e taxas de transação mais baixas para os usuários. | As sidechains requerem suposições de confiança mais elevados (por exemplo, um quórum de validadores maliciosos da sidechain pode cometer fraude). | +| As sidechains compatíveis com EVM permitem que dapps expandam seu ecossistema. | | ### Usar sidechains {#use-sidechains} @@ -68,6 +68,6 @@ Vários projetos fornecem implementações da cadeia Plasma que você pode integ ## Leitura adicional {#further-reading} -- [Como dimensionar dapps do Ethereum por meio de sidechains](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _Georgios Konstantopoulos, 8 de fev., 2018 (em inglês))._ +- [Escalando dapps do Ethereum através de sidechains](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _8 de fevereiro de 2018 - Georgios Konstantopoulos_ -_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/scaling/state-channels/index.md b/public/content/translations/pt-br/developers/docs/scaling/state-channels/index.md index c0667c73331..aab240312fa 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/state-channels/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/state-channels/index.md @@ -1,71 +1,71 @@ --- title: Canais de estado -description: Uma introdução aos canais de estado e canais de pagamento como uma solução de dimensionamento atualmente utilizada pela comunidade Ethereum. +description: "Uma introdução aos canais de estado e canais de pagamento como uma solução de dimensionamento atualmente utilizada pela comunidade Ethereum." lang: pt-br sidebarDepth: 3 --- -Os canais de estado permitem que os participantes transacionem com segurança off-chain, com o mínimo de interação com a rede principal do Ethereum. Os peers do canal podem conduzir um número arbitrário de transações off-chain enquanto enviam apenas duas transações on-chain para abrir e fechar o canal. Isso permite uma taxa de transferência de transação extremamente alta e resulta em custos mais baixos para os usuários. +Os canais de estado permitem que os participantes realizem transações com segurança off-chain, com o mínimo de interação com a rede principal do Ethereum. Os pares do canal podem conduzir um número arbitrário de transações offchain, enviando apenas duas transações onchain para abrir e fechar o canal. Isso permite uma taxa de transferência de transação extremamente alta e resulta em custos mais baixos para os usuários. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Você deve ter lido e compreendido nossas páginas sobre [escalando o Ethereum](/developers/docs/scaling/) e [segunda camada](/layer-2/). +Você deve ter lido e entendido nossas páginas aos [Ethereum scaling](/developers/docs/scaling/) e [layer 2](/layer-2/). ## O que são canais? {#what-are-channels} -Blockchains públicas, como Ethereum, enfrentam desafios de dimensionamento devido à sua arquitetura distribuída: onde as transações on-chain devem ser executadas por todos os nós. Os nós devem ser capazes de lidar com o volume de transações em um bloco usando hardware modesto, impondo um limite na taxa de transferência da transação para manter a rede descentralizada. Os canais de blockchain resolvem esse problema permitindo que os usuários interajam off-chain enquanto ainda confiam na segurança da cadeia principal para a liquidação final. +Blockchains públicas, como Ethereum, enfrentam desafios de escalabilidade devido à sua arquitetura distribuída: transações onchain devem ser executadas por todos os nós. Os nós devem ser capazes de lidar com o volume de transações em um bloco usando hardware modesto, impondo um limite na taxa de transferência da transação para manter a rede descentralizada. Os canais de blockchain resolvem esse problema permitindo que os usuários interajam offchain enquanto ainda confiam na segurança da cadeia principal para a liquidação final. -Os canais são simples protocolos ponto a ponto que permitem que duas partes façam muitas transações entre si e depois publiquem apenas os resultados finais na blockchain. O canal usa criptografia para demonstrar que os dados de resumo gerados são realmente o resultado de um conjunto válido de transações intermediárias. Um contrato inteligente ["multisig"](/developers/docs/smart-contracts/#multisig) garante que as transações sejam assinadas pelas partes corretas. +Os canais são simples protocolos ponto a ponto que permitem que duas partes façam muitas transações entre si e depois publiquem apenas os resultados finais na blockchain. O canal usa criptografia para demonstrar que os dados de resumo gerados são realmente o resultado de um conjunto válido de transações intermediárias. Um contrato inteligente ["multisig"](/developers/docs/smart-contracts/#multisig) garante transações assinadas pelas pessoas corretas. Com os canais, as mudanças de estado são executadas e validadas pelas partes interessadas, minimizando a computação na camada de execução do Ethereum. Isso diminui o congestionamento no Ethereum e também aumenta a velocidade de processamento de transações para os usuários. -Cada canal é gerenciado por um [contrato inteligente multisig](/developers/docs/smart-contracts/#multisig) em execução no Ethereum. Para abrir um canal, os participantes implantam o contrato de canal on-chain e depositam fundos nele. Ambas as partes assinam coletivamente uma atualização de estado para inicializar o estado do canal, após o qual podem realizar transações rápidas e livres off-chain. +Cada canal é gerenciado por um [multisig smart contract](/developers/docs/smart-contracts/#multisig) no Ethereum. Para abrir um canal, os participantes implementam o contrato do canal onchain e depositam fundos nele. Ambas as partes assinam coletivamente uma atualização de estado para inicializar o estado do canal, após o qual podem realizar transações offchain de forma rápida e livre. -Para fechar o canal, os participantes submetem o último estado acordado do canal on-chain. Em seguida, o contrato inteligente distribui os fundos bloqueados de acordo com o saldo de cada participante no estado final do canal. +Para fechar o canal, os participantes enviam o último estado acordado do canal onchain. Em seguida, o contrato inteligente distribui os fundos bloqueados de acordo com o saldo de cada participante no estado final do canal. -Os canais ponto a ponto são particularmente úteis para situações em que alguns participantes predefinidos desejam realizar transações com alta frequência sem incorrer em sobrecarga visível. Os canais da blockchain se enquadram em duas categorias: **canais de pagamento** e **canais de estado**. +Os canais ponto a ponto são particularmente úteis para situações em que alguns participantes predefinidos desejam realizar transações com alta frequência sem incorrer em sobrecarga visível. Os canais de blockchain dividem-se em **payment channels** e **state channels**. -## Canais de pagamento {#payment-channels} +## Payment channels {#payment-channels} -Um canal de pagamento é melhor descrito como um "livro de duas vias" mantido coletivamente por dois usuários. O saldo inicial do livro é a soma dos depósitos bloqueados no contrato on-chain durante a fase de abertura do canal. Transferências do canal de pagamento podem ser realizadas instantaneamente e sem o envolvimento da própria blockchain, exceto a criação inicial de uma única vez on-chain e um eventual fechamento do canal. +Um canal de pagamento é melhor descrito como um "livro de duas vias" mantido coletivamente por dois usuários. O saldo inicial do livro razão é a soma dos depósitos bloqueados no contrato onchain durante a fase de abertura do canal. As transferências de canais de pagamento podem ser realizadas instantaneamente e sem o envolvimento da blockchain em si, exceto por uma criação inicial única onchain e um eventual fechamento do canal. As atualizações no saldo do livro (ou seja, o estado do canal de pagamento) requerem a aprovação de todas as partes do canal. Uma atualização de canal, assinada por todos os participantes do canal, é considerada finalizada, assim como uma transação no Ethereum. -Os canais de pagamento estavam entre as primeiras soluções de dimensionamento projetadas para minimizar atividades caras on-chain, em interações simples do usuário (por exemplo, transferências ETH, atomic swaps, micropagamentos). Os participantes do canal podem conduzir uma quantidade ilimitada de instâncias, transações sem valor entre si, desde que a soma líquida de suas transferências não exceda os tokens depositados. +Os canais de pagamento estavam entre as primeiras soluções de escalonamento projetadas para minimizar atividades onchain dispendiosas de interações simples do usuário (por exemplo, transferências de ETH, atomic swaps, micropagamentos). Os participantes do canal podem conduzir uma quantidade ilimitada de instâncias, transações sem valor entre si, desde que a soma líquida de suas transferências não exceda os tokens depositados. -## Canais de Estado {#state-channels} +## State channels {#state-channels} -Além de oferecer suporte a pagamentos off-chain, os canais de pagamento não têm se mostrado úteis para lidar com a lógica geral de transição de estado. Os canais de estado foram criados para resolver esse problema e torná-los úteis para dimensionar a computação de propósito geral. +Além de oferecer suporte a pagamentos offchain, os canais de pagamento não se mostraram úteis para lidar com a lógica geral de transição de estado. Os canais de estado foram criados para resolver esse problema e torná-los úteis para dimensionar a computação de propósito geral. Os canais de estado ainda têm muito em comum com os canais de pagamento. Por exemplo, os usuários interagem através da troca de mensagens (transações) assinadas criptograficamente, que os outros participantes do canal também devem assinar. Se uma proposta de atualização de estado não for assinada por todos os participantes, ela não será válida. No entanto, além de manter os saldos do usuário, o canal também rastreia o estado atual do armazenamento do contrato (ou seja, valores das variáveis do contrato). -Isso torna possível a execução de um contrato inteligente off-chain entre dois usuários. Nesse cenário, as atualizações para o estado interno do contrato inteligente exigem apenas a aprovação dos pares que criaram o canal. +Isso torna possível executar um contrato inteligente offchain entre dois usuários. Nesse cenário, as atualizações para o estado interno do contrato inteligente exigem apenas a aprovação dos pares que criaram o canal. -Embora isso resolva o problema de dimensionamento descrito anteriormente, tem implicações para a segurança. Na Ethereum, a validade das transições de estado no Ethereum é imposta pelo protocolo de consenso da rede. Isso torna impossível propor uma atualização inválida para o estado de um contrato inteligente ou alterar a execução do contrato inteligente. +Embora isso resolva o problema de dimensionamento descrito anteriormente, tem implicações para a segurança. No Ethereum, a validade das transições de estado é imposta pelo protocolo de consenso da rede. Isso torna impossível propor uma atualização inválida para o estado de um contrato inteligente ou alterar a execução do contrato inteligente. -Os canais de estado não têm as mesmas garantias de segurança. Até certo ponto, um canal de estado é uma versão miniatura da rede principal. Com um conjunto limitado de participantes aplicando regras, a possibilidade de comportamento malicioso (por exemplo, propondo atualizações de estado inválidas) aumenta. Canais de estado derivam sua segurança de um sistema de arbitragem de disputas baseado em [provas de fraude](/glossary/#fraud-proof). +Os canais de estado não têm as mesmas garantias de segurança. Até certo ponto, um canal de estado é uma versão miniatura da rede principal. Com um conjunto limitado de participantes aplicando regras, a possibilidade de comportamento malicioso (por exemplo, propondo atualizações de estado inválidas) aumenta. O state channels security baseia dispute arbitration system (/glossary/#fraud-proof). -## Como os canais de estado funcionam {#how-state-channels-work} +## Como os state channels funcionam {#how-state-channels-work} -Basicamente, a atividade em um canal de estado é uma sessão de interações envolvendo usuários e um sistema blockchain. Os usuários se comunicam principalmente off-chain e interagem apenas com a blockchain subjacente para abrir o canal, fechar o canal ou resolver possíveis disputas entre os participantes. +Basicamente, a atividade em um canal de estado é uma sessão de interações envolvendo usuários e um sistema blockchain. Os usuários se comunicam principalmente entre si offchain e interagem com a blockchain subjacente apenas para abrir o canal, fechar o canal ou resolver possíveis disputas entre os participantes. A seção a seguir descreve o fluxo de trabalho básico de um canal de estado: -### Abrir o canal {#opening-the-channel} +### Opening the channel {#opening-the-channel} -Abrir um canal exige que os participantes comprometam fundos a um contrato inteligente na rede principal. O depósito também funciona como uma tabulação virtual, de modo que os atores participantes podem transacionar livremente sem necessidade de liquidar os pagamentos imediatamente. Somente quando o canal estiver finalizado on-chain, as partes fazem o acerto e retiram o que corresponde a cada uma delas. +Abrir um canal exige que os participantes comprometam fundos a um contrato inteligente na rede principal. O depósito também funciona como uma tabulação virtual, de modo que os atores participantes podem transacionar livremente sem necessidade de liquidar os pagamentos imediatamente. Somente quando o canal é finalizado onchain as partes liquidam entre si e retiram o que sobrou de suas contas. Este depósito também serve como um vínculo para garantir um comportamento honesto de cada participante. Se os depositantes forem considerados culpados de ações maliciosas durante a fase de resolução de litígios, o contrato reduzirá o depósito deles. Os pares de canal devem assinar um acordo inicial, com o qual todos concordam. Isto serve como origem do canal de estado, após a qual os usuários poderão começar a realizar transações. -### Usar o canal {#using-the-channel} +### Using the channel {#using-the-channel} Depois de inicializar o estado do canal, os pares interagem assinando transações e enviando uns aos outros para aprovação. Os participantes iniciam atualizações de estado com essas transações e assinam atualizações de estados de outros. Cada transação é composta do seguinte: -- Um **nonce**, que atua como um ID único para transações e impede ataques de replay. Ele também identifica a ordem pela qual ocorreram as atualizações de estado (o que é importante para a resolução de litígios) +- **Nonce**, o ID só por transações, pode evitar replay attacks. Ele também identifica a ordem pela qual ocorreram as atualizações de estado (o que é importante para a resolução de litígios) - O estado antigo do canal @@ -73,13 +73,13 @@ Depois de inicializar o estado do canal, os pares interagem assinando transaçõ - A transação que aciona a transição de estado (por exemplo, Alice envia 5 ETH para Bob) -As atualizações de estado no canal não são transmitidas on-chain, como normalmente acontece quando os usuários interagem na rede principal, o que se alinha com o objetivo dos canais de estado de minimizar a pegada on-chain. Desde que os participantes concordem em atualizações de estado, elas são tão finais como uma transação Ethereum. Os participantes só têm de depender do consenso da rede principal se surgir uma disputa. +As atualizações de estado no canal não são transmitidas onchain, como normalmente acontece quando os usuários interagem na Mainnet, o que está alinhado com o objetivo dos canais de estado de minimizar o impacto onchain. Desde que os participantes concordem em atualizações de estado, elas são tão finais como uma transação Ethereum. Os participantes só têm de depender do consenso da rede principal se surgir uma disputa. -### Fechar o canal {#closing-the-channel} +### Closing the channel {#closing-the-channel} -Fechar um canal de estado requer o envio do estado final e acordado do canal para o contrato inteligente on-chain. Os detalhes referenciados na atualização do estado incluem o número de movimentos de cada participante e uma lista de transações aprovadas. +Para fechar um canal de estado, é necessário enviar o estado final acordado para o contrato inteligente onchain. Os detalhes referenciados na atualização do estado incluem o número de movimentos de cada participante e uma lista de transações aprovadas. -Após verificar que a atualização de estado é válida (ou seja, está assinada por todas as partes), o contrato inteligente finaliza o canal e distribui os fundos bloqueados de acordo com o resultado do canal. Pagamentos feitos off-chain são aplicados ao estado do Ethereum e cada participante recebe sua porção restante dos fundos bloqueados. +Após verificar que a atualização de estado é válida (ou seja, está assinada por todas as partes), o contrato inteligente finaliza o canal e distribui os fundos bloqueados de acordo com o resultado do canal. Os pagamentos feitos offchain são aplicados ao estado do Ethereum e cada participante recebe sua parte restante dos fundos bloqueados. O cenário descrito acima representa o que acontece caso tudo dê certo. Às vezes, os usuários podem não conseguir chegar a um acordo e finalizar o canal. Uma das seguintes poderia ser a verdadeira situação: @@ -87,87 +87,87 @@ O cenário descrito acima representa o que acontece caso tudo dê certo. Às vez - Os participantes se recusam-se a coassinar atualizações de estado válidas -- Os participantes tentam finalizar o canal propondo uma antiga atualização de estado para o contrato on-chain +- Os participantes tentam finalizar o canal propondo uma atualização de estado antiga para o contrato onchain - Os participantes propõem transições de estado inválidas para que outros assinem -Sempre que o consenso se divide entre os participantes em um canal, a última opção é contar com o consenso da rede principal para impor o estado final e válido do canal. Neste caso, o encerramento do canal de estado exige a resolução de litígios on-chain. +Sempre que o consenso se divide entre os participantes em um canal, a última opção é contar com o consenso da rede principal para impor o estado final e válido do canal. Nesse caso, fechar o canal de estado exige a resolução de disputas onchain. -### Resolução de disputas {#settling-disputes} +### Settling disputes {#settling-disputes} -Normalmente, as partes em um canal concordam em fechar o canal antecipadamente e coassinam a última transição de estado, que eles submetem ao contrato inteligente. Uma vez que a atualização é aprovada on-chain, a execução do contrato inteligente off-chain termina e os participantes saem do canal com o dinheiro deles. +Normalmente, as partes em um canal concordam em fechar o canal antecipadamente e coassinam a última transição de estado, que eles submetem ao contrato inteligente. Assim que a atualização for aprovada onchain, a execução do contrato inteligente offchain termina e os participantes saem do canal com seu dinheiro. -No entanto, uma das partes pode submeter uma solicitação on-chain para terminar a execução do contrato inteligente e finalizar o canal, sem esperar a aprovação da contraparte. Se alguma das situações de ruptura de consenso descritas anteriormente ocorrer, qualquer das partes poderá acionar o contrato on-chain para fechar o canal e distribuir fundos. Isso fornece a **não necessidade de confiança**, garantindo que partes honestas possam sair com seus depósitos a qualquer momento, independentemente das ações da outra parte. +No entanto, uma parte pode enviar uma solicitação onchain para encerrar a execução do contrato inteligente e finalizar o canal, sem esperar a aprovação da contraparte. Se ocorrer qualquer uma das situações de quebra de consenso descritas anteriormente, qualquer uma das partes pode acionar o contrato onchain para fechar o canal e distribuir os fundos. A parte mais honestada pode sair a qualquer momento. -Para processar a saída do canal, o usuário deve submeter a última atualização válida do estado do aplicativo para o contrato on-chain. Se esta verificação ocorrer (ou seja, ele tem a assinatura de todas as partes), então os fundos serão redistribuídos a seu favor. +Para processar a saída do canal, o usuário deve enviar a última atualização de estado válida do aplicativo para o contrato onchain. Se esta verificação ocorrer (ou seja, ele tem a assinatura de todas as partes), então os fundos serão redistribuídos a seu favor. -No entanto, há um atraso na execução de pedidos de saída de um único usuário. Se o pedido para concluir o canal foi aprovado unanimemente, então a transação de saída on-chain é executada imediatamente. +No entanto, há um atraso na execução de pedidos de saída de um único usuário. Se a solicitação para concluir o canal for aprovada por unanimidade, a transação de saída onchain será executada imediatamente. -O atraso entra em vigor na saída de um único usuário devido à possibilidade de ações fraudulentas. Por exemplo, um usuário do canal pode tentar finalizar o canal no Ethereum, submetendo uma atualização mais antiga do estado on-chain. +O atraso entra em vigor na saída de um único usuário devido à possibilidade de ações fraudulentas. Por exemplo, um participante do canal pode tentar finalizar o canal no Ethereum enviando uma atualização de estado mais antiga onchain. -Como contramedida, canais de estado permitem que usuários honestos desafiem atualizações de estado inválidas submetendo o mais recente estado válido do canal on-chain. Canais de estado são projetados para que as mais recentes, e acordadas, atualizações de estado vençam atualizações de estado mais antigas. +Como contramedida, os canais de estado permitem que usuários honestos contestem atualizações de estado inválidas enviando o estado mais recente e válido do canal onchain. Canais de estado são projetados para que as mais recentes, e acordadas, atualizações de estado vençam atualizações de estado mais antigas. -Uma vez que uma parte aciona o sistema de resolução de disputas on-chain, a outra parte precisa responder dentro de um limite de tempo (chamado de janela do desafio). Isso permite que os usuários desafiem a transação de saída, especialmente se a outra pessoa estiver aplicando uma atualização obsoleta. +Quando uma parte aciona o sistema de resolução de disputas onchain, a outra parte é obrigada a responder dentro de um limite de tempo (chamado de janela de desafio). Isso permite que os usuários desafiem a transação de saída, especialmente se a outra pessoa estiver aplicando uma atualização obsoleta. -Seja qual for o caso, usuários de canais sempre têm fortes garantias de finalidade: se a transição de estado em sua posse foi assinada por todos os membros e é a atualização mais recente, então tem a mesma finalidade de uma transação regular on-chain. Continuam a ter de desafiar a outra parte on-chain, mas o único resultado possível é a conclusão do último estado válido, que eles detêm. +Seja qual for o caso, os usuários do canal sempre têm fortes garantias de finalidade: se a transição de estado em sua posse foi assinada por todos os membros e é a atualização mais recente, então ela é de mesma finalidade que uma transação regular onchain. Eles ainda precisam desafiar a outra parte onchain, mas o único resultado possível é finalizar o último estado válido, que eles detêm. ### Como os canais de estado interagem com o Ethereum? {#how-do-state-channels-interact-with-ethereum} -Embora eles existam como protocolos off-chain, os canais de estado têm um componente on-chain: o contrato inteligente implantado no Ethereum ao abrir o canal. Este contrato controla os ativos depositados no canal, verifica atualizações de estado e arbitra disputas entre os participantes. +Embora existam como protocolos offchain, os canais de estado têm um componente onchain: o contrato inteligente implantado no Ethereum ao abrir o canal. Este contrato controla os ativos depositados no canal, verifica atualizações de estado e arbitra disputas entre os participantes. -Canais de estado não publicam dados de transação ou compromissos de estado na rede principal, ao contrário das soluções de dimensionamento da [camada 2](/layer-2/). No entanto, eles estão mais conectados à rede principal do que, digamos, as [sidechains](/developers/docs/scaling/sidechains/), tornando-os um pouco mais seguros. +Os State channels não mostram dados de transações ou compromissos no Mainnet, diferente da escalabilidade da [camada 2](/layer-2/). No entanto, eles estão mais conectados ao Mainnet do que, digamos, [sidechains](/developers/docs/scaling/sidechains/), o quê faz os State Channels um pouco mais seguros. As canais de estado dependem do protocolo principal do Ethereum para o seguinte: -#### 1. Vivacidade {#liveness} +#### 1. Liveness {#liveness} -O contrato on-chain implantado ao abrir o canal é responsável pela funcionalidade do canal. Se o contrato estiver em execução no Ethereum, então o canal estará sempre disponível para uso. Inversamente, uma sidechain sempre pode falhar, mesmo que a rede principal esteja operacional, colocando o dinheiro dos usuários em risco. +O contrato onchain implantado ao abrir o canal é responsável pela funcionalidade do canal. Se o contrato estiver em execução no Ethereum, então o canal estará sempre disponível para uso. Inversamente, uma sidechain sempre pode falhar, mesmo que a rede principal esteja operacional, colocando o dinheiro dos usuários em risco. #### 2. Segurança {#security} Até certo ponto, os canais de estado dependem do Ethereum para fornecer segurança e proteger usuários de pares maliciosos. Conforme discutido em outras seções, os canais usam um mecanismo de prova de fraude que permite aos usuários desafiarem tentativas de finalizar o canal com uma atualização inválida ou obsoleta. -Neste caso, a parte honesta fornece o mais recente estado válido do canal como uma prova de fraude do contrato on-chain para verificação. As provas de fraude permitem que partes mutuamente desconfiadas realizem transações off-chain sem arriscar os seus fundos no processo. +Nesse caso, a parte honesta fornece o estado válido mais recente do canal como prova de fraude ao contrato onchain para verificação. Provas de fraude permitem que partes mutuamente desconfiadas conduzam transações offchain sem arriscar seus fundos no processo. -#### 3. Finalidade {#finality} +#### 3. Finality {#finality} -Atualizações de estado assinadas coletivamente pelos usuários do canal são consideradas como boas transações on-chain. Ainda assim, toda a atividade dentro do canal só atinge a verdadeira finalidade quando o canal é fechado no Ethereum. +Atualizações de estado assinadas coletivamente pelos usuários do canal são consideradas tão boas quanto transações onchain. Ainda assim, toda a atividade dentro do canal só atinge a verdadeira finalidade quando o canal é fechado no Ethereum. -No caso otimista, ambas as partes podem cooperar e assinar a atualização final do estado e enviar on-chain para fechar o canal, após o qual os fundos são distribuídos de acordo com o estado final do canal. No caso pessimista, onde alguém tenta trapacear publicando uma atualização incorreta do estado on-chain, sua transação não é finalizada até que a janela do desafio termine. +No caso otimista, ambas as partes podem cooperar e assinar a atualização do estado final e enviar on-chain para fechar o canal, após o que os fundos são distribuídos de acordo com o estado final do canal. No caso pessimista, onde alguém tenta trapacear publicando uma atualização incorreta do estado on-chain, sua transação não é finalizada até que a janela do desafio termine. -## Canais de estado virtual {#virtual-state-channels} +## Virtual state channels {#virtual-state-channels} -A implementação ingênua de um canal de estado seria implantar um novo contrato quando dois usuários desejam executar um aplicativo off-chain. Isso não é apenas inviável, mas também anula a relação custo-benefício dos canais de estado (os custos de transação on-chain podem aumentar rapidamente). +A implementação ingênua de um canal de estado seria implantar um novo contrato quando dois usuários desejam executar um aplicativo offchain. Isso não é apenas inviável, mas também anula a relação custo-benefício dos canais de estado (os custos de transação onchain podem aumentar rapidamente). -Para resolver este problema, foram criados "canais virtuais". Ao contrário dos canais regulares que exigem transações on-chain para abrir e encerrar, um canal virtual pode ser aberto, executado e finalizado sem interagir com a cadeia principal. É até possível resolver conflitos off-chain usando esse método. +Para resolver este problema, foram criados "canais virtuais". Ao contrário dos canais regulares que exigem transações onchain para abrir e encerrar, um canal virtual pode ser aberto, executado e finalizado sem interagir com a cadeia principal. É até possível resolver disputas offchain usando esse método. -Este sistema se baseia na existência dos chamados "canais ledgers" (canais de livro razão distribuídos), que foram financiados on-chain. Canais virtuais entre duas partes podem ser construídos sobre um canal ledger existente, com o(s) proprietário(s) do canal ledger servindo como intermediário. +Este sistema depende da existência dos chamados "canais de livro razão", que foram financiados onchain. Canais virtuais entre duas partes podem ser construídos sobre um canal ledger existente, com o(s) proprietário(s) do canal ledger servindo como intermediário. Os usuários em cada canal virtual interagem por meio de uma nova instância de contrato, com o canal ledger capaz de suportar várias instâncias de contrato. O estado do canal ledger também contém mais de um estado de armazenamento de contrato, permitindo a execução paralela de aplicativos off-chain entre diferentes usuários. -Assim como os canais regulares, os usuários trocam atualizações de estado para progredir na máquina de estado. Exceto quando surge uma disputa, o intermediário só precisa ser contatado ao abrir ou encerrar o canal. +Assim como os canais regulares, os usuários trocam atualizações de estado para progredir na máquina de estado. A menos que surja uma disputa, o intermediário só precisa ser contatado ao abrir ou encerrar o canal. -### Canais de pagamento virtual {#virtual-payment-channels} +### Virtual payment channels {#virtual-payment-channels} Os canais virtuais de pagamento funcionam com a mesma ideia dos canais virtuais de estado: os participantes conectados à mesma rede podem passar mensagens sem a necessidade de abrir um novo canal on-chain. Nos canais virtuais de pagamento, as transferências de valores são roteadas por um ou mais intermediários, com a garantia de que somente o destinatário pretendido poderá receber os recursos transferidos. -## Aplicações de canais de estado {#applications-of-state-channels} +## Applications of state channels {#applications-of-state-channels} -### Pagamentos {#payments} +### Payments {#payments} Os canais de blockchain iniciais eram simples protocolos que permitiam a dois participantes realizarem transferências rápidas e de baixas taxas off-chain sem terem que pagar elevadas taxas de transação na rede principal. Hoje, os canais de pagamento ainda são úteis para os aplicativos projetados para a troca e depósitos de ether e tokens. Pagamentos baseados em canais possuem as seguintes vantagens: -1. **Taxa de transferência**: a quantidade de transações off-chain por canal não está conectada à taxa de transferência do Ethereum, que é influenciada por vários fatores, especialmente o tamanho dos blocos e tempo de bloco. Ao executar transações off-chain, os canais da blockchain podem alcançar uma taxa de transferência mais alta. +1. **Taxa de transferência**: a quantidade de transações off-chain por canal não está conectada à taxa de transferência do Ethereum, que é influenciada por vários fatores, especialmente o tamanho dos blocos e tempo de bloco. Ao executar transações offchain, os canais de blockchain podem atingir maior rendimento. -2. **Privacidade**: devido à existência de canais off-chain, os detalhes das interações entre participantes não são gravados na blockchain pública do Ethereum. Os usuários do canal só têm que interagir na on-chain quando financiam e fecham canais ou resolvem disputas. Assim, os canais são úteis para as pessoas que desejam transações mais particulares. +2. **Privacidade**: Como os canais existem offchain, os detalhes das interações entre os participantes não são registradas na blockchain pública do Ethereum. Os usuários dos canais só precisam interagir onchain quando financiam e fecham canais ou resolvem disputas. Assim, os canais são úteis para as pessoas que desejam transações mais particulares. -3. **Latência**: as transações off-chain conduzidas entre os participantes do canal podem ser resolvidas instantaneamente, se ambas as partes cooperarem, reduzindo atrasos. Em contraste, enviar uma transação para a rede principal requer esperar que os nós processem a transação, produzam um novo bloco com a transação e alcançem consenso. Os usuários podem também precisar esperar por mais confirmações de blocos antes de considerar uma transação finalizada. +3. **Latência**: transações offchain conduzidas entre os participantes do canal podem ser liquidadas instantaneamente, se ambas as partes cooperarem, reduzindo atrasos. Em contraste, enviar uma transação para a rede principal requer esperar que os nós processem a transação, produzam um novo bloco com a transação e alcançem consenso. Os usuários podem também precisar esperar por mais confirmações de blocos antes de considerar uma transação finalizada. -4. **Custo**: canais de estados são particularmente úteis em situações em que um conjunto de participantes intercambiará muitas atualizações de estado por um longo período. Os únicos custos incorridos são a abertura e o encerramento do canal de estado do contrato inteligente; cada mudança de estado entre a abertura e o encerramento do canal será mais barata do que a última, uma vez que o custo da liquidação é distribuído em conformidade. +4. **Custo**: Canais de estados são particularmente úteis em situações em que um conjunto de participantes intercambiará muitas atualizações de estado por um longo período. Os únicos custos incorridos são a abertura e o encerramento do canal de estado do contrato inteligente; cada mudança de estado entre a abertura e o encerramento do canal será mais barata do que a última, uma vez que o custo da liquidação é distribuído em conformidade. -Implementar canais de estado nas soluções de camada 2, como [rollups](/developers/docs/scaling/#rollups), poderia torná-las ainda mais atraentes para pagamentos. Embora os canais ofereçam pagamentos baratos, os custos de estabelecer o contrato on-chain na rede principal durante a fase de abertura podem ser caros, especialmente quando as taxas de gás aumentam. Os rollups baseados no Ethereum oferecem [taxas de transação mais baixas](https://l2fees.info/) e podem reduzir a sobrecarga para os participantes do canal reduzindo as taxas de configuração. +Implementar canais estado em soluções de Layer 2, como [rollups](/developers/docs/scaling/#rollups), pode torná-las ainda mais atraentes para pagamentos. Embora os canais ofereçam pagamentos baratos, os custos de estabelecer o contrato on-chain na rede principal durante a fase de abertura podem ser caros, especialmente quando as taxas de gás aumentam. Os rollups baseados em Ethereum oferecem [taxas de transação mais baixas](https://l2fees.info/) e podem reduzir as despesas gerais para os participantes do canal ao diminuir as taxas de configuração. ### Microtransações {#microtransactions} @@ -177,25 +177,25 @@ Os canais de pagamento resolvem este problema reduzindo a sobrecarga associada c Além do custo de abrir e fechar o canal, os participantes não incorrem em custos adicionais nas microtransações (sem taxas de gás). Esta é uma situação vantajosa para todos, uma vez que os clientes têm mais flexibilidade na forma como pagam os serviços, e as empresas não perdem em microtransações rentáveis. -### Aplicativos descentralizados {#decentralized-applications} +### Aplicações descentralizadas {#decentralized-applications} -Tal como os canais de pagamento, os canais de estado podem fazer pagamentos condicionais, de acordo com os estados finais da máquina de estado. Canais de estado também podem suportar lógica arbitrária de transição de estado, tornando-os úteis para executar aplicativos genéricos off-chain. +Tal como os canais de pagamento, os canais de estado podem fazer pagamentos condicionais, de acordo com os estados finais da máquina de estado. Os canais de estado também podem suportar lógica de transição de estado arbitrária, tornando-os úteis para executar aplicativos genéricos offchain. -Os canais de estado são muitas vezes limitados a simples aplicativos baseados em turnos, já que isso facilita a gestão dos fundos comprometidos com o contrato on-chain. Além disso, com um número limitado de partes atualizando o estado do aplicativo off-chain em intervalos, punir comportamentos desonestos é relativamente simples. +Os canais de estado são geralmente limitados a aplicativos simples baseados em turnos, pois isso facilita o gerenciamento de fundos dedicados ao contrato on-chain. Além disso, com um número limitado de partes atualizando o estado do aplicativo off-chain em intervalos, punir comportamentos desonestos é relativamente simples. -A eficiência de um aplicativo do canal de estado depende também do seu desenho. Por exemplo, um desenvolvedor pode implantar o contrato de canal do aplicativo on-chain uma vez e permitir que outras partes reutilizem o app sem ter que estar on-chain. Neste caso, o canal inicial do aplicativo serve como um canal do ledger que oferece suporte a vários canais virtuais, cada um executando uma nova instância do contrato inteligente off-chain. +A eficiência de um aplicativo do canal de estado depende também do seu desenho. Por exemplo, um desenvolvedor pode implantar o contrato de canal do aplicativo on-chain uma vez e permitir que outras partes reutilizem o aplicativo sem ter que estar on-chain. Nesse caso, o canal do aplicativo inicial serve como um canal de registro que dá suporte a vários canais virtuais, cada um executando uma nova instância do contrato inteligente do aplicativo off-chain. -Um caso de uso potencial para aplicativos de canal de estado sao os jogos de dois jogadores, em que os fundos são distribuídos com base no resultado do jogo. O benefício aqui é que os jogadores não têm que confiar uns nos outros (trustlessness), e o contrato on-chain, não os jogadores, controla a alocação de fundos e a resolução de litígios (descentralização). +Um caso de uso potencial para aplicativos de canal de estado sao os jogos de dois jogadores, em que os fundos são distribuídos com base no resultado do jogo. O benefício aqui é que os jogadores não precisam confiar uns nos outros (trustlessness) e o contrato on-chain, não os jogadores, controla a alocação de fundos e a resolução de disputas (descentralização). Outros possíveis casos de uso para aplicativos de canais de estado incluem propriedade de nome ENS, registros NFT e muito mais. ### Transferências atômicas {#atomic-transfers} -Os canais de pagamento iniciais eram restritos a transferências entre duas partes, limitando a sua usabilidade. No entanto, a introdução de canais virtuais permitiu que indivíduos encaminhassem transferências através de intermediários (ou seja, vários canais p2p) sem ter que abrir um novo canal on-chain. +Os canais de pagamento iniciais eram restritos a transferências entre duas partes, limitando a sua usabilidade. No entanto, a introdução de canais virtuais permitiu que indivíduos encaminhassem transferências por meio de intermediários (ou seja, vários canais p2p) sem precisar abrir um novo canal on-chain. -Comumente descrito como transferências "multi-hop", os pagamentos roteados são atômicos (ou seja, ou todas as partes da transação são realizadas de forma bem-sucedida ou ela falha completamente). As transferências atômicas usam [Hashed Timelock Contracts (HTLCs)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) para garantir que o pagamento seja liberado apenas se certas condições forem atendidas, reduzindo assim o risco de contraparte. +Comumente descrito como transferências "multi-hop", os pagamentos roteados são atômicos (ou seja, ou todas as partes da transação são realizadas de forma bem-sucedida ou ela falha completamente). Transferências atômicas usam [Contratos de Bloqueio de Tempo com Hash (HTLCs)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) para garantir que o pagamento seja liberado somente se certas condições forem atendidas, reduzindo assim o risco da contraparte. -## Desvantagens de se usar canais de estado {#drawbacks-of-state-channels} +## Desvantagens do uso de canais estado {#drawbacks-of-state-channels} ### Suposições de vivacidade {#liveness-assumptions} @@ -203,7 +203,7 @@ Para garantir a eficiência, os canais de estado colocam limites de tempo na cap Na realidade, os usuários podem ficar offline por razões fora do seu controle (por exemplo, má conexão de internet, falha mecânica, etc.). Se um usuário honesto fica offline, um par malicioso pode explorar a situação apresentando os antigos estados intermediários ao contrato do adjudicador e roubar os fundos comprometidos. -Alguns canais usam "watchtowers" – entidades responsáveis por acompanhar eventos de disputas on-chain em nome de outros e tomar as ações necessárias, como alertar as partes interessadas. No entanto, isso pode aumentar os custos de utilização de um canal de estado. +Alguns canais usam "torres de vigilância", entidades responsáveis ​​por monitorar eventos de disputas on-chain em nome de terceiros e tomar as medidas necessárias, como alertar as partes interessadas. No entanto, isso pode aumentar os custos de utilização de um canal de estado. ### Indisponibilidade de dados {#data-unavailability} @@ -215,29 +215,29 @@ Os usuários do Ethereum não precisam lidar com esse problema, uma vez que a re ### Problemas de liquidez {#liquidity-issues} -Para estabelecer um canal blockchain, os participantes precisam bloquear fundos em um contrato inteligente on-chain para o ciclo de vida do canal. Isto reduz a liquidez dos usuários do canal e também limita os canais para aqueles que podem arcar com os fundos bloqueados na rede principal. +Para estabelecer um canal blockchain, os participantes precisam bloquear fundos em um contrato inteligente onchain durante o ciclo de vida do canal. Isto reduz a liquidez dos usuários do canal e também limita os canais para aqueles que podem arcar com os fundos bloqueados na rede principal. -No entanto, canais do ledger, operados por um provedor de serviços off-chain (OSP), podem reduzir problemas de liquidez para os usuários. Dois pares conectados a um canal de ledger podem criar um canal virtual, que eles podem abrir e finalizar completamente off-chain, quando quiserem. +No entanto, os canais de registro, operados por um provedor de serviços off-chain (OSP), podem reduzir os problemas de liquidez para os usuários. Dois pares conectados a um canal de registro podem criar um canal virtual, que eles podem abrir e finalizar completamente off-chain, quando quiserem. -Provedores de serviço off-chain também podem abrir canais com vários pares, tornando-os úteis para encaminhar pagamentos. É claro que os utilizadores têm de pagar taxas aos OSPs pelos seus serviços, o que pode ser indesejável para alguns. +Os provedores de serviços offchain também podem abrir canais com vários pares, tornando-os úteis para rotear pagamentos. É claro que os utilizadores têm de pagar taxas aos OSPs pelos seus serviços, o que pode ser indesejável para alguns. ### Ataques de griefing {#griefing-attacks} Os ataques de griefing são uma característica comum dos sistemas baseados em provas de fraude. Um ataque de griefing não beneficia diretamente o atacante, mas causa dor (ou seja, dano) à vítima, daí o nome. -A prova de fraude é suscetível a ataques de griefing porque a parte honesta deve responder a todas as disputas, até mesmo as inválidas, ou corre o risco de perder os seus fundos. Um participante malicioso pode decidir repetidamente publicar o estado de transições on-chain, forçando a parte honesta a responder com o estado válido. O custo dessas transações on-chain pode aumentar rapidamente, fazendo com que partes honestas se percam no processo. +A prova de fraude é suscetível a ataques de griefing porque a parte honesta deve responder a todas as disputas, até mesmo as inválidas, ou corre o risco de perder os seus fundos. Um participante malicioso pode decidir postar repetidamente transições de estado onchain, forçando a parte honesta a responder com o estado válido. O custo dessas transações onchain pode aumentar rapidamente, fazendo com que as partes honestas percam no processo. ### Conjuntos de participantes predefinidos {#predefined-participant-sets} -Por desenho, o número de participantes que compõem um canal do estado permanece fixo ao longo de sua vida. Isso porque atualizar o conjunto dos participantes iria complicar a operação do canal, especialmente ao financiar o canal ou resolver conflitos. Adicionar ou remover os participantes também exigiria atividade adicional on-chain, o que aumenta a sobrecarga para os usuários. +Por desenho, o número de participantes que compõem um canal do estado permanece fixo ao longo de sua vida. Isso porque atualizar o conjunto dos participantes iria complicar a operação do canal, especialmente ao financiar o canal ou resolver conflitos. Adicionar ou remover participantes também exigiria atividade adicional na onchain, o que aumentaria a sobrecarga para os usuários. Embora isso torne os canais de estado mais fáceis de justificar, ele limita a utilidade dos desenhos de canais aos desenvolvedores de aplicativos. Isso explica parcialmente porque os canais de estado foram preteridos a favor de outras soluções de dimensionamento, como rollups. -### Processamento paralelo de transações {#parallel-transaction-processing} +### Processamento de transações paralelas {#parallel-transaction-processing} -Os participantes do canal de estado enviam atualizações de estado em turnos, e é por isso que eles funcionam melhor para aplicativos baseados em turnos (por exemplo, um jogo de xadrez com dois jogadores). Isso elimina a necessidade de lidar com atualizações de estado simultâneas e reduz o trabalho que o contrato on-chain deve fazer para punir quem publica atualizações de estado obsoletas. No entanto, um efeito colateral desse desenho é que as transações são dependentes uma das outras, aumentando a latência e diminuindo a experiência geral do usuário. +Os participantes do canal de estado enviam atualizações de estado em turnos, e é por isso que eles funcionam melhor para aplicativos baseados em turnos (por exemplo, um jogo de xadrez com dois jogadores). Isso elimina a necessidade de lidar com atualizações de estado simultâneas e reduz o trabalho que o contrato on-chain deve fazer para punir quem publica atualizações desatualizadas. No entanto, um efeito colateral desse desenho é que as transações são dependentes uma das outras, aumentando a latência e diminuindo a experiência geral do usuário. -Alguns canais de estado resolvem esse problema usando um design "full-duplex" que separa o estado off-chain em dois estados unidirecionais de estados "simplex", permitindo atualizações de estado simultâneas. Tais desenhos melhoram a taxa de transferência off-chain e diminuem os atrasos nas transações. +Alguns canais de estado resolvem esse problema usando um design "full-duplex" que separa o estado offchain em dois estados "simplex" unidirecionais, permitindo atualizações de estado simultâneas. Esses projetos melhoram o rendimento offchain e diminuem os atrasos nas transações. ## Usar canais de estado {#use-state-channels} @@ -253,9 +253,9 @@ Vários projetos fornecem implementações da cadeia Plasma que você pode integ **Canais de Estado** -- [Entendendo a camada 2](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _12 de fev., 2018 - Josh Stark_ -- [Canais de estado: uma explicação](https://www.jeffcoleman.ca/state-channels/) _6 de nov., 2015 - Jeff Coleman_ -- [Fundamentos dos canais de estado](https://unlock-protocol.github.io/ethhub/ethereum-roadmap/layer-2-scaling/state-channels/) _District0x_ -- [Canais de estado da blockchain: um componente de última geração](https://ieeexplore.ieee.org/document/9627997) +- [Compreendendo as soluções de escalabilidade da camada 2 do Ethereum: canais de estado, plasma e Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark, Feb 12 2018_ +- [Estados de Canais - uma explicação](https://www.jeffcoleman.ca/state-channels/) _Nov 6, 2015 - Jeff Coleman_ +- [Noções básicas sobre Estados de Canais](https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/) - _District0x_ +- [Estados de Canais Blockchain: Um Estado da Arte](https://ieeexplore.ieee.org/document/9627997) -_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione-o!_ \ No newline at end of file +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/scaling/validium/index.md b/public/content/translations/pt-br/developers/docs/scaling/validium/index.md index 4d27137442b..b2aa8a4da66 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/validium/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/validium/index.md @@ -1,41 +1,41 @@ --- title: Validium -description: Uma introdução ao Validium como uma solução de dimensionamento atualmente utilizada pela comunidade Ethereum. +description: "Uma introdução ao Validium como uma solução de dimensionamento atualmente utilizada pela comunidade Ethereum." lang: pt-br sidebarDepth: 3 --- -Validium é uma [solução de dimensionamento](/developers/docs/scaling/) que reforça a integridade de transações usando provas de validade como [ZK-rollups](/developers/docs/scaling/zk-rollups/), mas não armazena dados de transação na rede principal do Ethereum. Embora a disponibilidade de dados off-chain introduz compromissos, ela pode levar a enormes melhorias de dimensionamento (validiums podem processar [cerca de 9.000 transações ou mais, por segundo](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). +O Validium é uma [solução de escalabilidade](/developers/docs/scaling/) que impõe a integridade das transações usando provas de validade como os [ZK-rollups](/developers/docs/scaling/zk-rollups/), mas não armazena os dados das transações na Mainnet do Ethereum. Embora a disponibilidade de dados fora da cadeia introduza alguns compromissos, ela pode levar a melhorias massivas na escalabilidade (os validiums podem processar [\~9.000 transações, ou mais, por segundo](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). ## Pré-requisitos {#prerequisites} -Você deve ler e entender mais sobre em nossa página [Dimensionamento Ethereum](/developers/docs/scaling/) e [camada 2](/layer-2). +Você deve ter lido e entendido nossa página sobre [escalabilidade do Ethereum](/developers/docs/scaling/) e [camada 2](/layer-2/). ## O que é validium? {#what-is-validium} -Validiums são soluções de dimensionamento que usam a disponibilidade de dados off-chain e computação projetadas para melhorar a taxa de transferência processando transações fora da rede principal do Ethereum. Como rollups de conhecimento zero (ZK-rollups), os validiums publicam [provas de conhecimento zero](/glossary/#zk-proof) para verificar transações off-chain no Ethereum. Isso impede transições de estado inválidas e melhora as garantias de segurança de uma cadeia validium. +Validiums são soluções de escala que usam a disponibilidade de dados off-chain e computação projetadas para melhorar a taxa de transferência processando transações fora da rede principal do Ethereum. Assim como os rollups de conhecimento zero (ZK-rollups), os validiums publicam [provas de conhecimento zero](/glossary/#zk-proof) para verificar transações fora da cadeia no Ethereum. Isso impede transições de estado inválidas e melhora as garantias de segurança de uma cadeia validium. Essas "provas de validade" podem vir na forma de ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) ou ZK-STARKs (Zero-Knowledge Scalable Transparent ARgument of Knowledge). Mais sobre [provas de conhecimento zero](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/). -Fundos pertencentes a usuários validium são controlados por um contrato inteligente no Ethereum. Os validiums oferecem saques quase instantâneos, muito parecidos com ZK-rollups; uma vez que a prova de validade para uma solicitação de retirada tenha sido verificada na rede principal, os usuários podem retirar fundos fornecendo [provas Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). A prova Merkle valida a inclusão da transação de retirada do usuário em um lote de transação verificado, permitindo o contrato on-chain processar a retirada. +Fundos pertencentes a usuários validium são controlados por um contrato inteligente no Ethereum. Os validiums oferecem saques quase instantâneos, assim como os ZK-rollups; uma vez que a prova de validade de uma solicitação de saque tenha sido verificada na Mainnet, os usuários podem sacar fundos fornecendo [provas Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). A prova Merkle valida a inclusão da transação de retirada do usuário em um lote de transações verificadas, permitindo que o contrato onchain processe a retirada. -No entanto, usuários validium podem ter seus fundos congelados e retiradas restritas. Isso pode acontecer se os gerentes de disponibilidade de dados na cadeia validium retiverem dados de estado off-chain de usuários. Sem acesso a dados de transação, os usuários não podem calcular a prova de Merkle necessária para provar a propriedade de fundos e executar retiradas. +No entanto, usuários validium podem ter seus fundos congelados e retiradas restritas. Isso pode acontecer se os gerentes de disponibilidade de dados na rede validium retiverem dados de estado off-chain de usuários. Sem acesso a dados de transação, os usuários não podem calcular a prova de Merkle necessária para provar a propriedade de fundos e executar retiradas. Esta é a maior diferença entre validiums e ZK-rollups: suas posições sobre o espectro de disponibilidade de dados. Ambas as soluções abordam o armazenamento de dados de forma diferente, o que tem implicações para a segurança e a não necessidade de confiança. ## Como os validiums interagem com o Ethereum? {#how-do-validiums-interact-with-ethereum} -Validiums são protocolos de dimensionamento criados sobre a cadeia Ethereum existente. Embora execute transações off-chain, uma cadeia validium é administrada por uma coleção de contratos inteligentes implantados na rede principal, incluindo: +Validiums são protocolos de dimensionamento criados sobre a cadeia Ethereum existente. Embora execute transações off-chain, uma rede validium é administrada por uma coleção de contratos inteligentes implementados na rede principal, incluindo: -1. **Contrato verificador**: o contrato verificador verifica a validade das provas submetidas pelo operador validium ao fazer atualizações no estado. Isso inclui provas de validade que atestam a exatidão das transações off-chain e provas de disponibilidade de dados verificando a existência de dados de transações off-chain. +1. **Contrato verificador**: O contrato verificador verifica a validade das provas enviadas pelo operador do validium ao fazer atualizações de estado. Isso inclui provas de validade que atestam a exatidão das transações off-chain e provas de disponibilidade de dados verificando a existência de dados de transações off-chain. -2. **Contrato principal**: o contrato principal armazena os compromissos do estado (Merkle roots) enviados por produtores de blocos e atualiza o estado do validium, uma vez que uma prova do validium é verificada on-chain. Este contrato também processa tanto saques quanto depósitos para a cadeia validium. +2. **Contrato principal**: O contrato principal armazena compromissos de estado (raízes Merkle) enviados por produtores de bloco e atualiza o estado do validium assim que uma prova de validade for verificada na cadeia. Este contrato também processa tanto saques quanto depósitos para a cadeia validium. Validiums também dependem da principal cadeia de Ethereum para o seguinte: ### Liquidação {#settlement} -Transações executadas em um validium não podem ser totalmente confirmadas até que a cadeia pai verifique sua validade. Todos os negócios realizados em um validium devem eventualmente ser estabelecidos na rede principal. A blockchain Ethereum também fornece "garantias de liquidação" para usuários validium, o que significa que as transações off-chain não podem ser revertidas ou alteradas uma vez gravadas on-chain. +Transações executadas em um validium não podem ser totalmente confirmadas até que a cadeia pai verifique sua validade. Todos os negócios realizados em um validium devem eventualmente ser estabelecidos na rede principal. A blockchain Ethereum também fornece "garantias de liquidação" para usuários validium, o que significa que as transações off-chain não podem ser revertidas ou alteradas uma vez gravadas onchain. ### Segurança {#security} @@ -47,17 +47,17 @@ Se o contrato do verificador on-chain considerar a prova inválida, as transaç ### Transações {#transactions} -Os usuários enviam transações para o operador, um nó responsável por executar transações na cadeia de validium. Alguns validiums podem usar um único operador para executar a cadeia ou depender de um mecanismo de [prova de participação (PoS)](/developers/docs/consensus-mechanisms/pos/) para rotar os operadores. +Os usuários enviam transações para o operador, um nó responsável por executar transações na cadeia de validium. Alguns validiums podem usar um único operador para executar a cadeia ou depender de um mecanismo de [prova de participação (PoS)](/developers/docs/consensus-mechanisms/pos/) para rotacionar operadores. O operador agrega as transações em um lote e envia para um circuito de prova para testar. O circuito de prova aceita o lote de transação (e outros dados relevantes) como entradas e produz como saída uma prova de validade verificando que as operações foram executadas corretamente. -### Compromissos com o estado {#state-commitments} +### Compromissos de estado {#state-commitments} O estado do validium é em hash como uma árvore Merkle, com a raiz armazenada no contrato principal no Ethereum. A raiz de Merkle, também conhecida como a raiz do estado, atua como um compromisso criptográfico com o estado atual das contas e saldos no validium. Para executar uma atualização de estado, o operador deve calcular uma nova raiz de estado (depois de executar transações) e enviá-la ao contrato on-chain. Se a prova de validade confirmar, o estado proposto é aceito e o validium muda para a nova raiz do estado. -### Depósitos e retiradas {#deposits-and-withdrawals} +### Depósitos e saques {#deposits-and-withdrawals} Os usuários movem fundos do Ethereum para um validium depositando ETH (ou qualquer token compatível com ERC) no contrato on-chain. O contrato transmite o evento de depósito para o validium off-chain, em que o endereço do usuário é creditado com um valor igual ao seu depósito. O operador também inclui esta transação de depósito em um novo lote. @@ -69,13 +69,13 @@ Como um mecanismo anticensura, o protocolo de validium permite que os usuários Após executar um lote de transações, o operador submete a prova de validade associada ao contrato verificador e propõe uma nova raiz do estado para o contrato principal. Se a prova for válida, o contrato principal atualizará o estado do validium e finalizará os resultados das transações do lote. -Ao contrário de uma ZK-rollup, produtores de blocos em um validium não são obrigados a publicar dados de transações para transação em lotes (apenas cabeçalhos do bloco). Isso faz do validium um protocolo de dimensionamento puramenteoff-chain, ao contrário de protocolos de dimensionamento "híbridos" (ou seja, [camada 2](/layer-2/)) que publicam dados de estado na cadeia principal do Ethereum como `calldata`. +Ao contrário de uma ZK-rollup, produtores de blocos em um validium não são obrigados a publicar dados de transações para transação em lotes (apenas cabeçalhos do bloco). Isso torna o validium um protocolo de escalabilidade puramente fora da cadeia, em oposição aos protocolos de escalabilidade "híbridos" (ou seja, [camada 2](/layer-2/)) que publicam dados de estado na cadeia principal do Ethereum usando dados blob, `calldata` ou uma combinação de ambos. ### Disponibilidade de dados {#data-availability} -Como mencionado, os validiums atuais utilizam um modelo de disponibilidade de dados off-chain em que os operadores armazenam todos os dados de transação fora da rede principal do Ethereum. A baixa pegada de dados on-chain do validium melhora o dimensionamento (a transferência não é limitada pela capacidade de processamento de dados do Ethereum) e reduz as taxas de usuário (o custo de publicação de `calldata` é menor). +Como mencionado, os validiums utilizam um modelo de disponibilidade de dados off-chain em que os operadores armazenam todos os dados de transação fora da rede principal do Ethereum. A baixa pegada de dados onchain do validium melhora o dimensionamento (a transferência não é limitada pela capacidade de processamento de dados do Ethereum) e reduz as taxas de usuário (o custo de publicação de calldata é menor). -No entanto, a disponibilidade de dados off-chain apresenta um problema: os dados necessários para a criação ou verificação de provas Merkle podem estar indisponíveis. Isto significa que os utilizadores poderão não conseguir retirar fundos do contrato on-chain se os operadores agirem de forma maliciosa. +No entanto, a disponibilidade de dados off-chain apresenta um problema: os dados necessários para a criação ou verificação de provas Merkle podem estar indisponíveis. Isto significa que os usuários podem não conseguir retirar fundos do contrato on-chain se os operadores agirem de forma maliciosa. Várias soluções validium tentam resolver este problema descentralizando o armazenamento de dados do estado. Isso envolve forçar os produtores de blocos a enviar os dados subjacentes a "gerentes de disponibilidade de dados" responsáveis por armazenar dados off-chain e disponibilizá-los aos usuários a pedido. @@ -87,17 +87,17 @@ Validiums diferem em sua abordagem da gestão da disponibilidade de dados. Algun Para garantir a disponibilidade de dados off-chain, algumas soluções validium nomeiam um grupo de entidades confiáveis, coletivamente conhecido como um comitê de disponibilidade de dados (DAC), para armazenar cópias do estado e fornecer uma prova de disponibilidade de dados. Os DACs são mais fáceis de implementar e exigem menos coordenação, uma vez que a adesão é baixa. -No entanto, os usuários devem confiar no DAC para disponibilizar os dados quando necessário (por exemplo, para a geração de provas de Merkle). Existe a possibilidade de membros dos comitês de disponibilidade de dados [serem comprometidos por um ator malicioso](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view) que pode então reter dados off-chain. +No entanto, os usuários devem confiar no DAC para disponibilizar os dados quando necessário (por exemplo, para a geração de provas de Merkle). Existe a possibilidade de membros dos comitês de disponibilidade de dados [serem comprometidos por um agente malicioso](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view) que pode então reter os dados fora da cadeia. -[Mais sobre comissões de disponibilidade de dados em validiums](https://medium.com/starkware/data-availability-e5564c416424). +[Mais sobre comitês de disponibilidade de dados em validiums](https://medium.com/starkware/data-availability-e5564c416424). -#### Disponibilidade de dados vinculados {#bonded-data-availability} +#### Disponibilidade de dados por vínculo {#bonded-data-availability} Outros validiums exigem que os participantes sejam cobrados com o armazenamento de dados offline para fazer staking (ou seja, bloquear) tokens em um contrato inteligente antes de assumir suas funções. Este stake serve como uma "obrigação" para garantir um comportamento honesto entre os gerentes de disponibilidade de dados e reduzir as suposições de confiança. Se esses participantes não conseguirem provar a disponibilidade de dados, o vínculo será reduzido. -Em um esquema de disponibilidade de dados vinculado, qualquer um pode ser atribuído para armazenar dados off-chain assim que eles fornecem o stake necessário. Isto expande o pool de gestores de disponibilidade de dados elegíveis, reduzindo a centralização que afeta os comitês de disponibilidade de dados (DAC). Mais importante, essa abordagem depende de incentivos criptoeconômicos para evitar atividade maliciosa, que é consideravelmente mais seguro do que a nomeação de partes de confiança para proteger dados offline no validium. +Em um esquema de disponibilidade de dados vinculados, qualquer um pode ser atribuído para armazenar dados off-chain assim que eles fornecerem o stake necessário. Isto expande o pool de gestores de disponibilidade de dados elegíveis, reduzindo a centralização que afeta os comitês de disponibilidade de dados (DAC). Mais importante, essa abordagem depende de incentivos criptoeconômicos para evitar atividade maliciosa, que é consideravelmente mais seguro do que a nomeação de partes de confiança para proteger dados offline no validium. -[Mais sobre a disponibilidade de dados vinculados em validiums](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). +[Mais sobre disponibilidade de dados por vínculo em validiums](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). ## Volitions e validium {#volitions-and-validium} @@ -107,51 +107,51 @@ Volitions combinam um ZK-rollup e uma cadeia validium e permitem que os usuário Uma exchange descentralizada (DEX) pode preferir usar uma infraestrutura validium dimensionável e particular para negociações de alto valor. Também pode usar uma ZK-rollup para usuários que queiram maiores garantias de segurança e sem necessidade de confiança de um ZK-rollup. -## Validiums e compatibilidade com EVM {#validiums-and-evm-compatibility} +## Validiums e compatibilidade com a EVM {#validiums-and-evm-compatibility} -Como os ZK-rollups, os validiums são geralmente adequados a aplicativos simples, como swaps de tokens e pagamentos. É difícil oferecer suporte à computação geral e à execução do contrato inteligente entre validiums, dada a sobrecarga considerável de provar instruções [EVM](/developers/docs/evm/) em um circuito de prova de conhecimento zero. +Como os ZK-rollups, os validiums são geralmente adequados a aplicativos simples, como swaps de tokens e pagamentos. Suportar computação geral e execução de contratos inteligentes entre validiums é difícil de implementar, dada a sobrecarga considerável de provar instruções da [EVM](/developers/docs/evm/) em um circuito de prova de conhecimento zero. Alguns projetos de validium tentam contornar este problema compilando linguagens compatíveis com EVM (por exemplo, Solidity, Vyper) para criar bytecode personalizado otimizado para uma prova eficiente. Uma desvantagem desta abordagem é que novas VMs amigáveis a conhecimento zero podem não suportar importantes opcodes EVM, e os desenvolvedores devem escrever diretamente na linguagem geral para uma experiência ideal. Isso cria ainda mais problemas: força os desenvolvedores a desenvolver dapps com uma pilha de desenvolvimento inteiramente nova e quebra a compatibilidade com a atual infraestrutura do Ethereum. -Algumas equipes, no entanto, estão tentando otimizar opcodes de EVM existentes para os circuitos de prova ZK. Isto resultará no desenvolvimento de uma Máquina Virtual Ethereum de conhecimento zero (zkEVM), uma VM compatível com EVM que produz provas para verificar a exatidão da execução do programa. Com um zkEVM, as cadeias de validium podem executar contratos inteligentes off-chain e submeter provas de validade para verificar uma computação off-chain (sem ter que executá-lo novamente) no Ethereum. +Algumas equipes, no entanto, estão tentando otimizar opcodes de EVM existentes para os circuitos de prova ZK. Isto resultará no desenvolvimento de uma Máquina Virtual Ethereum de conhecimento zero (zkEVM), uma VM compatível com EVM que produz provas para verificar a exatidão da execução do programa. Com um zkEVM, as redes de validium podem executar contratos inteligentes off-chain e submeter provas de validade para verificar uma computação off-chain (sem ter que executá-lo novamente) no Ethereum. [Mais sobre zkEVMs](https://www.alchemy.com/overviews/zkevm). ## Como os validiums dimensionam o Ethereum? {#scaling-ethereum-with-validiums} -### 1. Armazenamento de dados off-chain {#off-chain-data-storage} +### 1. Armazenamento de dados fora da cadeia {#offchain-data-storage} -Projetos de dimensionamento de camada 2, como optimistic rollups e ZK-rollups, negociam o dimensionamento infinito de protocolos de dimensionamento off-chain puros (por exemplo, [Plasma](/developers/docs/scaling/plasma/)) para fins de segurança, publicando alguns dados de transação na L1. Mas isso significa que as propriedades de dimensionamento dos rollups são limitadas pela largura de banda na Mainnet (Rede principal) do Ethereum (a [fragmentação (sharding) de dados](/roadmap/danksharding/) propõe melhorar a capacidade de armazenamento de dados do Ethereum por este motivo). +Projetos de escalabilidade de camada 2, como optimistic rollups e ZK-rollups, trocam a escalabilidade infinita de protocolos de escalabilidade puramente fora da cadeia (por exemplo, [Plasma](/developers/docs/scaling/plasma/)) por segurança, publicando alguns dados de transação na L1. Mas isso significa que as propriedades de escalabilidade dos rollups são limitadas pela largura de banda de dados na Mainnet do Ethereum (a [fragmentação de dados](/roadmap/danksharding/) propõe melhorar a capacidade de armazenamento de dados do Ethereum por esse motivo). -Os validiums alcançam o dimensionamento mantendo todos os dados de transação off-chain e apenas publicando compromissos do estado (e provas de validade) ao transmitir atualizações de estado para a cadeia principal do Ethereum. A existência de provas de validade, no entanto, dá aos validiums garantias de segurança mais elevadas do que outras soluções de dimensionamento off-chain puras, incluindo Plasma e [sidechains](/developers/docs/scaling/sidechains/). Ao reduzir a quantidade de dados que o Ethereum precisa processar antes de validar transações off-chain, os desenhos de validiums estendem muito a taxa de transferência na rede principal. +Os validiums alcançam escalabilidade mantendo todos os dados de transação off-chain e apenas publicando compromissos do estado (e provas de validade) ao transmitir atualizações de estado para a rede principal do Ethereum. A existência de provas de validade, no entanto, dá aos validiums garantias de segurança mais altas do que outras soluções de escalabilidade puramente fora da cadeia, incluindo Plasma e [sidechains](/developers/docs/scaling/sidechains/). Ao reduzir a quantidade de dados que o Ethereum precisa processar antes de validar transações off-chain, os projetos de validium aumentam muito a taxa de transferência na Mainnet. ### 2. Provas recursivas {#recursive-proofs} Uma prova recursiva é uma prova de validade que verifica a validade de outras provas. Essas "prova de provas" são geradas recursivamente agregando várias provas até que uma última prova que verifica todas as provas anteriores seja criada. As provas recursivas aumentam a velocidade de processamento da blockchain aumentando o número de transações que podem ser verificadas por prova de validade. -Normalmente, cada prova de validade que o operador validium submete para o Ethereum para verificação valida a integridade de um único bloco. Uma única prova recursiva pode ser usada para confirmar a validade de vários blocos validium ao mesmo tempo, e isso é possível porque o circuito de prova pode recursivamente agregar várias provas de bloco em uma prova final. Se o contrato do verificador on-chain aceitar a prova recursiva, todos os blocos subjacentes serão finalizados imediatamente. +Normalmente, cada prova de validade que o operador validium submete para o Ethereum para verificação valida a integridade de um único bloco. Uma única prova recursiva pode ser usada para confirmar a validade de vários blocos validium ao mesmo tempo, e isso é possível porque o circuito de prova pode recursivamente agregar várias provas de bloco em uma prova final. Se o contrato verificador on-chain aceitar a prova recursiva, todos os blocos subjacentes serão finalizados imediatamente. ## Prós e contras do validium {#pros-and-cons-of-validium} -| Prós | Contras | -| ------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Provas de validade reforçam a integridade das transações off-chain e impedem que os operadores finalizem atualizações de estado inválidas. | Produzir provas de validade requer hardware especial, o que representa um risco de centralização. | -| Aumenta a eficiência do capital para os usuários (sem atrasos na retirada dos fundos para o Ethereum) | Suporte limitado para computação geral/contratos inteligentes; linguagens especializadas necessárias para desenvolvimento. | -| Não vulnerável a certos ataques econômicos enfrentados por sistemas baseados em fraudes em aplicativos de elevado valor. | Alto poder computacional necessário para gerar provas ZK; a relação custo-benefício não é vantajosa para aplicativos de baixa taxa de transmissão. | +| Prós | Desvantagens | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Provas de validade reforçam a integridade das transações off-chain e impedem que os operadores finalizem atualizações de estado inválidas. | Produzir provas de validade requer hardware especial, o que representa um risco de centralização. | +| Aumenta a eficiência do capital para os usuários (sem atrasos na retirada dos fundos para o Ethereum) | Suporte limitado para computação geral/contratos inteligentes; linguagens especializadas necessárias para desenvolvimento. | +| Não vulnerável a certos ataques econômicos enfrentados por sistemas baseados em fraudes em aplicativos de elevado valor. | Alto poder computacional necessário para gerar provas ZK; a relação custo-benefício não é vantajosa para aplicativos de baixa taxa de transmissão. | | Reduz as taxas de gás para os usuários ao não publicar calldata para a rede principal do Ethereum. | Tempo de finalidade subjetiva mais lento (de 10 a 30 minutos para gerar uma prova de ZK), porém mais rápido para a finalidade completa porque não há nenhum atraso no tempo de disputas. | -| Adequado para casos de uso específicos, como trading ou jogos de blockchain que priorizam a privacidade de transações e o dimensionamento. | Os usuários podem ser impedidos de sacar fundos já que a geração de provas de propriedade Merkle requer que dados off-chain estejam disponíveis em todos os momentos. | -| A disponibilidade de dados off-chain fornece níveis mais elevados de transferência e aumenta o dimensionamento. | O modelo de segurança se baseia em suposições de confiança e incentivos criptoeconômicos, ao contrário dos ZK-rollups, que dependem apenas de mecanismos de segurança criptográficos. | +| Adequado para casos de uso específicos, como trading ou jogos de blockchain que priorizam a privacidade de transações e o dimensionamento. | Usuários podem ser impedidos de sacar fundos já que a geração de provas de propriedade Merkle requer que dados off-chain estejam disponíveis em todos os momentos. | +| A disponibilidade de dados off-chain fornece níveis mais elevados de transferência e aumenta a escalabilidade. | O modelo de segurança se baseia em suposições de confiança e incentivos criptoeconômicos, ao contrário dos ZK-rollups, que dependem apenas de mecanismos de segurança criptográficos. | -### Uso de validium/volitions {#use-validium-and-volitions} +### Use Validium/Volitions {#use-validium-and-volitions} Vários projetos fornecem implementações de validium e volitions que você pode integrar aos seus dapps: -**StarkWare StarkEx**: _StarkEx é uma solução de dimensionamento de camada 2 (L2) do Ethereum que é baseada em provas de validade. Pode operar em modos de disponibilidade de dados ZK-Rollup ou Validium._ +**StarkWare StarkEx** - _StarkEx é uma solução de escalabilidade de camada 2 (L2) do Ethereum que se baseia em provas de validade. Pode operar em modos de disponibilidade de dados ZK-Rollup ou Validium._ - [Documentação](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) - [Website](https://starkware.co/starkex/) -**Matter Labs zkPorter**: _zkPorter é um protocolo de dimensionamento de camada 2 que aborda a disponibilidade de dados com uma abordagem híbrida que combina os conceitos de zkRollup e sharding. Pode suportar arbitrariamente muitos shards, cada um com sua própria política de disponibilidade de dados._ +**Matter Labs zkPorter**- _O zkPorter é um protocolo de escalabilidade de camada 2 que lida com a disponibilidade de dados com uma abordagem híbrida que combina as ideias de zkRollup e fragmentação. Pode suportar arbitrariamente muitos shards, cada um com sua própria política de disponibilidade de dados._ - [Blog](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) - [Documentação](https://docs.zksync.io/zksync-protocol/rollup/data-availability) @@ -159,7 +159,8 @@ Vários projetos fornecem implementações de validium e volitions que você pod ## Leitura adicional {#further-reading} -- [Validium e a camada 2 juntos – Edição nº 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) -- [ZK-rollups vs Validium](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [Validium e a Camada 2 Dois por Dois — Edição nº 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [ZK-rollups vs. Validium](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) - [Volition e o espectro emergente de disponibilidade de dados](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) -- [Rollups, Validiums, e Volitions: aprenda sobre as soluções de dimensionamento mais recentes do Ethereum](https://medium.com/coinmonks/rollups-vs-validiums-vs-volitions-d76300170f4a) +- [Rollups, Validiums e Volitions: aprenda sobre as soluções de escalabilidade mais populares do Ethereum](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [O Guia Prático para Rollups da Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) diff --git a/public/content/translations/pt-br/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/pt-br/developers/docs/scaling/zk-rollups/index.md index d63c9e7b62d..1d06c87e684 100644 --- a/public/content/translations/pt-br/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/pt-br/developers/docs/scaling/zk-rollups/index.md @@ -1,46 +1,46 @@ --- title: Rollups de conhecimento zero -description: 'Uma introdução aos rollups de zero conhecimento: uma solução de dimensionamento usada pela comunidade Ethereum.' +description: "Uma introdução aos rollups de zero conhecimento: uma solução de dimensionamento usada pela comunidade Ethereum." lang: pt-br --- -Rollups de conhecimento zero (ZK-rollups) são [soluções de dimensionamento](/developers/docs/scaling/) de camada 2 que aumentam a vazão na rede principal do Ethereum movendo off-chain a computação e o armazenamento do estado. ZK-rollups podem processar milhares de transações em um lote e logo publicar apenas alguns dados mínimos resumidos para a rede principal. Este resumo de dados define as alterações que devem ser feitas ao estado do Ethereum e algumas provas criptográficas de que essas alterações estão corretas. +Rollups de conhecimento zero (ZK-rollups) são [soluções de escalabilidade](/developers/docs/scaling/) de camada 2 que aumentam a taxa de transferência na Rede Principal do Ethereum ao mover a computação e o armazenamento de estado para fora da cadeia. ZK-rollups podem processar milhares de transações em um lote e logo publicar apenas alguns dados mínimos resumidos para a rede principal. Este resumo de dados define as alterações que devem ser feitas ao estado do Ethereum e algumas provas criptográficas de que essas alterações estão corretas. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Você deve ler e entender mais sobre em nossa página [Ethereum scaling](/developers/docs/scaling/) e [camada 2](/layer-2). +Você deve ter lido e entendido nossa página sobre [escalabilidade do Ethereum](/developers/docs/scaling/) e [camada 2](/layer-2). ## O que são rollups de conhecimento zero? {#what-are-zk-rollups} -**Rollups de conhecimento zero (ZK-rollups)** agrupam (ou acumulam) transações em lotes que são executados off-chain. A computação off-chain reduz a quantidade de dados que devem ser publicados na blockchain. Operadores de ZK-rollups submetem um resumo das mudanças necessárias para representar todas as transações em um lote, ao invés de enviar cada transação individualmente. Eles também produzem [provas de validade](/glossary/#validity-proof) para provar a exatidão de suas mudanças. +**Rollups de conhecimento zero (ZK-rollups)** agrupam (ou 'enrolam') transações em lotes que são executados fora da cadeia. A computação offchain reduz a quantidade de dados que precisam ser postados na blockchain. Operadores de ZK-rollups submetem um resumo das mudanças necessárias para representar todas as transações em um lote, ao invés de enviar cada transação individualmente. Eles também produzem [provas de validade](/glossary/#validity-proof) para provar a correção de suas alterações. -O estado dos ZK-rollups é mantido por um contrato inteligente implantado na rede Ethereum. Para atualizar este estado, os nós ZK-rollup devem enviar uma prova de validade para verificação. Como mencionado, a prova de validade é uma garantia criptográfica de que a mudança de estado proposta pelo rollup é realmente o resultado da execução de um determinado lote de transações. Isso significa que os ZK-rollups só precisam fornecer provas de validade para finalizar as transações no Ethereum, em vez de publicar todos os dados da transação on-chain, como [optimistic rollups](/developers/docs/scaling/optimistic-rollups/). +O estado dos ZK-rollups é mantido por um contrato inteligente implantado na rede Ethereum. Para atualizar este estado, os nós ZK-rollup devem enviar uma prova de validade para verificação. Como mencionado, a prova de validade é uma garantia criptográfica de que a mudança de estado proposta pelo rollup é realmente o resultado da execução de um determinado lote de transações. Isso significa que os ZK-rollups só precisam fornecer provas de validade para finalizar as transações no Ethereum, em vez de publicar todos os dados da transação na cadeia, como os [optimistic rollups](/developers/docs/scaling/optimistic-rollups/). -Não há atrasos ao mover fundos de um ZK-rollup para o Ethereum porque as transações de saída são executadas assim que o contrato de ZK-rollup verifica a prova de validade. Inversamente, sacar fundos dos optimistic rollups está sujeito a um atraso para permitir que qualquer pessoa desafie a transação de saída com uma [prova de fraude](/glossary/#fraud-proof). +Não há atrasos ao mover fundos de um ZK-rollup para o Ethereum porque as transações de saída são executadas assim que o contrato de ZK-rollup verifica a prova de validade. Por outro lado, a retirada de fundos de optimistic rollups está sujeita a um atraso para permitir que qualquer pessoa conteste a transação de saída com uma [prova de fraude](/glossary/#fraud-proof). -ZK-rollups escrevem transações para o Ethereum como `calldata`. `calldata` é onde os dados incluídos em chamadas externas para funções de contrato inteligente ficam armazenados. As informações em `calldata` são publicadas na blockchain, permitindo que qualquer pessoa reconstrua o estado do rollup de forma independente. ZK-rollups utilizam técnicas de compactação para reduzir os dados de transação – por exemplo, as contas são representadas por um índice ao invés de um endereço, o que economiza 28 bytes de dados. A publicação de dados on-chain é um custo significativo para os rollups, de modo que a compressão de dados pode reduzir as tarifas para os usuários. +Os ZK-rollups gravam as transações no Ethereum como `calldata`. `calldata` é onde os dados incluídos em chamadas externas para as funções de contratos inteligentes são armazenados. As informações em `calldata` são publicadas na blockchain, permitindo que qualquer pessoa reconstrua o estado do rollup de forma independente. ZK-rollups utilizam técnicas de compactação para reduzir os dados de transação – por exemplo, as contas são representadas por um índice ao invés de um endereço, o que economiza 28 bytes de dados. A publicação de dados onchain é um custo significativo para rollups, portanto a compactação de dados pode reduzir as taxas para os usuários. ## Como os ZK-rollups interagem com o Ethereum? {#zk-rollups-and-ethereum} -Uma cadeia ZK-rollup é um protocolo off-chain que opera no topo da blockchain Ethereum e é gerenciado por contratos inteligentes on-chain no Ethereum. ZK-rollups executam transações fora da rede principal, mas periodicamente comprometem lotes de transações off-chain para um contrato de rollup on-chain. Este registro de transação é imutável, muito parecido com a blockchain Ethereum e forma a cadeia ZK-rollup. +Uma cadeia ZK-rollup é um protocolo offchain que opera sobre a blockchain Ethereum e é gerenciado por contratos inteligentes onchain Ethereum. Os ZK-rollups executam transações fora da Mainnet, mas periodicamente comprometem lotes de transações offchain com um contrato de rollup onchain. Este registro de transação é imutável, muito parecido com a blockchain Ethereum e forma a cadeia ZK-rollup. A arquitetura principal do ZK-rollup é composta dos seguintes componentes: -1. **Contratos on-chain**: conforme mencionado, o protocolo ZK-rollup é controlado por contratos inteligentes em execução no Ethereum. Isto inclui o contrato principal que armazena os blocos de rollup, rastreia os depósitos e monitora as atualizações de estado. Outro contrato on-chain (o contrato verificador) verifica as provas de conhecimento zero submetidas pelos produtores de blocos. Assim, o Ethereum serve como camada base ou "camada 1" para o ZK-rollup. +1. **Contratos na cadeia**: como mencionado, o protocolo ZK-rollup é controlado por contratos inteligentes executados no Ethereum. Isto inclui o contrato principal que armazena os blocos de rollup, rastreia os depósitos e monitora as atualizações de estado. Outro contrato onchain (o contrato verificador) verifica provas de conhecimento zero enviadas pelos produtores de blocos. Assim, o Ethereum serve como camada base ou "camada 1" para o ZK-rollup. -2. **Máquina virtual (VM) off-chain**: embora o protocolo ZK-rollup resida no Ethereum, a execução da transação e o armazenamento de estado ocorrem em uma máquina virtual separada, independente da [EVM](/developers/docs/evm/). Essa VM off-chain é o ambiente de execução para transações no ZK-rollup e serve como camada secundária ou "camada 2" para o protocolo ZK-rollup. As provas de validade verificadas na rede principal do Ethereum garantem a exatidão das transições de estado na VM off-chain. +2. **Máquina virtual fora da cadeia (VM)**: embora o protocolo ZK-rollup resida no Ethereum, a execução da transação e o armazenamento de estado acontecem em uma máquina virtual separada, independente da [EVM](/developers/docs/evm/). Esta VM offchain é o ambiente de execução para transações no ZK-rollup e serve como camada secundária ou "layer 2" para o protocolo ZK-rollup. Provas de validade verificadas na Mainnet Ethereum garantem a correção das transições de estado na VM offchain. -ZK-rollups são "soluções de dimensionemento híbrido", protocolos off-chain que operam de forma independente, mas obtêm segurança do Ethereum. Especificamente, a rede Ethereum impõe a validade das atualizações de estado no rollup ZK e garante a disponibilidade de dados por trás de cada atualização do estado do rollup. Como resultado, os ZK-rollups são consideravelmente mais seguros do que as soluções de dimensionamento fora da cadeia puras, tais como [sidechains](/developers/docs/scaling/sidechains/), que são responsáveis por suas propriedades de segurança, ou [validiums](/developers/docs/scaling/validium/), que também verificam transações no Ethereum com provas de validade, mas armazenam dados de transações em outro lugar. +ZK-rollups são "soluções de escalonamento híbrido" — protocolos offchain que operam de forma independente, mas obtêm segurança do Ethereum. Especificamente, a rede Ethereum impõe a validade das atualizações de estado no rollup ZK e garante a disponibilidade de dados por trás de cada atualização do estado do rollup. Como resultado, os ZK-rollups são consideravelmente mais seguros do que as soluções de escalabilidade puramente fora da cadeia, como as [sidechains](/developers/docs/scaling/sidechains/), que são responsáveis por suas próprias propriedades de segurança, ou os [validiums](/developers/docs/scaling/validium/), que também verificam transações no Ethereum com provas de validade, mas armazenam os dados das transações em outro lugar. ZK-rollups dependem do protocolo Ethereum principal para o seguinte: ### Disponibilidade de dados {#data-availability} -Os ZK-rollups publicam dados de estado para cada transação processada off-chain para o Ethereum. Com esses dados, é possível que indivíduos ou empresas reproduzam o estado do rollup e validem a cadeia por conta própria. O Ethereum disponibiliza esses dados para todos os participantes da rede como `calldata`. +Os ZK-rollups publicam dados de estado para cada transação processada offchain no Ethereum. Com esses dados, é possível que indivíduos ou empresas reproduzam o estado do rollup e validem a cadeia por conta própria. O Ethereum disponibiliza esses dados para todos os participantes da rede como `calldata`. -Os ZK-rollups não precisam publicar muitos dados de transação on-chain porque as provas de validade já verificam a autenticidade das transições de estado. No entanto, o armazenamento de dados on-chain ainda é importante porque permite a verificação independente e sem permissão do estado da cadeia L2 que, por sua vez, permite que qualquer pessoa envie lotes de transações, evitando que operadores maliciosos censurem ou congelem a cadeia. +Os ZK-rollups não precisam publicar muitos dados de transações na onchain porque as provas de validade já verificam a autenticidade das transições de estado. No entanto, armazenar dados na cadeia ainda é importante porque permite a verificação independente e sem permissão do estado da cadeia L2, o que, por sua vez, permite que qualquer pessoa envie lotes de transações, impedindo que operadores mal-intencionados censurem ou congelem a cadeia. -A cadeia on-chain é necessária para que os usuários interajam com o rollup. Sem acesso aos dados do estado, os usuários não podem consultar o saldo de sua conta ou iniciar transações (por exemplo, retiradas) que dependem de informações do estado. +O Onchain é necessário para que os usuários interajam com o rollup. Sem acesso aos dados do estado, os usuários não podem consultar o saldo de sua conta ou iniciar transações (por exemplo, retiradas) que dependem de informações do estado. ### Finalidade da transação {#transaction-finality} @@ -58,37 +58,37 @@ Como medida de segurança, os ZK-rollups permitem que os usuários enviem transa Os usuários do ZK-rollup assinam as transações e submetem aos operadores L2 para processamento e inclusão no próximo lote. Em alguns casos, o operador é uma entidade centralizada, chamada de sequenciador, que executa as transações, as agrega em lotes e envia ao L1. O sequenciador neste sistema é a única entidade autorizada a produzir blocos L2 e adicionar transações rollup ao contrato ZK-rollup. -Outros ZK-rollups podem alternar a função do operador usando um conjunto de validadores de [prova de participação](/developers/docs/consensus-mechanisms/pos/). Os operadores potenciais depositam fundos no contrato de rollup, com o tamanho de cada participação influenciando as chances do participante ser selecionado para produzir o próximo lote de rollup. A participação do operador pode ser reduzida se ele agir maliciosamente, o que o incentiva a publicar blocos válidos. +Outros ZK-rollups podem alternar a função de operador usando um conjunto de validadores de [prova de participação](/developers/docs/consensus-mechanisms/pos/). Os operadores potenciais depositam fundos no contrato de rollup, com o tamanho de cada participação influenciando as chances do participante ser selecionado para produzir o próximo lote de rollup. A participação do operador pode ser reduzida se ele agir maliciosamente, o que o incentiva a publicar blocos válidos. -#### Como os ZK-rollups publica dados de transações no Ethereum {#how-zk-rollups-publish-transaction-data-on-ethereum} +#### Como os ZK-rollups publicam dados de transação no Ethereum {#how-zk-rollups-publish-transaction-data-on-ethereum} -Como explicado, os dados de transações são publicados no Ethereum como `calldata`. `calldata` é uma área de dados em um contrato inteligente usado para passar argumentos para uma função e se comporta de forma semelhante à [memória](/developers/docs/smart-contracts/anatomy/#memory). Embora `calldata` não seja armazenado como parte do estado do Ethereum, ele persiste on-chain como parte do [histórico de logs](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) da cadeia Ethereum. `calldata` não afeta o estado do Ethereum, o que a torna uma maneira barata de armazenar dados on-chain. +Conforme explicado, os dados da transação são publicados no Ethereum como `calldata`. `calldata` é uma área de dados em um contrato inteligente usada para passar argumentos para uma função e se comporta de forma semelhante à [memória](/developers/docs/smart-contracts/anatomy/#memory). Embora o `calldata` não seja armazenado como parte do estado do Ethereum, ele persiste na cadeia como parte dos [registros de histórico](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) da cadeia Ethereum. O `calldata` não afeta o estado do Ethereum, tornando-o uma forma barata de armazenar dados na cadeia. -A palavra-chave `calldata` muitas vezes identifica o método do contrato inteligente sendo chamado por uma transação e contém entradas para o método na forma de uma sequência arbitrária de bytes. ZK-rollups usam `calldata` para publicar dados de transação compactados on-chain; o operador de rollup simplesmente adiciona um novo lote chamando a função requerida no contrato de rollup e passa os dados compactados como argumentos de função. Isto ajuda a reduzir os custos para os usuários, uma vez que uma grande parte das taxas de rollup vai para o armazenamento de dados de transações on-chain. +A palavra-chave `calldata` geralmente identifica o método do contrato inteligente que está sendo chamado por uma transação e contém as entradas para o método na forma de uma sequência arbitrária de bytes. Os ZK-rollups usam `calldata` para publicar dados de transação compactados na cadeia; o operador do rollup simplesmente adiciona um novo lote chamando a função necessária no contrato do rollup e passa os dados compactados como argumentos de função. Isso ajuda a reduzir custos para os usuários, já que uma grande parte das taxas de rollup é destinada ao armazenamento de dados de transações onchain. -### Compromissos com o estado {#state-commitments} +### Compromissos de estado {#state-commitments} -O estado do ZK-rollup, que inclui contas e saldos L2, é representado como uma [árvore Merkle](/whitepaper/#merkle-trees). Um hash criptográfico da raiz da árvore Merkle (raiz Merkle) é armazenado no contrato on-chain, permitindo que o protocolo de rollup rastreie alterações no estado do ZK-rollup. +O estado do ZK-rollup, que inclui contas e saldos da L2, é representado como uma [árvore de Merkle](/whitepaper/#merkle-trees). Um hash criptográfico da raiz da árvore Merkle (raiz Merkle) é armazenado no contrato onchain, permitindo que o protocolo rollup rastreie mudanças no estado do ZK-rollup. -O rollup passa para um novo estado após a execução de um novo conjunto de transações. O operador que iniciou a transição de estado é obrigado a calcular uma nova raiz de estado e se submeter ao contrato on-chain. Se a prova de validade associada ao lote for autenticada pelo contrato do verificador, a nova raiz Merkle se tornará a raiz do estado canônico do ZK-rollup. +O rollup passa para um novo estado após a execução de um novo conjunto de transações. O operador que iniciou a transição de estado deve calcular uma nova raiz de estado e enviá-la ao contrato onchain. Se a prova de validade associada ao lote for autenticada pelo contrato do verificador, a nova raiz Merkle se tornará a raiz do estado canônico do ZK-rollup. -Além de calcular as raízes de estado, o operador ZK-rollup também cria uma raiz de lote, a raiz de uma árvore Merkle que compreende todas as transações em um lote. Quando um novo lote é enviado, o contrato de rollup armazena a raiz do lote, permitindo que os usuários comprovem que uma transação (por exemplo, uma solicitação de saque) foi incluída no lote. Os usuários terão que fornecer detalhes da transação, a raiz do lote e uma [prova de Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) mostrando o caminho de inclusão. +Além de calcular as raízes de estado, o operador ZK-rollup também cria uma raiz de lote, a raiz de uma árvore Merkle que compreende todas as transações em um lote. Quando um novo lote é enviado, o contrato de rollup armazena a raiz do lote, permitindo que os usuários comprovem que uma transação (por exemplo, uma solicitação de saque) foi incluída no lote. Os usuários terão que fornecer detalhes da transação, a raiz do lote e uma [prova de Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) mostrando o caminho da inclusão. -### Prova de validação {#validity-proofs} +### Provas de validade {#validity-proofs} -A nova raiz de estado que o operador ZK-rollup submete ao contrato L1 é o resultado de atualizações no estado do rollup. Digamos que Alice envie 10 tokens para Bob, o operador simplesmente diminui o saldo de Alice em 10 e incrementa o saldo de Bob em 10. O operador então calcula o hash dos dados atualizados da conta, reconstrói a árvore Merkle do rollup e envia a nova raiz Merkle para o contrato on-chain. +A nova raiz de estado que o operador ZK-rollup submete ao contrato L1 é o resultado de atualizações no estado do rollup. Digamos que Alice envie 10 tokens para Bob, o operador simplesmente diminui o saldo de Alice em 10 e incrementa o saldo de Bob em 10. O operador então faz o hash dos dados atualizados da conta, reconstrói a árvore Merkle do rollup e envia a nova raiz Merkle para o contrato onchain. Mas o contrato de rollup não aceitará automaticamente o compromisso de estado proposto até que o operador prove que a nova raiz Merkle resultou de atualizações corretas no estado do rollup. O operador ZK-rollup faz isso produzindo uma prova de validade, um compromisso criptográfico sucinto que verifica a exatidão das transações em lote. -As provas de validade permitem que as partes provem a exatidão de uma declaração sem revelar a declaração em si – portanto, também são chamadas de provas de conhecimento zero. ZK-rollups usam provas de validade para confirmar a exatidão das transições de estado off-chain sem ter que executar novamente transações no Ethereum. Essas provas podem vir na forma de um [ZK-SNARK](https://arxiv.org/abs/2202.06877) (Argumento de Conhecimento Suncinto e Não Interativo de Conhecimento Zero) ou [ZK-STARK](https://eprint.iacr.org/2018/046) (Argumento de Conhecimento Transparente e Dimensionável de Conhecimento Zero). +As provas de validade permitem que as partes provem a exatidão de uma declaração sem revelar a declaração em si – portanto, também são chamadas de provas de conhecimento zero. Os ZK-rollups usam provas de validade para confirmar a correção das transições de estado offchain sem precisar reexecutar transações no Ethereum. Essas provas podem vir na forma de um [ZK-SNARK](https://arxiv.org/abs/2202.06877) (Argumento de Conhecimento Sucinto e Não Interativo de Conhecimento Zero) ou [ZK-STARK](https://eprint.iacr.org/2018/046) (Argumento de Conhecimento Transparente e Escalável de Conhecimento Zero). -Ambos SNARKs e STARKs ajudam a atestar a integridade da computação off-chain em ZK-rollups, embora cada tipo de prova tenha características distintas. +Tanto SNARKs quanto STARKs ajudam a atestar a integridade da computação offchain em ZK-rollups, embora cada tipo de prova tenha características distintas. **ZK-SNARKs** Para que o protocolo ZK-SNARK funcione, é necessário criar um Texto de Referência Comum (CRS, pela sigla em inglês): o CRS fornece parâmetros públicos para provar e verificar as provas de validade. A segurança do sistema de provas depende da configuração do CRS; se as informações usadas para criar parâmetros públicos caírem na posse de atores mal-intencionados, eles poderão gerar falsas provas de validade. -Alguns ZK-rollups tentam resolver esse problema usando uma [cerimônia de computação multipartidária (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), envolvendo pessoas de confiança, para gerar parâmetros públicos para o circuito ZK-SNARK. Cada parte contribui com alguma aleatoriedade (chamada de "lixo tóxico") para a construção do CRS, que deve ser destruída imediatamente. +Alguns ZK-rollups tentam resolver esse problema usando uma [cerimônia de computação multipartidária (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), envolvendo indivíduos de confiança, para gerar parâmetros públicos para o circuito ZK-SNARK. Cada parte contribui com alguma aleatoriedade (chamada de "lixo tóxico") para a construção do CRS, que deve ser destruída imediatamente. As configurações confiáveis são usadas porque aumentam a segurança da configuração do CRS. Desde que um participante honesto destrua sua entrada, a segurança do sistema ZK-SNARK é garantida. Ainda assim, esta abordagem requer a confiança dos envolvidos para eliminar suas amostras aleatórias e não prejudicar as garantias de segurança do sistema. @@ -96,11 +96,11 @@ Suposições de confiança à parte, ZK-SNARKs são populares por seus tamanhos **ZK-STARKs** -Como os ZK-SNARKs, os ZK-STARKs provam a validade da computação off-chain sem revelar as entradas. No entanto, os ZK-STARKs são considerados uma melhoria nos ZK-SNARKs devido a seu dimensionamento e transparência. +Assim como os ZK-SNARKs, os ZK-STARKs comprovam a validade da computação offchain sem revelar as entradas. No entanto, os ZK-STARKs são considerados uma melhoria nos ZK-SNARKs devido a seu dimensionamento e transparência. Os ZK-STARKs são "transparentes", pois podem funcionar sem a configuração confiável de um CRS. Em vez disso, os ZK-STARKs dependem da aleatoriedade verificável publicamente para estabelecer parâmetros de geração e verificação de provas. -Os ZK-STARKs também fornecem mais dimensionamento porque o tempo necessário para provar e verificar as provas de validade aumenta _quase linearmente_ em relação à complexidade da computação subjacente. Com ZK-SNARKs, os tempos de prova e verificação dimensionam _linearmente_ em relação ao tamanho da computação subjacente. Isso significa que os ZK-STARKs requerem menos tempo do que os ZK-SNARKs para provar e verificar quando grandes conjuntos de dados estão envolvidos, tornando-os úteis para aplicativos de alto volume. +Os ZK-STARKs também fornecem mais escalabilidade porque o tempo necessário para provar e verificar as provas de validade aumenta _quasilinearmente_ em relação à complexidade da computação subjacente. Com ZK-SNARKs, os tempos de prova e verificação escalam _linearmente_ em relação ao tamanho da computação subjacente. Isso significa que os ZK-STARKs requerem menos tempo do que os ZK-SNARKs para provar e verificar quando grandes conjuntos de dados estão envolvidos, tornando-os úteis para aplicativos de alto volume. Os ZK-STARKs também são seguros contra computadores quânticos, enquanto a Criptografia de Curva Elíptica (ECC, pela sigla em inglês) usada em ZK-SNARKs é amplamente considerada suscetível a ataques de computação quântica. A desvantagem dos ZK-STARKs é que eles produzem tamanhos de prova maiores, que são mais caros de verificar no Ethereum. @@ -136,13 +136,13 @@ O circuito de comprovação do ZK itera sobre todo o lote de transações, verif Após o circuito de prova verificar a correção das atualizações do estado, o operador L2 apresenta a prova de validade computada ao contrato do verificador em L1. O circuito de verificação do contrato verifica a validade das provas e também confere as entradas públicas que fazem parte da prova: -- **Raiz pré-estado**: o antigo estado raiz do ZK-rollup (ou seja, antes das transações em lote serem executadas), refletindo o último estado válido conhecido da cadeia L2. +- **Raiz do pré-estado**: a raiz de estado antiga do ZK-rollup (ou seja, antes que as transações em lote fossem executadas), refletindo o último estado válido conhecido da cadeia L2. -- **Raiz pós-estado**: o novo estado raiz do ZK-rollup (ou seja, após a execução de transações em lote), refletindo o estado mais recente da cadeia L2. A raiz pós-estado é a raiz final derivada após a aplicação de atualizações de estado no circuito de prova. +- **Raiz do pós-estado**: a nova raiz de estado do ZK-rollup (ou seja, após a execução de transações em lote), refletindo o estado mais recente da cadeia L2. A raiz pós-estado é a raiz final derivada após a aplicação de atualizações de estado no circuito de prova. -- **Raiz do lote**: a raiz Merkle do lote, derivada pela _aplicação da raiz de Merkle_ em transações no lote e pelo hash da raiz da árvore. +- **Raiz do lote**: a raiz de Merkle do lote, derivada da _merklização_ das transações no lote e da aplicação de hash na raiz da árvore. -- **Entradas de transação**: dados associados com as transações executadas como parte do lote enviado. +- **Entradas de transação**: dados associados às transações executadas como parte do lote enviado. Se a prova satisfaz o circuito (ou seja, é válida), significa que existe uma sequência de transações válidas que fazem a transição do rollup do estado anterior (impressões digitais criptográficas na raiz do pré-estado) para um novo estado (impressões digitais criptográficas na raiz do pós-estado). Se a raiz pré-estado corresponder à raiz armazenada no contrato de rollup e a prova for válida, o contrato de rollup obterá a raiz pós-estado da prova e atualizará sua árvore de estado para refletir o estado alterado do rollup. @@ -152,7 +152,7 @@ Os usuários entram no ZK-rollup depositando tokens no contrato de rollup implan Se a fila de depósitos pendentes começar a encher, o operador do ZK-rollup receberá as transações de depósito e as enviará ao contrato de rollup. Uma vez que os fundos do usuário estejam no rollup, eles podem começar a fazer transações enviando-as para o operador para processamento. Os usuários podem verificar saldos no rollup fazendo o hash de seus dados de conta, enviando o hash para o contrato de rollup e fornecendo uma prova Merkle para verificar a raiz do estado atual. -A retirada de um ZK-rollup para L1 é simples. O usuário inicia a transação de saída enviando seus ativos no rollup para uma conta específica para gravação. Se o operador incluir a transação no próximo lote, o usuário poderá enviar uma solicitação de retirada para o contrato on-chain. Este pedido de retirada incluirá o seguinte: +A retirada de um ZK-rollup para L1 é simples. O usuário inicia a transação de saída enviando seus ativos no rollup para uma conta específica para gravação. Se o operador incluir a transação no próximo lote, o usuário poderá enviar uma solicitação de retirada para o contrato onchain. Este pedido de retirada incluirá o seguinte: - Prova de Merkle provando a inclusão da transação do usuário na conta burn em um lote de transação @@ -164,11 +164,11 @@ A retirada de um ZK-rollup para L1 é simples. O usuário inicia a transação d O contrato de rollup faz o hash dos dados da transação, verifica se a raiz do lote existe e usa a prova de Merkle para verificar se o hash da transação faz parte da raiz do lote. Em seguida, o contrato executa a transação de saída e envia os fundos para o endereço escolhido pelo usuário na L1. -## Compatibilidade de ZK-rollups e EVM {#zk-rollups-and-evm-compatibility} +## ZK-rollups e compatibilidade com a EVM {#zk-rollups-and-evm-compatibility} -Ao contrário dos optimistic rollups, os ZK-rollups não são prontamente compatíveis com a [Máquina Virtual Ethereum (EVM)](/developers/docs/evm/). Provar o cálculo EVM de propósito geral em circuitos é mais difícil e intensivo em recursos do que provar cálculos simples (como a transferência simbólica descrita anteriormente). +Diferentemente dos optimistic rollups, os ZK-rollups não são diretamente compatíveis com a [Máquina Virtual Ethereum (EVM)](/developers/docs/evm/). Provar o cálculo EVM de propósito geral em circuitos é mais difícil e intensivo em recursos do que provar cálculos simples (como a transferência simbólica descrita anteriormente). -No entanto, [avanços na tecnologia de conhecimento zero](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) estão despertando um interesse renovado em envolver a computação EVM em provas de conhecimento zero. Esses esforços são voltados para a criação de uma implementação EVM de conhecimento zero (zkEVM) que pode verificar com eficiência a exatidão da execução do programa. Um zkEVM recria opcodes EVM existentes para prova/verificação em circuitos, permitindo a execução de contratos inteligentes. +No entanto, os [avanços na tecnologia de conhecimento zero](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) estão despertando um interesse renovado em encapsular a computação da EVM em provas de conhecimento zero. Esses esforços são voltados para a criação de uma implementação EVM de conhecimento zero (zkEVM) que pode verificar com eficiência a exatidão da execução do programa. Um zkEVM recria opcodes EVM existentes para prova/verificação em circuitos, permitindo a execução de contratos inteligentes. Como a EVM, um zkEVM transita entre os estados depois que a computação é executada em algumas entradas. A diferença é que o zkEVM também cria provas de conhecimento zero para verificar a exatidão de cada etapa da execução do programa. As provas de validade podem verificar a exatidão das operações que afetam o estado da VM (memória, pilha, armazenamento) e a própria computação (ou seja, a operação chamou os opcodes corretos e os executou corretamente?). @@ -178,21 +178,21 @@ A introdução de ZK-rollups compatíveis é esperado para ajudar os desenvolved O valor que os usuários pagam pelas transações em ZK-rollups depende da taxa de gás, assim como na rede principal do Ethereum. No entanto, as taxas de gás funcionam de maneira diferente na L2 e são influenciadas pelos seguintes custos: -1. **Gravação de estado**: há um custo fixo para gravar no estado do Ethereum (ou seja, enviar uma transação na blockchain Ethereum). Os ZK-rollups reduzem esse custo agrupando as transações e distribuindo os custos fixos entre vários usuários. +1. **Gravação de estado**: há um custo fixo para gravar no estado do Ethereum (ou seja, enviar uma transação na blockchain do Ethereum). Os ZK-rollups reduzem esse custo agrupando as transações e distribuindo os custos fixos entre vários usuários. -2. **Publicação de dados**: os ZK-rollups publicam dados de estado para cada transação no Ethereum como `calldata`. Os custos de `calldata` são atualmente regidos por [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), que estipula um custo de 16 gás para bytes diferentes de zero e 4 gás para zero bytes de `calldata`, respectivamente. O custo pago em cada transação é influenciado pela quantidade de `calldata` que precisa ser publicada na cadeia para isso. +2. **Publicação de dados**: os ZK-rollups publicam dados de estado de cada transação no Ethereum como `calldata`. Os custos de `calldata` são atualmente regidos pelo [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), que estipula um custo de 16 de gás para bytes diferentes de zero e 4 de gás para bytes zero de `calldata`, respectivamente. O custo pago em cada transação é influenciado pela quantidade de `calldata` que precisa ser postada na cadeia para ela. -3. **Taxas do operador L2**: este é o valor pago ao operador de rollup como compensação pelos custos computacionais incorridos no processamento de transações, muito parecido com ["taxas de prioridade (gorjetas)" de transação](/developers/docs/gas/#how-are-gas-fees-calculated) na rede principal do Ethereum. +3. **Taxas do operador L2**: este é o valor pago ao operador do rollup como compensação pelos custos computacionais incorridos no processamento de transações, muito semelhante às ["taxas de prioridade (gorjetas)" de transação](/developers/docs/gas/#how-are-gas-fees-calculated) na Rede Principal do Ethereum. -4. **Geração e verificação de provas**: os operadores de ZK-rollup devem produzir provas de validade para lotes de transações, que consomem muitos recursos. A verificação de provas de conhecimento zero na rede principal também custa gás (cerca de 500.000 gás). +4. **Geração e verificação de provas**: os operadores de ZK-rollup devem produzir provas de validade para lotes de transações, o que consome muitos recursos. A verificação de provas de conhecimento zero na rede principal também custa gás (cerca de 500.000 gás). -Além de transações em lote, os ZK-rollups reduzem as taxas para os usuários compactando os dados da transação. Veja um [panorama geral e em tempo real](https://l2fees.info/) de quanto custa usar ZK-rollups Ethereum. +Além de transações em lote, os ZK-rollups reduzem as taxas para os usuários compactando os dados da transação. Você pode [ver uma visão geral em tempo real](https://l2fees.info/) de quanto custa usar os ZK-rollups da Ethereum. ## De que maneira os ZK-rollups ajudam no dimensionamento do Ethereum? {#scaling-ethereum-with-zk-rollups} -### Compactação de dados da transação {#transaction-data-compression} +### Compressão de dados de transação {#transaction-data-compression} -Os ZK-rollups estendem a taxa de transferência na camada base do Ethereum, movendo a computação off-chain, mas o verdadeiro impulso para o dimensionamento vem da compactação dos dados da transação. O [tamanho do bloco](/developers/docs/blocks/#block-size) do Ethereum limita os dados que cada bloco pode conter e, por extensão, o número de transações processadas por bloco. Ao compactar os dados relacionados às transações, os ZK-rollups aumentam significativamente o número de transações processadas por bloco. +Os ZK-rollups estendem a taxa de transferência na camada base do Ethereum ao levar a computação para offchain, mas o verdadeiro impulso para o dimensionamento vem da compactação dos dados de transação. O [tamanho do bloco](/developers/docs/blocks/#block-size) do Ethereum limita a quantidade de dados que cada bloco pode conter e, por extensão, o número de transações processadas por bloco. Ao compactar os dados relacionados às transações, os ZK-rollups aumentam significativamente o número de transações processadas por bloco. Os ZK-rollups podem compactar melhor os dados das transações do que osoptimistic rollups, uma vez que não têm que publicar todos os dados necessários para validar cada transação. Eles só têm que publicar os dados mínimos necessários para reconstruir o estado mais recente das contas e saldos no rollup. @@ -204,19 +204,19 @@ Atualmente, as provas de validade são geradas bloco a bloco e submetidas ao con As provas recursivas, no entanto, permitem finalizar vários blocos com uma prova de validade. Isto porque o circuito de prova agrega recursivamente várias provas de blocos até que uma prova final seja criada. O operador L2 envia esta prova recursiva, e se o contrato aceitar, todos os blocos relevantes serão finalizados instantaneamente. Com provas recursivas, aumenta o número de transações de ZK-rollup que podem ser finalizadas no Ethereum em intervalos. -### Prós e contras de ZK-rollups {#zk-rollups-pros-and-cons} +### Prós e contras dos ZK-rollups {#zk-rollups-pros-and-cons} -| Prós | Contras | -| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| As provas de validade garantem a exatidão das transações off-chain e impedem que os operadores executem transições de estado inválido. | O custo associado à computação e verificação de provas de validade é substancial e pode aumentar as taxas para usuários de rollup. | -| Oferece uma conclusão mais rápida da transação, como as atualizações de estado são aprovadas assim que as provas de validade são verificadas em L1. | Construir ZK-rollups compatíveis com EVM é difícil devido à complexidade da tecnologia de conhecimento zero. | -| Baseia-se em mecanismos criptográficos não confiáveis para segurança, não na honestidade de atores incentivados como acontece com os [optimistic rollups](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | Produzir provas de validade requer hardware especializado, o que pode encorajar o controle centralizado da cadeia por algumas partes. | -| Armazena os dados necessários para recuperar o estado off-chain na L1, o que garante segurança, resistência à censura e descentralização. | Operadores centralizados (sequenciadores) podem influenciar a ordem das transações. | -| Os usuários se beneficiam de uma maior eficiência de capital e podem retirar fundos da L2 sem atrasos. | Os requisitos de hardware podem reduzir o número de participantes que podem forçar a cadeia a progredir, aumentando o risco de operadores maliciosos congelarem o estado do rollup e censurarem os usuários. | -| Não depende de suposições de vivacidade, e os usuários não têm que validar a cadeia para proteger seus fundos. | Alguns sistemas de prova (por exemplo, ZK-SNARK) requerem uma configuração confiável, o que, se mal conduzida, pode comprometer o modelo de segurança de um ZK-rollup. | -| Uma melhor compactação de dados pode ajudar a reduzir os custos de publicação de `calldata` no Ethereum e minimizar as taxas de rollup para os usuários. | | +| Prós | Contras | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Provas de validade garantem a correção de transações off-chain e impedem que operadores executem transições de estado inválidas. | O custo associado à computação e verificação de provas de validade é substancial e pode aumentar as taxas para usuários de rollup. | +| Oferece uma conclusão mais rápida da transação, como as atualizações de estado são aprovadas assim que as provas de validade são verificadas em L1. | Construir ZK-rollups compatíveis com EVM é difícil devido à complexidade da tecnologia de conhecimento zero. | +| Baseia-se em mecanismos criptográficos que não exigem confiança para segurança, não na honestidade de atores incentivados como nos [optimistic rollups](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | Produzir provas de validade requer hardware especializado, o que pode encorajar o controle centralizado da cadeia por algumas partes. | +| Armazena dados necessários para recuperar o estado off-chain em L1, o que garante segurança, resistência à censura e descentralização. | Operadores centralizados (sequenciadores) podem influenciar a ordem das transações. | +| Os usuários se beneficiam de uma maior eficiência de capital e podem retirar fundos da L2 sem atrasos. | Os requisitos de hardware podem reduzir o número de participantes que podem forçar a cadeia a progredir, aumentando o risco de operadores maliciosos congelarem o estado do rollup e censurarem os usuários. | +| Não depende de suposições de vivacidade, e os usuários não têm que validar a cadeia para proteger seus fundos. | Alguns sistemas de prova (por exemplo, ZK-SNARK) requerem uma configuração confiável, o que, se mal conduzida, pode comprometer o modelo de segurança de um ZK-rollup. | +| Uma melhor compressão de dados pode ajudar a reduzir os custos de publicação de `calldata` no Ethereum e minimizar as taxas de rollup para os usuários. | | -### Uma explicação visual de ZK-rollups {#zk-video} +### Uma explicação visual dos ZK-rollups {#zk-video} Assista ao Finematics explicando ZK-rollups: @@ -226,28 +226,32 @@ Assista ao Finematics explicando ZK-rollups: Os projetos que trabalham em zkEVMs incluem: -- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM é um projeto financiado pela Ethereum Foundation para desenvolver um ZK-rollup compatível com EVM e um mecanismo para gerar provas de validação para blocos Ethereum._ +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _O zkEVM é um projeto financiado pela Ethereum Foundation para desenvolver um ZK-rollup compatível com a EVM e um mecanismo para gerar provas de validade para os blocos do Ethereum._ -- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** — _é um ZK-Rollup descentralizado na rede principal do Ethereum que trabalha em uma Máquina Virtual Ethereum de conhecimento zero (zkEVM) e executa transações do Ethereum de maneira transparente, incluindo contratos inteligentes com validações de prova de conhecimento._ +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _é um ZK-Rollup descentralizado na rede principal do Ethereum que funciona em uma Máquina Virtual Ethereum de conhecimento zero (zkEVM) que executa transações do Ethereum de forma transparente, incluindo contratos inteligentes com validações de prova de conhecimento zero._ -- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll é uma empresa impulsionada pela tecnologia que trabalha no desenvolvimento de uma solução nativa zkEVM de camada 2 para Ethereum._ +- **[Scroll](https://scroll.io/blog/zkEVM)** - _A Scroll é uma empresa de tecnologia que trabalha na construção de uma solução nativa zkEVM de Camada 2 para o Ethereum._ -- **[Taiko](https://taiko.xyz)** - _Taiko é um ZK-rollup descentralizado, equivalente ao Ethereum (um [ZK-EVM do Tipo 1](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ +- **[Taiko](https://taiko.xyz)** - _Taiko é um ZK-rollup descentralizado e equivalente ao Ethereum (um [ZK-EVM Tipo 1](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ -- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era é um ZK Rollup compatível com EVM criado pela Matter Labs, com tecnologia do zkEVM da própria empresa._ +- **[ZKsync](https://docs.zksync.io/)** - _O ZKsync Era é um ZK-Rollup compatível com EVM construído pela Matter Labs, alimentado por seu próprio zkEVM._ -- **[Starknet](https://starkware.co/starknet/)** - _StarkNet é uma solução de dimensionamento de camada 2 compatível com EVM desenvolvida pela StarkWare._ +- **[Starknet](https://starkware.co/starknet/)** - _StarkNet é uma solução de escalabilidade de camada 2 compatível com EVM, construída pela StarkWare._ -- **[Morph](https://www.morphl2.io/)** - _Morph é uma solução de dimensionamento de rollup híbrida que utiliza zk-proof para resolver o problema do desafio de estado da Camada 2._ +- **[Morph](https://www.morphl2.io/)** - _Morph é uma solução de escalabilidade de rollup híbrido que utiliza prova de conhecimento zero para resolver o problema de desafio de estado da Camada 2._ -## Leitura adicional sobre leitura de ZK-rollups {#further-reading-on-zk-rollups} +- **[Linea](https://linea.build)** - _O Linea é uma Camada 2 zkEVM equivalente ao Ethereum, desenvolvida pela Consensys e totalmente alinhada com o ecossistema Ethereum._ -- [O que são os rollups de conhecimento zero?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) +## Leitura adicional sobre ZK-rollups {#further-reading-on-zk-rollups} + +- [O que são Rollups de Conhecimento Zero?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) - [O que são rollups de conhecimento zero?](https://alchemy.com/blog/zero-knowledge-rollups) -- [STARKs vs SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [O guia prático para os rollups do Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [STARKs vs. SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) - [O que é um zkEVM?](https://www.alchemy.com/overviews/zkevm) -- [Tipos de ZK-EVM: equivalente a Ethereum, equivalente a EVM, Tipo 1, Tipo 4 e outros termos do momento](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) -- [Introdução a zkEVMs](https://hackmd.io/@yezhang/S1_KMMbGt) -- [Recursos incríveis para zkEVM](https://github.com/LuozhuZhang/awesome-zkevm) -- [ZK-SNARKS nos bastidores](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) -- [SNARKs: como são possíveis?](https://vitalik.eth.limo/general/2021/01/26/snarks.html) +- [Tipos de ZK-EVM: equivalente ao Ethereum, equivalente à EVM, Tipo 1, Tipo 4 e outros jargões enigmáticos](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [Introdução ao zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt) +- [O que são ZK-EVM L2s?](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) +- [Recursos incríveis sobre zkEVM](https://github.com/LuozhuZhang/awesome-zkevm) +- [ZK-SNARKS por baixo dos panos](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) +- [Como os SNARKs são possíveis?](https://vitalik.eth.limo/general/2021/01/26/snarks.html) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/anatomy/index.md index d62a36f7c01..17c03c8ea37 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/anatomy/index.md @@ -1,6 +1,6 @@ --- title: Anatomia dos contratos inteligentes -description: Uma análise aprofundada na anatomia de um contrato inteligente - funções, dados e variáveis. +description: "Uma análise aprofundada na anatomia de um contrato inteligente - funções, dados e variáveis." lang: pt-br --- @@ -8,20 +8,20 @@ Um contrato inteligente (smart contract) é um programa executado em um endereç ## 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. +Certifique-se de que leu sobre [contratos inteligentes](/developers/docs/smart-contracts/) primeiro. 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. +Quaisquer dados de contrato devem ser atribuídos a um local: `storage` ou `memory`. É 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 +// Exemplo de Solidity contract SimpleStorage { - uint storedData; // State variable + uint storedData; // Variável de estado // ... } ``` @@ -31,7 +31,7 @@ contract SimpleStorage { 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. +Se você já programou linguagens orientadas a objetos, provavelmente você estará familiarizado com a maioria dos tipos. No entanto, `address` (endereço) deve ser novidade para você se você é novo no desenvolvimento para 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. @@ -42,31 +42,32 @@ Outros tipos incluem: - 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 +- literais racionais e inteiros +- literais de string +- literais hexadecimais +- enums 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) +- [Veja os tipos Vyper](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types) +- [Veja os tipos Solidity](https://docs.soliditylang.org/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). +Saiba mais sobre como a EVM armazena dados (Storage, Memory e a Pilha) nos [documentos do Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#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. +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 | +| **Propriedade** | **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} @@ -75,15 +76,15 @@ Da forma mais simplista, funções podem obter informação ou um conjunto de in 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 +- `internal` – estas não criam uma chamada de EVM + - As funções e variáveis de estado internas só podem ser acessadas internamente (ou seja, de dentro do contrato atual ou dos contratos que derivam dele) +- `external` – estas criam uma chamada de 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` +Elas também podem ser `public` ou `private` -- `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 +- As funções `public` podem ser chamadas internamente de dentro do contrato ou externamente por meio de mensagens +- As funções `private` são visíveis apenas para o contrato em que são definidas e não em contratos derivados Tanto funções quanto variáveis de estado podem ser tornadas públicas ou privadas @@ -96,11 +97,11 @@ function update_name(string value) public { } ``` -- 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 +- O parâmetro `value` do tipo `string` é passado para a função: `update_name` +- Ela é declarada como `public`, o que significa que qualquer pessoa pode acessá-la +- Ela não é declarada como `view`, portanto, pode modificar o estado do contrato -### Ver funções {#view-functions} +### Funções de visualização {#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. @@ -123,26 +124,26 @@ def readName() -> string: 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`. +2. [Emitindo eventos](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events). +3. [Criando outros contratos](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts). +4. Usando `selfdestruct`. 5. Enviando ether por chamadas. -6. Chamar qualquer função não marcada como`view`ou`puro`. +6. Chamando qualquer função não marcada como `view` ou `pure`. 7. Usando chamadas de baixo nível. 8. Usando montagem em linha que contém certos códigos. -### Funções de "construtor" {#constructor-functions} +### 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. +As funções `constructor` são executadas apenas uma vez quando o contrato é implantado pela primeira vez. Assim como o `constructor` em muitas linguagens de programação baseadas em classes, essas funções geralmente inicializam variáveis de estado para seus valores especificados. ```solidity -// Exemplo Solidity +// Exemplo de Solidity // Inicializa os dados do contrato, definindo o `owner` -// como endereço do criador do contrato. +// para o 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. + // como o endereço do remetente e o valor de 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; } @@ -158,16 +159,16 @@ def __init__(_beneficiary: endereço, _bidding_time: uint256): self.auctionEnd = self.auctionStart + _bidding_time ``` -### Funções integradas {#built-in-functions} +### Funções incorporadas {#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 +- `send(address)` – Vyper Estes permitem contratos para enviar ETH para outras contas. -## Como escrever funções {#writing-functions} +## Escrevendo funções {#writing-functions} Sua função precisa: @@ -180,28 +181,28 @@ Sua função precisa: pragma solidity >=0.4.0 <=0.6.0; contract ExampleDapp { - string dapp_name; // state variable + string dapp_name; // variável de estado - // Called when the contract is deployed and initializes the value + // Chamado quando o contrato é implantado e inicializa o valor constructor() public { - dapp_name = "My Example dapp"; + dapp_name = "Meu dapp de Exemplo"; } - // Get Function + // Função Get function read_name() public view returns(string) { return dapp_name; } - // Set Function + // Função Set 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`. +Um contrato completo pode parecer algo assim. Aqui, a função `constructor` fornece um valor inicial para a variável `dapp_name`. -## Eventos e registros {#events-and-logs} +## Eventos e logs {#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. @@ -209,29 +210,29 @@ Os eventos permitem que seu contrato inteligente se comunique com seu front-end 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} +### Olá, mundo {#hello-world} ```solidity -// Especifica a versão do Solidity usando a versão semântica. +// Especifica a versão do Solidity, usando versionamento semântico. // 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). +// Um contrato é um conjunto 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 + // Declara uma variável de estado `message` do tipo `string`. + // Variáveis de estado são variáveis cujos valores são armazenados permanentemente no armazenamento do contrato. + // A palavra-chave `public` torna as variáveis acessíveis de 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; + string public message; - // 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 + // Semelhante a muitas linguagens de programação orientadas a objetos baseadas em classes, um construtor é + // uma função especial que é executada apenas na criação do contrato. + // Construtores são usados para inicializar os dados do contrato. + // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors constructor(string memory initMessage) public { // Aceita um argumento de string `initMessage` e define o valor // na variável de armazenamento `message` do contrato). @@ -252,134 +253,136 @@ contract HelloWorld { 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). + // Um `address` é comparável a um endereço de e-mail - ele é usado para identificar uma conta na Ethereum. + // Endereços podem representar um contrato inteligente ou contas externas (de 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). + // Este `mapping` atribui um inteiro sem sinal (o saldo do token) a um endereço (o detentor 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 + // Eventos permitem o registro de atividades na blockchain. + // Clientes Ethereum podem ouvir eventos para reagir a mudanças de estado do contrato. + // Saiba mais: 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. + // Inicializa os dados do contrato, definindo o `owner` + // para o endereço do criador do contrato. constructor() public { - // Todos os contratos inteligentes dependem de transações externas para acionar suas funções. + // 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. + // como o endereço do remetente e o valor de 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 + // `require` é uma estrutura de controle usada para impor certas condições. + // Se uma instrução `require` for avaliada como `false`, uma exceção é acionada, + // que reverte todas as alterações feitas no estado durante a chamada atual. + // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#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. ); + require(msg.sender == owner, "Você não é o proprietário."); - // Reforça uma quantidade máxima de tokens + // Impõe uma quantidade máxima de tokens require(amount < 1e60, "Emissão máxima excedida"); // Aumenta o saldo de `receiver` em `amount` - saldos[receiver] += amount; + balances[receiver] += amount; } - // Envia uma quantidade de tokens existentes de qualquer chamada para um endereço. + // Envia uma quantidade de tokens existentes de qualquer chamador 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."); + require(amount <= balances[msg.sender], "Saldo insuficiente."); - // Ajusta os saldos do token dos dois endereços - balances[msg.sender] -= quantidade; - balances[receiver] += quantidade; + // Ajusta os saldos de token dos dois endereços + balances[msg.sender] -= amount; + balances[receiver] += amount; - // Emite um evendo definido anteriormente - emite Transfer(msg.sender, receiver, amount); + // Emite o evento definido anteriormente + emit Transfer(msg.sender, receiver, amount); } } ``` -### Ativo digital único {#unique-digital-asset} +### Ativo digital exclusivo {#unique-digital-asset} ```solidity -pragma solidity ^0.5.10. -// Neste caso, uma série de contratos auxiliares de OpenZeppelin. +pragma solidity ^0.5.10; + +// Importa símbolos de outros arquivos para o contrato atual. +// Neste caso, uma série de contratos de ajuda da 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/token/ERC721/IERC721Receiver.sol"; 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`. +// Neste caso, `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; + // Usa a biblioteca SafeMath do OpenZeppelin para realizar operações aritméticas com segurança. + // Saiba mais: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + using SafeMath for 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 + // Variáveis de estado constantes em Solidity são semelhantes a outras linguagens + // mas você deve atribuir a partir de uma expressão que é constante em tempo de compilação. + // Saiba mais: 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 + // Tipos de estrutura permitem que você defina seu próprio tipo + // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs struct Pizza { string name; uint256 dna; } - // Creates an empty array of Pizza structs + // Cria uma matriz vazia de estruturas Pizza Pizza[] public pizzas; - // Mapping from pizza ID to its owner's address + // Mapeamento do ID da pizza para o endereço do seu proprietário mapping(uint256 => address) public pizzaToOwner; - // Mapping from owner's address to number of owned token + // Mapeamento do endereço do proprietário para o número de tokens possuídos mapping(address => uint256) public ownerPizzaCount; - // Mapping from token ID to approved address + // Mapeamento do ID do token para o endereço aprovado mapping(uint256 => address) pizzaApprovals; - // You can nest mappings, this example maps owner to operator approvals + // Você pode aninhar mapeamentos, este exemplo mapeia o proprietário para as aprovações do operador mapping(address => mapping(address => bool)) private operatorApprovals; - // Internal function to create a random Pizza from string (name) and DNA + // Função interna para criar uma Pizza aleatória a partir de uma string (nome) e 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 + // A palavra-chave `internal` significa que esta função só é visível + // dentro deste contrato e dos contratos que derivam deste contrato + // Saiba mais: 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` é um modificador de função que verifica se a pizza já existe + // Saiba mais: 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 + // Adiciona a Pizza à matriz de Pizzas e obtém o 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 + // Verifica se o proprietário da Pizza é o mesmo que o usuário atual + // Saiba mais: 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. + // note que address(0) é o endereço zero, + // indicando que pizza[id] ainda não foi alocada para um usuário em particular. assert(pizzaToOwner[id] == address(0)); - // Maps the Pizza to the owner + // Mapeia a Pizza para o proprietário pizzaToOwner[id] = msg.sender; ownerPizzaCount[msg.sender] = SafeMath.add( ownerPizzaCount[msg.sender], @@ -387,38 +390,38 @@ contract CryptoPizza is IERC721, ERC165 { ); } - // Creates a random Pizza from string (name) + // Cria uma Pizza aleatória a partir de uma string (nome) 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) + // Gera DNA aleatório a partir de uma string (nome) e do endereço do proprietário (criador) 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 + // As funções marcadas como `pure` prometem não ler ou modificar o estado + // Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions pure returns (uint256) { - // Generates random uint from string (name) + address (owner) + // Gera um uint aleatório a partir de uma string (nome) + endereço (proprietário) uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + uint256(_owner); rand = rand % dnaModulus; return rand; } - // Returns array of Pizzas found by owner + // Retorna uma matriz de Pizzas encontradas pelo proprietário 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 + // Funções marcadas como `view` prometem não modificar o estado + // Saiba mais: 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 + // Usa o local de armazenamento `memory` para armazenar valores apenas para o + // ciclo de vida desta chamada de função. + // Saiba mais: 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++) { @@ -430,28 +433,28 @@ contract CryptoPizza is IERC721, ERC165 { return result; } - // Transfers Pizza and ownership to other address + // Transfere a Pizza e a propriedade para outro endereço 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."); + require(_from != address(0) && _to != address(0), "Endereço inválido."); + require(_exists(_pizzaId), "A pizza não existe."); + require(_from != _to, "Não é possível transferir para o mesmo endereço."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "O endereço não está aprovado."); 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 + // Emite evento definido no contrato IERC721 importado 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 + * Transfere com segurança a propriedade de um determinado ID de token para outro endereço + * Se o endereço de destino for um contrato, ele deverá implementar `onERC721Received`, + * que é chamado após uma transferência segura e retorna o valor mágico * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * otherwise, the transfer is reverted. + * caso contrário, a transferência será revertida. */ function safeTransferFrom(address from, address to, uint256 pizzaId) public @@ -461,11 +464,11 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * 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 + * Transfere com segurança a propriedade de um determinado ID de token para outro endereço + * Se o endereço de destino for um contrato, ele deverá implementar `onERC721Received`, + * que é chamado após uma transferência segura e retorna o valor mágico * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * otherwise, the transfer is reverted. + * caso contrário, a transferência será revertida. */ function safeTransferFrom( address from, @@ -474,12 +477,12 @@ contract CryptoPizza is IERC721, ERC165 { bytes memory _data ) public { this.transferFrom(from, to, pizzaId); - require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received."); + require(_checkOnERC721Received(from, to, pizzaId, _data), "Deve implementar onERC721Received."); } /** - * Internal function to invoke `onERC721Received` on a target address - * The call is not executed if the target address is not a contract + * Função interna para invocar `onERC721Received` em um endereço de destino + * A chamada não é executada se o endereço de destino não for um contrato */ function _checkOnERC721Received( address from, @@ -500,13 +503,13 @@ contract CryptoPizza is IERC721, ERC165 { 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 + // Queima uma Pizza - destrói o Token completamente + // O modificador de função `external` significa que esta função é + // parte da interface do contrato e outros contratos podem chamá-la 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."); + require(msg.sender != address(0), "Endereço inválido."); + require(_exists(_pizzaId), "A pizza não existe."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "O endereço não está aprovado."); ownerPizzaCount[msg.sender] = SafeMath.sub( ownerPizzaCount[msg.sender], @@ -515,58 +518,58 @@ contract CryptoPizza is IERC721, ERC165 { pizzaToOwner[_pizzaId] = address(0); } - // Returns count of Pizzas by address + // Retorna a contagem de Pizzas por endereço function balanceOf(address _owner) public view returns (uint256 _balance) { return ownerPizzaCount[_owner]; } - // Returns owner of the Pizza found by id + // Retorna o proprietário da Pizza encontrado por id function ownerOf(uint256 _pizzaId) public view returns (address _owner) { address owner = pizzaToOwner[_pizzaId]; - require(owner != address(0), "Invalid Pizza ID."); + require(owner != address(0), "ID de pizza inválido."); return owner; } - // Approves other address to transfer ownership of Pizza + // Aprova outro endereço para transferir a propriedade da Pizza function approve(address _to, uint256 _pizzaId) public { - require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); + require(msg.sender == pizzaToOwner[_pizzaId], "Deve ser o proprietário da Pizza."); pizzaApprovals[_pizzaId] = _to; emit Approval(msg.sender, _to, _pizzaId); } - // Returns approved address for specific Pizza + // Retorna o endereço aprovado para uma Pizza específica function getApproved(uint256 _pizzaId) public view returns (address operator) { - require(_exists(_pizzaId), "Pizza does not exist."); + require(_exists(_pizzaId), "A pizza não existe."); 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 + * Função privada para limpar a aprovação atual de um determinado ID de token + * Reverte se o endereço fornecido não for de fato o proprietário do token */ function _clearApproval(address owner, uint256 _pizzaId) private { - require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); - require(_exists(_pizzaId), "Pizza does not exist."); + require(pizzaToOwner[_pizzaId] == owner, "Deve ser o proprietário da pizza."); + require(_exists(_pizzaId), "A pizza não existe."); 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 + * Define ou cancela a aprovação de um determinado operador + * Um operador tem permissão para transferir todos os tokens do remetente em seu nome */ function setApprovalForAll(address to, bool approved) public { - require(to != msg.sender, "Cannot approve own address"); + require(to != msg.sender, "Não é possível aprovar o próprio endereço"); operatorApprovals[msg.sender][to] = approved; emit ApprovalForAll(msg.sender, to, approved); } - // Tells whether an operator is approved by a given owner + // Informa se um operador é aprovado por um determinado proprietário function isApprovedForAll(address owner, address operator) public view @@ -575,20 +578,20 @@ contract CryptoPizza is IERC721, ERC165 { return operatorApprovals[owner][operator]; } - // Takes ownership of Pizza - only for approved users + // Assume a propriedade da Pizza - apenas para usuários aprovados function takeOwnership(uint256 _pizzaId) public { - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "O endereço não está aprovado."); address owner = this.ownerOf(_pizzaId); this.transferFrom(owner, msg.sender, _pizzaId); } - // Checks if Pizza exists + // Verifica se a Pizza existe 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 + // Verifica se o endereço é o proprietário ou se está aprovado para transferir a Pizza function _isApprovedOrOwner(address spender, uint256 pizzaId) internal view @@ -603,7 +606,7 @@ contract CryptoPizza is IERC721, ERC165 { this.isApprovedForAll(owner, spender)); } - // Check if Pizza is unique and doesn't exist yet + // Verifica se a Pizza é única e ainda não existe modifier isUnique(string memory _name, uint256 _dna) { bool result = true; for (uint256 i = 0; i < pizzas.length; i++) { @@ -615,19 +618,19 @@ contract CryptoPizza is IERC721, ERC165 { result = false; } } - require(result, "Pizza with such name already exists."); + require(result, "Uma pizza com esse nome já existe."); _; } - // Returns whether the target address is a contract + // Retorna se o endereço de destino é um contrato 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. + // Atualmente não há uma maneira melhor de verificar se há um contrato em um endereço + // do que verificar o tamanho do código nesse endereço. + // Veja https://ethereum.stackexchange.com/a/14016/36603 + // para mais detalhes sobre como isso funciona. + // TODO Verificar isso novamente antes do lançamento do Serenity, porque todos os endereços serão + // contratos então. // solium-disable-next-line security/no-inline-assembly assembly { size := extcodesize(account) @@ -641,16 +644,16 @@ contract CryptoPizza is IERC721, ERC165 { 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/) +- [Solidity](https://docs.soliditylang.org/) +- [Vyper](https://docs.vyperlang.org/en/stable/) ## Tópicos relacionados {#related-topics} -- [Smart Contracts](/developers/docs/smart-contracts/) +- [Contratos inteligentes](/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._ +- [Reduzindo o tamanho dos contratos para combater o limite de tamanho do contrato](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Algumas dicas práticas para reduzir o tamanho do 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._ +- [Interaja com outros contratos a partir do 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/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/compiling/index.md index 1d9a3f0514e..6a57de7822d 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/compiling/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/compiling/index.md @@ -1,26 +1,26 @@ --- -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. +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} +## 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. +Pode ser útil ler a nossa introdução aos [contratos inteligentes](/developers/docs/smart-contracts/) e à [máquina virtual ethereum](/developers/docs/evm/) antes de ler sobre a 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: +Para que a [EVM](/developers/docs/evm/) possa executar seu contrato, ele precisa estar em **bytecode**. A compilação transforma isso: ```solidity pragma solidity 0.4.24; -contract Saudações { +contract Greeter { - function greet() public constant returns (string) { + function greet() public view returns (string memory) { return "Olá"; } @@ -33,17 +33,17 @@ contract Saudações { 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. +Eles são chamados de **códigos de operação**. 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/) +[Mais sobre códigos de operação](/developers/docs/evm/opcodes/) -## Aplicativos Web {#web-applications} +## Aplicações 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. +O compilador também produzirá a **Interface Binária de Aplicação (ABI)**, que é necessária para que sua aplicação entenda 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. +Uma [biblioteca de cliente JavaScript](/developers/docs/apis/javascript/) lerá a **ABI** para que você possa chamar seu contrato inteligente na interface da sua aplicação web. Abaixo está a ABI para o contrato de token ERC-20. Um ERC-20 é um token que você pode negociar no Ethereum. @@ -274,9 +274,9 @@ Abaixo está a ABI para o contrato de token ERC-20. Um ERC-20 é um token que vo ## Leitura adicional {#further-reading} -- [ Especificações ABI](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html)_– Solidity_ +- [Especificação da 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/) +- [Bibliotecas de cliente JavaScript](/developers/docs/apis/javascript/) +- [máquina virtual ethereum](/developers/docs/evm/) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/composability/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/composability/index.md index 65bdef6b491..5a424715cda 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/composability/index.md @@ -1,13 +1,13 @@ --- -title: Composição de contrato inteligente -description: +title: "Composição de contrato inteligente" +description: Aprenda como os contratos inteligentes podem ser combinados como blocos de Lego para construir dapps complexos reutilizando componentes existentes. 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). +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 da [Uniswap](https://uniswap.exchange/swap), uma corretora 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} @@ -19,17 +19,17 @@ Na Ethereum, todo contrato inteligente é uma espécie de Lego – você pode us 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). +\*\*1. **Modularidade**: Esta é a capacidade de componentes individuais de realizar 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. +\*\*2. **Autonomia**: Componentes componíveis devem ser capazes de operar de forma independente. 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. +\*\*3. **Capacidade de descoberta**: Desenvolvedores não podem chamar contratos externos ou integrar bibliotecas de software em aplicativos se os primeiros não estiverem disponíveis 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} +## Benefícios da componibilidade {#benefits-of-composability} -### Ciclo de desenvolvimento curto {#shorter-development-cycle} +### Ciclo de desenvolvimento mais curto {#shorter-development-cycle} -A composabilidade reduz o trabalho que os desenvolvedores têm de fazer ao criar [dapps](/apps/#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." +A componibilidade reduz o trabalho que os desenvolvedores precisam fazer ao criar [dapps](/apps/#what-are-dapps). [Como diz Naval Ravikant:](https://twitter.com/naval/status/1444366754650656770) "Código aberto significa que cada problema precisa ser resolvido apenas 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. @@ -43,13 +43,13 @@ A interoperabilidade entre os componentes do ecossistema Ethereum melhora a expe 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`). +Se um token está sendo negociado a um preço mais alto na `corretora A` do que na `corretora 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 `corretora B` e vendê-lo na `corretora 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. +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. [Empréstimos-relâmpago](/defi/#flash-loans) são altamente técnicos, mas a ideia básica é que você pode tomar ativos emprestados (sem colateral) e devolvê-los dentro de _uma_ única 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. +Voltando ao nosso exemplo inicial, um trader de arbitragem pode fazer um grande empréstimo-relâmpago, comprar tokens da `corretora B`, vendê-los na `corretora A`, pagar o capital + juros e ficar com o lucro, tudo na 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} +## Exemplos de componibilidade na Ethereum {#composability-in-ethereum} ### Trocas de tokens {#token-swaps} @@ -57,20 +57,20 @@ Se você criar um dapp que exige que as transações sejam pagas em ETH, você p ### 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. +Construir sistemas de governança personalizados para uma [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 o [Aragon Client](https://client.aragon.org/), para inicializar sua DAO e criar rapidamente uma estrutura 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. +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 a funcionalidade "Sign in with Ethereum", que permite que os usuários autentiquem 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._ +- [Dê um pontapé inicial no desenvolvimento de frontend do seu dapp com o 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 aplicativos 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ -- [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.) +- [Componibilidade é Inovação](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) +- [Por que a componibilidade é importante para a Web3](https://hackernoon.com/why-composability-matters-for-web3) +- [O que é componibilidade?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/deploying/index.md index 88aa1119212..94593d0d84f 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/deploying/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/deploying/index.md @@ -1,6 +1,6 @@ --- -title: Implantação de contratos inteligentes -description: +title: "Implantação de contratos inteligentes" +description: "Aprender como implantar contratos inteligentes para redes Ethereum, incluindo pré-requisitos, ferramentas e etapas de implantação." lang: pt-br --- @@ -8,52 +8,52 @@ Você precisa implantar o seu contrato inteligente para que ele esteja disponív 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} +## 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. +Você deve entender sobre [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. +Implantar um contrato também custa ether (ETH), uma vez que eles são armazenados na blockchain, então você deve estar familiarizado com [gás e taxas](/developers/docs/gas/) no 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/). +Finalmente, você precisará compilar seu contrato antes de implantá-lo, portanto, certifique-se de que leu sobre a [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} +### Do que você vai precisar {#what-youll-need} -- Bytecode do seu contrato - isto é gerado através da [compilação](/developers/docs/smart-contracts/compiling/). +- O bytecode do seu contrato – 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/) +- acesso a um [nó do Ethereum](/developers/docs/nodes-and-clients/), seja executando o seu próprio, conectando-se a um nó público ou por meio de uma chave de API usando um [serviço de nós](/developers/docs/nodes-and-clients/nodes-as-a-service/) -### Como implantar um contrato inteligente {#steps-to-deploy} +### Passos para 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/docs/tutorial/deploying) 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). +Os passos específicos envolvidos dependerão do framework de desenvolvimento em questão. Por exemplo, você pode conferir a [documentação do Hardhat sobre a implantação de seus contratos](https://hardhat.org/docs/tutorial/deploying) ou a [documentação do Foundry sobre a implantação e verificação de um contrato inteligente](https://book.getfoundry.sh/forge/deploying). Uma vez implantado, seu contrato terá um endereço Ethereum como outras [contas](/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 - _O Remix IDE permite desenvolver, implantar e administrar contratos inteligentes para blockchains como o Ethereum_** - [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 - _Plataforma de desenvolvimento Web3 que fornece depuração, observabilidade e blocos de construção de infraestrutura para desenvolver, testar, monitorar e operar contratos inteligentes_** -- [tenderly.com](https://tenderly.co/) +- [tenderly.co](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 - _Um ambiente de desenvolvimento para compilar, implantar, testar e depurar seu software Ethereum_** - [hardhat.org](https://hardhat.org/getting-started/) -- [Documentos na implantação de seus contratos](https://hardhat.org/docs/tutorial/deploying) +- [Documentação sobre a implantação de seus contratos](https://hardhat.org/docs/tutorial/deploying) - [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_** +**thirdweb - _Implante 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 - _Plataforma de desenvolvimento web3 de nível empresarial para implantar contratos inteligentes, habilitar pagamentos com cartão de crédito e cross-chain e usar APIs para criar, distribuir, vender, armazenar e editar NFTs._** - [crossmint.com](https://www.crossmint.com) - [Documentação](https://docs.crossmint.com) @@ -62,20 +62,20 @@ Os passos específicos envolvidos dependerão do framework de desenvolvimento em ## 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_ +- [Implantando seu primeiro contrato inteligente](/developers/tutorials/deploying-your-first-smart-contract/) _– Uma introdução à implantação de seu primeiro contrato inteligente em uma rede de teste da Ethereum._ +- [Hello World | tutorial de contrato inteligente](/developers/tutorials/hello-world-smart-contract/) _– Um tutorial fácil de seguir para criar e implantar um contrato inteligente básico no Ethereum._ +- [Interaja com outros contratos a partir do 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 reduzir o tamanho do 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 gás_ -## Leia mais {#further-reading} +## Leitura adicional {#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/docs/tutorial/deploying) - _Nomic Labs_ +- [Implantando seus contratos com o Hardhat](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ -_Conhece um recurso da comunidade que te ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## 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) +- [Frameworks de desenvolvimento](/developers/docs/frameworks/) +- [Executar um nó Ethereum](/developers/docs/nodes-and-clients/run-a-node/) +- [Nós como serviço](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/formal-verification/index.md index 9ff72b630c0..2be5b23281d 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/formal-verification/index.md @@ -1,12 +1,12 @@ --- -title: Verificação formal de contratos inteligentes -description: Uma visão geral da verificação formal de contratos inteligentes na Ethereum +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. +[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. +A verificação formal é uma das técnicas recomendadas para melhorar a [segurança de contratos inteligentes](/developers/docs/smart-contracts/security/). A verificação formal, que usa [métodos formais](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) para especificar, projetar e verificar programas, tem sido usada há anos para garantir a correção de sistemas de hardware e software críticos. 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. @@ -18,7 +18,7 @@ Comportamentos esperados do sistema (um contrato inteligente, neste caso) são d ### 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. +Em 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. @@ -26,15 +26,15 @@ Diferentes técnicas são utilizadas para modelagem de contratos inteligentes pa 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. +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 visão de caixa-branca à análise de programas e dependem de representações de nível inferior de aplicativos de contratos inteligentes, como rastreamentos de programas e [gráficos de fluxo de controle](https://en.wikipedia.org/wiki/Control-flow_graph), para analisar 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. +Modelos de baixo nível são considerados ideais, pois representam a execução real de um contrato inteligente no ambiente de execução do 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. +No contexto de contratos inteligentes, as especificações formais se referem a _propriedades_ — descrições formais dos requisitos que um contrato deve satisfazer. 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. @@ -44,55 +44,55 @@ As especificações formais são fundamentais no desenvolvimento de implementaç 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). +As especificações formais são derivadas usando elementos da [lógica de programação](https://en.wikipedia.org/wiki/Logic_programming), que permitem o 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ção são usadas na criação de especificações formais, incluindo [lógica de alcançabilidade](https://en.wikipedia.org/wiki/Reachability_problem), [lógica temporal](https://en.wikipedia.org/wiki/Temporal_logic) e [lógica de 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. +As especificações formais para contratos inteligentes podem ser classificadas de forma ampla 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. +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. As especificações de alto nível modelam um contrato inteligente como uma [máquina de estados finitos](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM), que pode transitar entre estados realizando operações, com a lógica temporal sendo 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. +[Lógicas temporais](https://en.wikipedia.org/wiki/Temporal_logic) são "regras para raciocinar sobre proposições qualificadas em termos de tempo (por exemplo, "Estou _sempre_ com fome" ou "Eu _eventualmente_ ficarei 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). +As 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 a ausência de [deadlock](https://www.techtarget.com/whatis/definition/deadlock), ou expressar propriedades específicas de domínio para contratos (p. ex., invariantes no controle de acesso para funções, valores admissíveis de variáveis de estado ou condições para transferências de tokens). -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. +Considere, por exemplo, este requisito de segurança que abrange as 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). +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 poderão sacar os ativos armazenados no contrato, como o que aconteceu com o [incidente da carteira 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. +Em termos mais simples, as especificações de baixo nível analisam _rastreamentos de programa_ e tentam definir propriedades de um contrato inteligente sobre esses rastreamentos. 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} +### Propriedades no 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. +A [Lógica de Hoare](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 uma tripla de Hoare `{P}c{Q}`, onde `c` é um programa e `P` e `Q` são predicados sobre o estado de `c` (ou seja, o programa), formalmente descritos como _pré-condiçõ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). +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 _invariante_ na lógica de 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. +As especificações de 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. +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 no 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. +As instruções `require` expressam uma pré-condição ou invariante e são frequentemente usadas para validar as entradas do usuário, enquanto `assert` captura uma pós-condição necessária para a 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 pré-condição na identidade da conta chamadora. Da mesma forma, uma invariante sobre os valores admissíveis das variáveis de estado em um contrato (por exemplo, o número total de tokens em circulação) pode ser protegida de 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} +### Propriedades em nível de rastreamento {#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. +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 fluxo de controle](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 usado 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: +Vamos usar um exemplo de um contrato de [DAO](/dao/) que tem algumas funções publicamente acessíveis para descrever propriedades de nível de rastreamento. Aqui, assumimos que o contrato DAO permite aos usuários executar as seguintes operações: - Depositar fundos @@ -100,7 +100,7 @@ Vamos usar um exemplo de um contrato com [DAO](/dao/) que tem algumas funções - 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). +Exemplos de propriedades em nível de rastreamento poderiam ser _“usuários que não depositam fundos não podem votar em uma proposta”_ ou _“usuários que não votam em uma proposta devem sempre poder solicitar um reembolso”_. Ambas as propriedades afirmam sequências de execução preferidas (a votação não pode acontecer _antes_ de depositar fundos e a solicitação de reembolsos não pode acontecer _depois_ de votar em uma proposta). ## Técnicas para verificação formal de contratos inteligentes {#formal-verification-techniques} @@ -108,19 +108,19 @@ Exemplo de propriedades de nível de traços poderia ser _"usuários que não de 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 requer a criação de uma representação matemática abstrata de um sistema (ou seja, um contrato) e a expressão de propriedades desse sistema usando fórmulas baseadas 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. +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_, que 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. +Por exemplo, uma propriedade de segurança relacionada ao controle de acesso (p. ex., _Apenas o proprietário do contrato pode chamar `selfdestruct`_) pode ser escrita em 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} +### Prova de teoremas {#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. +O objetivo da comprovação de teorema é verificar a equivalência lógica entre essas declarações. A “equivalência lógica” (também chamada de “bi-implicação lógica”) é um tipo de relação entre duas instruções, de modo que a primeira instrução é verdadeira _se, e somente se_, a segunda instruçã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. @@ -130,13 +130,13 @@ Como resultado, muitas vezes a assistência humana é necessária para guiar o c ### 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 é um método de analisar um contrato inteligente executando funções usando _valores simbólicos_ (p. ex., `x > 5`) em vez de _valores concretos_ (p. ex., `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. +A execução simbólica representa um rastreamento de execução como uma fórmula matemática sobre valores de entrada simbólicos, também chamado de _predicado de caminho_. Um [solucionador SMT](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) é usado para verificar se um predicado de caminho é "satisfatível" (ou seja, existe um valor que pode satisfazer 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. +Suponha que a função de um contrato inteligente receba 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 acione o erro usando um procedimento de teste normal exigiria a execução de dezenas de casos de teste (ou mais) sem a garantia de encontrar de fato uma entrada que acione o 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`. +Por outro lado, 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 de caminho associado `x = X > 5 ∧ X < 10` seria então fornecido a um solucionador SMT para ser resolvido. Se um valor específico satisfizer a fórmula `x = X > 5 ∧ X < 10`, o solucionador SMT o calculará — 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. @@ -152,25 +152,26 @@ function safe_add(uint x, uint y) returns(uint z){ 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. +Um rastreamento de execução que resulta em um overflow de inteiro precisaria satisfazer a fórmula: `z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)` É improvável que tal fórmula seja resolvida, portanto, serve como prova 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} +### Por que usar a verificação formal para contratos inteligentes? Benefícios da verificação formal {#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 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. Os contratos inteligentes são aplicativos de alto valor que controlam enormes quantidades de valor, e erros simples no projeto podem levar a [perdas irrecuperáveis para os 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} +#### Comprovação da 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**. +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 bugs (ou seja, se alguns caminhos de código não retornarem os resultados desejados durante a execução), mas **não pode provar conclusivamente 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. +Por outro lado, a verificação formal pode provar formalmente que um contrato inteligente satisfaz os requisitos para uma gama infinita de execuções _sem_ executar o 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. @@ -182,7 +183,7 @@ Contratos inteligentes, pelo menos em certa medida, preenchem ambos os requisito ### 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?"). +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 ocorre porque a verificação formal se baseia em valores simbólicos para testar asserções ("e se um usuário tentar sacar _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. @@ -206,78 +207,78 @@ Se as especificações forem mal escritas, as violações de propriedades - que 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. +Além disso, nem sempre é possível para os verificadores de programas determinar se uma propriedade (descrita como uma fórmula lógica) pode ser satisfeita ou não (o "[problema da decidibilidade](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} +## Ferramentas de verificação formal para contratos inteligentes do Ethereum {#formal-verification-tools} -### Linguagens de especificação para criação de especificações formais {#specification-languages} +### Linguagens de especificação para criar 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.** +**Act**: __O Act permite a especificação de atualizações de armazenamento, pré/pós-condições e invariantes de 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/) +- [Documentação](https://github.com/argotorg/act) -**Scribble** - _*Scribble transforma anotações de código na linguagem de especificação Scribble em afirmações concretas que verificam a especificação.** +**Scribble** - __O Scribble transforma anotações de código na linguagem de especificação Scribble em asserçõ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.** +**Dafny** - __Dafny é uma linguagem de programação pronta para verificação que se baseia em anotações de alto nível para raciocinar e provar a correção do código.__ - [GitHub](https://github.com/dafny-lang/dafny) -### Verificadores de programa para checagem de exatidão {#program-verifiers} +### Verificadores de programa para checagem de correçã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._ +**Certora Prover** - _O Certora Prover é uma ferramenta automática de verificação formal para checar a correção do código em contratos inteligentes. As especificações são escritas em CVL (Certora Verification Language), com as 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.** +**Solidity SMTChecker** - __O SMTChecker do Solidity é um verificador de modelo integrado baseado em SMT (Satisfiability Modulo Theories) e na soluçã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.** +**solc-verify** - __O solc-verify é uma versão estendida do compilador Solidity que pode realizar 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.** +**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} +### Frameworks lógicos para prova de teoremas {#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._ +**Isabelle** - _O Isabelle/HOL é um assistente de prova que permite que fórmulas matemáticas sejam expressas em uma linguagem formal e fornece ferramentas para provar 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._ +**Rocq** - _O Rocq é um provador de teoremas interativo que permite definir programas usando teoremas e gerar interativamente provas 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) +- [GitHub](https://github.com/rocq-prover/rocq) +- [Documentação](https://rocq-prover.org/docs) -### Ferramentas de execução simbólica para detectar padrões vulneráveis em contratos inteligentes {#symbolic-execution-tools} +### Ferramentas baseadas em 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*.* +**Manticore** - __Uma ferramenta para analisar bytecode da EVM baseada 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.** +**hevm** - __hevm é um mecanismo de execução simbólica e um verificador de equivalência para o bytecode da 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_ +**Mythril** - _Uma ferramenta de execução simbólica para detectar vulnerabilidades em contratos inteligentes do 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) +- [Como funciona a verificação formal de contratos inteligentes](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [Como a verificação formal pode garantir contratos inteligentes sem falhas](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 do 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/developers/docs/smart-contracts/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/index.md index 4c1715fd383..3180c72c704 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/index.md @@ -1,6 +1,6 @@ --- -title: Introdução aos contratos inteligentes -description: Uma visão geral dos contratos inteligentes, centrada em suas características e limitações únicas. +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 --- @@ -8,17 +8,17 @@ lang: pt-br 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. +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. +Certifique-se de que leu sobre [contas](/developers/docs/accounts/), [transações](/developers/docs/transactions/) e a [máquina virtual Ethereum](/developers/docs/evm/) antes de mergulhar no mundo dos contratos inteligentes. -## Uma máquina de vendas digitais {#a-digital-vending-machine} +## Uma máquina de venda automática digital {#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. +Talvez a melhor metáfora para um contrato inteligente seja uma máquina de venda automática, conforme descrito 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: @@ -35,27 +35,28 @@ pragma solidity 0.8.7; contract VendingMachine { - // Declarar variáveis de estado do endereço público do proprietário do contrato; + // Declarar variáveis de estado do contrato + address public owner; 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 { + // Quando o contrato 'VendingMachine' for implantado: + // 1. defina o endereço de implantação como o proprietário do contrato + // 2. defina o saldo de cupcakes do contrato inteligente implantado como 100 + constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } - // Permite que o proprietário aumente o saldo de cupcake no contrato inteligente + // Permitir que o proprietário aumente o saldo de cupcakes do contrato inteligente function refill(uint amount) public { - require(msg.sender == owner, "Only the owner can refill."); + require(msg.sender == owner, "Apenas o proprietário pode reabastecer."); cupcakeBalances[address(this)] += amount; } - // Permite que qualquer pessoa adquira cupcakes + // Permitir que qualquer pessoa compre 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"); + require(msg.value >= amount * 1 ether, "Você deve pagar pelo menos 1 ETH por cupcake"); + require(cupcakeBalances[address(this)] >= amount, "Não há cupcakes suficientes em estoque para concluir esta compra"); cupcakeBalances[address(this)] -= amount; cupcakeBalances[msg.sender] += amount; } @@ -64,9 +65,9 @@ contract VendingMachine { 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} +## Sem 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. +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. Implantar um contrato inteligente é tecnicamente uma transação, então você precisa pagar [gás](/developers/docs/gas/) da mesma forma que precisa pagar gás 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: @@ -81,23 +82,23 @@ Contudo, elas devem ser compiladas antes de poderem ser implantadas para que a m 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/). +Saiba mais sobre a [componibilidade de contratos inteligentes](/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/), instrumentos que ingerem dados off-chain e os disponibilizam para contratos inteligentes. +No entanto, é importante que aplicações blockchain possam usar dados off-chain. A solução são [oráculos](/developers/docs/oracles/), que são ferramentas que ingerem dados fora da cadeia 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). +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 Diamante (The Diamond Pattern)](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. +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 exigem N de M assinaturas possíveis (onde N ≤ M e M > 1) para serem executados. `N = 3, M = 5` e `N = 4, M = 7` são comumente usados. 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} +## Recursos de contratos inteligentes {#smart-contract-resources} -**OpenZeppelin Contracts -** **_Biblioteca para o desenvolvimento de contratos inteligentes seguros._** +**OpenZeppelin Contracts -** **_Biblioteca para desenvolvimento seguro de contratos inteligentes._** - [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) - [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) @@ -107,5 +108,5 @@ Os contratos multisig (com múltiplas assinaturas) são contas de contrato intel - [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) +- [Vídeo: Explicando de forma simples - Contratos Inteligentes](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft: plataforma de aprendizado e auditoria da Web3](https://updraft.cyfrin.io) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/languages/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/languages/index.md index 4e03783385c..dd739390f20 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/languages/index.md @@ -1,10 +1,10 @@ --- title: Linguagens de contratos inteligentes -description: Uma visão geral e comparação de duas línguagens de contratos inteligentes – Solidity e Vyper. +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. +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 chaves](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), pode encontrar uma linguagem com sintaxe familiar. As duas linguagens mais ativas e mantidas são: @@ -34,15 +34,15 @@ Conhecimento anterior de linguagens de programação, especialmente de JavaScrip ### 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) +- [Portal da Linguagem Solidity](https://soliditylang.org/) +- [Solidity por Exemplo](https://docs.soliditylang.org/en/latest/solidity-by-example.html) - [GitHub](https://github.com/ethereum/solidity/) -- [Solidity Matrix 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) +- [Chat do Solidity no Gitter](https://gitter.im/ethereum/solidity) com ponte para o [Chat do Solidity no Matrix](https://matrix.to/#/#ethereum_solidity:gitter.im) +- [Folha de consulta](https://reference.auditless.com/cheatsheet) +- [Blog do Solidity](https://blog.soliditylang.org/) +- [Twitter do Solidity](https://twitter.com/solidity_lang) -### Exemplo de contrato {#example-contract} +### Contrato de exemplo {#example-contract} ```solidity // SPDX-License-Identifier: GPL-3.0 @@ -58,14 +58,14 @@ contract Coin { // alterações de contrato que você declara event Sent(address from, address to, uint amount); - // O código constructor só é executado quando o contrato + // O código do construtor 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 + // Envia uma quantidade de moedas recém-criadas para um endereço + // Só pode ser chamado pelo criador do contrato function mint(address receiver, uint amount) public { require(msg.sender == minter); require(amount < 1e60); @@ -73,7 +73,7 @@ contract Coin { } // Envia uma quantidade de moedas existentes - // de qualquer solicitador para um endereço + // de qualquer chamador para um endereço function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Saldo insuficiente."); balances[msg.sender] -= amount; @@ -101,21 +101,21 @@ Esse exemplo deve dar a você, uma ideia de como é a sintaxe de um contrato na - 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). +Para mais informações, [leia a justificativa 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) +- [Vyper por 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) -- [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) +- [Chat da comunidade Vyper no Discord](https://discord.gg/SdvKC79cJk) +- [Folha de consulta](https://reference.auditless.com/cheatsheet) +- [Estruturas e ferramentas 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) +- [Hub Vyper para desenvolvimento](https://github.com/zcor/vyper-dev) +- [Exemplos de contratos inteligentes Vyper greatest hits](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [Awesome Vyper: recursos selecionados](https://github.com/spadebuilders/awesome-vyper) ### Exemplo {#example} @@ -123,72 +123,90 @@ Para obter mais informações, [leia a lógica do Vyper](https://vyper.readthedo # Leilão aberto # Parâmetros do leilão -# Beneficiário recebe dinheiro do licitante com lance mais alto + +# O beneficiário recebe o dinheiro do maior lance + 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 +# Definido como verdadeiro no final, não permite nenhuma alteração + ended: public(bool) -# Acompanha os lances reembolsados para que possamos seguir o padrão de saque +# Acompanhe 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 +# Crie um leilão simples com tempo de lance de `_bidding_time` + +# segundos 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 +# Dê um lance 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. + +# O valor só será reembolsado se o + +# leilão não for ganho. + @external @payable def bid(): - # Verifica se o período de licitação acabou. + # Verifique se o período de lances terminou. assert block.timestamp < self.auctionEnd - # Verifica se o lance é alto o suficiente + # Verifique se o lance é alto o suficiente assert msg.value > self.highestBid - # Rastreia o reembolso do licitante anterior + # Acompanhe o reembolso do licitante anterior com o lance mais alto self.pendingReturns[self.highestBidder] += self.highestBid - # Rastreia o mais recente lance mais alto + # Acompanhe o novo lance mais alto self.highestBidder = msg.sender self.highestBid = msg.value -# Retira um lance previamente reembolsado. O padrão de retirada é +# Saque um lance reembolsado anteriormente. O padrão de saque é + # 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. + +# enviados como parte do bid(), um contrato de lance malicioso poderia bloquear + +# esses reembolsos e, assim, impedir 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 +# Encerre o leilão e envie 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) + # É uma boa diretriz 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 + # 1. verificação de condições + # 2. execução de ações (potencialmente alterando condições) + # 3. interação com outros contratos + # Se essas fases forem misturadas, o outro contrato poderá chamar + # de volta para o contrato atual e modificar o estado ou causar + # efeitos (pagamento de ether) a serem realizados várias vezes. + # Se as funções chamadas internamente incluírem interação com + # contratos externos, elas também deverão ser consideradas como interação com # contratos externos. # 1. Condições @@ -213,24 +231,25 @@ Se você é novo na Ethereum e ainda não fez qualquer codificação com linguag **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. +- Suporta a [EVM](/developers/docs/evm) e o [Ewasm](https://github.com/ewasm), um WebAssembly com sabor de Ethereum, e foi projetado 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/). +- Inicialmente projetado para um contrato de [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} +### Links importantes {#important-links-2} -- [Documentação](https://docs.soliditylang.org/en/latest/yul.html) -- [Documentação Yul+](https://github.com/fuellabs/yulp) -- [Yul+ Post de Introdução](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) +- [Documentação do Yul](https://docs.soliditylang.org/en/latest/yul.html) +- [Documentação do Yul+](https://github.com/fuellabs/yulp) +- [Post de introdução ao Yul+](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) -### Exemplo de contrato {#example-contract-2} +### Contrato de exemplo {#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. +O exemplo a seguir simples implementa uma função de energia. Pode ser compilado usando `solc --strict-assembly --bin input.yul`. O exemplo deve ser +armazenado no arquivo input.yul. ``` { @@ -251,7 +270,7 @@ O exemplo a seguir simples implementa uma função de energia. Ele pode ser comp } ``` -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). +Se você já tem bastante experiência com contratos inteligentes, uma implementação completa do ERC20 em Yul pode ser encontrada [aqui](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example). ## Fe {#fe} @@ -263,31 +282,31 @@ Se você já é bem experiente com contratos inteligentes, uma implementação d ### 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) +- [Anúncio do Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [Planejamento do Fe para 2021](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) +- [Chat do Fe no Discord](https://discord.com/invite/ywpkAXFjZH) +- [Twitter do Fe](https://twitter.com/official_fe) -### Exemplo de contrato {#example-contract-3} +### Contrato de exemplo {#example-contract-3} O seguinte é um contrato simples implementado em Fe. ``` type BookMsg = bytes[100] -contrate GuestBook: +contract GuestBook: pub guest_book: map event Signed: book_msg: BookMsg pub def sign(book_msg: BookMsg): - eu mesmo. uest_book[msg.sender] = book_msg + self.guest_book[msg.sender] = book_msg - emite Signed(book_msg=book_msg) + emit Signed(book_msg=book_msg) pub def get_msg(addr: address) -> BookMsg: - remeter. uest_book[addr].to_mem() + return self.guest_book[addr].to_mem() ``` @@ -299,7 +318,7 @@ Aqui estão algumas coisas a considerar se você ainda não tentou nenhuma das l ### 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/). +- 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. @@ -316,9 +335,9 @@ Aqui estão algumas coisas a considerar se você ainda não tentou nenhuma das l ## 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/) +Para comparações de sintaxe básica, ciclo de vida do contrato, interfaces, operadores, estruturas de dados, funções, fluxo de controle e muito mais, confira esta [folha de consulta da Auditless](https://reference.auditless.com/cheatsheet/) ## Leitura adicional {#further-reading} -- [Biblioteca de Contratos da Solidity por OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/) -- [Solidity como exemplo](https://solidity-by-example.org) +- [Biblioteca de Contratos Solidity da OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/) +- [Solidity por Exemplo](https://solidity-by-example.org) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/libraries/index.md index b392fff6b0c..7c3f5cca2b3 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/libraries/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/libraries/index.md @@ -1,14 +1,14 @@ --- title: Biblioteca de contratos inteligentes -description: +description: "Acesse bibliotecas de contratos inteligentes pré-construídos e reutilize-os para desenvolver projetos em Ethereum mais rapidamente." 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} +## 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. +Antes de entrar em bibliotecas de contratos inteligentes, é uma boa ideia ter uma boa compreensão da estrutura de um contrato inteligente. Acesse a [anatomia de contratos inteligentes](/developers/docs/smart-contracts/anatomy/) se você ainda não o fez. ## O que há em uma biblioteca {#whats-in-a-library} @@ -16,11 +16,11 @@ Geralmente, você pode encontrar dois tipos de blocos de construção em bibliot ### 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. +Ao escrever contratos inteligentes, há uma boa chance de que você se pegue escrevendo padrões semelhantes repetidamente, como atribuir um endereço de _admin_ para realizar operações protegidas em um contrato, ou adicionar um botão de _pausa_ de emergência no 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. +As bibliotecas de contratos inteligentes geralmente fornecem implementações reutilizáveis desses 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. +Como exemplo, a seguir está uma versão simplificada do [contrato `Ownable`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) da [biblioteca OpenZeppelin Contracts](https://github.com/OpenZeppelin/openzeppelin-contracts), que designa um endereço como o proprietário de um contrato, e fornece um modificador para restringir o acesso a um método apenas a esse proprietário. ```solidity contract Ownable { @@ -50,19 +50,19 @@ contract MyContract is Ownable { } ``` -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! +Outro exemplo popular é [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/). +Para facilitar a [componibilidade e 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. +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 ERC20](/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. +Vale a pena mencionar que alguns ERCs não são sozinhos, mas são adições a outros ERCs. Por exemplo, o [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: +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 `npm`, então você pode simplesmente `npm install` nelas. A maioria das ferramentas para [compilar](/developers/docs/smart-contracts/compiling/) contratos procurará em seus `node_modules` por bibliotecas de contratos inteligentes, para que você possa fazer o seguinte: ```solidity // Isto irá carregar a biblioteca @openzeppelin/contracts de seus node_modules @@ -73,13 +73,13 @@ contrato MyNFT é ERC721 { } ``` -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. +Independentemente do método que você usa, ao incluir uma biblioteca, sempre fique de olho na versão da [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. +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 passam por [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! @@ -87,31 +87,31 @@ Por último, ao decidir se deve incluir uma biblioteca, considere a sua utiliza ## Ferramentas relacionadas {#related-tools} -**OpenZeppelin Contracts -** **_Biblioteca para o desenvolvimento de contratos inteligentes seguros._** +**OpenZeppelin Contracts -** **_A biblioteca mais popular para o desenvolvimento seguro de contratos inteligentes._** - [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._** +**DappSys -** **_Blocos de construção 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._** +**HQ20 -** **_Um projeto Solidity com contratos, bibliotecas e exemplos para ajudá-lo a construir aplicativos distribuídos completos 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_** +**thirdweb Solidity SDK -** **_Fornece as ferramentas necessárias para construir contratos inteligentes personalizados de forma eficiente_** - [Documentação](https://portal.thirdweb.com/contracts/build/overview) - [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._ +- [Considerações de segurança para desenvolvedores Ethereum](/developers/docs/smart-contracts/security/) _– Um tutorial sobre considerações de segurança ao construir contratos inteligentes, incluindo o uso de bibliotecas._ +- [Entenda o contrato inteligente do token ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- Tutorial sobre o 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!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/naming/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/naming/index.md new file mode 100644 index 00000000000..41183a694e4 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/naming/index.md @@ -0,0 +1,101 @@ +--- +title: Nomeando contratos inteligentes +description: "Melhores práticas para nomear contratos inteligentes do Ethereum com ENS" +lang: pt-br +--- + +Os contratos inteligentes são uma pedra angular da infraestrutura descentralizada do Ethereum, permitindo aplicações e protocolos autônomos. Mas, mesmo com a evolução das capacidades dos contratos, usuários e desenvolvedores ainda dependem de endereços hexadecimais brutos para identificar e referenciar esses contratos. + +Nomear contratos inteligentes com o [Ethereum Name Service (ENS)](https://ens.domains/) melhora a experiência do usuário, eliminando os endereços de contrato hexadecimais e reduz o risco de ataques como envenenamento de endereços e ataques de spoofing. Este guia explica por que a nomeação de contratos inteligentes é importante, como ela pode ser implementada e as ferramentas disponíveis, como o [Enscribe](https://www.enscribe.xyz), para simplificar o processo e ajudar os desenvolvedores a adotar essa prática. + +## Por que nomear contratos inteligentes? {#why-name-contracts} + +### Identificadores legíveis por humanos {#human-readable-identifiers} + +Em vez de interagir com endereços de contrato opacos como `0x8f8e...f9e3`, os desenvolvedores e usuários podem usar nomes legíveis por humanos como `v2.myapp.eth`. Isso simplifica as interações de contratos inteligentes. + +Isso é possível graças ao [Ethereum Name Service](https://ens.domains/), que fornece um serviço de nomeação descentralizado para endereços Ethereum. Isso é análogo a como o Serviço de Nomes de Domínio (DNS) permite que os usuários da internet acessem endereços de rede usando um nome como ethereum.org em vez de um endereço IP como `104.18.176.152`. + +### Segurança e confiança aprimoradas {#improved-security-and-trust} + +Contratos nomeados ajudam a reduzir transações acidentais para o endereço errado. Eles também ajudam os usuários a identificar contratos vinculados a aplicativos ou marcas específicas. Isso adiciona uma camada de confiança reputacional, especialmente quando os nomes estão vinculados a domínios pais bem conhecidos como `uniswap.eth`. + +Devido ao comprimento de 42 caracteres de um endereço Ethereum, é muito difícil para os usuários identificarem pequenas alterações nos endereços, onde alguns caracteres foram modificados. Por exemplo, um endereço como `0x58068646C148E313CB414E85d2Fe89dDc3426870` normalmente seria truncado para `0x580...870` por aplicativos voltados para o usuário, como carteiras. É improvável que um usuário perceba um endereço malicioso onde alguns caracteres foram alterados. + +Esse tipo de técnica é empregado em ataques de falsificação e envenenamento de endereço, nos quais os usuários são levados a acreditar que estão interagindo ou enviando fundos para o endereço correto, quando, na verdade, o endereço apenas se assemelha ao endereço correto, mas não é o mesmo. + +Nomes ENS para carteiras e contratos protegem contra esses tipos de ataques. Assim como os ataques de spoofing de DNS, os ataques de spoofing de ENS também podem ocorrer, no entanto, um usuário tem maior probabilidade de notar um erro de digitação em um nome ENS do que uma pequena modificação em um endereço hexadecimal. + +### Melhor UX para carteiras e exploradores {#better-ux} + +Quando um contrato inteligente foi configurado com um nome ENS, é possível para aplicativos como carteiras e exploradores de blockchain exibir nomes ENS para contratos inteligentes, em vez de endereços hexadecimais. Isso proporciona uma melhoria significativa na experiência do usuário (UX) para os usuários. + +Por exemplo, ao interagir com um aplicativo como o Uniswap, os usuários normalmente verão que o aplicativo com o qual estão interagindo está hospedado no site `uniswap.org`, mas um endereço de contrato hexadecimal seria apresentado se o Uniswap não nomeasse seus contratos inteligentes com ENS. Se o contrato for nomeado, em vez disso, eles poderiam ver `v4.contracts.uniswap.eth`, o que é muito mais útil. + +## Nomeação na implantação vs. pós-implantação {#when-to-name} + +Há dois momentos em que os contratos inteligentes podem ser nomeados: + +- **No momento da implantação**: atribuir um nome ENS ao contrato no momento em que ele é implantado. +- **Após a implantação**: mapear um endereço de contrato existente para um novo nome ENS. + +Ambas as abordagens dependem de ter acesso de proprietário ou gerente a um domínio ENS para que possam criar e definir registros ENS. + +## Como funciona a nomeação de contratos com ENS {#how-ens-naming-works} + +Os nomes ENS são armazenados na cadeia e resolvidos para endereços Ethereum através de resolvedores ENS. Para nomear um contrato inteligente: + +1. Registre ou controle um domínio pai ENS (p. ex., `myapp.eth`) +2. Crie um subdomínio (p. ex., `v1.myapp.eth`) +3. Defina o registro de `endereço` do subdomínio para o endereço do contrato +4. Defina o registro reverso do contrato para o ENS para permitir que o nome seja encontrado por meio de seu endereço + +Os nomes ENS são hierárquicos e suportam um número ilimitado de subnomes. A definição desses registros normalmente envolve a interação com o registro ENS e os contratos do resolvedor público. + +## Ferramentas para nomear contratos {#tools} + +Existem duas abordagens para nomear contratos inteligentes. Seja usando o [App ENS](https://app.ens.domains) com alguns passos manuais, ou usando o [Enscribe](https://www.enscribe.xyz). Eles são descritos abaixo. + +### Configuração manual do ENS {#manual-ens-setup} + +Usando o [App ENS](https://app.ens.domains/), os desenvolvedores podem criar subnomes manualmente e definir registros de endereço de encaminhamento. No entanto, eles não podem definir um nome primário para um contrato inteligente, definindo o registro reverso para o nome através do aplicativo ENS. Devem ser tomadas medidas manuais, que são abordadas nos [documentos do ENS](https://docs.ens.domains/web/naming-contracts/). + +### Enscribe {#enscribe} + +[Enscribe](https://www.enscribe.xyz) simplifica a nomeação de contratos inteligentes com o ENS e aumenta a confiança do usuário em contratos inteligentes. Ele fornece: + +- **Implantação e nomeação atômicas**: atribua um nome ENS ao implantar um novo contrato +- **Nomeação pós-implantação**: anexe nomes a contratos já implantados +- **Suporte multichain**: funciona em redes Ethereum e L2 onde o ENS é suportado +- **Dados de verificação de contrato**: inclui dados de verificação de contrato obtidos de várias fontes para aumentar a confiança dos usuários + +O Enscribe suporta nomes ENS fornecidos pelos usuários ou seus próprios domínios se o usuário não tiver um nome ENS. + +Você pode acessar o [Enscribe App](https://app.enscribe.xyz) para começar a nomear e visualizar contratos inteligentes. + +## Boas práticas {#best-practices} + +- **Use nomes claros e com versão**, como `v1.myapp.eth`, para tornar as atualizações do contrato transparentes +- **Defina registros reversos** para vincular contratos a nomes ENS para visibilidade em aplicativos como carteiras e exploradores da blockchain. +- **Monitore os vencimentos de perto** se quiser evitar alterações acidentais de propriedade +- **Verifique a fonte do contrato** para que os usuários possam confiar que o contrato nomeado se comporta como esperado + +## Riscos {#risks} + +A nomeação de contratos inteligentes oferece benefícios significativos para os usuários do Ethereum, no entanto, os proprietários de domínios ENS devem ser vigilantes em relação à sua gestão. Riscos notáveis incluem: + +- **Vencimento**: assim como os nomes de DNS, os registros de nomes de ENS têm duração finita. Portanto, é vital que os proprietários monitorem as datas de validade de seus domínios e os renovem com bastante antecedência do vencimento. Tanto o App ENS quanto o Enscribe fornecem indicadores visuais para os proprietários de domínio quando o vencimento está se aproximando. +- **Mudança de propriedade**: os registros ENS são representados como NFTs na Ethereum, onde o proprietário de um domínio `.eth` específico tem o NFT associado em sua posse. Portanto, se uma conta diferente assumir a propriedade deste NFT, o novo proprietário poderá modificar quaisquer registros ENS como achar melhor. + +Para mitigar esses riscos, a conta do proprietário dos domínios de segundo nível (2LD) `.eth` deve ser protegida por meio de uma carteira de assinaturas múltiplas, com subdomínios sendo criados para gerenciar a nomenclatura de contratos. Dessa forma, no caso de quaisquer alterações acidentais ou maliciosas na propriedade no nível do subdomínio, elas podem ser substituídas pelo proprietário do 2LD. + +## O futuro da nomeação de contratos {#future} + +A nomeação de contratos está se tornando uma melhor prática para o desenvolvimento de dapps, semelhante a como os nomes de domínio substituíram os endereços IP na web. À medida que mais infraestrutura, como carteiras, exploradores e painéis, integram a resolução ENS para contratos, os contratos nomeados melhorarão a segurança e reduzirão os erros em todo o ecossistema. + +Ao tornar os contratos inteligentes mais fáceis de reconhecer e de se raciocinar sobre, a nomeação ajuda a preencher a lacuna entre os usuários e os aplicativos na Ethereum, melhorando a segurança e a experiência do usuário (UX). + +## Leitura adicional {#further-reading} + +- [Nomeando Contratos Inteligentes com ENS](https://docs.ens.domains/web/naming-contracts/) +- [Nomeando Contratos Inteligentes com Enscribe](https://www.enscribe.xyz/docs). diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/security/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/security/index.md index 2f250c0fed8..9ede9cb3b3f 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/security/index.md @@ -1,14 +1,14 @@ --- -title: Segurança de um Contrato Inteligente -description: Uma visão geral das diretrizes para a construção segura de contratos inteligentes na Ethereum +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. +Blockchains públicas, como a Ethereum, complicam ainda mais a questão de proteger contratos inteligentes. O código do 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/markets/2017/07/19/30-million-ether-reported-stolen-due-to-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). +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 grande repercussão, como o [hack da DAO](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3,6M de ETH roubados, valendo mais de US$ 1 bilhão nos preços de hoje), o [hack da carteira multi-assinatura da Parity](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) (US$ 30 milhões perdidos para hackers) e o [problema 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. @@ -16,73 +16,73 @@ As questões mencionadas tornam imperativo para os desenvolvedores investirem es 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} +## Diretrizes para a criação de contratos inteligentes Ethereum seguros {#smart-contract-security-guidelines} -### 1. Crie controles de acesso adequados {#design-proper-access-controls} +### 1. Projete 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). +Em contratos inteligentes, as funções marcadas como `public` ou `external` podem ser chamadas por quaisquer contas de propriedade externa (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. No entanto, as funções marcadas como `private` 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: +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 Ownable** e o **controle baseado em papéis** são dois padrões úteis para a implementação do controle de acesso em contratos inteligentes: -#### Padrão proprietário {#ownable-pattern} +#### Padrão Ownable {#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. +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 recebem 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} +#### Controle de acesso baseado em papéis {#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. +Registrar um único endereço como `Owner` em um contrato inteligente introduz 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. +Outra abordagem para implementar um controle de acesso seguro é 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} +### 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. +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 impor o comportamento correto em contratos inteligentes usando as instruções `require()`, `assert()` e `revert()` para acionar exceções e reverter alterações de estado se a execução falhar em satisfazer certos 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. +**`require()`**: As instruções `require` são definidas no início das funções e garantem que as condições predefinidas sejam atendidas 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 chamadora 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. +**`assert()`**: `assert()` é usado para detectar erros internos e verificar violações de “invariantes” 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 de `assert()` garante que seu contrato nunca atinja um estado vulnerável e, se isso acontecer, todas as alterações 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: +**`revert()`**: `revert()` pode ser usado em uma instrução if-else que aciona uma exceção se a condição necessária não for satisfeita. O contrato de exemplo abaixo usa `revert()` para proteger a execução das funções: ``` pragma solidity ^0.8.4; contract VendingMachine { address owner; - error Unauthorized(); + error NaoAutorizado(); function buy(uint amount) public payable { if (amount > msg.value / 2 ether) - revert("Not enough Ether provided."); - // Perform the purchase. + revert("Ether insuficiente fornecido."); + // Realizar a compra. } function withdraw() public { if (msg.sender != owner) - revert Unauthorized(); + revert NaoAutorizado(); 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} +### 3. Teste contratos inteligentes e verifique a exatidão 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. +A imutabilidade do código em execução na [Máquina Virtual Ethereum](/developers/docs/evm/) significa que os contratos inteligentes exigem 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. +O método habitual é escrever pequenos testes unitários utilizando dados simulados que o contrato deverá receber dos usuários. [Teste de unidade](/developers/docs/smart-contracts/testing/#unit-testing) é bom para testar a funcionalidade de certas 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. +Uma abordagem melhor é combinar testes de unidade com testes baseados em propriedades, realizados usando [análise estática e dinâmica](/developers/docs/smart-contracts/testing/#static-dynamic-analysis). A análise estática se baseia em representações de baixo nível, como [gráficos de fluxo de controle](https://en.wikipedia.org/wiki/Control-flow_graph) e [árvores de sintaxe abstrata](https://deepsource.io/glossary/ast/), para analisar os estados do programa e os caminhos de execução alcançáveis. Enquanto isso, as técnicas de análise dinâmica, como o [fuzzing de contratos inteligentes](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. +[A verificação formal](/developers/docs/smart-contracts/formal-verification) é outra técnica para verificar as 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} +### 4. Solicite 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. @@ -92,16 +92,16 @@ A comissão de uma auditoria de contrato inteligente é uma forma de realizar um 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_ +- [Dicas e truques de 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/) - _Inference_ -#### Recompensa por bugs {#bug-bounties} +#### Recompensas 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 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/). +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 permitido a um invasor criar uma quantidade ilimitada de ether no [Optimism](https://www.optimism.io/), um protocolo de [Camada 2](/layer-2/) em execução no Ethereum. Felizmente, um hacker white hat [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. +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 bug de escalabilidade](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)”, essa abordagem fornece incentivos financeiros para que indivíduos divulguem 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} @@ -115,11 +115,11 @@ A existência de auditorias e recompensas por bugs não dispensa sua responsabil - 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 Aderyn](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 +- Execute seu código através de ferramentas básicas de análise de código, como [Cyfrin Aderyn](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. +- 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 uma linguagem de fácil compreensão. Isso facilitará para outras pessoas auditarem e revisarem seu código. ### 6. Implemente planos robustos de recuperação de desastres {#implement-disaster-recovery-plans} @@ -129,30 +129,30 @@ Conceber controles de acesso seguros, implementar modificadores de função e ou 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. +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. [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. +As contas interagem com o contrato de proxy, que encaminha todas as chamadas de função para o contrato de lógica usando a chamada de baixo nível [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries). Diferente de uma chamada de mensagem regular, `delegatecall()` garante que o código em execução no endereço do contrato de lógica seja executado no contexto do contrato chamador. Isso significa que o contrato de lógica sempre gravará no armazenamento do proxy (em vez de em seu próprio armazenamento) e os valores originais de `msg.sender` e `msg.value` serã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/). +[Mais sobre a atualização de contratos](/developers/docs/smart-contracts/upgrading/). -#### Interrupções de emergência {#emergency-stops} +#### Paradas 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. +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 configurar 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). +3. Uma entidade que tenha acesso à função de parada 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: +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. Abaixo está [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. +// Este código não foi auditado profissionalmente e não faz promessas sobre segurança ou exatidão. Use por sua conta e risco. contract EmergencyStop { @@ -169,7 +169,7 @@ contract EmergencyStop { } modifier onlyAuthorized { - // Check for authorization of msg.sender here + // Verifique a autorização do msg.sender aqui _; } @@ -182,20 +182,20 @@ contract EmergencyStop { } function deposit() public payable stoppedInEmergency { - // Deposit logic happening here + // Lógica de depósito aqui } function emergencyWithdraw() public onlyWhenStopped { - // Emergency withdraw happening here + // Saque de emergência aqui } } ``` 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. +- `isStopped` é uma variável booleana que avalia para `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. +- Os modificadores de função `onlyWhenStopped` e `stoppedInEmergency` verificam a variável `isStopped`. `stoppedInEmergency` é usado para controlar funções que devem estar inacessíveis quando o contrato está 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”. @@ -203,7 +203,7 @@ Usar uma funcionalidade de interrupção de emergência fornece um paliativo efi #### 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). +[Eventos](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) permitem que você rastreie chamadas para funções de contrato inteligente e monitore alterações nas 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. @@ -213,17 +213,17 @@ Você também pode optar por uma ferramenta de monitoramento pronta para uso, qu Você pode querer descentralizar sua aplicação, transferindo o controle dos principais contratos inteligentes para os membros da comunidade. Neste 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. +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 pelo número de tokens detidos) ao fazer um [empréstimo relâmpago](/defi/#flash-loans) e aprovar 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 influenciar os votos on-chain. +Uma forma 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 influenciar 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. +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 a DAOs que se aproveitam do 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/5.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. +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 alcançar a simplicidade ao escrever contratos inteligentes é reutilizar bibliotecas existentes, como os [Contratos OpenZeppelin](https://docs.openzeppelin.com/contracts/5.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. @@ -231,14 +231,14 @@ Outro conselho comum é escrever funções pequenas e manter contratos modulares #### 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. +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. Este 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 ("vítima") que permite que qualquer pessoa deposite e saque Ether: ```solidity -// This contract is vulnerable. Do not use in production +// Este contrato é vulnerável. Não use em produção contract Victim { mapping (address => uint256) public balances; @@ -256,15 +256,15 @@ contract Victim { } ``` -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: +Este contrato expõe uma função `withdraw()` para permitir que os usuários saquem ETH previamente depositado 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). +A função `withdraw()` no contrato `Victim` segue um padrão de “verificações-interações-efeitos”. Ele _verifica_ se as condições necessárias para a execução são satisfeitas (ou seja, o usuário tem um saldo de 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, reduzindo 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. +Se `withdraw()` for chamada a partir de uma conta de propriedade externa (EOA), a função será executada como esperado: `msg.sender.call.value()` envia ETH para o chamador. No entanto, se `msg.sender` for uma conta de contrato inteligente que chama `withdraw()`, o envio de fundos usando `msg.sender.call.value()` também acionará a execução do código armazenado nesse endereço. Imagine que este é o código implantado no endereço do contrato: @@ -289,7 +289,7 @@ Este contrato foi concebido para fazer três coisas: 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: +Não há nada de errado aqui, exceto que `Attacker` tem outra função que chama `withdraw()` em `Victim` novamente se o gás restante do `msg.sender.call.value` recebido for maior que 40.000. Isso dá a `Attacker` a capacidade de reentrar em `Victim` e sacar mais fundos _antes_ que a primeira invocação de `withdraw` seja concluída. O ciclo fica assim: ```solidity - EOA do invasor chama `Attacker.beginAttack()` com 1 ETH @@ -304,13 +304,13 @@ Não há nada de errado aqui, exceto que o `Attacker` tem outra função que cha - `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/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). +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 os fundos de um contrato inteligente, como o que aconteceu no [hack da DAO em 2016](https://www.coindesk.com/learn/understanding-the-dao-attack). Os ataques de reentrância ainda são um problema crítico para os contratos inteligentes hoje, como mostram as [listas públicas de explorações 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: +O padrão de interação de verificação-efeito é usado em uma versão revisada do contrato `Victim` mostrado abaixo: ```solidity contract NoLongerAVictim { @@ -323,9 +323,9 @@ contract NoLongerAVictim { } ``` -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. +Este contrato realiza uma _verificação_ no saldo do usuário, aplica os _efeitos_ da função `withdraw()` (redefinindo o saldo do usuário para 0) e prossegue para 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 `NoLongerAVictim`, mas como `balances[msg.sender]` foi definido como 0, saques 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. +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 que a função seja executada e reverte para `false` após a conclusão da invocação. 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; @@ -335,15 +335,15 @@ contract MutexPattern { mapping(address => uint256) public balances; modifier noReentrancy() { - require(!locked, "Blocked from reentrancy."); + require(!locked, "Bloqueado contra reentrância."); 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 + // Esta função está protegida por um mutex, portanto, chamadas reentrantes de dentro de `msg.sender.call` não podem chamar `withdraw` novamente. + // A instrução `return` é avaliada como `true`, mas ainda avalia a instrução `locked = false` no modificador function withdraw(uint _amount) public payable noReentrancy returns(bool) { - require(balances[msg.sender] >= _amount, "No balance to withdraw."); + require(balances[msg.sender] >= _amount, "Nenhum saldo para sacar."); balances[msg.sender] -= _amount; (bool success, ) = msg.sender.call{value: _amount}(""); @@ -354,31 +354,31 @@ contract MutexPattern { } ``` -Você também pode usar um sistema de [receber pagamentos](https://docs.openzeppelin.com/contracts/5.x/api/utils#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). +Você também pode usar um sistema de [pagamentos pull](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment) que exige que os usuários retirem fundos dos contratos inteligentes, em vez de um sistema de "pagamentos push" que envia fundos para as 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} +#### Underflows e overflows de números inteiros {#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). +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. As operações aritméticas que resultam em valores superiores a `255` sofrerão overflow e redefinirão `uint` para `0`, semelhante a como o hodômetro de um carro é redefinido para 0 quando 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`). +Underflows de inteiros acontecem por razões 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. +// Este contrato foi projetado para atuar como um cofre de tempo. +// O usuário pode depositar neste contrato, mas não pode sacar por pelo menos uma semana. +// O usuário também pode estender o tempo de espera para além do período de espera 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. +1. Implante o TimeLock +2. Implante o Attack com o endereço do TimeLock +3. Chame Attack.attack enviando 1 ether. Você poderá imediatamente + sacar seu ether. O que aconteceu? -O ataque causou o extravasamento do TimeLock.lockTime e foi capaz de retirar +O ataque causou o overflow de TimeLock.lockTime e foi capaz de sacar antes do período de espera de 1 semana. */ @@ -396,14 +396,14 @@ contract TimeLock { } function withdraw() public { - require(balances[msg.sender] > 0, "Insufficient funds"); - require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); + require(balances[msg.sender] > 0, "Fundos insuficientes"); + require(block.timestamp > lockTime[msg.sender], "O tempo de bloqueio não expirou"); uint amount = balances[msg.sender]; balances[msg.sender] = 0; (bool sent, ) = msg.sender.call{value: amount}(""); - require(sent, "Failed to send Ether"); + require(sent, "Falha ao enviar Ether"); } } @@ -419,11 +419,11 @@ contract Attack { function attack() public payable { timeLock.deposit{value: msg.value}(); /* - if t = current lock time then we need to find x such that + se t = tempo de bloqueio atual, então precisamos encontrar x tal que x + t = 2**256 = 0 - so x = -t + então x = -t 2**256 = type(uint).max + 1 - so x = type(uint).max + 1 - t + então x = type(uint).max + 1 - t */ timeLock.increaseLockTime( type(uint).max + 1 - timeLock.lockTime(address(this)) @@ -435,15 +435,15 @@ contract Attack { ##### 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). +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, os contratos compilados com uma versão inferior do compilador devem realizar verificações em funções que envolvam operações aritméticas ou usar uma biblioteca (por exemplo, [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) que verifica a ocorrência de underflow/overflow. #### Manipulação de oráculos {#oracle-manipulation} -Os [oráculos](/developers/docs/oracles/) fornecem informações off-chain e as enviam on-chain para que os contratos inteligentes possam usá-las. Com oráculos, você pode criar contratos inteligentes que interagem com sistemas off-chain, como mercados capitais, expandindo muito sua aplicação. +[Oráculos](/developers/docs/oracles/) obtêm informações off-chain e as enviam on-chain para uso em contratos inteligentes. Com oráculos, você pode criar contratos inteligentes que interagem com sistemas off-chain, como mercados capitais, expandindo muito sua aplicação. Mas se o oráculo estiver corrompido e enviar informações incorretas on-chain, os 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. +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. As plataformas de empréstimo no setor de [finanças descentralizadas (DeFi)](/defi/) costumam fazer isso para determinar o valor da garantia de um usuário e, assim, definir o quanto ele pode tomar emprestado. 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). @@ -451,125 +451,125 @@ Por exemplo, um invasor pode explodir artificialmente o preço de um ativo fazen ##### 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. +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 consulta 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 sobre 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. +Se você planeja consultar um oráculo on-chain sobre preços de ativos, considere usar um que implemente um mecanismo de preço médio ponderado por tempo (TWAP). Um [oráculo TWAP](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) consulta o preço de um ativo em dois momentos diferentes (que você pode modificar) e calcula o preço à vista 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} +## Recursos de segurança de contratos inteligentes 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 para analisar contratos inteligentes e verificar a correçã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 e bibliotecas de teste](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _Coleção de ferramentas e bibliotecas padrão da indústria para realizar testes de unidade, 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._ +- **[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 checar invariantes._ -- **[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._ +- **[Serviços de auditoria de contratos inteligentes](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _Listagem de organizações que fornecem serviços de auditoria de contratos inteligentes 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._ +- **[Plataformas de recompensa por bugs](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _Plataformas para coordenar recompensas por bugs e premiar 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._ +- **[Fork Checker](https://forkchecker.hashex.org/)** - _Uma ferramenta on-line 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._ +- **[ABI Encoder](https://abi.hashex.org/)** - _Um serviço online gratuito para codificar as funções e os argumentos do construtor do seu contrato 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._ +- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Analisador estático do Solidity, percorrendo as Árvores de Sintaxe Abstrata (AST) para identificar vulnerabilidades suspeitas e imprimir problemas em um formato markdown de fácil consumo._ ### Ferramentas para monitorar contratos inteligentes {#smart-contract-monitoring-tools} -- **[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._ +- **[Tenderly Real-Time Alerting](https://tenderly.co/monitoring)** - _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} -- **[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)._ +- **[Safe](https://safe.global/)** - _Carteira de contrato inteligente executada 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/5.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._ +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _Bibliotecas de contratos para implementar recursos administrativos, incluindo propriedade de contrato, atualizações, controles de acesso, governança, pausabilidade e muito mais._ -### Serviços de auditoria de contrato inteligente {#smart-contract-auditing-services} +### Serviços de auditoria de contratos inteligentes {#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._ +- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _Serviço de auditoria de contratos inteligentes que ajuda projetos em todo o ecossistema de blockchain a garantir que seus protocolos estejam prontos para o lançamento e construídos 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._ +- **[CertiK](https://www.certik.com/)** - _Empresa de segurança de blockchain pioneira no uso de tecnologia de verificação formal de ponta em contratos inteligentes e redes de 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._ +- **[Trail of Bits](https://www.trailofbits.com/)** - _Empresa de segurança cibernética que combina pesquisa de segurança com uma mentalidade de invasor para reduzir riscos e fortalecer códigos._ -- **[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._ +- **[PeckShield](https://peckshield.com/)** - _Empresa de segurança de blockchain que oferece produtos e serviços para a segurança, privacidade e usabilidade de todo o ecossistema de 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._ +- **[QuantStamp](https://quantstamp.com/)** - _Serviço de auditoria que facilita a adoção em massa da tecnologia blockchain por meio de serviços de segurança e avaliação de riscos._ -- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _ Empresa de segurança de contrato inteligente que fornece auditorias de segurança para sistemas distribuídos._ +- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _Empresa de segurança de contratos inteligentes 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._ +- **[Runtime Verification](https://runtimeverification.com/)** - _Empresa de segurança especializada em modelagem e verificação formal de contratos inteligentes._ -- **[Hacken](https://hacken.io)** - _Auditor de cibersegurança da Web3 que traz a abordagem de 360 graus à segurança da blockchain._ +- **[Hacken](https://hacken.io)** - _Auditor de segurança cibernética da Web3 que traz a abordagem de 360 graus para a segurança da blockchain._ -- **[Nethermind](https://www.nethermind.io/smart-contract-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._ +- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _Serviços de auditoria em 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._ +- **[HashEx](https://hashex.org/)** - _A HashEx se concentra na auditoria de blockchain e contratos inteligentes para garantir a segurança de criptomoedas, fornecendo serviços como desenvolvimento de contratos inteligentes, testes 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._ +- **[Cyfrin](https://cyfrin.io)** - _Potência em segurança Web3, incubando a segurança de criptoativos através de produtos e serviços de auditoria de contratos inteligentes._ -- **[ImmuneBytes](https://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._ +- **[ImmuneBytes](https://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 as 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._ +- **[Oxorio](https://oxor.io/)** - _Auditorias de contratos inteligentes e serviços de segurança de blockchain com experiência em EVM, Solidity, ZK e tecnologia cross-chain para empresas de criptoativos e projetos de 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._ +- **[Inference](https://inference.ag/)** - _Empresa de auditoria de segurança especializada em auditoria de contratos inteligentes para blockchains baseadas 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._ +- **[Immunefi](https://immunefi.com/)** - _Plataforma de recompensa por bugs para contratos inteligentes e projetos de DeFi, onde pesquisadores de segurança revisam códigos, divulgam vulnerabilidades, são pagos e tornam as criptomoedas mais seguras._ -- **[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._ +- **[HackerOne](https://www.hackerone.com/)** - _Plataforma de coordenação de vulnerabilidades e 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._ +- **[HackenProof](https://hackenproof.com/)** - _Plataforma de recompensa por bugs especializada para projetos de cripto (DeFi, contratos inteligentes, carteiras, CEX e mais), onde profissionais de segurança fornecem serviços de triagem e pesquisadores são pagos por relatórios de bugs relevantes e 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._ +- **[Sherlock](https://www.sherlock.xyz/)** - _Subscritor na Web3 para segurança de contratos inteligentes, com pagamentos para auditores gerenciados por meio de contratos inteligentes para garantir que os 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._ +- **[CodeHawks](https://www.codehawks.com/)** - _Plataforma de recompensa por bugs competitiva, onde os auditores participam de concursos e desafios de segurança e (em breve) em suas próprias auditorias privadas._ -### Publicações de vulnerabilidades e exploits conhecidos em contratos inteligentes {#common-smart-contract-vulnerabilities-and-exploits} +### Publicações de vulnerabilidades e ataques (exploits) conhecidos de contratos inteligentes {#common-smart-contract-vulnerabilities-and-exploits} -- **[ConsenSys: Ataques Conhecidos em Contrato Inteligente](https://consensysdiligence.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._ +- **[ConsenSys: ataques conhecidos em contratos inteligentes](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _Explicação amigável para iniciantes sobre as 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._ +- **[Registro SWC](https://swcregistry.io/)** - _Lista com curadoria de itens da Enumeração de Fraquezas Comuns (CWE) que se aplicam a contratos inteligentes 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._ +- **[Rekt](https://rekt.news/)** - _Publicação atualizada regularmente sobre hacks e explorações de criptoativos de grande repercussão, juntamente com relatórios post-mortem detalhados._ -### Desafios para aprender a segurança de contratos inteligentes {#challenges-for-learning-smart-contract-security} +### Desafios para aprender sobre 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._ +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _Lista com curadoria de wargames de segurança de blockchain, desafios e competições de [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) e artigos 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._ +- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _Wargame para aprender segurança ofensiva de contratos inteligentes de 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'._ +- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _Wargame 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._ +- **[ConsenSys: melhores práticas de segurança de 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._ +- **[Nascent: Simple Security Toolkit](https://github.com/nascentxyz/simple-security-toolkit)** - _Coleção de guias práticos focados 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.* +- **[Padrões do Solidity](https://fravoll.github.io/solidity-patterns/)** - _Compilação útil de padrões seguros e melhores práticas para a linguagem de programação de contratos inteligentes 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._ +- **[Documentação do Solidity: Considerações de segurança](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _Diretrizes para escrever 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._ +- **[Padrão de Verificação de Segurança de Contratos Inteligentes](https://github.com/securing/SCSVS)** - _Lista de verificação de quatorze partes criada 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._ +- **[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 aprimorar suas melhores práticas 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 escrever 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 Slither para encontrar bugs em 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/) +- [Diretrizes de segurança para contratos inteligentes](/developers/tutorials/smart-contract-security-guidelines/) - [Como integrar com segurança seu contrato de token com tokens arbitrários](/developers/tutorials/token-integration-checklist/) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/testing/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/testing/index.md index fa409657f8b..5256b287f01 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/testing/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/testing/index.md @@ -1,38 +1,38 @@ --- title: Testes de contratos inteligentes -description: Uma visão geral das técnicas e considerações para testar contratos inteligentes Ethereum. +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. +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 exigem consenso social. Além disso, uma atualização só pode corrigir um erro _após_ sua descoberta — se um invasor descobrir a vulnerabilidade primeiro, seu contrato inteligente corre o risco de 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. +Por esses motivos, testar contratos inteligentes antes de [implantá-los](/developers/docs/smart-contracts/deploying/) na Mainnet é um requisito mínimo para a [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 que é teste de contrato inteligente? O que é o 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} +### Por que é importante testar contratos inteligentes? Importância de 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. +Como os contratos inteligentes geralmente gerenciam ativos financeiros de alto valor, pequenos erros de programação podem levar, e frequentemente 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. +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. +Os métodos para testar contratos inteligentes do Ethereum se dividem em duas grandes categorias: **testes automatizados** e **testes manuais**. 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. +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 não detectar 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} @@ -44,19 +44,19 @@ Um teste manual eficaz requer recursos consideráveis ​​(habilidade, tempo, ## Teste automatizado para contratos inteligentes {#automated-testing-for-smart-contracts} -### Teste unitário {#unit-testing-for-smart-contracts} +### Teste de unidade {#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} +#### Diretrizes para testes de unidade 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) +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 o resultado correto para entradas de usuário válidas. 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) -``` +```solidity constructor( uint biddingTime, address payable beneficiaryAddress @@ -108,11 +108,11 @@ function auctionEnd() external { } ``` -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. +Este é um contrato de leilão simples projetado para receber lances durante o período de submissão de ofertas. Se o `highestBid` aumentar, o licitante com o lance mais alto anterior recebe seu dinheiro de volta; quando o período de lances terminar, o `beneficiary` chama o contrato para receber 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`. +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 de unidade que verifica se um usuário pode fazer um lance enquanto o leilão está em andamento (ou seja, as chamadas para `bid()` são bem-sucedidas) ou um que verifica se um usuário pode fazer um lance maior que o `highestBid` atual. -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`). +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 fazer lances quando o leilão termina (ou seja, quando `auctionEndTime` é menor que `block.timestamp`). Assim, um desenvolvedor pode executar um teste de unidade que verifica se as chamadas para a função `bid()` são bem-sucedidas ou falham quando o leilão termina (ou seja, quando `auctionEndTime` > `block.timestamp`). ##### 2. Avalie todas as suposições relacionadas à execução do contrato @@ -126,11 +126,11 @@ Muitos frameworks de teste unitário permitem você criar afirmações - simples - 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`. +**Observação**: outra maneira de testar suposições é escrever testes que acionem [modificadores de função](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) em um contrato, especialmente as instruçõ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. Os testes devem contar com uma boa cobertura de código para minimizar o risco de vulnerabilidades não testadas. Sem cobertura suficiente, você pode presumir erroneamente que seu contrato é seguro porque todos os testes foram aprovados, embora ainda existam vulnerabilidades em caminhos de código não testados. 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. +A [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 instruções em seu código executadas durante os testes. Os testes devem contar com uma boa cobertura de código para minimizar o risco de vulnerabilidades não testadas. Sem cobertura suficiente, você pode presumir erroneamente que seu contrato é seguro porque todos os testes foram aprovados, embora ainda existam vulnerabilidades em caminhos de código não testados. 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 @@ -138,19 +138,19 @@ A qualidade das ferramentas usada para rodar testes unitários para o seu contra 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/)** +- **[Executando testes de unidade com o Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** +- **[Executando testes de unidade com o Foundry](https://book.getfoundry.sh/forge/writing-tests)** +- **[Executando testes de unidade com o Waffle](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** +- **[Executando testes de unidade com o Remix](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** +- **[Executando testes de unidade com Ape](https://docs.apeworx.io/ape/stable/userguides/testing.html)** +- **[Executando testes de unidade com o Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** +- **[Executando testes de unidade com Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** -### Teste de Integração {#integration-testing-for-smart-contracts} +### 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. +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, os testes de integração podem ajudar a verificar se itens como [herança](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) e injeção de dependência funcionam corretamente. -Os testes de integração são úteis 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. +Os testes de integração são úteis 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 é [bifurcar a cadeia de blocos](/glossary/#fork) em 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. @@ -158,151 +158,153 @@ O blockchain que sofreu fork irá se comportar similarmente à Mainnet e ter con 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** e **análise dinâmica** são duas técnicas comuns para executar testes baseados em propriedades, e ambas podem verificar que o código de um programa (um contrato inteligente, neste caso) satisfaz alguma propriedade predefinida. 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. +[Linting](https://www.perforce.com/blog/qac/what-is-linting) e [testes estáticos](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) são métodos comuns para executar análises estáticas em contratos. Ambos exigem a análise de 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 fluxo de controle](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) gerados 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. +A 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 as funções de um contrato inteligente para ver se algum traço de execução viola 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](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing) é um exemplo de uma técnica de análise 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. +1. **Escrever casos de teste para cobrir muitos cenários é difícil.** Um teste de propriedade exige apenas que você defina um comportamento e um intervalo de dados para testar o comportamento — o programa gera automaticamente casos de teste com base 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. +2. **Seu conjunto de testes pode não cobrir suficientemente todos os caminhos possíveis dentro do programa.** Mesmo com 100% de cobertura, é possível deixar passar casos extremos. -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. +3. **Testes de unidade provam que um contrato é executado corretamente para dados de amostra, mas se o contrato é executado corretamente para entradas fora da amostra permanece desconhecido.** Os testes de propriedade executam um contrato de destino com várias variações de um determinado valor de entrada para encontrar traços de execução que causam falhas de asserçã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} +### Diretrizes para executar testes baseados 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. +A execução de testes baseados em propriedade geralmente começa com a definição de uma propriedade (por exemplo, ausência de [estouros de inteiros](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) ou uma coleção de propriedades que você deseja 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/)** +- **[Análise estática de contratos inteligentes com Slither](https://github.com/crytic/slither)** +- **[Análise estática de contratos inteligentes com o Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** +- **[Teste baseado em propriedade com o Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** +- **[Fuzzing de contratos com Foundry](https://book.getfoundry.sh/forge/fuzz-testing)** +- **[Fuzzing de contratos com Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** +- **[Fuzzing de contratos com 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 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} +### Testando contratos em uma cadeia de blocos 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. +Testar seu contrato em uma cadeia de blocos local (também conhecida como uma [rede de desenvolvimento](/developers/docs/development-networks/)) é uma alternativa recomendada para 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. [Os contratos inteligentes são altamente combináveis](/developers/docs/smart-contracts/composability/), o que permite integrá-los com protocolos existentes — mas você ainda precisará garantir que interações on-chain complexas como essas produzam os resultados corretos. +Rodar contratos em blockchain local pode ser útil como forma de teste de integração manual. [Os contratos inteligentes são altamente combináveis](/developers/docs/smart-contracts/composability/), permitindo a integração com protocolos existentes — mas você ainda precisará garantir que interações on-chain 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} +### Testando contratos em redes de teste {#testing-contracts-on-testnets} -Uma rede de teste ou testnet funciona exatamente como o Ethereum Mainnet, exceto pelo fato de usar 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. +Uma rede de teste ou testnet funciona exatamente como o Ethereum Mainnet, exceto pelo fato de usar Ether (ETH) sem valor no mundo real. Implantar seu contrato em uma [rede de teste](/developers/docs/networks/#ethereum-testnets) significa que qualquer pessoa pode interagir com ele (por exemplo, por meio do frontend 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) +[Mais sobre as redes de teste do Ethereum.](/developers/docs/development-networks/#public-beacon-testchains) -## Testes vs. Verificação formal {#testing-vs-formal-verification} +## Teste 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). +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 a "exatidão funcional" (ou seja, não pode mostrar que um programa se comporta conforme o 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. +Diferentemente dos testes, a verificação formal pode ser usada para verificar se a execução de um contrato inteligente satisfaz uma especificação formal para _todas_ as execuções (ou seja, não tem bugs) sem a necessidade de 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) +[Mais sobre verificação formal para contratos inteligentes.](/developers/docs/smart-contracts/formal-verification) -## Testes vs auditorias e recompensas por bugs {#testing-vs-audits-bug-bounties} +## Teste 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. +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 [programas de recompensa por bugs](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) são duas maneiras de fazer com que outras pessoas analisem 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. +Por outro lado, um programa de recompensa por bugs geralmente envolve a oferta de uma recompensa financeira a um indivíduo (comumente descrito como [hackers whitehat](https://en.wikipedia.org/wiki/White_hat_\(computer_security\))) que descobre uma vulnerabilidade em um contrato inteligente e a divulga aos 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 e bibliotecas de teste {#testing-tools-and-libraries} -### Ferramentas de testes unitários {#unit-testing-tools} +### Ferramentas de teste de unidade {#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)_. +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _Framework para desenvolvimento e teste avançados de contratos inteligentes (baseado em 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._ +- **[Testes Remix](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!_ +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _Biblioteca de asserção para testes de contratos inteligentes do 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._ +- **[Framework de teste de unidade do Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _O Brownie utiliza o Pytest, um framework de teste rico em recursos que permite escrever testes pequenos com código mínimo, é adequado para grandes projetos e é altamente extensível._ -- **[Testes Foundry](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** — _Foundry oferece o Forge, uma estrutura de testes no Ethereum rápida e flexível, capaz de executar testes de unidade simples, verificações de otimização de gás e mutações (fuzzing) em contratos._ +- **[Testes Foundry](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry oferece Forge, um framework de teste do Ethereum rápido e flexível, capaz de executar testes de unidade simples, verificações de otimização de gás e fuzzing de 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._ +- **[Testes do Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _Framework para testar contratos inteligentes com base em 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._ +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _Framework de desenvolvimento e teste baseado em Python para contratos inteligentes direcionados à 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._ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Framework baseado em Python para testes de unidade e fuzzing com fortes recursos de depuração e suporte a testes entre cadeias, utilizando pytest e Anvil para a melhor experiência do usuário e desempenho._ ### 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._ +- **[Slither](https://github.com/crytic/slither)** - _Framework de análise estática de Solidity baseado em Python para encontrar vulnerabilidades, melhorar a compreensão do código e escrever análises personalizadas para contratos inteligentes._ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Linter para aplicar as melhores práticas de estilo e segurança para a linguagem de programação de contrato inteligente Solidity._ -- **[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, projetado especificamente para a segurança e o desenvolvimento de contratos inteligentes da Web3._ -- **[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 vulnerabilidade e qualidade de código, impressores para extrair informações úteis do código e suporte para escrever submódulos personalizados._ -- **[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._ +- **[Slippy](https://github.com/fvictorio/slippy)** - _Um linter simples e poderoso para Solidity._ #### 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._ +- **[Echidna](https://github.com/crytic/echidna/)** - _Fuzzer de contrato rápido para detectar vulnerabilidades em contratos inteligentes por meio de testes baseados em propriedades._ -- **[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._ +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _Ferramenta de fuzzing 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._ +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _Framework de execução simbólica dinâmica para analisar bytecode da 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._ +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _Ferramenta de avaliação de bytecode da EVM para detectar vulnerabilidades de contratos usando análise de propagação de dados (taint analysis), análise concolica 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._ +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble é uma linguagem de especificação e uma ferramenta de verificação em tempo de execução que permite anotar contratos inteligentes com propriedades que permitem 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 usar o Slither para encontrar bugs em 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) +- [Como executar testes de unidade 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) +- [Como testar contratos inteligentes como um rockstar](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/upgrading/index.md index 0ea6b7aca97..db42daeb81e 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/upgrading/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/upgrading/index.md @@ -1,6 +1,6 @@ --- title: Atualizando contratos inteligentes -description: Uma visão geral dos padrões de atualização de contratos inteligentes no Ethereum +description: "Uma visão geral dos padrões de atualização de contratos inteligentes no Ethereum" lang: pt-br --- @@ -12,7 +12,7 @@ Entretanto, mais pesquisas sobre melhoria de contratos inteligentes tem levado ## 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. +Você deve ter um bom entendimento de [contratos inteligentes](/developers/docs/smart-contracts/), [anatomia de contratos inteligentes](/developers/docs/smart-contracts/anatomy/) e da [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} @@ -42,7 +42,7 @@ O último passo na migração do contrato é convencer usuários a mudar para o 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/) +[Mais sobre a migração de contratos.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) ### Mecanismo de atualização 2: Separação de dados {#data-separation} @@ -66,17 +66,17 @@ 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`. +2. O contrato proxy armazena o endereço do contrato de lógica e delega todas as chamadas de função para o contrato de lógica (que contém a lógica de negócios) 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. +Usar os padrões de proxy requer um entendimento da função **delegatecall**. Basicamente, `delegatecall` é um opcode que permite que um contrato chame outro contrato, enquanto a execução real do código acontece no contexto do contrato chamador. Uma implicação de usar `delegatecall` em padrões de proxy é que o contrato de proxy lê e escreve em seu armazenamento e executa a lógica armazenada no contrato de lógica como se estivesse chamando uma função interna. -Da [Documentação Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries): +Da [documentação do 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._ +> _Existe uma variante especial de uma chamada de mensagem, chamada **delegatecall**, que é idêntica a uma chamada de mensagem, exceto pelo fato de que o código no endereço de destino é executado no contexto (ou seja, no endereço) do contrato chamador e os valores de `msg.sender` e `msg.value` não se alteram._ _Isso significa que um contrato pode carregar código dinamicamente 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. +O contrato proxy sabe que deve invocar o `delegatecall` sempre que um usuário chamar uma função, pois ele tem uma função `fallback` incorporada. Na programação em Solidity, a [função de fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) é executada quando uma chamada de função não corresponde às 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. @@ -84,29 +84,29 @@ O contrato proxy é imutável por padrão, mas novos contratos lógicos com lóg 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. +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 de seletor de função](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357), se usados incorretamente. [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. +Essa técnica é influenciada pelo [padrão de estratégia](https://en.wikipedia.org/wiki/Strategy_pattern), que incentiva a criação de 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. +Você pode construir um novo contrato satélite e configurar o contrato principal com o novo endereço. Isso permite que você altere _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} +### 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. +Os contratos de lógica no padrão diamante são conhecidos como _facets_. Para que o padrão diamante funcione, você precisa criar um mapeamento no contrato proxy que mapeia [seletores de função](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) para diferentes endereços de facet. -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. +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. Em seguida, ele invoca o `delegatecall` (usando a função de fallback) e redireciona a chamada para o contrato de lógica apropriado. O padrão de atualização diamante tem algumas desvantagens sobre os padrões tradicionais de atualização proxy: @@ -114,27 +114,27 @@ O padrão de atualização diamante tem algumas desvantagens sobre os padrões t 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. +3. Padrões proxy adotam uma abordagem de pegar todos para controle de acesso. Uma entidade com acesso às funções de atualização pode alterar 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). +[Mais sobre o 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 | -| ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 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. | +| | 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} +## Considerações sobre a atualização de 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. +3. Reduza as suposições de confiança ao descentralizar o processo de implementação de atualizações. As estratégias possíveis incluem o uso de um [contrato de carteira multi-sig](/developers/docs/smart-contracts/#multisig) para controlar as atualizações, ou exigir que [membros de uma DAO](/dao/) votem 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. @@ -142,24 +142,24 @@ O padrão de atualização diamante tem algumas desvantagens sobre os padrões t 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} +## Documentos {#resources} -**Plugins de atualização do OpenZeppelin - _Um conjunto de ferramentas para implantar e proteger contratos inteligentes atualizáveis._** +**Plugins de atualização da 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 +- [Atualizando seus Contratos Inteligentes | Tutorial do YouTube](https://www.youtube.com/watch?v=bdXJmWajZRY) por Patrick Collins +- [Tutorial de Migração de Contrato Inteligente do 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 +- [Tutorial Web3: Escreva um 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 +- [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 da Crypto Market Pool +- [Aprenda: Atualizando Contratos Inteligentes](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - Documentação da OpenZeppelin +- [Padrões de Proxy para Atualização de Contratos Solidity: Proxies Transparentes vs. UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) por Naveen Sahu +- [Como Funcionam as Atualizações Diamante](https://dev.to/mudgen/how-diamond-upgrades-work-417j) por Nick Mudge diff --git a/public/content/translations/pt-br/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/pt-br/developers/docs/smart-contracts/verifying/index.md index e2de46ba098..bbcd9588eed 100644 --- a/public/content/translations/pt-br/developers/docs/smart-contracts/verifying/index.md +++ b/public/content/translations/pt-br/developers/docs/smart-contracts/verifying/index.md @@ -1,16 +1,16 @@ --- title: Verificando contratos inteligentes -description: Uma visão geral da verificação do código-fonte de contratos inteligentes no Ethereum +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. +[Contratos inteligentes](/developers/docs/smart-contracts/) são projetados para serem “sem confiança”, o que significa que os usuários não precisam confiar em terceiros (por exemplo, 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. +É importante fazer a distinção entre "verificação de código-fonte" e "[verificação formal](/developers/docs/smart-contracts/formal-verification/)". A 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 (por exemplo, Solidity) compila para 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. +Antes de implantar um contrato inteligente na [Máquina Virtual do Ethereum (EVM)](/developers/docs/evm/), os 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. @@ -20,17 +20,17 @@ A verificação do contrato inteligente permite investigar o que um contrato faz 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). +É possível evitar isso anexando dados extras ao bytecode para servir como uma _garantia criptográfica_ para a exatidão do código-fonte, e como uma _impressão digital_ das informações de compilação. As informações necessárias são encontradas nos [metadados do contrato do Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html), e o hash desse arquivo é anexado ao bytecode de um contrato. Você pode ver isso 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. +Este tipo de verificação que utiliza o hash de metadados é referido como **"[verificação completa](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 seria refletido no código-fonte verificado sem a verificação completa. 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. +A ausência de confiança é, sem dúvida, a maior premissa para contratos inteligentes e [aplicativos descentralizados (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. @@ -40,13 +40,13 @@ As ferramentas de verificação do código-fonte fornecem garantias de que os ar ### 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. +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 verificação, contratos inteligentes maliciosos podem ter [backdoors](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), mecanismos de controle de acesso controversos, vulnerabilidades exploráveis e outras coisas que comprometem a segurança do usuário 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} +## Como verificar o código-fonte de contratos inteligentes da 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. +[Implantar um contrato inteligente na Ethereum](/developers/docs/smart-contracts/deploying/) exige o envio de uma transação com um payload de dados (bytecode compilado) para um endereço especial. O payload de dados é gerado pela compilação do código-fonte, mais os [argumentos do construtor](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) da instância do contrato anexados ao payload de dados na transação. A compilação é determinística, o que significa que sempre produz a mesma saída (isto é, o bytecode do contrato) se os mesmos arquivos de origem e configurações de compilação (por exemplo, versão do compilador, otimizador) forem usados. ![Um diagrama mostrando a verificação do código-fonte do contrato inteligente](./source-code-verification.png) @@ -62,41 +62,47 @@ A verificação de um contrato inteligente basicamente envolve os seguintes pass 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/). +Observe 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} +## Ferramentas de verificação do 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. +Embora seja mais conhecido como um [explorador de blockchain da 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/). +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 em cadeia, 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. +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 do bytecode recompilado. Portanto, as correspondências no Etherscan são correspondências parciais. +Etherscan é a ferramenta mais usada para verificação de contratos. No entanto, a verificação de contrato do Etherscan tem uma desvantagem: ela falha ao comparar o **hash de metadados** do bytecode em cadeia e do 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). +[Saiba mais sobre como verificar contratos no Etherscan](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). + +### Blockscout {#blockscout} + +O [Blockscout](https://blockscout.com/) é um explorador de blockchain de código aberto que também fornece um [serviço de verificação de contratos](https://eth.blockscout.com/contract-verification) para desenvolvedores e usuários de contratos inteligentes. Como uma alternativa de código aberto, o Blockscout oferece transparência sobre como a verificação é realizada e permite contribuições da comunidade para melhorar o processo de verificação. + +Como outros serviços de verificação, o Blockscout permite que você verifique o código-fonte do seu contrato recompilando o bytecode e comparando-o com o contrato implantado. Após a verificação, seu contrato recebe o status de verificação e o código-fonte fica disponível publicamente para auditoria e interação. Os contratos verificados também são listados no [repositório de contratos verificados](https://eth.blockscout.com/verified-contracts) do Blockscout para facilitar a navegação e a descoberta. ### 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. +O [Sourcify](https://sourcify.dev/#/verifier) é outra ferramenta de verificação de contratos que é de código aberto e descentralizada. Não é um explorador de blockchain e apenas verifica contratos em [diferentes redes baseadas na EVM](https://docs.sourcify.dev/docs/chains). Ele atua como uma infraestrutura pública para que outras ferramentas possam ser desenvolvidas sobre ele, e visa permitir interações de contrato mais amigáveis ao ser humano usando os comentários do [ABI](/developers/docs/smart-contracts/compiling/#web-applications) e do [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. +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/) em HTTP e [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), que é um armazenamento descentralizado e [endereçado por conteúdo](https://docs.storacha.network/concepts/content-addressing/). 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. +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-fonte através da sua API ou da [IU](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/). +[Saiba mais sobre a verificação de contratos no Sourcify](https://soliditylang.org/blog/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. +A [plataforma Tenderly](https://tenderly.co/) permite que os desenvolvedores da Web3 construam, 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). +Você pode verificar seus contratos usando o [Painel](https://docs.tenderly.co/contract-verification), o [plugin Hardhat da Tenderly](https://docs.tenderly.co/contract-verification/hardhat), ou a [CLI (interface de linha de comando)](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. diff --git a/public/content/translations/pt-br/developers/docs/standards/index.md b/public/content/translations/pt-br/developers/docs/standards/index.md index ef2d2757224..ee48efac94b 100644 --- a/public/content/translations/pt-br/developers/docs/standards/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/index.md @@ -1,58 +1,59 @@ --- -title: Padrões de desenvolvimento Ethereum -description: Standards +title: "Padrões de desenvolvimento Ethereum" +description: "Aprenda sobre padrões de Ethereum, incluindo EIPs, padrões de token como ERC-20 e ERC-721 e convenções de desenvolvimento." lang: pt-br incomplete: true --- ## Visão geral dos padrões {#standards-overview} -A comunidade Ethereum adotou vários padrões que ajudam a manter projetos (tais como [Ethereum clients](/developers/docs/nodes-and-clients/) e carteiras) interoperáveis entre implementações, e asseguram que os contratos inteligentes e os dapps permaneçam compostos. +A comunidade Ethereum adotou muitos padrões que ajudam a manter os projetos (como [clientes Ethereum](/developers/docs/nodes-and-clients/) e carteiras) interoperáveis entre implementações e garantem que os contratos inteligentes e dapps permaneçam componíveis. -Normalmente, os padrões são apresentados como [Propostas de melhorias do Ethereum](/eips/) (EIPs), que são discutidas pela comunidade por meio de um [processo padronizado](https://eips.ethereum.org/EIPS/eip-1). +Normalmente, os padrões são introduzidos como [Propostas de Melhoria do Ethereum](/eips/) (EIPs), que são discutidas pelos membros da comunidade por meio de um [processo padrão](https://eips.ethereum.org/EIPS/eip-1). - [Introdução às EIPs](/eips/) - [Lista de EIPs](https://eips.ethereum.org/) -- [Repositório de GitHub sobre EIP](https://github.com/ethereum/EIPs) -- [Tabela de discussão de EIP](https://ethereum-magicians.org/c/eips) -- [Introdução à governança do Ethereum](/governance/) -- [Visão geral da governança Ethereum](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31 de Março de 2019 - Boris Mann_ -- [Coordenação de desenvolvimento do protocolo de governança do Ethereum e atualização da rede](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 de Março 23 - Hudson Jameson_ -- [Lista de reprodução de todas as reuniões de Ethereum Core Dev](https://www.youtube.com/@EthereumProtocol) _(YouTube Playlist)_ +- [Repositório GitHub de EIPs](https://github.com/ethereum/EIPs) +- [Fórum de discussão sobre EIPs](https://ethereum-magicians.org/c/eips) +- [Introdução à Governança do Ethereum](/governance/) +- [Visão geral da Governança do Ethereum](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31 de março de 2019 - Boris Mann_ +- [Governança de Desenvolvimento do Protocolo Ethereum e Coordenação de Upgrade da Rede](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 de março de 2020 - Hudson Jameson_ +- [Playlist de todas as reuniões de desenvolvedores do núcleo do Ethereum](https://www.youtube.com/@EthereumProtocol) _(Playlist do YouTube)_ ## Tipos de padrões {#types-of-standards} Existem 3 tipos de EIP: - Acompanhemento padrão: descreve qualquer mudança que afeta a maioria ou todas as implementações do Ethereum -- [Acompanhamento Meta](https://eips.ethereum.org/meta): descreve um processo em torno do Ethereum ou propõe uma alteração para um processo -- [Acompanhamento informativo](https://eips.ethereum.org/informational): descreve um problema de design do Ethereum e fornece orientações ou informações gerais para a comunidade Ethereum +- [Trilha Meta](https://eips.ethereum.org/meta): descreve um processo em torno do Ethereum ou propõe uma mudança a um processo +- [Trilha Informativa](https://eips.ethereum.org/informational): descreve um problema de design do Ethereum ou fornece diretrizes gerais ou informações para a comunidade Ethereum Além disso, o acompanhamento padrão é subdividido em 4 categorias: -- [Core](https://eips.ethereum.org/core): melhorias que requerem um fork de consenso -- [Networking](https://eips.ethereum.org/networking): melhorias em torno do devp2p e do Light Ethereum Subprotocol, bem como propostas de melhorias nas especificações de protocolo de rede do whisper e do swarm. -- [Interface](https://eips.ethereum.org/interface): melhorias em torno das especificações e padrões de API/RPC, e certos padrões no nível de linguagem, como nomes de método e contratos ABIs. -- [ERC](https://eips.ethereum.org/erc): normas e convenções dno nível do aplicativo +- [Núcleo (Core)](https://eips.ethereum.org/core): melhorias que exigem uma bifurcação de consenso +- [Rede (Networking)](https://eips.ethereum.org/networking): melhorias em torno do devp2p e do Subprotocolo Leve do Ethereum (Light Ethereum Subprotocol), bem como melhorias propostas para especificações de protocolo de rede do whisper e do swarm. +- [Interface](https://eips.ethereum.org/interface): melhorias em torno de especificações e padrões de API/RPC do cliente, e certos padrões de nível de linguagem como nomes de métodos e ABIs de contrato. +- [ERC](https://eips.ethereum.org/erc): padrões e convenções de nível de aplicativo -Encontre informações mais detalhadas sobre esses tipos e categorias diferentes em [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) +Informações mais detalhadas sobre esses diferentes tipos e categorias podem ser encontradas na [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) ### Padrões de token {#token-standards} -- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Uma interface padrão para tokens fungíveis (intermutáveis), como tokens de votação, tokens de staking ou moedas virtuais. - - [ERC-1363:](/developers/docs/standards/tokens/erc-1363/)define uma interface de token para tokens ERC-20 que suportam a execução do código destinatário após a transferência (ou transferFrom), ou o código do gastador após a aprovação -- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Uma interface padrão para tokens não fungíveis, como uma ação para obra de arte ou uma música. - - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309): um evento padronizado emitido ao criar/transferir um ou muitos tokens não-fungíveis usando identificadores de token consecutivos. - - [ERC-4400:](https://eips.ethereum.org/EIPS/eip-4400)extensão da interface para o papel do consumidor EIP-721 - - [ERC-4907:](https://eips.ethereum.org/EIPS/eip-4907) adicione um papel com limitação de tempo com permissões restritas aos tokens ERC-721. -- [ERC-777](/developers/docs/standards/tokens/erc-777/) **(NÃO RECOMENDADO): ** um padrão de token que aprimora o ERC-20. -- [ERC-1155](/developers/docs/standards/tokens/erc-1155/): um padrão de token que pode conter ativos fungíveis e não-fungíveis. -- [ERC-4626](/developers/docs/standards/tokens/erc-4626/): um padrão de cofre tokenizado projetado para otimizar e unificar os parâmetros técnicos dos cofres de rendimento. +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Uma interface padrão para tokens fungíveis (intercambiáveis), como tokens de votação, tokens de staking ou moedas virtuais. + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - Um padrão de tokens fungíveis que faz com que os tokens se comportem de forma idêntica ao ether e oferece suporte ao tratamento de transferências de tokens no lado do destinatário. + - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - Uma interface de extensão para tokens ERC-20 que suporta a execução de um callback em contratos de destinatário em uma única transação. +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Uma interface padrão para tokens não fungíveis, como um título de propriedade para uma obra de arte ou uma música. + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - Um evento padronizado emitido ao criar/transferir um ou muitos tokens não fungíveis usando identificadores de token consecutivos. + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - Extensão de interface para a função de consumidor da EIP-721. + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - Adiciona uma função com tempo limitado e com permissões restritas aos tokens ERC-721. +- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(NÃO RECOMENDADO)** Um padrão de token que melhora o ERC-20. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - Um padrão de token que pode conter ativos fungíveis e não fungíveis. +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - Um padrão de cofre tokenizado projetado para otimizar e unificar os parâmetros técnicos de cofres de rendimento. -Aprenda mais sobre [padrões de token](/developers/docs/standards/tokens/). +Saiba mais sobre [padrões de token](/developers/docs/standards/tokens/). ## Leitura adicional {#further-reading} -- [Propostas de Melhorias do Ethereum (EIPs)](/eips/) +- [Propostas de Melhoria do Ethereum (EIPs)](/eips/) -_Conhece algum recurso da comunidade que o ajudou? Edite essa página e adicione!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1155/index.md index 0198cc8f268..2a756ce1bc5 100644 --- a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1155/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1155/index.md @@ -1,35 +1,35 @@ --- -title: Padrão Multi-Token ERC-1155 -description: Token +title: "Padrão Multi-Token ERC-1155" +description: "Saiba mais sobre o ERC-1155, um padrão de múltiplos tokens que combina tokens fungíveis e não fungíveis em um único contrato." lang: pt-br --- ## Introdução {#introduction} -Uma interface padrão para contratos que gerenciam vários tipos de tokens. Um único contrato implementado pode incluir qualquer combinação de tokens fungíveis, tokens não fungíveis ou outras configurações, por exemplo, tokens semifungíveis. +Uma interface padrão para contratos que gerenciam vários tipos de tokens. Um único contrato implementado pode incluir qualquer combinação de tokens fungíveis, tokens não fungíveis ou outras configurações (por exemplo, tokens semifungíveis). **O que se entende por padrão Multi-Token?** -A ideia é simples e trata-se de criar uma interface de contratos inteligentes que possa representar e controlar qualquer número de tipos de token, fungíveis ou não fungíveis. Dessa forma, o token ERC-1155 pode fazer as mesmas funções que um token [ERC-20](/developers/docs/standards/tokens/erc-20/) ou um token [ERC-721](/developers/docs/standards/tokens/erc-721/), ou ainda as duas funções simultaneamente. Ele melhora a funcionalidade de ambos os padrões ERC-20 e ERC-721, tornando-os mais eficientes e corrigindo erros óbvios de implementação. +A ideia é simples e trata-se de criar uma interface de contratos inteligentes que possa representar e controlar qualquer número de tipos de token, fungíveis ou não fungíveis. Dessa forma, o token ERC-1155 pode executar as mesmas funções de um token [ERC-20](/developers/docs/standards/tokens/erc-20/) e [ERC-721](/developers/docs/standards/tokens/erc-721/), e até mesmo de ambos ao mesmo tempo. Ele melhora a funcionalidade de ambos os padrões ERC-20 e ERC-721, tornando-os mais eficientes e corrigindo erros óbvios de implementação. -O token ERC-1155 é descrito com profundidade em [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155). +O token ERC-1155 é descrito em detalhes na [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155). ## Pré-requisitos {#prerequisites} -Para entender melhor esta página, recomendamos ler primeiro sobre [padrões de token](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/) e [ERC-721](/developers/docs/standards/tokens/erc-721/). +Para entender melhor esta página, recomendamos que você leia primeiro sobre os [padrões de token](/developers/docs/standards/tokens/), o [ERC-20](/developers/docs/standards/tokens/erc-20/) e o [ERC-721](/developers/docs/standards/tokens/erc-721/). ## Funções e características do ERC-1155: {#body} -- [Transferências em lote](#batch_transfers): transfira vários ativos em uma única chamada. +- [Transferência em lote](#batch_transfers): transfira vários ativos em uma única chamada. - [Saldo em lote](#batch_balance): obtenha os saldos de vários ativos em uma única chamada. -- [Aprovação em lote](#batch_approval): aprove todos os tokens de um endereço. -- [Hooks](#receive_hook): receba hook de tokens. -- [Suporte para NFT](#nft_support): se a cunhagem for de apenas 1, tratar como NFT. -- [Regras de transferência segura](#safe_transfer_rule): conjunto de regras para transferências seguras. +- [Aprovação em lote](#batch_approval): aprove todos os tokens para um endereço. +- [Hooks](#receive_hook): hook para recebimento de tokens. +- [Suporte a NFT](#nft_support): se o fornecimento for de apenas 1, trate-o como um NFT. +- [Regras de transferência segura](#safe_transfer_rule): conjunto de regras para transferência segura. ### Transferências em lote {#batch-transfers} -As transferências em lote funcionam de forma muito semelhante às transferências regulares do ERC-20. Vejamos a função `transferFrom` da ERC-20 habitual: +As transferências em lote funcionam de forma muito semelhante às transferências regulares do ERC-20. Vejamos a função `transferFrom` regular do ERC-20: ```solidity // ERC-20 @@ -45,17 +45,17 @@ function safeBatchTransferFrom( ) external; ``` -A única diferença no ERC-1155 é que passamos os valores como um array e também passamos um array de ‘ids’. Por exemplo, dadas as matrizes `ids=[3, 6, 13]` e `values=[100, 200, 5]`, as transferências resultantes serão +A única diferença no ERC-1155 é que passamos os valores como um array e também passamos um array de ‘ids’. Por exemplo, dados `ids=[3, 6, 13]` e `values=[100, 200, 5]`, as transferências resultantes serão -1. Transferir 100 tokens da ID 3 de `_from` para `_to`. -2. Transferir 200 tokens da ID 6 de `_from` para `_to`. -3. Transferir 5 tokens da ID 13 de `_from` to `_to`. +1. Transferir 100 tokens com o id 3 de `_from` para `_to`. +2. Transferir 200 tokens com o id 6 de `_from` para `_to`. +3. Transferir 5 tokens com o id 13 de `_from` para `_to`. -No ERC-1155, só temos `transferFrom`, ou seja, não há `transfer`. Para usá-lo como uma transferência regular, ou `transfer`, defina o endereço de origem como o endereço que está chamando a função. +No ERC-1155, só temos `transferFrom`, não `transfer`. Para usá-lo como um `transfer` regular, basta definir o endereço de origem como o endereço que está chamando a função. ### Saldo em lote {#batch-balance} -A respectiva chamada `balanceOf` do ERC-20 também tem sua função parceira com suporte para lotes. Como lembrete, esta é a versão do ERC-20: +A respectiva chamada `balanceOf` do ERC-20 também tem sua função parceira com suporte a lote. Como lembrete, esta é a versão do ERC-20: ```solidity // ERC-20 @@ -70,7 +70,7 @@ function balanceOfBatch( Ainda mais simples para a chamada de saldo, podemos recuperar saldos múltiplos em uma única chamada. Passamos a matriz de proprietários, seguida pela matriz dos IDs dos tokens. -Por exemplo, dado `_ids=[3, 6, 13]` e `_owners=[0xbeef..., 0x1337..., 0x11...]`, o valor de retorno será +Por exemplo, dados `_ids=[3, 6, 13]` e `_owners=[0xbeef..., 0x1337..., 0x1111...]`, o valor de retorno será ```solidity [ @@ -95,13 +95,13 @@ function isApprovedForAll( ) external view returns (bool); ``` -As aprovações são um pouco diferentes do ERC-20. Em vez de aprovar valores específicos, você define um operador para aprovados ou não aprovados via `setApprovalForAll`. +As aprovações são um pouco diferentes do ERC-20. Em vez de aprovar valores específicos, você define um operador como aprovado ou não aprovado através do `setApprovalForAll`. -Ler o status atual pode ser feito via `isApprovedForAll`. Como você pode ver, é uma operação de tudo ou nada. Você não pode definir quantos tokens aprovar ou mesmo quais classes de token. +A leitura do status atual pode ser feita através do `isApprovedForAll`. Como você pode ver, é uma operação de tudo ou nada. Você não pode definir quantos tokens aprovar ou mesmo quais classes de token. Isto é intencionalmente concebido pensando na simplicidade. Você só pode aprovar tudo para um endereço. -### Receber hooks {#receive-hook} +### Hook de recebimento {#receive-hook} ```solidity function onERC1155BatchReceived( @@ -113,7 +113,7 @@ function onERC1155BatchReceived( ) external returns(bytes4); ``` -Dado o suporte da [EIP-165](https://eips.ethereum.org/EIPS/eip-165), o ERC-1155 pode receber hooks apenas por contratos inteligentes. A função de hook deve retornar um valor mágico predefinido de 4 bytes que é dado como: +Com o suporte da [EIP-165](https://eips.ethereum.org/EIPS/eip-165), o ERC-1155 suporta hooks de recebimento apenas para contratos inteligentes. A função de hook deve retornar um valor mágico predefinido de 4 bytes que é dado como: ```solidity bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) @@ -121,26 +121,26 @@ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],byt Quando o contrato de recebimento devolve este valor, assume-se que o contrato aceita a transferência e sabe como lidar com os tokens ERC-1155. Ótimo, nenhum token bloqueados em um contrato! -### Suporte para NFTs {#nft-support} +### Suporte a NFT {#nft-support} -Quando a oferta é apenas uma, o token é essencialmente um token não-fungível (NFT, pela sigla em inglês) E como é padrão para o ERC-721, você pode definir um URL de metadados. Esse URL pode ser lido e modificado pelos clientes; veja [aqui](https://eips.ethereum.org/EIPS/eip-1155#metadata). +Quando a oferta é apenas uma, o token é essencialmente um token não-fungível (NFT, pela sigla em inglês) E como é padrão para o ERC-721, você pode definir um URL de metadados. A URL pode ser lida e modificada pelos clientes, veja [aqui](https://eips.ethereum.org/EIPS/eip-1155#metadata). ### Regra de transferência segura {#safe-transfer-rule} Já abordamos algumas regras de transferência segura nas explicações anteriores. Mas vamos analisar as regras mais importantes: -1. O chamador deve ser aprovado para gastar os tokens para o endereço `_from` ou o chamador deve ser igual ao endereço `_from`. +1. O chamador deve ser aprovado para gastar os tokens do endereço `_from` ou o chamador deve ser igual a `_from`. 2. A chamada de transferência deve ser revertida caso - 1. o enderaço `_to` seja 0. - 2. o comprimento dos `_ids` não seja o mesmo que o comprimento dos `_values`. - 3. qualquer um do saldos dos titulares dos tokens em `_ids` seja menor que as respectivas quantidades em `_values` enviados para o destinatário. + 1. O endereço `_to` é 0. + 2. O comprimento de `_ids` não é o mesmo que o comprimento de `_values`. + 3. qualquer um dos saldos dos detentores de tokens em `_ids` for menor que as respectivas quantias em `_values` enviadas ao destinatário. 4. ocorra qualquer outro erro. -_Nota_: Todas as funções por lotes, incluindo o hook, também existem como versões sem lotes. Isto é feito para fins de eficiência do gás, já que é provável que a transferência de apenas um ativo continue sendo a maneira habitualmente mais utilizada. Por simplificar as explicações, as deixamos de lado, incluindo as regras de transferência segura. Os nomes são idênticos, basta eliminar a palavra "lote". +_Nota_: Todas as funções em lote, incluindo o hook, também existem como versões sem lote. Isto é feito para fins de eficiência do gás, já que é provável que a transferência de apenas um ativo continue sendo a maneira habitualmente mais utilizada. Por simplificar as explicações, as deixamos de lado, incluindo as regras de transferência segura. Os nomes são idênticos, basta eliminar a palavra "lote". ## Leitura adicional {#further-reading} -- [EIP-1155: Padrão Multi-Token](https://eips.ethereum.org/EIPS/eip-1155) -- [ERC-1155: Documentos da Openzeppelin](https://docs.openzeppelin.com/contracts/3.x/erc1155) -- [ERC-1155: Repositório no GitHub](https://github.com/enjin/erc-1155) -- [NFT API do Alchemy](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) +- [EIP-1155: Padrão de múltiplos tokens](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155: Documentos da OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/erc1155) +- [ERC-1155: Repositório do GitHub](https://github.com/enjin/erc-1155) +- [API de NFT da Alchemy](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1363/index.md new file mode 100644 index 00000000000..e99a0189080 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-1363/index.md @@ -0,0 +1,213 @@ +--- +title: "Padrão de Token Pagável ERC-1363" +description: "O ERC-1363 é uma interface de extensão para tokens ERC-20 que suporta a execução de lógica personalizada em um contrato receptor após transferências, ou em um contrato gastador após aprovações, tudo em uma única transação." +lang: pt-br +--- + +## Introdução {#introduction} + +### O que é ERC-1363? {#what-is-erc1363} + +O ERC-1363 é uma interface de extensão para tokens ERC-20 que suporta a execução de lógica personalizada em um contrato receptor após transferências, ou em um contrato gastador após aprovações, tudo em uma única transação. + +### Diferenças do ERC-20 {#erc20-differences} + +As operações padrão do ERC-20, como `transfer`, `transferFrom` e `approve`, não permitem a execução de código no contrato receptor ou gastador sem uma transação separada. +Isso introduz complexidade no desenvolvimento de UI e atrito na adoção, porque os usuários devem esperar a primeira transação ser executada para então enviar a segunda. +Eles também devem pagar GÁS duas vezes. + +O ERC-1363 torna os tokens fungíveis capazes de realizar ações com mais facilidade e funcionar sem o uso de qualquer ouvinte off-chain. +Ele permite fazer um callback em um contrato receptor ou gastador, após uma transferência ou aprovação, em uma única transação. + +## Pré-requisitos {#prerequisites} + +Para entender melhor esta página, recomendamos que primeiro leia sobre: + +- [Padrões de token](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## Body {#body} + +O ERC-1363 introduz uma API padrão para que os tokens ERC-20 interajam com contratos inteligentes após `transfer`, `transferFrom` ou `approve`. + +Este padrão fornece a funcionalidade básica para transferir tokens, bem como permite que os tokens sejam aprovados para que possam ser gastos por um terceiro on-chain, e em seguida, fazer um callback no contrato receptor ou gastador. + +Existem muitos usos propostos para contratos inteligentes que podem aceitar callbacks de ERC-20. + +Alguns exemplos são: + +- **Vendas coletivas**: os tokens enviados acionam a alocação instantânea de recompensas. +- **Serviços**: o pagamento ativa o acesso ao serviço em uma única etapa. +- **Faturas**: os tokens liquidam faturas automaticamente. +- **Assinaturas**: a aprovação da taxa anual ativa a assinatura com o pagamento do primeiro mês. + +Por essas razões, ele foi originalmente nomeado **"Payable Token"**. + +O comportamento de callback expande ainda mais sua utilidade, permitindo interações perfeitas como: + +- **Staking**: os tokens transferidos acionam o bloqueio automático em um contrato de staking. +- **Votação**: os tokens recebidos registram votos em um sistema de governança. +- **Troca**: aprovações de token ativam a lógica de troca em uma única etapa. + +Os tokens ERC-1363 podem ser usados para utilidades específicas em todos os casos que exigem a execução de um callback após o recebimento de uma transferência ou aprovação. +O ERC-1363 também é útil para evitar a perda ou o bloqueio de tokens em contratos inteligentes, verificando a capacidade do destinatário de lidar com os tokens. + +Diferentemente de outras propostas de extensão do ERC-20, o ERC-1363 não substitui os métodos `transfer` e `transferFrom` do ERC-20 e define os IDs das interfaces a serem implementadas, mantendo a retrocompatibilidade com o ERC-20. + +De [EIP-1363](https://eips.ethereum.org/EIPS/eip-1363): + +### Métodos {#methods} + +Os contratos inteligentes que implementam o padrão ERC-1363 **DEVEM** implementar todas as funções na interface `ERC1363`, bem como as interfaces `ERC20` e `ERC165`. + +```solidity +pragma solidity ^0.8.0; + +/** + * @title ERC1363 + * @dev Uma interface de extensão para tokens ERC-20 que suporta a execução de código em um contrato receptor + * após `transfer` ou `transferFrom`, ou código em um contrato gastador após `approve`, em uma única transação. + */ +interface ERC1363 is ERC20, ERC165 { + /* + * NOTA: o identificador ERC-165 para esta interface é 0xb0202a11. + * 0xb0202a11 === + * bytes4(keccak256('transferAndCall(address,uint256)')) ^ + * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) + */ + + /** + * @dev Move uma quantidade de tokens de `value` da conta do chamador para `to` + * e então chama `ERC1363Receiver::onTransferReceived` em `to`. + * @param to O endereço para o qual os tokens estão sendo transferidos. + * @param value A quantidade de tokens a serem transferidos. + * @return Um valor booleano que indica que a operação foi bem-sucedida, a menos que uma exceção seja lançada. + */ + function transferAndCall(address to, uint256 value) external returns (bool); + + /** + * @dev Move uma quantidade de tokens de `value` da conta do chamador para `to` + * e então chama `ERC1363Receiver::onTransferReceived` em `to`. + * @param to O endereço para o qual os tokens estão sendo transferidos. + * @param value A quantidade de tokens a serem transferidos. + * @param data Dados adicionais sem formato especificado, enviados na chamada para `to`. + * @return Um valor booleano que indica que a operação foi bem-sucedida, a menos que uma exceção seja lançada. + */ + function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev Move uma quantidade de tokens de `value` de `from` para `to` usando o mecanismo de permissão (allowance) + * e então chama `ERC1363Receiver::onTransferReceived` em `to`. + * @param from O endereço do qual os tokens são enviados. + * @param to O endereço para o qual os tokens estão sendo transferidos. + * @param value A quantidade de tokens a serem transferidos. + * @return Um valor booleano que indica que a operação foi bem-sucedida, a menos que uma exceção seja lançada. + */ + function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + + /** + * @dev Move uma quantidade de tokens de `value` de `from` para `to` usando o mecanismo de permissão (allowance) + * e então chama `ERC1363Receiver::onTransferReceived` em `to`. + * @param from O endereço do qual os tokens são enviados. + * @param to O endereço para o qual os tokens estão sendo transferidos. + * @param value A quantidade de tokens a serem transferidos. + * @param data Dados adicionais sem formato especificado, enviados na chamada para `to`. + * @return Um valor booleano que indica que a operação foi bem-sucedida, a menos que uma exceção seja lançada. + */ + function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev Define uma quantidade de tokens de `value` como a permissão (allowance) de `spender` sobre os tokens do chamador + * e então chama `ERC1363Spender::onApprovalReceived` em `spender`. + * @param spender O endereço que gastará os fundos. + * @param value A quantidade de tokens a serem gastos. + * @return Um valor booleano que indica que a operação foi bem-sucedida, a menos que uma exceção seja lançada. + */ + function approveAndCall(address spender, uint256 value) external returns (bool); + + /** + * @dev Define uma quantidade de tokens de `value` como a permissão (allowance) de `spender` sobre os tokens do chamador + * e então chama `ERC1363Spender::onApprovalReceived` em `spender`. + * @param spender O endereço que gastará os fundos. + * @param value A quantidade de tokens a serem gastos. + * @param data Dados adicionais sem formato especificado, enviados na chamada para `spender`. + * @return Um valor booleano que indica que a operação foi bem-sucedida, a menos que uma exceção seja lançada. + */ + function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); +} + +interface ERC20 { + event Transfer(address indexed from, address indexed to, uint256 value); + event Approval(address indexed owner, address indexed spender, uint256 value); + function transfer(address to, uint256 value) external returns (bool); + function transferFrom(address from, address to, uint256 value) external returns (bool); + function approve(address spender, uint256 value) external returns (bool); + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function allowance(address owner, address spender) external view returns (uint256); +} + +interface ERC165 { + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} +``` + +Um contrato inteligente que queira aceitar tokens ERC-1363 via `transferAndCall` ou `transferFromAndCall` **DEVE** implementar a interface `ERC1363Receiver`: + +```solidity +/** + * @title ERC1363Receiver + * @dev Interface para qualquer contrato que queira suportar `transferAndCall` ou `transferFromAndCall` de contratos de token ERC-1363. + */ +interface ERC1363Receiver { + /** + * @dev Sempre que tokens ERC-1363 são transferidos para este contrato via `ERC1363::transferAndCall` ou `ERC1363::transferFromAndCall` + * por `operator` de `from`, esta função é chamada. + * + * NOTA: Para aceitar a transferência, esta função deve retornar + * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` + * (ou seja, 0x88a7ca5c, ou seu próprio seletor de função). + * + * @param operator O endereço que chamou a função `transferAndCall` ou `transferFromAndCall`. + * @param from O endereço do qual os tokens são transferidos. + * @param value A quantidade de tokens transferidos. + * @param data Dados adicionais sem formato especificado. + * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` se a transferência for permitida, a menos que uma exceção seja lançada. + */ + function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +Um contrato inteligente que queira aceitar tokens ERC-1363 via `approveAndCall` **DEVE** implementar a interface `ERC1363Spender`: + +```solidity +/** + * @title ERC1363Spender + * @dev Interface para qualquer contrato que queira dar suporte a `approveAndCall` de contratos de token ERC-1363. + */ +interface ERC1363Spender { + /** + * @dev Sempre que o `owner` (dono) de um token ERC-1363 aprova este contrato via `ERC1363::approveAndCall` + * para gastar seus tokens, esta função é chamada. + * + * NOTA: Para aceitar a aprovação, esta função deve retornar + * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` + * (ou seja, 0x7b04a2d0, ou seu próprio seletor de função). + * + * @param owner O endereço que chamou a função `approveAndCall` e que anteriormente possuía os tokens. + * @param value A quantidade de tokens a ser gasta. + * @param data Dados adicionais sem formato especificado. + * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` se a aprovação for permitida, a menos que uma exceção seja lançada. + */ + function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +## Leitura adicional {#further-reading} + +- [ERC-1363: Padrão de Token Pagável](https://eips.ethereum.org/EIPS/eip-1363) +- [ERC-1363: Repositório no GitHub](https://github.com/vittominacori/erc1363-payable-token) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-20/index.md index a48379944e5..3ebb162e486 100644 --- a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-20/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-20/index.md @@ -1,6 +1,6 @@ --- -title: Padrão de token ERC-20 -description: Token +title: "Padrão de token ERC-20" +description: "Aprenda sobre ERC-20, o padrão para tokens fungiveis em Ethereum que permite aplicações de token interoperáveis." lang: pt-br --- @@ -12,27 +12,28 @@ Um token podem representar praticamente qualquer coisa em Ethereum: - pontos de reputação em uma plataforma online - habilidades de um personagem em um jogo -- bilhetes de loteria - ativos financeiros, como a ação em uma empresa - uma moeda fiduciária, como USD - 28,3 gr de ouro - e mais... -Uma característica tão poderosa do Ethereum deve ser tratada por um padrão robusto, certo? É aí que o ERC-20 entra! Este padrão permite que desenvolvedores criem aplicativos de token que são interoperáveis com outros produtos e serviços. +Uma característica tão poderosa do Ethereum deve ser tratada por um padrão robusto, certo? É aí que o ERC-20 entra! Este padrão permite que desenvolvedores criem aplicativos de token que são interoperáveis com outros produtos e serviços. O padrão ERC-20 também é usado para fornecer funcionalidade adicional ao [ether](/glossary/#ether). **O que é ERC-20?** -O ERC-20 introduz um padrão para os tokens fungíveis, ou seja, eles têm uma propriedade que faz com que cada token tenha exatamente o mesmo de outro token (em termos de tipo e valor). Por exemplo, um token ERC-20 age como o ETH, significando que 1 token é e será sempre igual a todos os outros tokens. +O ERC-20 introduz um padrão para os tokens fungíveis, ou seja, eles têm uma propriedade que faz com que cada token tenha exatamente o mesmo de outro token (em termos de tipo e valor). Por exemplo, um token ERC-20 age como o ETH, significando que 1 token +é e será sempre igual a todos os outros tokens. ## Pré-requisitos {#prerequisites} - [Contas](/developers/docs/accounts) -- [Contratos Inteligentes](/developers/docs/smart-contracts/) +- [Contratos inteligentes](/developers/docs/smart-contracts/) - [Padrões de token](/developers/docs/standards/tokens/) -## Apresentação {#body} +## Body {#body} -O ERC-20 (Ethereum Request for Comments 20), proposto por Fabian Vogelsteller em novembro de 2015, é um padrão de token que implementa uma API para tokens em contratos inteligentes. +O ERC-20 (Ethereum Request for Comments 20), proposto por Fabian Vogelsteller em novembro de 2015, é um padrão de token que +implementa uma API para tokens em contratos inteligentes. Exemplo de funcionalidades que o ERC-20 fornece: @@ -68,11 +69,13 @@ event Approval(address indexed _owner, address indexed _spender, uint256 _value) ### Exemplos {#web3py-example} -Vejamos por que um padrão é importante e como ele simplifica o controle de qualquer contrato de token ERC-20 no Ethereum. Só precisamos da Interface Binária de Aplicativos (ABI, pela sigla em inglês) do contrato para criar uma interface com qualquer token ERC-20. Como você pode ver abaixo, usaremos uma ABI simplificada, para torná-la um exemplo de fácil compreensão. +Vejamos por que um padrão é importante e como ele simplifica o controle de qualquer contrato de token ERC-20 no Ethereum. +Só precisamos da Interface Binária de Aplicativos (ABI, pela sigla em inglês) do contrato para criar uma interface com qualquer token ERC-20. Como você pode +ver abaixo, usaremos uma ABI simplificada, para torná-la um exemplo de fácil compreensão. -#### Exemplo para a Web3.py {#web3py-example} +#### Exemplo de Web3.py {#web3py-example} -Primeiro, certifique-se de que você instalou a biblioteca [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) do Python: +Primeiro, certifique-se de que você instalou a biblioteca Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation): ``` pip install web3 @@ -85,12 +88,12 @@ from web3 import Web3 w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI -weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH) +weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Ether encapsulado (WETH) acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 -# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract. -# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() +# Esta é uma Interface Binária de Aplicação (ABI) de Contrato simplificada de um Contrato de Token ERC-20. +# Ela irá expor apenas os métodos: balanceOf(address), decimals(), symbol() e totalSupply() simplified_abi = [ { 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], @@ -126,8 +129,8 @@ addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decima # DAI print("===== %s =====" % symbol) -print("Total Supply:", totalSupply) -print("Addr Balance:", addr_balance) +print("Fornecimento Total:", totalSupply) +print("Saldo do Endereço:", addr_balance) weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) symbol = weth_contract.functions.symbol().call() @@ -137,13 +140,50 @@ addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decim # WETH print("===== %s =====" % symbol) -print("Total Supply:", totalSupply) -print("Addr Balance:", addr_balance) +print("Fornecimento Total:", totalSupply) +print("Saldo do Endereço:", addr_balance) ``` +## Problemas conhecidos {#erc20-issues} + +### Problema de recebimento de token ERC-20 {#reception-issue} + +**Em 20/06/2024, pelo menos US$ 83.656.418 em tokens ERC-20 foram perdidos devido a esse problema. Observe que uma implementação ERC-20 pura está propensa a esse problema, a menos que você implemente um conjunto de restrições adicionais além do padrão, conforme listado abaixo.** + +Quando tokens ERC-20 são enviados para um contrato inteligente que não foi projetado para lidar com tokens ERC-20, esses tokens podem ser permanentemente perdidos. Isso acontece porque o contrato receptor não possui a funcionalidade para reconhecer ou responder aos tokens recebidos, e não há um mecanismo no padrão ERC-20 para notificar o contrato receptor sobre os tokens recebidos. As principais formas pelas quais esse problema se manifesta são: + +1. Mecanismo de transferência de tokens + +- Os tokens ERC-20 são transferidos usando as funções transfer ou transferFrom + - Quando um usuário envia tokens para um endereço de contrato usando essas funções, os tokens são transferidos independentemente de o contrato receptor estar ou não projetado para manipulá-los + +2. Falta de notificação + - O contrato receptor não recebe uma notificação ou retorno de chamada de que os tokens foram enviados a ele + - Se o contrato de recebimento não tiver um mecanismo para lidar com tokens (por exemplo, uma função de fallback ou uma função dedicada para gerenciar a recepção de tokens), os tokens ficarão efetivamente presos no endereço do contrato +3. Sem manuseio integrado + - O padrão ERC-20 não inclui uma função obrigatória para receber contratos a serem implementados, levando a uma situação em que muitos contratos não conseguem gerenciar os tokens recebidos adequadamente + +**Possíveis Soluções** + +Embora não seja possível evitar completamente esse problema com o ERC-20, existem métodos que permitiriam reduzir significativamente a possibilidade de perda de tokens para o usuário final: + +- O problema mais comum é quando um usuário envia tokens para o próprio endereço do contrato do token (por exemplo, USDT depositado no endereço do contrato do token USDT). É recomendável restringir a função `transfer(..)` para reverter tais tentativas de transferência. Considere adicionar a verificação `require(_to != address(this));` na implementação da função `transfer(..)`. +- A função `transfer(..)` em geral não foi projetada para depositar tokens em contratos. O padrão `approve(..) & transferFrom(..)` é usado, em vez disso, para depositar tokens ERC-20 em contratos. É possível restringir a função de transferência para não permitir o depósito de tokens em quaisquer contratos com ela, no entanto, isso pode quebrar a compatibilidade com contratos que assumem que os tokens podem ser depositados em contratos com a função `trasnfer(..)` (por exemplo, pools de liquidez Uniswap). +- Sempre presuma que tokens ERC-20 podem acabar no seu contrato, mesmo que seu contrato nunca deva recebê-los. Não há como evitar ou rejeitar depósitos acidentais por parte dos destinatários. É recomendável implementar uma função que permita extrair tokens ERC-20 depositados acidentalmente. +- Considere usar padrões de token alternativos. + +Alguns padrões alternativos surgiram desse problema, como o [ERC-223](/developers/docs/standards/tokens/erc-223) ou o [ERC-1363](/developers/docs/standards/tokens/erc-1363). + ## Leitura adicional {#further-reading} -- [EIP-20: Padrão de token ERC-20](https://eips.ethereum.org/EIPS/eip-20) -- [OpenZeppelin: Tokens](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) -- [OpenZeppelin: Implementação ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) -- [Alchemy — Guia para os Tokens ERC20 do Solidity](https://www.alchemy.com/overviews/erc20-solidity) +- [EIP-20: Padrão de Token ERC-20](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin - Tokens](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin - Implementação do ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy - Guia para Tokens ERC20 em Solidity](https://www.alchemy.com/overviews/erc20-solidity) + +## Outros padrões de tokens fungíveis {#fungible-token-standards} + +- [ERC-223](/developers/docs/standards/tokens/erc-223) +- [ERC-1363](/developers/docs/standards/tokens/erc-1363) +- [ERC-777](/developers/docs/standards/tokens/erc-777) +- [ERC-4626 - Vaults tokenizados](/developers/docs/standards/tokens/erc-4626) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-223/index.md new file mode 100644 index 00000000000..1c453a4d1a6 --- /dev/null +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-223/index.md @@ -0,0 +1,198 @@ +--- +title: "Padrão de token ERC-223" +description: "Uma visão geral do padrão de token fungível ERC-223, como ele funciona e uma comparação com o ERC-20." +lang: pt-br +--- + +## Introdução {#introduction} + +### O que é ERC-223? {#what-is-erc223} + +O ERC-223 é um padrão para tokens fungíveis, semelhante ao padrão ERC-20. A principal diferença é que o ERC-223 define não apenas a API do token, mas também a lógica para transferir tokens do remetente para o destinatário. Ele introduz um modelo de comunicação que permite que transferências de tokens sejam manipuladas pelo lado do destinatário. + +### Diferenças do ERC-20 {#erc20-differences} + +O ERC-223 aborda algumas limitações do ERC-20 e introduz um novo método de interação entre o contrato de token e um contrato que pode receber os tokens. Há poucas coisas que são possíveis com ERC-223, mas não com ERC-20: + +- Tratamento de transferência de tokens no lado do destinatário: os destinatários podem detectar que um token ERC-223 está sendo depositado. +- Rejeição de tokens enviados incorretamente: se um usuário enviar tokens ERC-223 para um contrato que não deveria receber tokens, o contrato poderá rejeitar a transação, evitando a perda de tokens. +- Metadados em transferências: tokens ERC-223 podem incluir metadados, permitindo que informações arbitrárias sejam anexadas às transações de tokens. + +## Pré-requisitos {#prerequisites} + +- [Contas](/developers/docs/accounts) +- [Contratos inteligentes](/developers/docs/smart-contracts/) +- [Padrões de token](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## Body {#body} + +ERC-223 é um padrão de token que implementa uma API para tokens dentro de contratos inteligentes. Ele também declara uma API para contratos que devem receber tokens ERC-223. Contratos que não suportam a API do Receptor ERC-223 não podem receber tokens ERC-223, evitando erros do usuário. + +Se um contrato inteligente implementar os seguintes métodos e eventos, ele poderá ser chamado de contrato de token compatível com ERC-223. Uma vez implantado, ele +será responsável por manter o controle dos tokens criados no Ethereum. + +O contrato não é obrigado a ter apenas essas funções e um desenvolvedor pode adicionar qualquer outro recurso de diferentes padrões de token a este contrato. Por exemplo, as funções `approve` e `transferFrom` não fazem parte do padrão ERC-223, mas essas funções podem ser implementadas caso seja necessário. + +De [EIP-223](https://eips.ethereum.org/EIPS/eip-223): + +### Métodos {#methods} + +O token ERC-223 deve implementar os seguintes métodos: + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) +``` + +Um contrato que deve receber tokens ERC-223 deve implementar o seguinte método: + +```solidity +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` + +Se os tokens ERC-223 forem enviados para um contrato que não implementa a função `tokenReceived(..)`, a transferência deverá falhar e os tokens não deverão ser movidos do saldo do remetente. + +### Eventos {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) +``` + +### Exemplos {#examples} + +A API do token ERC-223 é semelhante à do ERC-20, portanto, do ponto de vista do desenvolvimento da interface do usuário, não há diferença. A única exceção aqui é que os tokens ERC-223 não podem ter as funções `approve` + `transferFrom`, pois elas são opcionais para este padrão. + +#### Exemplos de Solidity {#solidity-example} + +O exemplo a seguir ilustra como um contrato básico de token ERC-223 opera: + +```solidity +pragma solidity ^0.8.19; +abstract contract IERC223Recipient { + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} +contract VeryBasicERC223Token { + event Transfer(address indexed from, address indexed to, uint value, bytes data); + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + mapping(address => uint256) private balances; + function name() public view returns (string memory) { return _name; } + function symbol() public view returns (string memory) {return _symbol; } + function decimals() public view returns (uint8) { return _decimals; } + function totalSupply() public view returns (uint256) { return _totalSupply; } + function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } + function isContract(address account) internal view returns (bool) { + uint256 size; + assembly { size := extcodesize(account) } + return size > 0; + } + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value, _data); + return true; + } + function transfer(address _to, uint _value) public returns (bool success){ + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value, _empty); + return true; + } +} +``` + +Agora queremos que outro contrato aceite depósitos de `tokenA`, assumindo que o tokenA é um token ERC-223. O contrato deve aceitar apenas o tokenA e rejeitar quaisquer outros tokens. Quando o contrato recebe o tokenA, ele deve emitir um evento `Deposit()` e aumentar o valor da variável interna `deposits`. + +Aqui está o código: + +```solidity +contract RecipientContract is IERC223Recipient { + event Deposit(address whoSentTheTokens); + uint256 deposits = 0; + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + // It is important to understand that within this function + // msg.sender is the address of a token that is being received, + // msg.value is always 0 as the token contract does not own or send ether in most cases, + // _from is the sender of the token transfer, + // _value is the amount of tokens that was deposited. + require(msg.sender == tokenA); + deposits += _value; + emit Deposit(_from); + } +} +``` + +## Perguntas mais frequentes {#faq} + +### O que acontecerá se enviarmos algum tokenB para o contrato? {#sending-tokens} + +A transação falhará e a transferência de tokens não acontecerá. Os tokens serão devolvidos ao endereço do remetente. + +### Como podemos fazer um depósito neste contrato? {#contract-deposits} + +Chame a função `transfer(address,uint256)` ou `transfer(address,uint256,bytes)` do token ERC-223, especificando o endereço do `RecipientContract`. + +### O que acontecerá se transferirmos um token ERC-20 para este contrato? {#erc-20-transfers} + +Se um token ERC-20 for enviado para o `RecipientContract`, os tokens serão transferidos, mas a transferência não será reconhecida (nenhum evento `Deposit()` será disparado e o valor dos depósitos não será alterado). Depósitos indesejados de ERC-20 não podem ser filtrados ou evitados. + +### E se quisermos executar alguma função após a conclusão do depósito do token? {#function-execution} + +Há várias maneiras de fazer isso. Neste exemplo, seguiremos o método que torna as transferências ERC-223 idênticas às transferências de ether: + +```solidity +contract RecipientContract is IERC223Recipient { + event Foo(); + event Bar(uint256 someNumber); + address tokenA; // O único token que queremos aceitar. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + require(msg.sender == tokenA); + address(this).call(_data); // Manipular a transação recebida e executar uma chamada de função subsequente. + } + function foo() public + { + emit Foo(); + } + function bar(uint256 _someNumber) public + { + emit Bar(_someNumber); + } +} +``` + +Quando o `RecipientContract` receber token de acordo à ERC-223 o contrato executará uma função codificada como parâmetro `_data` da transação do token, idêntico a como transações ether codificam chamadas de função como `data` da transação. Leia [o campo de dados](/developers/docs/transactions/#the-data-field) para obter mais informações. + +No exemplo acima, um token ERC-223 deve ser transferido para o endereço do `RecipientContract` com a função `transfer(address,uin256,bytes calldata _data)`. Se o parâmetro de dados for `0xc2985578` (a assinatura de uma função `foo()`), então a função foo() será invocada após o depósito do token ser recebido e o evento Foo() será disparado. + +Os parâmetros também podem ser codificados nos `data` da transferência do token, por exemplo, podemos chamar a função bar() com o valor 12345 para `_someNumber`. Neste caso, o `data` deve ser `0x0423a13200000000000000000000000000000000000000000000000000000000000000000000004d2` onde `0x0423a132` é a assinatura da função `bar(uint256)` e `000000000000000000000000000000000000000000000000000000000000000000000004d2` é 12345 como uint256. + +## Limitações {#limitations} + +Embora o ERC-223 aborde vários problemas encontrados no padrão ERC-20, ele não está isento de limitações: + +- Adoção e compatibilidade: o ERC-223 ainda não foi amplamente adotado, o que pode limitar sua compatibilidade com ferramentas e plataformas existentes. +- Compatibilidade com versões anteriores: O ERC-223 não é compatível com versões anteriores do ERC-20, o que significa que os contratos e ferramentas ERC-20 existentes não funcionarão com tokens ERC-223 sem modificações. +- Custos de gás: as verificações e funcionalidades adicionais nas transferências ERC-223 podem resultar em custos de gás mais altos em comparação às transações ERC-20. + +## Leitura adicional {#further-reading} + +- [EIP-223: Padrão de Token ERC-223](https://eips.ethereum.org/EIPS/eip-223) +- [Proposta inicial ERC-223](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-4626/index.md index 371ffca8180..bf2786d15bb 100644 --- a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-4626/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-4626/index.md @@ -1,6 +1,6 @@ --- -title: Padrão de cofre tokenizado ERC-4626 -description: Um padrão para os cofres de rendimento. +title: "Padrão de cofre tokenizado ERC-4626" +description: "Um padrão para os cofres de rendimento." lang: pt-br --- @@ -14,20 +14,36 @@ Mercados de empréstimo, agregadores e tokens intrinsecamente de rendimento ajud O ERC-4626 nos cofres de rendimento reduzirá o esforço de integração e desbloqueará o acesso a rendimentos em várias aplicações, com pouco esforço especializado dos desenvolvedores, criando padrões de implementação mais consistentes e robustos. -O token ERC-4626 é descrito em mais detalhes em [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626). +O token ERC-4626 é descrito por completo em [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626). + +**Extensão assíncrona de cofre (ERC-7540)** + +O ERC-4626 é otimizado para depósitos e resgates atômicos até um limite. Se o limite for atingido, nenhum novo depósito ou resgate poderá ser enviado. Essa limitação não funciona bem para qualquer sistema de contrato inteligente com ações assíncronas ou atrasos como pré-requisito para interagir com o Cofre (por exemplo, protocolos de ativos do mundo real, protocolos de empréstimos subcolateralizados, protocolos de empréstimos cross-chain, tokens de staking líquido ou módulos de segurança de seguro). + +O ERC-7540 amplia a utilidade dos cofres ERC-4626 para casos de uso assíncronos. A interface de Cofre existente (`deposit`/`withdraw`/`mint`/`redeem`) é totalmente utilizada para reivindicar Solicitações assíncronas. + +A extensão ERC-7540 é descrita por completo em [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540). + +**Extensão de cofre multiativo (ERC-7575)** + +Um caso de uso ausente que não é suportado pelo ERC-4626 são cofres que possuem múltiplos ativos ou pontos de entrada, como tokens de provedor de liquidez (LP tokens). Esses casos geralmente são difíceis de manejar ou não compatíveis devido ao requisito de que o ERC-4626 seja, por si só, um ERC-20. + +O ERC-7575 adiciona suporte a cofres com múltiplos ativos ao externalizar a implementação do token ERC-20 da implementação do ERC-4626. + +A extensão ERC-7575 é descrita por completo em [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575). ## Pré-requisitos {#prerequisites} -Para entender melhor esta página, recomendamos que você leia primeiro sobre [padrões de tokens](/developers/docs/standards/tokens/) e [ERC-20](/developers/docs/standards/tokens/erc-20/). +Para entender melhor esta página, recomendamos que você leia primeiro sobre [padrões de token](/developers/docs/standards/tokens/) e [ERC-20](/developers/docs/standards/tokens/erc-20/). -## Funções e características do ERC-4626: {#body} +## Funções e recursos do ERC-4626: {#body} ### Métodos {#methods} #### asset {#asset} ```solidity -function asset() public view returns (address) +function asset() public view returns (address assetTokenAddress) ``` Esta função retorna o endereço do token subjacente usado para o cofre para contabilidade, depósito, retirada. @@ -46,7 +62,7 @@ Esta função retorna a quantidade total de ativos subjacentes mantidos pelo cof function convertToShares(uint256 assets) public view returns (uint256 shares) ``` -Esta função retorna a quantidade de `shares` que seriam intercambiadas pelo cofre pela quantidade de `assets` fornecidos. +Esta função retorna a quantidade de `shares` que seriam trocadas pelo cofre pela quantidade de `assets` fornecida. #### convertToAssets {#convertoassets} @@ -54,92 +70,92 @@ Esta função retorna a quantidade de `shares` que seriam intercambiadas pelo co function convertToAssets(uint256 shares) public view returns (uint256 assets) ``` -Esta função retorna a quantidade de `assets` que seriam intercambiadas pelo cofre pela quantidade de `shares` fornecidos. +Esta função retorna a quantidade de `assets` que seriam trocados pelo cofre pela quantidade de `shares` fornecida. #### maxDeposit {#maxdeposit} ```solidity -function maxDeposit(address receiver) public view returns (uint256) +function maxDeposit(address receiver) public view returns (uint256 maxAssets) ``` -Esta função retorna a quantidade máxima de ativos subjacentes que podem ser depositados em um único [`deposit`](#deposit) chamado pelo `receiver`. +Esta função retorna a quantidade máxima de ativos subjacentes que podem ser depositados em uma única chamada de [`deposit`](#deposit), com as shares mintadas para o `receiver`. #### previewDeposit {#previewdeposit} ```solidity -function previewDeposit(uint256 assets) public view returns (uint256) +function previewDeposit(uint256 assets) public view returns (uint256 shares) ``` Esta função permite aos usuários simular os efeitos de seu depósito no bloco atual. -#### depositar {#deposit} +#### deposit {#deposit} ```solidity function deposit(uint256 assets, address receiver) public returns (uint256 shares) ``` -Esta função deposita `assets` de tokens subjacentes no cofre e concede a propriedade de `shares` para o `receiver`. +Esta função deposita `assets` de tokens subjacentes no cofre e concede a propriedade de `shares` ao `receiver`. #### maxMint {#maxmint} ```solidity -function maxMint(address receiver) public view returns (uint256) +function maxMint(address receiver) public view returns (uint256 maxShares) ``` -Esta função retorna a quantidade máxima de ativos subjacentes que podem ser mintados em um único [`mint`](#mint) chamado pelo `receiver`. +Esta função retorna a quantidade máxima de shares que podem ser mintadas em uma única chamada de [`mint`](#mint), com as shares mintadas para o `receiver`. #### previewMint {#previewmint} ```solidity -function previewMint(uint256 shares) public view returns (uint256) +function previewMint(uint256 shares) public view returns (uint256 assets) ``` Esta função permite aos usuários simular os efeitos de seu mint no bloco atual. -#### cunhar {#mint} +#### mint {#mint} ```solidity function mint(uint256 shares, address receiver) public returns (uint256 assets) ``` -Esta função minta exatamente `shares` no cofre para o `receiver` depositando `assets` dos tokens subjacentes. +Esta função minta exatamente `shares` de cofre para o `receiver`, depositando `assets` de tokens subjacentes. #### maxWithdraw {#maxwithdraw} ```solidity -function maxWithdraw(address owner) public view returns (uint256) +function maxWithdraw(address owner) public view returns (uint256 maxAssets) ``` -Esta função retorna a quantidade máxima de ativos subjacentes que podem ser retirados do saldo do `owner` com uma única chamada [`withdraw`](#withdraw). +Esta função retorna a quantidade máxima de ativos subjacentes que podem ser sacados do saldo do `owner` com uma única chamada de [`withdraw`](#withdraw). #### previewWithdraw {#previewwithdraw} ```solidity -function previewWithdraw(uint256 assets) public view returns (uint256) +function previewWithdraw(uint256 assets) public view returns (uint256 shares) ``` Esta função permite aos usuários simular os efeitos da sua retirada no bloco atual. -#### sacar {#withdraw} +#### withdraw {#withdraw} ```solidity function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) ``` -Esta função queima `shares` do `owner` e envia exatamente tokens `assets` do cofre para o `receiver`. +Esta função queima `shares` do `owner` e envia exatamente `assets` de token do cofre para o `receiver`. #### maxRedeem {#maxredeem} ```solidity -function maxRedeem(address owner) public view returns (uint256) +function maxRedeem(address owner) public view returns (uint256 maxShares) ``` -Essa função retorna a quantidade máxima de ações que podem ser resgatadas do saldo do `owner` com uma chamada de [`redeem`](#redeem). +Esta função retorna a quantidade máxima de shares que podem ser resgatadas do saldo do `owner` por meio de uma chamada de [`redeem`](#redeem). #### previewRedeem {#previewredeem} ```solidity -function previewRedeem(uint256 shares) public view returns (uint256) +function previewRedeem(uint256 shares) public view returns (uint256 assets) ``` Essa função permite aos usuários simular os efeitos de seu resgate no bloco atual. @@ -150,7 +166,7 @@ Essa função permite aos usuários simular os efeitos de seu resgate no bloco a function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) ``` -Essa função resgata um número específico de `shares` do `owner` e envia `assets` do token subjacente do cofre para o `receiver`. +Esta função resgata um número específico de `shares` do `owner` e envia `assets` do token subjacente do cofre para o `receiver`. #### totalSupply {#totalsupply} @@ -166,13 +182,17 @@ Retorna o número total de shares não resgatadas do cofre em circulação. function balanceOf(address owner) public view returns (uint256) ``` -Retorna a quantidade total de shares do cofre que o `owner` tem atualmente. +Retorna a quantidade total de shares do cofre que o `owner` possui atualmente. + +### Mapa da interface {#mapOfTheInterface} + +![Mapa da interface ERC-4626](./map-of-erc-4626.png) ### Eventos {#events} #### Evento de depósito -**PRECISA** ser emitido quando os tokens são depositados no cofre por meio dos métodos [`mint`](#mint) e [`deposit`](#deposit) +**DEVE** ser emitido quando tokens são depositados no cofre através dos métodos [`mint`](#mint) e [`deposit`](#deposit). ```solidity event Deposit( @@ -183,11 +203,11 @@ event Deposit( ) ``` -Em que `sender` é o usuário que trocou `assets` por `shares` e transferiu aquelas `shares` para o `owner`. +Onde `sender` é o usuário que trocou `assets` por `shares` e transferiu essas `shares` para o `owner`. #### Evento de retirada -**PRECISA** ser emitido quando as shares são retiradas do cofre por um depositante nos métodos de [`redeem`](#redeem) ou [`withdraw`](#withdraw). +**DEVE** ser emitido quando shares são sacadas do cofre por um depositante nos métodos [`redeem`](#redeem) ou [`withdraw`](#withdraw). ```solidity event Withdraw( @@ -195,13 +215,13 @@ event Withdraw( address indexed receiver, address indexed owner, uint256 assets, - uint256 share + uint256 shares ) ``` -Em que `sender` é o usuário que acionou a retirada e trocou `shares`, de propriedade do `owner`, por `assets`. `receiver` é o usuário que recebeu os `assets ` retirados. +Onde `sender` é o usuário que acionou o saque e trocou `shares`, de propriedade do `owner`, por `assets`. `receiver` é o usuário que recebeu os `assets` sacados. ## Leitura adicional {#further-reading} -- [EIP-4626: Padrão do cofre tokenizado](https://eips.ethereum.org/EIPS/eip-4626) -- [ERC-4626: GitHub Repo](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) +- [EIP-4626: Padrão de Cofre Tokenizado](https://eips.ethereum.org/EIPS/eip-4626) +- [ERC-4626: Repositório no GitHub](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-721/index.md index 57648ada626..13b5e56f174 100644 --- a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-721/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-721/index.md @@ -1,32 +1,42 @@ --- -title: ERC-721 Padrão de token não-fungível -description: Token +title: "ERC-721 Padrão de token não-fungível" +description: "Conheça sobre ERC-721, o padrão para tokens não substituíveis (NFTs) que representam um único Ethereum digital." lang: pt-br --- ## Introdução {#introduction} -**O que é um token não fungível (NFT)?** +**O que é um Token Não Fungível?** -Um token não fungível (NFT) é utilizado para identificar algo ou alguém de uma forma única. Este tipo de token é perfeito para ser usado em plataformas que oferecem itens colecionáveis, acessar chaves, bilhetes de loteria, assentos numerados para concertos, jogos esportivos etc. Este tipo especial de token tem possibilidades incríveis, então merece um padrão adequado, o ERC-721! +Um token não fungível (NFT) é utilizado para identificar algo ou alguém de uma forma única. Este tipo de token é perfeito para ser +usado em plataformas que oferecem itens colecionáveis, acessar chaves, bilhetes de loteria, assentos numerados para concertos, +jogos esportivos etc. Este tipo especial de token tem possibilidades incríveis, então merece um padrão adequado, o ERC-721! **O que é ERC-721?** -O ERC-721 apresenta um padrão para NFT. Em outras palavras, este tipo de token é único e pode ter um valor diferente do que outro token do mesmo contrato inteligente, talvez devido a sua validade, raridade ou mesmo sua aparência. Um momento, aparência? +O ERC-721 apresenta um padrão para NFT. Em outras palavras, este tipo de token é único e pode ter um valor diferente +do que outro token do mesmo contrato inteligente, talvez devido a sua validade, raridade ou mesmo sua aparência. +Um momento, aparência? -Sim! Todos os NFTs têm uma variável `uint256` chamada `tokenId`, então para qualquer contrato ERC-721, o par `contract address, uint256 tokenId` deve ser globalmente único. Dito isso, um dApp pode ter um "conversor" que usa o `tokenId` como entrada e retorna uma imagem de algo legal, como zumbis, armas, habilidades ou gatinhos incríveis! +Sim! Todos os NFTs têm uma variável `uint256` chamada `tokenId`, então, para qualquer Contrato ERC-721, o par +`contract address, uint256 tokenId` deve ser globalmente único. Dito isso, um dapp pode ter um "conversor" que +usa o `tokenId` como entrada e produz uma imagem de algo legal, como zumbis, armas, habilidades ou gatinhos incríveis! ## Pré-requisitos {#prerequisites} - [Contas](/developers/docs/accounts/) -- [Contratos Inteligentes](/developers/docs/smart-contracts/) +- [Contratos inteligentes](/developers/docs/smart-contracts/) - [Padrões de token](/developers/docs/standards/tokens/) -## Apresentação {#body} +## Body {#body} -O ERC-721(Ethereum Request for Comments 721), proposto por William Entriken, Dieter Shirley, Jacob Evans e Nastassia Sachs em janeiro de 2018, é um padrão de token não-fungível que implementa uma API para tokens em contratos inteligentes. +O ERC-721(Ethereum Request for Comments 721), proposto por William Entriken, Dieter Shirley, Jacob Evans e +Nastassia Sachs em janeiro de 2018, é um padrão de token não-fungível que implementa uma API para tokens em contratos inteligentes. -Oferece funcionalidades, como transferir tokens de uma conta para outra, para obter o saldo atual do token de uma conta e também a oferta total do token disponível na rede. Além disso, ele também tem algumas outras funcionalidades como aprovar que uma quantidade de token de uma conta pode ser gasta por uma conta de terceiros. +Oferece funcionalidades, como transferir tokens de uma conta para outra, para obter o saldo atual do token de uma conta +e também a oferta total do token disponível na rede. +Além disso, ele também tem algumas outras funcionalidades +como aprovar que uma quantidade de token de uma conta pode ser gasta por uma conta de terceiros. Se um contrato inteligente implementa os métodos e eventos a seguir, ele pode ser chamado de Contrato de token ERC-721 e, uma vez implantado, é responsável por fazer um acompanhamento dos tokens criados no Ethereum. @@ -56,11 +66,13 @@ De [EIP-721](https://eips.ethereum.org/EIPS/eip-721): ### Exemplos {#web3py-example} -Vejamos por que um padrão é importante e como ele simplifica o controle de qualquer contrato de token ERC-721 no Ethereum. Só precisamos da Interface Binária de Aplicativos (ABI, pela sigla em inglês) do contrato para criar uma interface com qualquer token ERC-721. Como você pode ver abaixo, usaremos uma ABI simplificada, para torná-la um exemplo de fácil compreensão. +Vejamos por que um padrão é importante e como ele simplifica o controle de qualquer contrato de token ERC-721 no Ethereum. +Só precisamos da Interface Binária de Aplicativos (ABI, pela sigla em inglês) do contrato para criar uma interface com qualquer token ERC-721. Como você pode +ver abaixo, usaremos uma ABI simplificada, para torná-la um exemplo de fácil compreensão. -#### Exemplo Web3.py {#web3py-example} +#### Exemplo de Web3.py {#web3py-example} -Primeiro, certifique-se de que você instalou a [biblioteca Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) do Python: +Primeiro, certifique-se de que você instalou a biblioteca Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation): ``` pip install web3 @@ -73,12 +85,12 @@ from web3._utils.events import get_event_data w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) -ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract +ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # Contrato CryptoKitties -acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction +acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # Leilão de Vendas CryptoKitties -# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract. -# Serão expostos apenas os métodos: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() +# Esta é uma Interface Binária de Aplicação de Contrato (ABI) simplificada de um Contrato de NFT ERC-721. +# Ela exporá apenas os métodos: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() simplified_abi = [ { 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], @@ -127,16 +139,16 @@ ck_extra_abi = [ } ] -ck_contract = w3.eth.contract(address=w3.toChecksumAddress(ck_token_addr), abi=simplified_abi+ck_extra_abi) +ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) name = ck_contract.functions.name().call() symbol = ck_contract.functions.symbol().call() kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() -print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") +print(f"{name} [{symbol}] NFTs em leilões: {kitties_auctions}") pregnant_kitties = ck_contract.functions.pregnantKitties().call() -print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") +print(f"{name} [{symbol}] NFTs grávidos: {pregnant_kitties}") -# Usando o Evento de Transferência ABI para obter informações sobre os Kitties transferidos. +# Usando o ABI do Evento de Transferência para obter informações sobre os Kitties transferidos. tx_event_abi = { 'anonymous': False, 'inputs': [ @@ -147,34 +159,34 @@ tx_event_abi = { 'type': 'event' } -# We need the event's signature to filter the logs -event_signature = w3.sha3(text="Transfer(address,address,uint256)").hex() +# Precisamos da assinatura do evento para filtrar os logs +event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() -logs = w3.eth.getLogs({ - "fromBlock": w3.eth.blockNumber - 120, - "address": w3.toChecksumAddress(ck_token_addr), +logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), "topics": [event_signature] }) -# Notes: -# - 120 blocks is the max range for CloudFlare Provider -# - If you didn't find any Transfer event you can also try to get a tokenId at: +# Observações: +# - Aumente o número de blocos acima de 120 se nenhum evento de Transferência for retornado. +# - Se você não encontrou nenhum evento de Transferência, também pode tentar obter um tokenId em: # https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events -# Click to expand the event's logs and copy its "tokenId" argument - +# Clique para expandir os logs do evento e copie seu argumento "tokenId" recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] -kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above -is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() -print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") +if recent_tx: + kitty_id = recent_tx[0]['tokenId'] # Cole o "tokenId" aqui do link acima + is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() + print(f"{name} [{symbol}] NFT {kitty_id} está grávido: {is_pregnant}") ``` Contrato de CriptoKitties tem alguns eventos interessantes além dos padrões. -Vamos ver dois deles, `Pregnant` e `Birth`. +Vamos verificar dois deles, `Pregnant` e `Birth`. ```python -# Usando o Evento ABI "Gravidez e Nascimento" para obter informações sobre os novos Kitties. +# Usando o ABI dos eventos Pregnant e Birth para obter informações sobre novos Kitties. ck_extra_events_abi = [ { 'anonymous': False, @@ -198,27 +210,27 @@ ck_extra_events_abi = [ 'type': 'event' }] -# We need the event's signature to filter the logs +# Precisamos da assinatura do evento para filtrar os logs ck_event_signatures = [ - w3.sha3(text="Pregnant(address,uint256,uint256,uint256)").hex(), - w3.sha3(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), + w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), + w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), ] -# Here is a Pregnant Event: +# Aqui está um evento Pregnant: # - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog -pregnant_logs = w3.eth.getLogs({ - "fromBlock": w3.eth.blockNumber - 120, - "address": w3.toChecksumAddress(ck_token_addr), +pregnant_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), "topics": [ck_event_signatures[0]] }) recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] -# Here is a Birth Event: +# Aqui está um evento Birth: # - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a -birth_logs = w3.eth.getLogs({ - "fromBlock": w3.eth.blockNumber - 120, - "address": w3.toChecksumAddress(ck_token_addr), +birth_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), "topics": [ck_event_signatures[1]] }) @@ -227,18 +239,24 @@ recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] f ## NFTs populares {#popular-nfts} -- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) lista o maior NFT no Ethereum por volume de transferências. -- [CryptoKitties](https://www.cryptokitties.co/) é um jogo centrado em criaturas de coleção adoráveis que chamamos de CryptoKitties. -- [Sorare](https://sorare.com/) é um jogo global de fantasia em que você pode coletar edições limitadas, gerenciar suas equipes e concorrer para ganhar prêmios. -- [Ethereum Name Service (ENS)](https://ens.domains/) oferece uma forma segura e descentralizada de endereçar os recursos dentro e fora da blockchain usando nomes legíveis simples. -- [POAP](https://poap.xyz) oferece NFTs grátis para pessoas que participam de eventos ou realizam ações específicas. Os POAPs são livres para criar e distribuir. -- [Unstoppable Domains](https://unstoppabledomains.com/) é uma empresa com sede em São Francisco que cria domínios em blockchains. Os domínios de blockchain substituem endereços de criptomoeda por nomes legíveis e podem ser usados para habilitar sites resistentes à censura. -- [Gods Unchained Cards](https://godsunchained.com/) é uma TCG na blockchain Ethereum que usa NFT para representar a propriedade real nos ativos do jogo. -- [Bored Ape Yacht Club](https://boredapeyachtclub.com) é uma coleção de 10.000 NFT exclusivos que, além de ser uma peça de arte comprovadamente eclética, atua como um token de adesão ao clube, oferecendo vantagens e benefícios aos membros, que aumentam ao longo do tempo como resultado dos esforços da comunidade. - -## Leia mais {#further-reading} - -- [EIP-721: ERC-721 Padrão de token não-fungível](https://eips.ethereum.org/EIPS/eip-721) -- [OpenZeppelin: Documentação ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721) -- [OpenZeppelin: Implementação ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) -- [API do NFT da Alchemy](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) +- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) lista os principais NFTs no Ethereum por volume de transferências. +- [CryptoKitties](https://www.cryptokitties.co/) é um jogo centrado em criaturas criáveis, colecionáveis e superadoráveis + que chamamos de CryptoKitties. +- [Sorare](https://sorare.com/) é um jogo de futebol fantasia global onde você pode colecionar itens colecionáveis de edição limitada, + gerenciar suas equipes e competir para ganhar prêmios. +- [O Ethereum Name Service (ENS)](https://ens.domains/) oferece uma maneira segura e descentralizada de endereçar recursos tanto + dentro quanto fora da blockchain usando nomes simples e legíveis por humanos. +- [POAP](https://poap.xyz) entrega NFTs gratuitos para pessoas que participam de eventos ou concluem ações específicas. Os POAPs são livres para criar e distribuir. +- [Unstoppable Domains](https://unstoppabledomains.com/) é uma empresa com sede em São Francisco que constrói domínios em + blockchains. Domínios de blockchain substituem endereços de criptomoedas por nomes legíveis por humanos e podem ser usados para habilitar + sites resistentes à censura. +- [Gods Unchained Cards](https://godsunchained.com/) é um TCG na blockchain Ethereum que usa NFTs para trazer propriedade real + para os ativos do jogo. +- [Bored Ape Yacht Club](https://boredapeyachtclub.com) é uma coleção de 10.000 NFTs únicos que, além de ser uma obra de arte comprovadamente rara, funciona como um token de associação ao clube, oferecendo vantagens e benefícios aos membros que aumentam com o tempo como resultado dos esforços da comunidade. + +## Leitura adicional {#further-reading} + +- [EIP-721: Padrão de Token Não Fungível ERC-721](https://eips.ethereum.org/EIPS/eip-721) +- [OpenZeppelin - Documentação do ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721) +- [OpenZeppelin - Implementação do ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +- [API de NFT da Alchemy](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-777/index.md index da86904e165..de23574d146 100644 --- a/public/content/translations/pt-br/developers/docs/standards/tokens/erc-777/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/erc-777/index.md @@ -1,45 +1,45 @@ --- -title: Padrão de token ERC-777 -description: Token +title: "Padrão de token ERC-777" +description: "Saiba mais sobre o ERC-777, um padrão de token fungível aprimorado com ganchos, embora o ERC-20 seja recomendado por questões de segurança." lang: pt-br --- -## Atenção {#warning} +## Aviso {#warning} -**ERC-777 é difícil de implementar adequadamente, devido à sua [suscetibilidade a diferentes formas de ataque](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620). Recomenda-se usar [ERC-20](/developers/docs/standards/tokens/erc-20/) em vez disso.** Esta página permanece como um arquivo histórico. +**ERC-777 é difícil de implementar propriamente, devido à sua [suscetibilidade a diferentes formas de ataque](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620). É recomendável usar [ERC-20](/developers/docs/standards/tokens/erc-20/) ao invés. ** Essa página mantém um histórico de arquivos. -## Introdução {#introduction} +## Introdução? {#introduction} -ERC-777 é um padrão de token fungível com o objetivo de aprimorar o padrão [ERC-20](/developers/docs/standards/tokens/erc-20/) existente. +ERC-777 é um padrão de token fungível superior aos anteriores [ERC-20](/developers/docs/standards/tokens/erc-20/). -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -Para entender melhor essa página, recomendamos primeiramente uma leitura sobre [ERC-20](/developers/docs/standards/tokens/erc-20/). +Para entender melhor essa página, recomendamos que leia sobre[ERC-20](/developers/docs/standards/tokens/erc-20/). ## Quais as melhorias do ERC-777 em relação ao ERC-20? {#-erc-777-vs-erc-20} O ERC-777 proporciona as seguintes melhorias em relação ao ERC-20. -### Hooks {#hooks} +### Ganchos {#hooks} -Os hooks são funções descritas no código de um contrato inteligente. Eles são invocados quando os tokens são enviados ou recebidos pelo contrato. Isso possibilita que o contrato inteligente reaja aos tokens recebidos ou enviados. +Os hooks são funções descritas no código de um smart contract. Eles são invocados quando os tokens são enviados ou recebidos pelo contrato. Isso possibilita que o smart contract reaja aos tokens recebidos ou enviados. -Os hooks são registrados e descobertos utilizando o padrão [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820). +Os hooks são registrados e descobertos por meio do padrão [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820). #### Porque os hooks são uma vantagem? {#why-are-hooks-great} -1. Os hooks possibilitam o envio de tokens para um contrato e a notificação do contrato em apenas uma transação. O [ERC-20](https://eips.ethereum.org/EIPS/eip-20), porém, necessita de duas chamadas (`approve`/`transferFrom`) para fazer isso. -2. Contratos que não possuem hooks registrados são incompatíveis com o ERC-777. O contrato enviado irá abortar a transação quando o receptor não estiver com um hook registrado. Isso previne transferências acidentais para contratos inteligentes fora do padrão ERC-777. -3. Hooks podem rejeitas transações. +1. Eles possibilitam o envio de tokens para um contrato e a notificação do contrato em apenas uma transação. O [ERC-20](https://eips.ethereum.org/EIPS/eip-20), porém, necessita de duas chamadas (`approve`/`transferFrom`) para fazer isso. +2. Contratos que não possuem hooks registrados são incompatíveis com o ERC-777. O contrato enviado irá abortar a transação quando o receptor não estiver com um hook registrado. Isso previne transferências acidentais para smart contracts fora do padrão ERC-777. +3. Hooks podem rejeitar transações. ### Decimais {#decimals} O padrão ERC-777 também soluciona a confusão referente a `decimals` causada pelo ERC-20. Esta clareza melhora a experiência do desenvolvedor. -### Retrocompatibilidade com o ERC-20 {#backwards-compatibility-with-erc-20} +### Retrocompatibilidade com ERC-20 {#backwards-compatibility-with-erc-20} -Contratos ERC-777 permitem interação como se fossem contratos ERC-20. +Contratos ERC-777 podem ter interações como se fossem contratos ERC-20. -## Leitura Adicional {#further-reading} +## Leitura adicional {#further-reading} -[EIP-777: Padrão de token](https://eips.ethereum.org/EIPS/eip-777) +[EIP-777: Padrão de Token](https://eips.ethereum.org/EIPS/eip-777) diff --git a/public/content/translations/pt-br/developers/docs/standards/tokens/index.md b/public/content/translations/pt-br/developers/docs/standards/tokens/index.md index 6f20013c39e..615f556b783 100644 --- a/public/content/translations/pt-br/developers/docs/standards/tokens/index.md +++ b/public/content/translations/pt-br/developers/docs/standards/tokens/index.md @@ -1,36 +1,41 @@ --- -title: Padrões de token -description: Token +title: "Padrões de token" +description: "Explorar os padrões de tokens Ethereum, incluindo ERC-20, ERC-721, e ERC-1155 para tokens substituível e não substituível." lang: pt-br incomplete: true --- ## Introdução {#introduction} -Muitos padrões de desenvolvimento do Ethereum focam em interfaces de tokens. Esses padrõess ajudam a garantir que os contratos inteligentes permaneçam compostos. Por exemplo, quando um novo projeto emite um token, que ele permaneça compatível com exchanges descentralizadas existentes. +Muitos padrões de desenvolvimento do Ethereum focam em interfaces de tokens. Esses padrões ajudam a garantir que os contratos inteligentes permaneçam componíveis, para que, quando um novo projeto emitir um token, ele permaneça compatível com as corretoras e aplicativos descentralizados existentes. + +Os padrões de token definem como os tokens se comportam e interagem em todo o ecossistema Ethereum. Eles facilitam a criação para os desenvolvedores sem reinventar a roda, garantindo que os tokens funcionem perfeitamente com carteiras, corretoras e plataformas DeFi. Seja em jogos, governança ou outros casos de uso, esses padrões fornecem consistência e tornam o Ethereum mais interconectado. ## Pré-requisitos {#prerequisites} -- [Critérios de desenvolvimento do Ethereum](/developers/docs/standards/) -- [Smart Contracts](/developers/docs/smart-contracts/) +- [Padrões de desenvolvimento do Ethereum](/developers/docs/standards/) +- [Contratos inteligentes](/developers/docs/smart-contracts/) ## Padrões de token {#token-standards} Aqui estão alguns dos padrões mais populares de token no Ethereum: -- [ERC-20](/developers/docs/standards/tokens/erc-20/): uma interface padrão para tokens fungíveis (intercambiáveis), como tokens de votação, tokens de staking ou moedas virtuais. -- [ERC-721](/developers/docs/standards/tokens/erc-721/): uma interface padrão para tokens não-fungíveis, como uma ação para obra de arte ou uma música. -- [ERC-777](/developers/docs/standards/tokens/erc-777/): o ERC-777 permite que as pessoas criem funcionalidades extras com base nos tokens, como um contrato mixto para melhorar a privacidade das transações ou uma função de recuperação de emergência para ajudá-lo a recuperar suas chaves privadas caso você as perca. -- [ERC-1155](/developers/docs/standards/tokens/erc-1155/): o ERC-1155 permite operações mais eficientes e pode enviar pacotes de transações, o que economiza custos. Este padrão de token permite a criação tanto de tokens utilitários, como $BNB ou $BAT, quanto de tokens não-fungíveis, por exemplo, os CryptoPunks. -- [ERC-4626](/developers/docs/standards/tokens/erc-4626/): um padrão de cofre tokenizado projetado para otimizar e unificar os parâmetros técnicos dos cofres de rendimento. +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Uma interface padrão para tokens fungíveis (intercambiáveis), como tokens de votação, tokens de staking ou moedas virtuais. + +### Padrões de NFT {#nft-standards} + +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Uma interface padrão para tokens não fungíveis, como um título de propriedade para uma obra de arte ou uma música. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - O ERC-1155 permite negociações mais eficientes e o agrupamento de transações, economizando custos. Este padrão de token permite a criação tanto de tokens utilitários, como $BNB ou $BAT, quanto de tokens não-fungíveis, por exemplo, os CryptoPunks. + +A lista completa de propostas [ERC](https://eips.ethereum.org/erc). ## Leitura adicional {#further-reading} -_Conhece um recurso da comunidade que ajudou você? Edite essa página e adicione-o!_ +_Conhece um recurso da comunidade que o ajudou? Edite esta página e adicione-a!_ ## Tutoriais relacionados {#related-tutorials} -- [Lista de verificação para integração de tokens:](/developers/tutorials/token-integration-checklist/) _uma lista de verificação para considerar quando estiver interagindo com tokens._ -- [Entenda o contrato inteligente de token do ERC20:](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _uma introdução para a implementação do seu primeiro contrato inteligente na rede de teste do Ethereum_ -- [Transferências e aprovação de tokens do ERC20 de um contrato inteligente Solidity:](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _como usar um contrato inteligente para interagir com um token usando a linguagem Solidity._ -- [Implementação de um mercado ERC721 [um guia prático]:](/developers/tutorials/how-to-implement-an-erc721-market/) _ como colocar itens tokenizados à venda em um painel de classificações descentralizadas._ +- [Lista de verificação da integração de tokens](/developers/tutorials/token-integration-checklist/) _– Uma lista de verificação de itens a serem considerados ao interagir com tokens._ +- [Entenda o contrato inteligente do token ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Uma introdução à implantação do seu primeiro contrato inteligente em uma rede de teste Ethereum._ +- [Transferências e aprovação de tokens ERC20 a partir de um contrato inteligente em Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Como usar um contrato inteligente para interagir com um token usando a linguagem Solidity._ +- [Implementando um mercado ERC721 [um guia prático]](/developers/tutorials/how-to-implement-an-erc721-market/) _– Como colocar itens tokenizados à venda em um quadro de classificados descentralizado._ diff --git a/public/content/translations/pt-br/developers/docs/storage/index.md b/public/content/translations/pt-br/developers/docs/storage/index.md index ca22c62ad58..daaa3451119 100644 --- a/public/content/translations/pt-br/developers/docs/storage/index.md +++ b/public/content/translations/pt-br/developers/docs/storage/index.md @@ -1,12 +1,12 @@ --- title: Armazenamento Descentralizado -description: Visão geral do que é o armazenamento descentralizado e as ferramentas disponíveis para integrar a um dapp. +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). +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 cadeia está crescendo de forma constante, mas, no momento da redação, a cadeia Ethereum tem cerca de 500 GB a 1 TB ([dependendo do cliente](https://etherscan.io/chartsync/chaindefault)), e cada nó na 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 tantos dados na Mainnet 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. @@ -14,7 +14,7 @@ Ao analisar as opções de armazenamento descentralizado (dStorage), existem alg - Mecanismo de persistência/estrutura de incentivo - Execução de retenção de dados -- Descentralizada +- Descentralização - Consenso ## Mecanismo de persistência / estrutura de incentivo {#persistence-mechanism} @@ -23,9 +23,9 @@ Ao analisar as opções de armazenamento descentralizado (dStorage), existem alg 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**. +Isso é conhecido 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). +O problema com a persistência baseada em blockchain é que a cadeia pode se tornar grande demais para manter e armazenar todos os dados de forma viável (por exemplo, [muitas fontes](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) estimam que a Internet exige 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. @@ -34,23 +34,23 @@ Plataformas com persistência baseada em blockchain (cadeia de blocos): - Ethereum - [Arweave](https://www.arweave.org/) -### Baseado em contratos {#contract-based} +### Baseado em contrato {#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. +A persistência **baseada em contrato** parte do princípio de que os dados não podem ser replicados por todos os nós e armazenados para sempre e, em vez 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. +Na maioria dos casos, em vez de armazenar todos os dados onchain, o hash de onde os dados estão localizados onchain é 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/) +- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin) +- [Skynet](https://sia.tech/) - [Storj](https://storj.io/) - [Züs](https://zus.network/) -- [Rede Crust](https://crust.network) +- [Crust Network](https://crust.network) - [Swarm](https://www.ethswarm.org/) - [4EVERLAND](https://www.4everland.org/) -### Considerações finais {#additional-consideration} +### Considerações adicionais {#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! @@ -58,12 +58,12 @@ IPFS é um sistema distribuído para armazenamento e acesso a arquivos, sites, a - [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 pinning IPFS/Filecoin)_ +- [IPFS Scan](https://ipfs-scan.io) _(explorador de fixação 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 fixação 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. +O SWARM é uma tecnologia de armazenamento e distribuição de dados descentralizada com um sistema de incentivo de armazenamento e um oráculo de preços de aluguel de armazenamento. ## Retenção de dados {#data-retention} @@ -98,7 +98,7 @@ Ferramentas descentralizadas sem KYC: ### 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/). +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 [**prova de trabalho (PoW)**](/developers/docs/consensus-mechanisms/pow/) ou [**prova de participação (PoS)**](/developers/docs/consensus-mechanisms/pos/). Baseado em prova de trabalho (proof-of-work): @@ -114,23 +114,23 @@ Baseado em prova de participação (proof-of-stake): ## Ferramentas relacionadas {#related-tools} -**IPFS - _InterPlanetary File System é um sistema descentralizado de armazenamento e referenciamento de arquivos para a Ethereum._** +**IPFS - _O InterPlanetary File System é um sistema descentralizado de armazenamento e referenciamento de arquivos para o 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 DCS - _Armazenamento de objetos em nuvem descentralizado, seguro, privado e compatível com S3 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._** +**Sia - _Utiliza criptografia para criar um mercado de armazenamento em nuvem sem necessidade de confiança, permitindo que compradores e vendedores transacionem diretamente._** -- [Skynet.net](https://siasky.net/) -- [Documentação](https://siasky.net/docs/) -- [GitHub](https://github.com/SkynetLabs/) +- [Skynet.net](https://sia.tech/) +- [Documentação](https://docs.sia.tech/) +- [GitHub](https://github.com/SiaFoundation/) **Filecoin - _Filecoin foi criado pela mesma equipe por trás do IPFS. É uma camada de incentivo no topo dos ideais IPFS._** @@ -144,49 +144,49 @@ Baseado em prova de participação (proof-of-stake): - [Documentação](https://docs.arweave.org/info/) - [Arweave](https://github.com/ArweaveTeam/arweave/) -**Züs - _Züs é uma plataforma de dStorage baseada em prova de participação, com suporte a fragmentação e blobbers._** +**Züs - _Züs é uma plataforma de dStorage de prova de participação com fragmentação e blobbers._** - [zus.network](https://zus.network/) -- [Documentação](https://0chaindocs.gitbook.io/zus-docs) +- [Documentação](https://docs.zus.network/zus-docs/) - [GitHub](https://github.com/0chain/) -**Rede Croust - _Crust é uma plataforma de dStorage no topo do IPFS._** +**Crust Network - _Crust é uma plataforma de dStorage sobre o 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._** +**Swarm - _Uma plataforma de armazenamento distribuída e um serviço de distribuição de conteúdo para a pilha web3 do Ethereum._** - [EthSwarm.org](https://www.ethswarm.org/) -- [Documentação](https://docs.ethswarm.org/docs/) +- [Documentação](https://docs.ethswarm.org/) - [GitHub](https://github.com/ethersphere/) -**OrbitDB - _Um banco de dados descentralizado peer-to-peer no topo do IPFS._** +**OrbitDB - _Um banco de dados peer-to-peer descentralizado sobre o 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 - _Projeto de nuvem descentralizada (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/) +- [Aleph.im](https://aleph.cloud/) +- [Documentação](https://docs.aleph.cloud/) - [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/) +- [Documentação](https://developers.ceramic.network/) - [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 - _Armazenamento descentralizado compatível com S3 e serviço de fixação IPFS com redundância geográfica. Todos os arquivos enviados 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 - _Uma plataforma de computação em nuvem Web 3.0 que integra recursos essenciais de armazenamento, computação e rede, é compatível com S3 e fornece armazenamento de dados síncrono em redes de armazenamento descentralizadas, como IPFS e Arweave._** - [4everland.org](https://www.4everland.org/) - [Documentação](https://docs.4everland.org/) @@ -198,7 +198,7 @@ Baseado em prova de participação (proof-of-stake): - [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 busca lançar seus aplicativos em infraestrutura descentralizada com o melhor desempenho. Oferece computação, armazenamento descentralizado, CDN e hospedagem web prontos para uso._** +**Spheron Network - _A Spheron é uma plataforma como serviço (PaaS) projetada para dApps que procuram lançar seus aplicativos 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/) @@ -206,11 +206,11 @@ Baseado em prova de participação (proof-of-stake): ## 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_ +- [O que é armazenamento descentralizado?](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ +- [Desvendando 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/) +- [Frameworks de desenvolvimento](/developers/docs/frameworks/) diff --git a/public/content/translations/pt-br/developers/docs/transactions/index.md b/public/content/translations/pt-br/developers/docs/transactions/index.md index 8b9f9f85a0c..a9a66b541fc 100644 --- a/public/content/translations/pt-br/developers/docs/transactions/index.md +++ b/public/content/translations/pt-br/developers/docs/transactions/index.md @@ -1,20 +1,21 @@ --- -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.' +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} +## Pré-requisitos {#prerequisites} -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/). +Para ajudar você a entender melhor esta página, recomendamos que você leia primeiro [Contas](/developers/docs/accounts/) 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 mostrando uma transação que causa mudança de estado](./tx.png) _Diagrama adaptado de [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagrama mostrando uma transação causando mudança de estado](./tx.png) +_Diagrama adaptado de [Ethereum EVM illustrated](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. @@ -22,15 +23,15 @@ As transações exigem uma taxa e devem ser incluídas em um bloco validado. Par 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`) +- `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 +- `to` – o endereço de recebimento (se for uma conta de propriedade externa, a transação transferirá 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 da conta +- `value` – quantia de ETH a ser transferida do remetente para o destinatário (denominada em WEI, em que 1 ETH é igual a 1e+18 wei) +- `input data` – campo opcional para incluir dados arbitrários +- `gasLimit` – a quantidade máxima de unidades 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 uma gorjeta para o validador +- `maxFeePerGas` - a taxa máxima por unidade de gás que se está disposto a pagar pela transação (incluindo `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/). @@ -99,22 +100,26 @@ Exemplo de resposta: } ``` -- 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 +- o `raw` é a transação assinada em formato codificado com [Prefixo de Comprimento Recursivo (RLP)](/developers/docs/data-structures-and-encoding/rlp) +- o `tx` é a transação assinada em 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). +A grande maioria das transações acessa um contrato de uma conta de propriedade externa. +A maioria dos contratos é escrita em Solidity e interpreta seu campo de dados de acordo com a [interface binária de aplicação (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/). +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). +O resto do calldata são os argumentos, [codificados conforme especificado nas especificações da 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. +Por exemplo, vamos dar uma olhada [nesta transação](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1). +Use **Clique para ver mais** para ver o calldata. -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 seletor de função é `0xa9059cbb`. Existem várias [funções conhecidas com esta assinatura](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). +Neste caso, [o código-fonte do contrato](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) foi carregado no Etherscan, então sabemos que a função é `transfer(address,uint256)`. O resto dos dados é: @@ -123,21 +128,23 @@ O resto dos dados é: 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. +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. +Então, sabemos que o endereço `to` é [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279). +O `value` é 0x3b0559f4 = 990206452. ## Tipos de transações {#types-of-transactions} -No Ethereum existem alguns tipos diferentes de transações: +Existem alguns tipos diferentes de transações no Ethereum: - 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} +### Sobre o 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: +Então, para Bob enviar 1 ETH para Alice com um `baseFeePerGas` de 190 gwei e `maxPriorityFeePerGas` de 10 gwei, Bob precisará pagar a seguinte taxa: ``` (190 + 10) * 21000 = 4.200.000 gwei @@ -145,16 +152,16 @@ Então para Bob enviar a Alice 1 ETH para `baseFeePerGas` de 190 gwei e `maxPrio 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 Bob será debitada em **-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 conta de Alice será creditada em **+1,0 ETH** -A taxa base queimará **-0,00399 ETH** +A taxa base será queimada **-0,00399 ETH** -O validador mantém a gorjeta de **+0,000210 ETH** +O validador fica com a gorjeta **+0,000210 ETH** - -![Diagrama que mostra como o gás não utilizado é reembolsado](./gas-tx.png) _Diagrama adaptado do [Ethereum EVM ilustrado](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagrama mostrando como o gás não utilizado é reembolsado](./gas-tx.png) +_Diagrama adaptado de [Ethereum EVM illustrated](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. @@ -162,18 +169,21 @@ Qualquer gás não usado em uma transação é reembolsado para a conta do usuá 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) +Contratos inteligentes também podem conter funções conhecidas como funções [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) ou [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), que 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 este 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. +Diferentemente de quando são acessadas usando `eth_call`, essas funções `view` ou `pure` também são comumente chamadas internamente (ou seja, do próprio contrato ou de outro contrato), o que custa gás. -## Ciclo de vida de transação {#transaction-lifecycle} +## Ciclo de vida da transação {#transaction-lifecycle} Quando uma transação é enviada, acontece o seguinte: -1. Um hash de transação é gerado criptograficamente: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` +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. +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 que sua transação foi bem-sucedida e nunca será alterada. Uma vez que um bloco é "finalizado", ele só poderia ser alterado + por um ataque em nível de rede que custaria muitos bilhões de dólares. ## Uma demonstração visual {#a-visual-demo} @@ -181,41 +191,43 @@ Assista Austin mostrar as transações, gás e mineração. -## Envelope de transação digitado {#typed-transaction-envelope} +## Envelope de Transação Tipada {#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: +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 com RLP](/developers/docs/data-structures-and-encoding/rlp/), para se parecer com algo assim: -`RLP ([emissor, taxa de "queima", parâmetros de "queima", destino, valor, dados, v, r, s])` +`RLP([nonce, gasPrice, gasLimit, to, value, data, 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. +O Ethereum evoluiu para suportar múltiplos tipos de transações para permitir que novos recursos, como listas de acesso e o [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), sejam implementados sem afetar os formatos de transação legados. -[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) é o que permite esse comportamento. Transações são interpretadas como: +O [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) é o que permite este 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. +- `TransactionType` - um número entre 0 e 0x7f, para um total de 128 tipos de transação possíveis. +- `TransactionPayload` - uma matriz de bytes arbitrária definida pelo tipo de transação. -Baseado no valor do `TransactionType` , a transação pode ser classificada como +Com base no valor de `TransactionType`, uma 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`. +1. **Transações do Tipo 0 (Legado):** O formato de transação original usado desde o lançamento do Ethereum. Elas 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 possuem 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)](/developers/docs/data-structures-and-encoding/rlp). O valor de 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](/ethereum-forks/#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`. +2. **Transações do Tipo 1:** Introduzidas no [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) como parte da [Atualização Berlim](/ethereum-forks/#berlin) do Ethereum, essas transações incluem um parâmetro `accessList`. Esta lista especifica os endereços e as 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 são identificadas começando com o byte `0x01`, e seu valor de 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](/ethereum-forks/#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`. +3. **Transações do tipo 2**, comumente chamadas de transações EIP-1559, são transações introduzidas no [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), na [Atualização Londres](/ethereum-forks/#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 de TransactionType para essas transações é `0x2`. +4. **Transações do Tipo 3 (Blob)** foram introduzidas no [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) como parte da [Atualização Dencun](/ethereum-forks/#dencun) do Ethereum. Essas transações são projetadas para manipular dados "blob" (Binary Large Objects) de forma mais eficiente, beneficiando particularmente os rollups da Layer 2, pois fornecem uma maneira de postar dados na rede Ethereum a um custo menor. As transações blob incluem campos adicionais, como `blobVersionedHashes`, `maxFeePerBlobGas` e `blobGasPrice`. Elas começam com o byte `0x03`, e seu valor de TransactionType é `0x3`. As transações de blobs representam uma melhoria significativa na disponibilidade de dados e nos recursos de dimensionamento do Ethereum. +5. **Transações do Tipo 4** foram introduzidas no [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) como parte da [Atualização Pectra](/roadmap/pectra/) do Ethereum. Essas transações são projetadas para serem compatíveis com a abstração de conta. Elas permitem que as EOAs se comportem temporariamente como contas de contrato inteligente sem comprometer sua funcionalidade original. Elas incluem um parâmetro `authorization_list`, que especifica o contrato inteligente para o qual a EOA delega sua autoridade. Após a transação, o campo de código da EOA terá o endereço do contrato inteligente delegado. ## Leitura adicional {#further-reading} -- [EIP-2718: Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718) +- [EIP-2718: Envelope de transação tipada](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/) +- [Máquina Virtual Ethereum (EVM)](/developers/docs/evm/) - [Gás](/developers/docs/gas/) diff --git a/public/content/translations/pt-br/developers/docs/web2-vs-web3/index.md b/public/content/translations/pt-br/developers/docs/web2-vs-web3/index.md index 15e5e20e0d5..3f1a00ddd89 100644 --- a/public/content/translations/pt-br/developers/docs/web2-vs-web3/index.md +++ b/public/content/translations/pt-br/developers/docs/web2-vs-web3/index.md @@ -1,12 +1,12 @@ --- title: Web2 vs Web3 -description: +description: "Comparar os serviços centralizados do Web2 com as aplicações descentralizadas da Web3 baseadas na tecnologia Ethereum blockchain." 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/). +Procurando por uma explicação mais adaptada para iniciantes? Veja nossa [introdução à web3](/web3/). ## Benefícios da Web3 {#web3-benefits} @@ -36,27 +36,27 @@ O Web3 tem alguns limites neste momento: - 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} +## 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. | +| 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. | +| 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} +## Leitura adicional {#further-reading} -- [O que é Web3?](/web3/) - _ethereum.org_ +- [O que é a 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_ +- [O Significado da Descentralização](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _6 de fev. de 2017 - Vitalik Buterin_ +- [Por que a descentralização é importante](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) _18 de fev. de 2018 - Chris Dixon_ +- [O que é a Web 3.0 e por que ela é importante](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _31 de dez. de 2019 - Max Mersch e Richard Muirhead_ +- [Por que precisamos da Web 3.0](https://gavofyork.medium.com/why-we-need-web-3-0-5da4f2bf95ab) _12 de set. de 2018 - Gavin Wood_ diff --git a/public/content/translations/pt-br/developers/docs/wrapped-eth/index.md b/public/content/translations/pt-br/developers/docs/wrapped-eth/index.md index a8b7225af4b..97f66878dd5 100644 --- a/public/content/translations/pt-br/developers/docs/wrapped-eth/index.md +++ b/public/content/translations/pt-br/developers/docs/wrapped-eth/index.md @@ -1,6 +1,6 @@ --- -title: O que é Wrapped Ether (WETH) -description: Uma introdução ao Wrapped ether (WETH), um wrapper compatível com ERC20 para ether (ETH). +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 --- @@ -35,19 +35,16 @@ O [ERC-20](/developers/docs/standards/tokens/erc-20/) define uma interface padr 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 - +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 @@ -55,7 +52,6 @@ Além da [implementação canônica do WETH] (https://etherscan.io/token/0xc02aa - [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} diff --git a/public/content/translations/pt-br/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md b/public/content/translations/pt-br/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md index 7e4e56b22c1..2cd0404a826 100644 --- a/public/content/translations/pt-br/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md +++ b/public/content/translations/pt-br/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md @@ -1,33 +1,32 @@ --- -title: Uma introdução do desenvolvedor Python ao Ethereum, parte 1 -description: Uma introdução ao desenvolvimento do Ethereum, especialmente útil para aqueles com conhecimento sobre a linguagem de programação Python +title: "Uma introdução ao Ethereum para desenvolvedores Python, parte 1" +description: "Uma introdução ao desenvolvimento em Ethereum, especialmente útil para aqueles com conhecimento da linguagem de programação Python" author: Marc Garreau lang: pt-br -tags: - - "python" - - "web3.py" +tags: [ "Python", "web3.py" ] skill: beginner published: 2020-09-08 -source: O encantador de cobras +source: Snake charmers sourceUrl: https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/ --- -Então, você ouviu falar sobre esta coisa do Ethereum e está pronto para se aventurar no buraco do coelho? Este post cobrirá rapidamente alguns conceitos básicos de blockchain e, em seguida, fará com que você interaja com um nó simulado do Ethereum – lendo dados do bloco, verificando saldos da conta e enviando transações. Em todo o caminho, vamos destacar as diferenças entre as maneiras tradicionais de desenvolver aplicativos e este novo paradigma descentralizado. +Então, você já ouviu falar de Ethereum e está pronto para entrar na toca do coelho? Este artigo abordará rapidamente alguns conceitos básicos de blockchain e, em seguida, fará com que você interaja com um nó Ethereum simulado – lendo dados de blocos, verificando saldos de contas e enviando transações. Ao longo do caminho, destacaremos as diferenças entre as formas tradicionais de criar aplicativos e este novo paradigma descentralizado. -## Pré-requisitos de software {#soft-prerequisites} +## (Pré-requisitos flexíveis) {#soft-prerequisites} -Este post espera ser acessível a muitos desenvolvedores. Usaremos [ferramentas Python](/developers/docs/programming-languages/python/), mas elas são apenas um meio para as ideias — não há problema se você não é um desenvolvedor Python. No entanto, vou fazer apenas algumas suposições sobre o que você já sabe, para que possamos passar rapidamente aos temas específicos do Ethereum. +Este artigo pretende ser acessível a uma vasta gama de desenvolvedores. [Ferramentas Python](/developers/docs/programming-languages/python/) serão usadas, mas elas são apenas um veículo para as ideias – não há problema se você não for um desenvolvedor Python. No entanto, farei apenas algumas suposições sobre o que você já sabe, para que possamos avançar rapidamente para os pontos específicos do Ethereum. Suposições: -- Você pode utilizar um terminal, +- Você sabe usar um terminal, - Você já escreveu algumas linhas de código Python, -- A versão 3.6 ou superior do Python está instalada no seu computador (uso de um [ambiente virtual](https://realpython.com/effective-python-environment/#virtual-environments) é fortemente recomendado) e -- você já usou o `pip`, instalador de pacotes do Python. Novamente, se algum destes pré-requisitos não for verdadeiro, ou se você não planeja reproduzir o código apresentado neste artigo, é provável que você ainda possa acompanhar sem maiores problemas. +- A versão 3.6 ou superior do Python está instalada em sua máquina (o uso de um [ambiente virtual](https://realpython.com/effective-python-environment/#virtual-environments) é fortemente incentivado), e +- você já usou o `pip`, o instalador de pacotes do Python. + Novamente, se algum desses pontos não for verdadeiro, ou se você não planeja reproduzir o código neste artigo, provavelmente ainda conseguirá acompanhar sem problemas. -## Blockchains, em poucas palavras {#blockchains-briefly} +## Blockchains, resumidamente {#blockchains-briefly} -Há muitas maneiras de descrever o Ethereum, mas no fundo é uma blockchain. As blockchains são compostas de uma série de blocos, então vamos começar por aí. Em termos mais simples, cada bloco na blockchain do Ethereum é somente um conjunto de metadados e uma lista de transações. No formato JSON, que se parece com algo assim: +Existem muitas maneiras de descrever o Ethereum, mas em sua essência, ele é uma blockchain. As blockchains são compostas por uma série de blocos, então vamos começar por aí. Em termos mais simples, cada bloco na blockchain Ethereum é apenas um conjunto de metadados e uma lista de transações. No formato JSON, se parece com algo assim: ```json { @@ -41,98 +40,98 @@ Há muitas maneiras de descrever o Ethereum, mas no fundo é uma blockchain. As Cada [bloco](/developers/docs/blocks/) tem uma referência ao bloco que veio antes dele; o `parentHash` é simplesmente o hash do bloco anterior. -Observação: o Ethereum faz uso regular de funções hash para produzir valores de tamanho fixo ("hashes"). Os hashes desempenham um papel importante no Ethereum, mas você pode pensar neles como IDs exclusivos por enquanto. +Observação: o Ethereum faz uso regular de funções hash para produzir valores de tamanho fixo (“hashes”). Os hashes desempenham um papel importante no Ethereum, mas você pode pensar neles como IDs exclusivos por enquanto. -![Um diagrama que retrata uma blockchain incluindo os dados dentro de cada bloco](./blockchain-diagram.png) +![Um diagrama que retrata uma blockchain, incluindo os dados dentro de cada bloco](./blockchain-diagram.png) -_Uma blockchain é essencialmente uma lista encadeada; onde cada bloco tem uma referência ao bloco anterior._ +_Uma blockchain é essencialmente uma lista encadeada; cada bloco tem uma referência ao bloco anterior._ -Esta estrutura de dados não é nada nova, mas as regras (por exemplo, os protocolos peer-to-peer) que regem a rede são. Não há autoridade central; a rede de pares deve colaborar para sustentar a rede e competir para decidir quais transações incluir no próximo bloco. Então, quando você quiser enviar algum dinheiro para um amigo, você precisará transmitir essa transação para a rede, depois espere que ela seja incluída em um próximo bloco. +Essa estrutura de dados não é nova, mas as regras (ou seja, protocolos ponto a ponto) que governam a rede, sim. Não há autoridade central; a rede de pares deve colaborar para sustentar a rede e competir para decidir quais transações incluir no próximo bloco. Então, quando você quiser enviar dinheiro para um amigo, precisará transmitir essa transação para a rede e esperar que ela seja incluída em um bloco futuro. -A única maneira de a blockchain verificar se o dinheiro foi realmente enviado de um usuário para outro é usar uma moeda nativa de (isto é, criada e governada por) aquela blockchain. No Ethereum, esta moeda é chamada ether, e a blockchain Ethereum contém o único registro oficial dos saldos das contas. +A única maneira de a blockchain verificar se o dinheiro foi realmente enviado de um usuário para outro é usar uma moeda nativa daquela blockchain (ou seja, criada e governada por ela). No Ethereum, essa moeda é chamada ether, e a blockchain Ethereum contém o único registro oficial de saldos de contas. ## Um novo paradigma {#a-new-paradigm} -Esta nova pilha de tecnologia descentralizada gerou novas ferramentas de desenvolvedor. Tais ferramentas existem em muitas linguagens de programação, mas vamos analisar através das lentes do Python. Para reiterar: mesmo que o Python não seja sua linguagem escolhida, você não terá muitos problemas para acompanhar. +Essa nova pilha de tecnologia descentralizada gerou novas ferramentas para desenvolvedores. Essas ferramentas existem em muitas linguagens de programação, mas nós as veremos pela ótica do Python. Reiterando: mesmo que Python não seja sua linguagem de escolha, não deve ser muito difícil acompanhar. -Os desenvolvedores do Python que querem interagir com o Ethereum provavelmente usem a [Web3.py](https://web3py.readthedocs.io/). Web3.py é uma biblioteca que simplifica muito a forma como você se conecta a um nó Ethereum, e depois envia e recebe dados dele. +Desenvolvedores Python que desejam interagir com o Ethereum provavelmente usarão o [Web3.py](https://web3py.readthedocs.io/). Web3.py é uma biblioteca que simplifica muito a maneira como você se conecta a um nó Ethereum e, em seguida, envia e recebe dados dele. -Nota: "Nó Ethereum" e "Cliente Ethereum" são usados de forma intercambiável. Em ambos os casos, refere-se ao software que um participante da rede Ethereum executa. Este software pode ler dados de blocos, receber atualizações quando novos blocos são adicionados à cadeia, transmitir novas transações e mais. Tecnicamente, o cliente é o software, o nódulo é o computador que executa o software. +Observação: “nó Ethereum” e “cliente Ethereum” são usados de forma intercambiável. Em ambos os casos, refere-se ao software que um participante da rede Ethereum executa. Este software pode ler dados de blocos, receber atualizações quando novos blocos são adicionados à cadeia, transmitir novas transações e muito mais. Tecnicamente, o cliente é o software, e o nó é o computador que executa o software. -[Clientes Ethereum](/developers/docs/nodes-and-clients/) podem ser configurados para serem acessíveis por [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTPS ou Websockets, então Web3.py precisará espelhar esta configuração. Web3.py refere-se a estas opções de conexão como **provedores**. Você vai querer escolher um dos três provedores para vincular a instância da Web3.py ao seu nó. +[Clientes Ethereum](/developers/docs/nodes-and-clients/) podem ser configurados para serem acessíveis por [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTP ou Websockets, então o Web3.py precisará espelhar essa configuração. O Web3.py se refere a essas opções de conexão como **provedores**. Você precisará escolher um dos três provedores para vincular a instância do Web3.py com seu nó. -![Um diagrama mostrando como web3.py usa IPC para conectar seu aplicativo a um nódulo Ethereum](./web3py-and-nodes.png) +![Um diagrama mostrando como o web3.py usa IPC para conectar seu aplicativo a um nó Ethereum](./web3py-and-nodes.png) -_Configure o nó Ethereum e o Web3.py para se comunicarem através do mesmo protocolo, por exemplo, o IPC neste diagrama._ +_Configure o nó Ethereum e o Web3.py para se comunicarem através do mesmo protocolo, por exemplo, IPC neste diagrama._ -Uma vez que o Web3.py estiver configurado corretamente, você pode começar a interagir com a blockchain. Aqui estão alguns exemplos de uso da Web3.py como uma prévia do que está por vir: +Uma vez que o Web3.py esteja configurado corretamente, você pode começar a interagir com a blockchain. Aqui estão alguns exemplos de uso do Web3.py como uma prévia do que está por vir: ```python -# read block data: +# ler dados de bloco: w3.eth.get_block('latest') -# send a transaction: +# enviar uma transação: w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...}) ``` ## Instalação {#installation} -Neste guia, vamos trabalhar apenas com um interpretador de Python. Não criaremos nenhum diretório, arquivos, classes ou funções. +Neste passo a passo, trabalharemos apenas dentro de um interpretador Python. Não criaremos nenhum diretório, arquivo, classe ou função. Observação: nos exemplos abaixo, os comandos que começam com `$` devem ser executados no terminal. (Não digite o `$`, ele apenas significa o início da linha.) -Primeiro, instale [IPython](https://ipython.org/) para explorar em um ambiente amigável. IPython propõe, entre outros, um recurso de autopreenchimento com tab, o que facilita a navegação no Web3.py. +Primeiro, instale o [IPython](https://ipython.org/) para ter um ambiente amigável para explorar. O IPython oferece preenchimento com a tecla Tab, entre outros recursos, tornando muito mais fácil ver o que é possível dentro do Web3.py. ```bash pip install ipython ``` -Web3.py é publicado sob o nome `web3`. Instale-o assim: +O Web3.py é publicado com o nome `web3`. Instale-o da seguinte forma: ```bash pip install web3 ``` -Mais uma coisa: vamos simular uma blockchain mais tarde, o que requer mais algumas dependências. Você pode instalar por meio de: +Mais uma coisa – vamos simular uma blockchain mais tarde, o que requer mais algumas dependências. Você pode instalá-las via: ```bash pip install 'web3[tester]' ``` -Você está pronto para começar! +Está tudo pronto para começar! -Nota: o pacote `web3[tester]` funciona até Python 3.10.xx +Observação: o pacote `web3[tester]` funciona até o Python 3.10.xx -## Crie uma sandbox {#spin-up-a-sandbox} +## Iniciando um sandbox {#spin-up-a-sandbox} -Abra um novo ambiente Python executando o `ipython` no seu terminal. Isso é como executar `python`, mas vem com mais "efeitos especiais". +Abra um novo ambiente Python executando `ipython` em seu terminal. Isso é comparável a executar `python`, mas vem com mais recursos extras. ```bash ipython ``` -Isso mostrará algumas informações sobre as versões do Python e do IPython que você está executando, então você deve ver um prompt esperando por uma entrada: +Isso imprimirá algumas informações sobre as versões do Python e do IPython que você está executando, e então você verá um prompt aguardando a entrada: ```python In [1]: ``` -Você está olhando para um shell interativo do Python agora. Essencialmente, é um ambiente de testes para brincar. Se você chegou até aqui, é hora de importar Web3.py: +Você está vendo um shell interativo do Python agora. Essencialmente, é um sandbox para experimentar. Se você chegou até aqui, é hora de importar o Web3.py: ```python In [1]: from web3 import Web3 ``` -## Introduzindo o módulo Web3 {#introducing-the-web3-module} +## Apresentando o módulo Web3 {#introducing-the-web3-module} -Além de ser um gateway para Ethereum, o módulo [Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) oferece algumas funções práticas. Vamos ver algumas. +Além de ser um portal para o Ethereum, o módulo [Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) oferece algumas funções de conveniência. Vamos explorar algumas delas. -Em um aplicativo Ethereum, você normalmente precisará converter denominações de moeda. O módulo web3 fornece alguns métodos auxiliares apenas para isso: [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) e [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei). +Em um aplicativo Ethereum, você comumente precisará converter denominações de moeda. O módulo Web3 fornece alguns métodos auxiliares apenas para isso: [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) e [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei). -Observação: os computadores são notoriamente pouco eficazes para lidar com números decimais. Para contornar isso, os desenvolvedores costumam armazenar valores em dólares em centavos. Por exemplo, um item com preço de $5,99 pode ser armazenado no banco de dados como 599. +Observação: computadores são conhecidos por não lidarem bem com matemática decimal. Para contornar isso, os desenvolvedores geralmente armazenam valores em dólares como centavos. Por exemplo, um item com o preço de US$ 5,99 pode ser armazenado no banco de dados como 599. -Um padrão similar é usado ao lidar com transações em ether. No entanto, em vez de dois pontos decimais, ether tem 18! A menor denominação de ether é chamada de wei, portanto, esse é o valor especificado ao enviar transações. +Um padrão semelhante é usado ao lidar com transações em ether. No entanto, em vez de duas casas decimais, o ether tem 18! A menor denominação do ether é chamada de wei, então esse é o valor especificado ao enviar transações. 1 ether = 1000000000000000000 wei @@ -140,7 +139,7 @@ Um padrão similar é usado ao lidar com transações em ether. No entant -Tente converter alguns valores de e para wei. Note que [existem nomes para muitas das denominações](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations) entre ether e wei. Um dos mais conhecidos entre eles é o **gwei**, já que é frequentemente como as taxas de transação são representadas. +Tente converter alguns valores de e para wei. Observe que [existem nomes para muitas das denominações](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations) entre ether e wei. Um dos mais conhecidos entre eles é o **gwei**, pois é frequentemente como as taxas de transação são representadas. ```python In [2]: Web3.to_wei(1, 'ether') @@ -150,32 +149,33 @@ In [3]: Web3.from_wei(500000000, 'gwei') Out[3]: Decimal('0.5') ``` -Outros métodos utilitários no módulo Web3 incluem conversores de formato de dados (por exemplo, [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)), os métodos para gerar endereços (por exemplo, [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)) e funções hash (por exemplo, [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)). Muitos deles serão cobertos mais tarde pela série. Para ver todos os métodos e propriedades disponíveis, utilize o autopreenchimento do IPython, digitando `Web3` e pressionando a tecla tab duas vezes após o ponto. +Outros métodos utilitários no módulo Web3 incluem conversores de formato de dados (por exemplo, [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)), auxiliares de endereço (por exemplo, [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)) e funções de hash (por exemplo, [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)). Muitos deles serão abordados mais adiante na série. Para ver todos os métodos e propriedades disponíveis, utilize o preenchimento automático do IPython digitando `Web3`. e pressionando a tecla Tab duas vezes após o ponto. -## Se comunicar com a cadeia {#talk-to-the-chain} +## Conversando com a cadeia {#talk-to-the-chain} -Os métodos práticos são convenientes, mas vamos passar à blockchain. O próximo passo é configurar o Web3.py para se comunicar com um nó Ethereum. Aqui temos a opção de usar os provedores IPC, HTTPS ou Websocket. +Os métodos de conveniência são ótimos, mas vamos passar para a blockchain. O próximo passo é configurar o Web3.py para se comunicar com um nó Ethereum. Aqui, temos a opção de usar os provedores IPC, HTTP ou Websocket. -Não vamos nos adentrar nesse tema, mas um exemplo de um fluxo de trabalho completo usando o provedor HTTP pode parecer algo assim: +Não seguiremos por este caminho, mas um exemplo de um fluxo de trabalho completo usando o Provedor HTTP pode ser algo assim: -- Baixe um nó Ethereum, por exemplo, [Geth](https://geth.ethereum.org/). -- Inicie o Geth em uma janela de terminal e aguarde a sincronização da rede. A porta HTTP padrão é `8545`, mas é configurável. -- Peça ao Web3.py para se conectar ao nó via HTTP, no `localhost:8545`. `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))` +- Baixe um nó Ethereum, por exemplo, o [Geth](https://geth.ethereum.org/). +- Inicie o Geth em uma janela de terminal e espere que ele sincronize com a rede. A porta HTTP padrão é `8545`, mas é configurável. +- Diga ao Web3.py para se conectar ao nó via HTTP, em `localhost:8545`. + `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))` - Use a instância `w3` para interagir com o nó. -Embora esta seja uma maneira "real" de fazer isso, o processo de sincronização leva horas e é desnecessário se você só quer um ambiente de desenvolvimento. A Web3.py expõe um quarto provedor para esse propósito, o **EthereumTesterProvider**. Este provedor de teste se vincula a um nó Ethereum simulado com autorizações abrangentes e moeda falsa para utilizar. +Embora esta seja uma maneira “real” de fazer isso, o processo de sincronização leva horas e é desnecessário se você só quer um ambiente de desenvolvimento. O Web3.py expõe um quarto provedor para este fim, o **EthereumTesterProvider**. Este provedor de teste se vincula a um nó Ethereum simulado com permissões flexíveis e moeda falsa para experimentar. -![Um diagrama mostrando o EthereumTesterProvider que vincula o seu aplicativo web3.py a um nó simulado de Ethereum](./ethereumtesterprovider.png) +![Um diagrama mostrando o EthereumTesterProvider que vincula o seu aplicativo web3.py a um nó Ethereum simulado](./ethereumtesterprovider.png) -_O EthereumTesterProvider conecta-se a um nó simulado e é útil para ambientes de desenvolvimento rápido._ +_O EthereumTesterProvider se conecta a um nó simulado e é útil para ambientes de desenvolvimento rápidos._ -O nó simulado é chamado [eth-tester](https://github.com/ethereum/eth-tester) e o instalamos como parte do `pip install web3[tester]`. Configurar o Web3.py para usar este provedor de teste é tão simples como: +Esse nó simulado é chamado [eth-tester](https://github.com/ethereum/eth-tester) e nós o instalamos como parte do comando `pip install web3[tester]`. Configurar o Web3.py para usar este provedor de teste é tão simples quanto: ```python In [4]: w3 = Web3(Web3.EthereumTesterProvider()) ``` -Agora você está pronto para navegar pela cadeia! Disso as pessoas não falam. É algo que eu acabei de inventar. Façamos um tour rápido. +Agora você está pronto para surfar na cadeia! Isso não é algo que as pessoas dizem. Eu acabei de inventar isso. Vamos fazer um tour rápido. ## O tour rápido {#the-quick-tour} @@ -186,11 +186,11 @@ In [5]: w3.is_connected() Out[5]: True ``` -Já que estamos utilizando o provedor de teste, esse não é um teste muito importante, mas se ele falhar, você provavelmente digitou algo errado ao instanciar a variável `w3`. Verifique se você incluiu os parênteses internos, ou seja, `Web3.EthereumTesterProvider()`. +Como estamos usando o provedor de teste, este não é um teste muito valioso, mas se ele falhar, é provável que você tenha digitado algo errado ao instanciar a variável `w3`. Verifique se você incluiu os parênteses internos, ou seja, `Web3.EthereumTesterProvider()`. -## Parada n.º 1 do tour: [contas](/developers/docs/accounts/) {#tour-stop-1-accounts} +## Parada do tour nº 1: [contas](/developers/docs/accounts/) {#tour-stop-1-accounts} -Por conveniência, o provedor de teste criou algumas contas e as pré-carregou com o ether. +Por conveniência, o provedor de teste criou algumas contas e as pré-carregou com ether de teste. Primeiro, vamos ver uma lista dessas contas: @@ -201,16 +201,16 @@ Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf', '0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...] ``` -Se você executar esse comando, você deverá ver uma lista de dez variáveis que começam com `0x`. Cada um é um **endereço público** e é, em alguns aspectos, análogo ao número da conta em uma conta corrente. Você forneceria este endereço a alguém que quisesse mandar ether para você. +Se você executar este comando, verá uma lista de dez strings que começam com `0x`. Cada um é um **endereço público** e é, de certa forma, análogo ao número de uma conta corrente. Você forneceria este endereço a alguém que quisesse lhe enviar ether. -Como mencionado, o provedor de teste pré-carregou cada uma dessas contas com algum ether. Vamos descobrir quanto há na primeira conta: +Como mencionado, o provedor de teste pré-carregou cada uma dessas contas com um pouco de ether de teste. Vamos descobrir quanto há na primeira conta: ```python In [7]: w3.eth.get_balance(w3.eth.accounts[0]) Out[7]: 1000000000000000000000000 ``` -São muitos zeros! Antes de você ir rindo até o banco falso, lembre-se daquela lição anterior sobre denominações de moeda. Os valores de ether são representados na menor denominação, wei. Converta para ether: +São muitos zeros! Antes de sair rindo até o banco falso, lembre-se da lição sobre denominações de moeda de antes. Os valores de Ether são representados na menor denominação, wei. Converta isso para ether: ```python In [8]: w3.from_wei(1000000000000000000000000, 'ether') @@ -219,7 +219,7 @@ Out[8]: Decimal('1000000') Um milhão de ether de teste — nada mal. -## Parada n.º 2 do tour: dados do bloco {#tour-stop-2-block-data} +## Parada do tour nº 2: dados do bloco {#tour-stop-2-block-data} Vamos dar uma olhada no estado desta blockchain simulada: @@ -234,15 +234,15 @@ Out[9]: AttributeDict({ }) ``` -São fornecidas muitas informações sobre um bloco, mas há apenas alguns pontos para salientar aqui: +Muitas informações são retornadas sobre um bloco, mas há apenas algumas coisas a serem destacadas aqui: -- O número de bloco é zero — não importa quanto tempo você configurou o provedor de teste. Ao contrário da rede Ethereum real, que minera um novo bloco aproximadamente a cada 12 segundos, essa simulação esperará até que você a instrua a fazer alguma coisa. +- O número do bloco é zero — não importa há quanto tempo você configurou o provedor de teste. Ao contrário da rede Ethereum real, que adiciona um novo bloco a cada 12 segundos, esta simulação esperará até que você lhe dê algum trabalho a fazer. - `transactions` é uma lista vazia, pelo mesmo motivo: ainda não fizemos nada. Este primeiro bloco é um **bloco vazio**, apenas para iniciar a cadeia. -- Observe que o `parentHash` é apenas um monte de bytes vazios. Isso significa que ele é o primeiro bloco da cadeia, também conhecido como **bloco de início**. +- Observe que o `parentHash` é apenas um monte de bytes vazios. Isso significa que é o primeiro bloco da cadeia, também conhecido como **bloco gênese**. -## Parada n.º 2 do tour: [transações](/developers/docs/transactions/) {#tour-stop-3-transactions} +## Parada do tour nº 3: [transações](/developers/docs/transactions/) {#tour-stop-3-transactions} -Estamos parados no bloco zero até que haja uma transação para minerar, então vamos começar. Envie um teste com ether de uma conta para outra: +Estamos presos no bloco zero até que haja uma transação pendente, então vamos criar uma. Envie alguns ether de teste de uma conta para outra: ```python In [10]: tx_hash = w3.eth.send_transaction({ @@ -253,13 +253,16 @@ In [10]: tx_hash = w3.eth.send_transaction({ }) ``` -Esse é normalmente o ponto em que você espera (vários segundos) até que sua transação seja minerada em um novo bloco. O processo completo envolve algo como isto: +Este é geralmente o ponto em que você esperaria vários segundos para que sua transação fosse incluída em um novo bloco. O processo completo é mais ou menos assim: -1. Envie uma transação e espere pelo hash da transação. Até que o bloco que contém a transação seja criado e transmitido, a transação fica "pendente" `tx_hash = w3.eth.send_transaction({ … })` -2. Aguarde a mineração da transação: `w3.eth.wait_for_transaction_receipt(tx_hash)` -3. Continue a lógica do aplicativo. Para visualizar a transação bem-sucedida: `w3.eth.get_transaction(tx_hash)` +1. Envie uma transação e guarde o hash da transação. Até que o bloco contendo a transação seja criado e transmitido, a transação fica “pendente”. + `tx_hash = w3.eth.send_transaction({ … })` +2. Aguarde a transação ser incluída em um bloco: + `w3.eth.wait_for_transaction_receipt(tx_hash)` +3. Continue a lógica do aplicativo. Para ver a transação bem-sucedida: + `w3.eth.get_transaction(tx_hash)` -Nosso ambiente simulado adicionará a transação a um novo bloco instantaneamente para que possamos ver a transação imediatamente: +Nosso ambiente simulado adicionará a transação a um novo bloco instantaneamente, para que possamos ver a transação imediatamente: ```python In [11]: w3.eth.get_transaction(tx_hash) @@ -274,9 +277,9 @@ Out[11]: AttributeDict({ }) ``` -Você verá alguns detalhes familiares aqui: os campos `de`, `para` e `valor` devem corresponder às entradas da chamada `sendTransaction`. A outra parte tranquilizadora é que esta transação foi incluída como a primeira transação (`'transactionIndex': 0`) dentro do bloco número 1. +Você verá alguns detalhes familiares aqui: os campos `from`, `to` e `value` devem corresponder às entradas de nossa chamada `send_transaction`. O outro detalhe reconfortante é que esta transação foi incluída como a primeira transação (`'transactionIndex': 0`) no bloco número 1. -Também podemos ver facilmente o sucesso dessa transação, verificando o saldo das duas contas envolvidas. Três ether deveriam ter sido enviados de uma conta para outra. +Também podemos verificar facilmente o sucesso desta transação, verificando os saldos das duas contas envolvidas. Três ether deveriam ter sido movidos de uma para outra. ```python In [12]: w3.eth.get_balance(w3.eth.accounts[0]) @@ -286,12 +289,12 @@ In [13]: w3.eth.get_balance(w3.eth.accounts[1]) Out[13]: 1000003000000000000000000 ``` -O último parece bem! O saldo foi de 1.000.000 a 1.000.003 ether. Mas o que aconteceu com a primeira conta? Parece ter perdido um pouco mais que três ether. Infelizmente, nada na vida é gratuito, e o uso da rede pública Ethereum requer que você compense os seus pares pelo papel de apoio deles. Uma pequena taxa de transação foi deduzida da conta que submeteu a transação - esta taxa é a quantidade de gás queimado (21000 unidades de gás para uma transferência ETH) multiplicado por uma taxa base, que varia de acordo com a atividade da rede, mais a gorjeta que vai para o validador que inclui a transação em um bloco. +O último parece bom! O saldo passou de 1.000.000 para 1.000.003 ether. Mas o que aconteceu com a primeira conta? Parece ter perdido um pouco mais de três ether. Infelizmente, nada na vida é de graça, e usar a rede pública Ethereum exige que você compense seus pares por seu papel de apoio. Uma pequena taxa de transação foi deduzida da conta que enviou a transação - essa taxa é a quantidade de gás queimado (21.000 unidades de gás para uma transferência de ETH) multiplicada por uma taxa base que varia de acordo com a atividade da rede, mais uma gorjeta que vai para o validador que inclui a transação em um bloco. Mais sobre [gás](/developers/docs/gas/#post-london) -Observação: na rede pública, as taxas de transação são variáveis baseadas na demanda da rede e na rapidez com que você gostaria que uma transação fosse processada. Se você estiver interessado em ver como as taxas são calculadas, veja minha publicação anterior sobre como transações são incluídas em um bloco. +Observação: na rede pública, as taxas de transação são variáveis com base na demanda da rede e na rapidez com que você gostaria que uma transação fosse processada. Se você estiver interessado em uma análise de como as taxas são calculadas, veja minha postagem anterior sobre como as transações são incluídas em um bloco. -## Agora uma pausa {#and-breathe} +## E respire {#and-breathe} -Já estamos nisso por um tempo, então este parece um lugar tão bom quanto qualquer um para fazer uma pausa. A descoberta continua, e vamos continuar com a parte dois desta série. Alguns conceitos que surgem: conectar a um nó real, contratos inteligentes e tokens. Tem perguntas adicionais? Queremos saber! Seu feedback influenciará o caminho a seguir. Suas perguntas são bem-vindas no [Twitter](https://twitter.com/wolovim). +Já estamos nisso há um tempo, então este parece ser um bom lugar para fazer uma pausa. A descoberta continua, e vamos continuar explorando na parte dois desta série. Alguns conceitos futuros: conectar a um nó real, contratos inteligentes e tokens. Tem mais alguma pergunta? Queremos saber! Seu feedback influenciará para onde vamos a partir daqui. Pedidos são bem-vindos via [Twitter](https://twitter.com/wolovim). diff --git a/public/content/translations/pt-br/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/pt-br/developers/tutorials/all-you-can-cache/index.md index 7a99bcf4de1..9a0c6fce339 100644 --- a/public/content/translations/pt-br/developers/tutorials/all-you-can-cache/index.md +++ b/public/content/translations/pt-br/developers/tutorials/all-you-can-cache/index.md @@ -1,42 +1,39 @@ --- -title: "Tudo que você puder armazenar em cache" -description: Aprenda como criar e usar um contrato de cache para transações de roll-up mais baratas +title: "Tudo que você pode colocar em cache" +description: "Aprenda a criar e usar um contrato de cache para transações de rollup mais baratas" author: Ori Pomerantz -tags: - - "camada 2" - - "armazenamento em cache" - - "armazenamento" +tags: [ "camada 2", "cache", "armazenamento" ] skill: intermediate published: 2022-09-15 lang: pt-br --- -Ao usar roll-ups, o custo de um byte na transação é muito mais caro que o custo de um slot de armazenamento. Portanto, faz sentido armazenar em cache o máximo de informações possível na cadeia. +Ao usar rollups, o custo de um byte na transação é muito mais caro do que o custo de um slot de armazenamento. Portanto, faz sentido armazenar em cache o máximo de informações on-chain possível. -Neste artigo, você aprenderá como criar e usar um contrato de armazenamento em cache de forma que qualquer valor de parâmetro, provável de ser usado diversas vezes, será armazenado em cache e ficará disponível para uso (depois da primeira vez) com um número muito menor de bytes, e como escrever código off-chain para usar esse cache. +Neste artigo, você aprenderá a criar e usar um contrato de cache de forma que qualquer valor de parâmetro que provavelmente será usado várias vezes será armazenado em cache e estará disponível para uso (após a primeira vez) com um número muito menor de bytes, e como escrever código off-chain que usa esse cache. -Se você quiser pular o artigo e somente ver o código-fonte, [consulte-o aqui](https://github.com/qbzzt/20220915-all-you-can-cache). A pilha de desenvolvimento é [Foundry](https://book.getfoundry.sh/getting-started/installation). +Se quiser pular o artigo e ver apenas o código-fonte, [ele está aqui](https://github.com/qbzzt/20220915-all-you-can-cache). A pilha de desenvolvimento é a [Foundry](https://getfoundry.sh/introduction/installation/). -## Design Geral {#overall-design} +## Projeto geral {#overall-design} -Para fins de simplicidade, vamos supor que todos os parâmetros de transação são `uint256`, com 32 bytes de tamanho. Quando recebemos uma transação, fazemos o parse em cada parâmetro deste modo: +Para simplificar, vamos supor que todos os parâmetros da transação são `uint256`, com 32 bytes de comprimento. Ao receber uma transação, analisaremos cada parâmetro desta forma: -1. Se o primeiro byte for `0xFF`, pegue os 32 bytes seguintes como um valor de parâmetro e escreva-o no cache. +1. Se o primeiro byte for `0xFF`, pegue os próximos 32 bytes como um valor de parâmetro e escreva-o no cache. 2. Se o primeiro byte for `0xFE`, pegue os próximos 32 bytes como um valor de parâmetro, mas _não_ o escreva no cache. -3. Para qualquer outro valor, pegue os primeiros quatro bits como o número de bytes adicionais, e os últimos quatro bits como os bits mais significantes da chave do cache. Veja aqui alguns exemplos: +3. Para qualquer outro valor, pegue os quatro bits superiores como o número de bytes adicionais e os quatro bits inferiores como os bits mais significativos da chave do cache. Veja aqui alguns exemplos: - | Bytes em calldata | Chave da cache | - |:----------------- | --------------:| + | Bytes em calldata | Chave de cache | + | :---------------- | -------------: | | 0x0F | 0x0F | | 0x10,0x10 | 0x10 | | 0x12,0xAC | 0x02AC | | 0x2D,0xEA, 0xD6 | 0x0DEAD6 | -## Manipulação do cache {#cache-manipulation} +## Manipulação de cache {#cache-manipulation} -A cache é implementada em [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol). Vamos passar por ele linha a linha. +O cache é implementado em [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol). Vamos analisá-lo linha por linha. ```solidity // SPDX-License-Identifier: UNLICENSED @@ -49,22 +46,22 @@ contract Cache { bytes1 public constant DONT_CACHE = 0xFE; ``` -Essas constantes são usadas para interpretar os casos especiais nos quais fornecemos todas as informações, independentemente de as querermos escritas no cache ou não. Escrever no cache requer duas operações [`SSTORE`](https://www.evm.codes/#55) nos slots de armazenamento previamente não utilizados, ao custo de 22.100 gás cada. Portanto, deixamos isso opcional. +Essas constantes são usadas para interpretar os casos especiais em que fornecemos todas as informações e queremos ou não que elas sejam gravadas no cache. Escrever no cache requer duas operações [`SSTORE`](https://www.evm.codes/#55) em slots de armazenamento não utilizados anteriormente, a um custo de 22.100 de gás cada, por isso tornamos isso opcional. ```solidity mapping(uint => uint) public val2key; ``` -Um [mapeamento](https://www.geeksforgeeks.org/solidity-mappings/) entre os valores e suas chaves. Esta informação é necessária para codificar valores antes de você enviar a transação. +Um [mapeamento](https://www.geeksforgeeks.org/solidity/solidity-mappings/) entre os valores e suas chaves. Esta informação é necessária para codificar valores antes de enviar a transação. ```solidity - // Location n has the value for key n+1, because we need to preserve - // zero as "not in the cache". + // A localização n tem o valor da chave n+1, porque precisamos preservar + // o zero como "não está no cache". uint[] public key2val; ``` -Podemos usar uma matriz para mapear das chaves aos valores, pois atribuímos as chaves e, para simplificar, fazemos isso de modo sequencial. +Podemos usar um array para o mapeamento de chaves para valores, pois atribuímos as chaves e, para simplificar, fazemos isso sequencialmente. ```solidity function cacheRead(uint _key) public view returns (uint) { @@ -73,69 +70,69 @@ Podemos usar uma matriz para mapear das chaves aos valores, pois atribuímos as } // cacheRead ``` -Ler um valor da cache. +Lê um valor do cache. ```solidity - // Write a value to the cache if it's not there already - // Only public to enable the test to work + // Escreve um valor no cache se ele ainda não estiver lá + // Público apenas para permitir que o teste funcione function cacheWrite(uint _value) public returns (uint) { - // If the value is already in the cache, return the current key + // Se o valor já estiver no cache, retorne a chave atual if (val2key[_value] != 0) { return val2key[_value]; } ``` -Não faz sentido colocar o mesmo valor no cache mais de uma vez. Se o valor já está lá, apenas retorne a chave existente. +Não faz sentido colocar o mesmo valor no cache mais de uma vez. Se o valor já estiver lá, basta retornar a chave existente. ```solidity - // Since 0xFE is a special case, the largest key the cache can - // hold is 0x0D followed by 15 0xFF's. If the cache length is already that - // large, fail. + // Como 0xFE é um caso especial, a maior chave que o cache pode + // conter é 0x0D seguido por 15 0xFF's. Se o tamanho do cache já for tão + // grande, falhe. // 1 2 3 4 5 6 7 8 9 A B C D E F require(key2val.length+1 < 0x0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, "cache overflow"); ``` -Não acho que iremos algum dia ter um cache tão grande (cerca de 1,8\*1037 entradas, o que exigiria cerca de 1027 TB de armazenamento). No entanto, eu sou velho o suficiente para lembrar que ["640kB sempre será o suficiente"](https://quoteinvestigator.com/2011/09/08/640k-enough/). Este teste é muito barato. +Acho que nunca teremos um cache tão grande (aproximadamente 1,8\*1037 entradas, o que exigiria cerca de 1027 TB para armazenar). No entanto, tenho idade suficiente para me lembrar de ["640kB sempre seriam suficientes"](https://quoteinvestigator.com/2011/09/08/640k-enough/). Este teste é muito barato. ```solidity - // Write the value using the next key + // Escreve o valor usando a próxima chave val2key[_value] = key2val.length+1; ``` -Adicione a busca reversa (do valor para a chave). +Adicione a pesquisa reversa (do valor para a chave). ```solidity key2val.push(_value); ``` -Adicione a busca para frente (da chave para o valor). Como atribuímos valores de modo sequencial, podemos apenas adicioná-los depois do último valor da matriz. +Adicione a pesquisa direta (da chave para o valor). Como atribuímos valores sequencialmente, podemos simplesmente adicioná-lo após o último valor do array. ```solidity return key2val.length; } // cacheWrite ``` -Retorne o novo tamanho de `key2val`, que é a célula onde o novo valor está armazenado. +Retorna o novo comprimento de `key2val`, que é a célula onde o novo valor está armazenado. ```solidity function _calldataVal(uint startByte, uint length) private pure returns (uint) ``` -Essa função lê um valor de calldata de tamanho arbitrário (até 32 bytes, o tamanho da palavra). +Esta função lê um valor do calldata de comprimento arbitrário (até 32 bytes, o tamanho da palavra). ```solidity { uint _retVal; require(length < 0x21, - "_calldataVal length limit is 32 bytes"); + "O limite de comprimento de _calldataVal é de 32 bytes"); require(length + startByte <= msg.data.length, - "_calldataVal trying to read beyond calldatasize"); + "_calldataVal tentando ler além do tamanho do calldata"); ``` -A função é interna, por isso, se o resto do código for escrito corretamente, esses testes não serão obrigatórios. Porém, como eles não custam muito, podemos tê-los de qualquer forma. +Esta função é interna, então se o resto do código for escrito corretamente, esses testes não são necessários. No entanto, eles não custam muito, então podemos mantê-los. ```solidity assembly { @@ -143,7 +140,7 @@ A função é interna, por isso, se o resto do código for escrito corretamente, } ``` -Este código está em [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html). Ele lê um valor de 32 bytes do calldata. Isso funciona até mesmo se o calldata parar antes `startByte+32`, pois o espaço não inicializado na EVM é considerado como zero. +Este código está em [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html). Ele lê um valor de 32 bytes do calldata. Isso funciona mesmo que o calldata pare antes de `startByte+32`, porque o espaço não inicializado na EVM é considerado como zero. ```solidity _retVal = _retVal >> (256-length*8); @@ -156,39 +153,39 @@ Não queremos necessariamente um valor de 32 bytes. Isso elimina os bytes em exc } // _calldataVal - // Read a single parameter from the calldata, starting at _fromByte + // Lê um único parâmetro do calldata, começando em _fromByte function _readParam(uint _fromByte) internal returns (uint _nextByte, uint _parameterValue) { ``` -Leia um único parâmetro do calldata. Observe que precisamos retornar não somente o valor que lemos, mas também a localização do próximo byte, pois os parâmetros podem estar na faixa de comprimento de 1 byte a 33 bytes. +Lê um único parâmetro do calldata. Observe que precisamos retornar não apenas o valor que lemos, mas também a localização do próximo byte, porque os parâmetros podem variar de 1 a 33 bytes de comprimento. ```solidity - // The first byte tells us how to interpret the rest + // O primeiro byte nos diz como interpretar o resto uint8 _firstByte; _firstByte = uint8(_calldataVal(_fromByte, 1)); ``` -O Solidity tenta reduzir o número de bugs proibindo [conversões de tipo implícitas](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions) potencialmente perigosas. Um rebaixamento, por exemplo, de 256 bits para 8 bits, precisa ser explícito. +O Solidity tenta reduzir o número de bugs, proibindo [conversões de tipo implícitas](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions) potencialmente perigosas. Um rebaixamento, por exemplo, de 256 bits para 8 bits, precisa ser explícito. ```solidity - // Read the value, but do not write it to the cache + // Lê o valor, mas não o escreve no cache if (_firstByte == uint8(DONT_CACHE)) return(_fromByte+33, _calldataVal(_fromByte+1, 32)); - // Read the value, and write it to the cache + // Lê o valor e o escreve no cache if (_firstByte == uint8(INTO_CACHE)) { uint _param = _calldataVal(_fromByte+1, 32); cacheWrite(_param); return(_fromByte+33, _param); } - // If we got here it means that we need to read from the cache + // Se chegamos aqui, significa que precisamos ler do cache - // Number of extra bytes to read + // Número de bytes extras para ler uint8 _extraBytes = _firstByte / 16; ``` @@ -207,13 +204,13 @@ Pegue o [nibble](https://en.wikipedia.org/wiki/Nibble) inferior e combine-o com function _readParams(uint _paramNum) internal returns (uint[] memory) { ``` -Poderíamos pegar o número de parâmetros que temos do calldata propriamente dito, mas as funções que nos chamam sabem quantos parâmetros elas esperam. É mais fácil que elas nos contem. +Poderíamos obter o número de parâmetros que temos do próprio calldata, mas as funções que nos chamam sabem quantos parâmetros esperam. É mais fácil que elas nos contem. ```solidity - // The parameters we read + // Os parâmetros que lemos uint[] memory params = new uint[](_paramNum); - // Parameters start at byte 4, before that it's the function signature + // Os parâmetros começam no byte 4, antes disso é a assinatura da função uint _atByte = 4; for(uint i=0; i<_paramNum; i++) { @@ -221,14 +218,14 @@ Poderíamos pegar o número de parâmetros que temos do calldata propriamente di } ``` -Leia os parâmetros até que você tenha o número de que precisa. Se ultrapassarmos o fim do calldata, `_readParams` reverterá a chamada. +Leia os parâmetros até ter o número que você precisa. Se passarmos do final do calldata, `_readParams` reverterá a chamada. ```solidity return(params); } // readParams - // For testing _readParams, test reading four parameters + // Para testar _readParams, teste a leitura de quatro parâmetros function fourParam() public returns (uint256,uint256,uint256,uint256) { @@ -238,45 +235,45 @@ Leia os parâmetros até que você tenha o número de que precisa. Se ultrapassa } // fourParam ``` -Uma grande vantagem do Foundry é que ele permite que os testes sejam escritos no Solidity ([veja o teste de cache abaixo](#testing-the-cache)). Isto faz testes unitários muito mais fáceis. Essa é uma função que lê quatro parâmetros e retorna-os para que o teste possa verificar que eles estão corretos. +Uma grande vantagem da Foundry é que ela permite que os testes sejam escritos em Solidity ([veja Testando o cache abaixo](#testing-the-cache)). Isso torna os testes de unidade muito mais fáceis. Esta é uma função que lê quatro parâmetros e os retorna para que o teste possa verificar se eles estavam corretos. ```solidity - // Get a value, return bytes that will encode it (using the cache if possible) + // Obtém um valor, retorna os bytes que o codificarão (usando o cache, se possível) function encodeVal(uint _val) public view returns(bytes memory) { ``` -`encodeVal` é uma função que o código off-chain chama para ajudar a criar o calldata que usa o cache. Ela recebe um único valor e retorna os bytes que o codificam. Essa função é uma `view`, portanto, ela não requer uma transação e, quando chamada externamente, não custa nenhum gás. +`encodeVal` é uma função que o código off-chain chama para ajudar a criar calldata que usa o cache. Ela recebe um único valor e retorna os bytes que o codificam. Esta função é uma `view`, portanto não requer uma transação e, quando chamada externamente, não custa gás. ```solidity uint _key = val2key[_val]; - // The value isn't in the cache yet, add it + // O valor ainda não está no cache, adicione-o if (_key == 0) return bytes.concat(INTO_CACHE, bytes32(_val)); ``` -Na [EVM](/developers/docs/evm/) todo o armazenamento não inicializado é considerado como zero. Então, se buscarmos a chave de um valor que não está lá, obteremos zero. Nesse caso, os bytes que o codificaram são `INTO_CACHE` (portanto, ele será armazenado em cache da próxima vez), seguido do valor real. +Na [EVM](/developers/docs/evm/), todo o armazenamento não inicializado é considerado como zero. Então, se procurarmos a chave de um valor que não está lá, obtemos um zero. Nesse caso, os bytes que o codificam são `INTO_CACHE` (para que seja armazenado em cache da próxima vez), seguido do valor real. ```solidity - // If the key is <0x10, return it as a single byte + // Se a chave for <0x10, retorne-a como um único byte if (_key < 0x10) return bytes.concat(bytes1(uint8(_key))); ``` -Bytes únicos são os mais fáceis. Somente usamos [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) para transformar um tipo de `bytes` em uma matriz de bytes que pode ser de qualquer tamanho. Apesar do nome, isso funciona bem quando fornecemos somente um argumento. +Bytes únicos são os mais fáceis. Nós apenas usamos [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) para transformar um tipo `bytes` em um array de bytes que pode ter qualquer comprimento. Apesar do nome, funciona bem quando fornecido com apenas um argumento. ```solidity - // Two byte value, encoded as 0x1vvv + // Valor de dois bytes, codificado como 0x1vvv if (_key < 0x1000) return bytes.concat(bytes2(uint16(_key) | 0x1000)); ``` -Quando temos uma chave que é inferior a 163, podemos expressá-la em dois bytes. Primeiro, convertemos `_key`, que é um valor de 256 bits, para um valor de 16 bits e usamos um cálculo lógico para adicionar o número de bytes extras ao primeiro byte. Então, convertemos o byte em um valor `bytes2`, que pode ser convertido para `bytes`. +Quando temos uma chave menor que 163, podemos expressá-la em dois bytes. Primeiro, convertemos `_key`, que é um valor de 256 bits, para um valor de 16 bits e usamos o OU lógico para adicionar o número de bytes extras ao primeiro byte. Então, o transformamos em um valor `bytes2`, que pode ser convertido em `bytes`. ```solidity - // There is probably a clever way to do the following lines as a loop, - // but it's a view function so I'm optimizing for programmer time and - // simplicity. + // Provavelmente existe uma maneira inteligente de fazer as seguintes linhas como um loop, + // mas é uma função de visualização, então estou otimizando para o tempo do programador e + // simplicidade. if (_key < 16*256**2) return bytes.concat(bytes3(uint24(_key) | (0x2 * 16 * 256**2))); @@ -291,14 +288,14 @@ Quando temos uma chave que é inferior a 163, podemos expressá-la em return bytes.concat(bytes16(uint128(_key) | (0xF * 16 * 256**15))); ``` -Os outros valores (3 bytes, 4 bytes, etc.) são manipulados da mesma maneira, apenas com diferentes tamanhos de campo. +Os outros valores (3 bytes, 4 bytes, etc.) são tratados da mesma forma, apenas com tamanhos de campo diferentes. ```solidity - // If we get here, something is wrong. - revert("Error in encodeVal, should not happen"); + // Se chegarmos aqui, algo está errado. + revert("Erro em encodeVal, não deveria acontecer"); ``` -Se chegarmos até aí, significa que temos a chave que não é inferior a 16\*25615. Porém, `cacheWrite` limita as chaves, portanto, não conseguimos nem mesmo chegar a 14\*25616 (o que teria o primeiro byte de 0xFE, que se pareceria com `DONT_CACHE`). Mas ele não nos custa tanto para adicionar um teste caso um futuro programador introduza um bug. +Se chegarmos aqui, significa que obtivemos uma chave que não é menor que 16\*25615. Mas `cacheWrite` limita as chaves para que não possamos chegar a 14\*25616 (o que teria um primeiro byte de 0xFE, então se pareceria com `DONT_CACHE`). Mas não custa muito adicionar um teste caso um futuro programador introduza um bug. ```solidity } // encodeVal @@ -308,7 +305,7 @@ Se chegarmos até aí, significa que temos a chave que não é inferior a 16\*25 ### Testando o cache {#testing-the-cache} -Uma das vantagens do Foundry é que [ele deixa você escrever testes em Solidity](https://book.getfoundry.sh/forge/tests), o que facilita escrever testes de unidade. Os testes para a classe `Cache` estão [aqui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol). Como o código de teste pode ser repetitivo, assim como os testes tendem a ser, este artigo explica apenas as partes interessantes. +Uma das vantagens da Foundry é que [ela permite que você escreva testes em Solidity](https://getfoundry.sh/forge/tests/overview/), o que facilita a escrita de testes de unidade. Os testes para a classe `Cache` estão [aqui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol). Como o código de teste é repetitivo, como os testes tendem a ser, este artigo explica apenas as partes interessantes. ```solidity // SPDX-License-Identifier: UNLICENSED @@ -317,11 +314,11 @@ pragma solidity ^0.8.13; import "forge-std/Test.sol"; -// Need to run `forge test -vv` for the console. +// É necessário executar `forge test -vv` para o console. import "forge-std/console.sol"; ``` -Isso é apenas um modelo necessário para usar o pacote de teste e `console.log`. +Isso é apenas um código padrão necessário para usar o pacote de teste e o `console.log`. ```solidity import "src/Cache.sol"; @@ -338,13 +335,13 @@ contract CacheTest is Test { } ``` -A função `setUp` é chamada antes de cada teste. Nesse caso, acabamos de criar um novo cache, de modo que nossos testes não sejam afetados um pelo outro. +A função `setUp` é chamada antes de cada teste. Neste caso, apenas criamos um novo cache, para que nossos testes não afetem uns aos outros. ```solidity function testCaching() public { ``` -Testes são funções cujos nomes começam com `test`. Essa função verifica a funcionalidade básica do cache, escrevendo valores e lendo-os novamente. +Testes são funções cujos nomes começam com `test`. Esta função verifica a funcionalidade básica do cache, escrevendo valores e lendo-os novamente. ```solidity for(uint i=1; i<5000; i++) { @@ -355,15 +352,15 @@ Testes são funções cujos nomes começam com `test`. Essa função verifica a assertEq(cache.cacheRead(i), i*i); ``` -Isto é como você faz teste realmente, usando as funções [`assert...`](https://book.getfoundry.sh/reference/forge-std/std-assertions). Nesse caso, nós verificamos que o valor que escrevemos é o mesmo que lemos. Podemos descartar o resultado de `cache.cacheWrite`, pois sabemos que as chaves do cache são atribuídos linearmente. +É assim que você faz o teste real, usando as [funções `assert...`](https://getfoundry.sh/reference/forge-std/std-assertions/). Neste caso, verificamos que o valor que escrevemos é o que lemos. Podemos descartar o resultado de `cache.cacheWrite` porque sabemos que as chaves de cache são atribuídas linearmente. ```solidity } } // testCaching - // Cache the same value multiple times, ensure that the key stays - // the same + // Armazena o mesmo valor em cache várias vezes, garante que a chave permaneça + // a mesma function testRepeatCaching() public { for(uint i=1; i<100; i++) { uint _key1 = cache.cacheWrite(i); @@ -372,7 +369,7 @@ Isto é como você faz teste realmente, usando as funções [`assert...`](https: } ``` -Primeiro, escrevemos cada valor duas vezes para o cache e nos certificamos de que as chaves são as mesmas (ou seja, a segunda escrita não aconteceu realmente). +Primeiro, escrevemos cada valor duas vezes no cache e garantimos que as chaves sejam as mesmas (o que significa que a segunda escrita não aconteceu de fato). ```solidity for(uint i=1; i<100; i+=3) { @@ -382,20 +379,20 @@ Primeiro, escrevemos cada valor duas vezes para o cache e nos certificamos de qu } // testRepeatCaching ``` -Na teoria poderia haver um bug que não afetasse escritas em cache consecutivas. Então, fazemos aqui algumas escritas que não sejam consecutivas e observamos que os valores ainda não foram reescritos. +Em teoria, poderia haver um bug que não afeta as escritas consecutivas no cache. Então, aqui fazemos algumas escritas que não são consecutivas e vemos que os valores ainda não são reescritos. ```solidity - // Read a uint from a memory buffer (to make sure we get back the parameters - // we sent out) + // Lê um uint de um buffer de memória (para garantir que recebamos de volta os parâmetros + // que enviamos) function toUint256(bytes memory _bytes, uint256 _start) internal pure returns (uint256) ``` -Leia uma palavra de 256 bits de um buffer de `bytes memory`. Essa função utilitária nos deixa verificar que recebemos os resultados corretos quando executamos uma chamada de função que usa o cache. +Lê uma palavra de 256 bits de um buffer `bytes memory`. Esta função utilitária nos permite verificar se recebemos os resultados corretos quando executamos uma chamada de função que usa o cache. ```solidity { - require(_bytes.length >= _start + 32, "toUint256_outOfBounds"); + require(_bytes.length >= _start + 32, "toUint256_fora_dos_limites"); uint256 tempUint; assembly { @@ -403,31 +400,31 @@ Leia uma palavra de 256 bits de um buffer de `bytes memory`. Essa função utili } ``` -O Yul não suporta estruturas de dados além de `uint256`, então quando você se refere a uma estrutura de dados mais sofisticada, como um buffer de memória `_bytes`, você obtém o endereço dessa estrutura. O Solidity armazena valores `bytes memory` como uma palavra de 32 bytes que contém o tamanho, seguida dos bytes reais, então, para obter o número de bytes `_start`, precisamos calcular `_bytes+32+_start`. +O Yul não suporta estruturas de dados além de `uint256`, então, quando você se refere a uma estrutura de dados mais sofisticada, como o buffer de memória `_bytes`, você obtém o endereço dessa estrutura. O Solidity armazena valores `bytes memory` como uma palavra de 32 bytes que contém o comprimento, seguida pelos bytes reais, então para obter o byte de número `_start` precisamos calcular `_bytes+32+_start`. ```solidity return tempUint; } // toUint256 - // Function signature for fourParams(), courtesy of + // Assinatura da função para fourParams(), cortesia de // https://www.4byte.directory/signatures/?bytes4_signature=0x3edc1e6d bytes4 constant FOUR_PARAMS = 0x3edc1e6d; - // Just some constant values to see we're getting the correct values back + // Apenas alguns valores constantes para ver se estamos recebendo os valores corretos de volta uint256 constant VAL_A = 0xDEAD60A7; uint256 constant VAL_B = 0xBEEF; uint256 constant VAL_C = 0x600D; uint256 constant VAL_D = 0x600D60A7; ``` -Algumas constantes de que precisamos para os testes. +Algumas constantes que precisamos para testar. ```solidity function testReadParam() public { ``` -Chame `fourParams()`, uma função que usa `readParams`, para testar nós podemos ler parâmetros corretamente. +Chame `fourParams()`, uma função que usa `readParams`, para testar se conseguimos ler os parâmetros corretamente. ```solidity address _cacheAddr = address(cache); @@ -436,7 +433,7 @@ Chame `fourParams()`, uma função que usa `readParams`, para testar nós podemo bytes memory _callOutput; ``` -Não podemos usar o mecanismo de ABI normal para chamar uma função usando o cache, por isso, precisamos usar o mecanismo de baixo nível [`
.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses). Esse mecanismo pega um `bytes memory` como entrada e retorna aquele (assim como o valor booleano) como saída. +Não podemos usar o mecanismo ABI normal para chamar uma função usando o cache, então precisamos usar o mecanismo de baixo nível [`
.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses). Esse mecanismo usa um `bytes memory` como entrada e o retorna (assim como um valor booleano) como saída. ```solidity // First call, the cache is empty @@ -444,15 +441,15 @@ Não podemos usar o mecanismo de ABI normal para chamar uma função usando o ca FOUR_PARAMS, ``` -É útil para o mesmo contrato suportar ambas funções em cache (para chamadas diretamente de transações) e funções não em cache (para chamadas de outros contratos inteligentes). Para fazer isso nós precisamos continuar a confiar no mecanismo Solidity para chamar a função correta, ao invés de pôr tudo em [uma função `fallback`](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function). Fazer isso torna a componibilidade muito mais fácil. Um único byte seria suficiente para identificar a função na maioria dos casos, por isso, estamos desperdiçando três bytes (16\*3=48 gás). No entanto, no momento em que escrevo este artigo, 48 gás custam 0,07 centavos de dólar, o que é um custo razoável para um código mais simples e menos sujeito a bugs. +É útil que o mesmo contrato suporte tanto funções em cache (para chamadas diretamente de transações) quanto funções não armazenadas em cache (para chamadas de outros contratos inteligentes). Para fazer isso, precisamos continuar a confiar no mecanismo do Solidity para chamar a função correta, em vez de colocar tudo em uma [função `fallback`](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function). Fazer isso torna a componentização muito mais fácil. Um único byte seria suficiente para identificar a função na maioria dos casos, então estamos desperdiçando três bytes (16\*3=48 de gás). No entanto, no momento em que escrevo, esses 48 de gás custam 0,07 centavos de dólar, o que é um custo razoável para um código mais simples e menos propenso a bugs. ```solidity - // First value, add it to the cache + // Primeiro valor, adicione-o ao cache cache.INTO_CACHE(), bytes32(VAL_A), ``` -O primeiro valor: Um sinalizador dizendo que é um valor que precisa ser escrito na cache, seguido pelos 32 bytes do valor. Os outros três valores são similares, exceto que `VAL_B` não é escrito no cache e `VAL_C` é ambos o terceiro e quarto parâmetros. +O primeiro valor: um sinalizador dizendo que é um valor completo que precisa ser escrito no cache, seguido pelos 32 bytes do valor. Os outros três valores são semelhantes, exceto que `VAL_B` não é escrito no cache e `VAL_C` é tanto o terceiro quanto o quarto parâmetro. ```solidity . @@ -468,14 +465,14 @@ O primeiro valor: Um sinalizador dizendo que é um valor que precisa ser escrito assertEq(_success, true); ``` -Nós esperamos que a chamada tenha sucesso. +Esperamos que a chamada seja bem-sucedida. ```solidity assertEq(cache.cacheRead(1), VAL_A); assertEq(cache.cacheRead(2), VAL_C); ``` -Nós começamos com uma cache vazia e então adicionamos `VAL_A` seguida de `VAL_C`. Nós esperaríamos a primeira ter a chave 1, e a segunda ter a 2. +Começamos com um cache vazio e depois adicionamos `VAL_A` seguido de `VAL_C`. Esperaríamos que o primeiro tivesse a chave 1 e o segundo a chave 2. ``` assertEq(toUint256(_callOutput,0), VAL_A); @@ -484,25 +481,25 @@ Nós começamos com uma cache vazia e então adicionamos `VAL_A` seguida de `VAL assertEq(toUint256(_callOutput,96), VAL_C); ``` -A saída é composta pelos quatro parâmetros. Aqui, verificamos que está correto. +A saída são os quatro parâmetros. Aqui verificamos que está correto. ```solidity - // Second call, we can use the cache + // Segunda chamada, podemos usar o cache _callInput = bytes.concat( FOUR_PARAMS, - // First value in the Cache + // Primeiro valor no Cache bytes1(0x01), ``` -As chaves de cache abaixo de 16 correspondem a apenas um byte. +Chaves de cache abaixo de 16 têm apenas um byte. ```solidity - // Second value, don't add it to the cache + // Segundo valor, não o adicione ao cache cache.DONT_CACHE(), bytes32(VAL_B), - // Third and fourth values, same value + // Terceiro e quarto valores, mesmo valor bytes1(0x02), bytes1(0x02) ); @@ -512,13 +509,13 @@ As chaves de cache abaixo de 16 correspondem a apenas um byte. } // testReadParam ``` -Os testes depois da chamada são idênticos a aqueles depois da primeira chamada. +Os testes após a chamada são idênticos aos da primeira chamada. ```solidity function testEncodeVal() public { ``` -Esta função é similar a `testReadParam`, exceto que ao invés de escrever os parâmetros explicitamente, nós usamos `encodeVal()`. +Esta função é semelhante a `testReadParam`, exceto que, em vez de escrever os parâmetros explicitamente, usamos `encodeVal()`. ```solidity . @@ -538,23 +535,23 @@ Esta função é similar a `testReadParam`, exceto que ao invés de escrever os } // testEncodeVal ``` -O único teste adicional em `testEncodeVal()` é verificar que o comprimento de `_callInput` está correto. Para a primeira chamada, ele é 4+33\*4. Para a segunda, na qual cada valor já está no cache, ele é 4+1\*4. +O único teste adicional em `testEncodeVal()` é verificar se o comprimento de `_callInput` está correto. Para a primeira chamada, é 4+33\*4. Para a segunda, onde cada valor já está no cache, é 4+1\*4. ```solidity - // Test encodeVal when the key is more than a single byte - // Maximum three bytes because filling the cache to four bytes takes - // too long. + // Testa encodeVal quando a chave tem mais de um byte + // Máximo de três bytes porque preencher o cache até quatro bytes leva + // muito tempo. function testEncodeValBig() public { - // Put a number of values in the cache. - // To keep things simple, use key n for value n. + // Coloca uma série de valores no cache. + // Para simplificar, use a chave n para o valor n. for(uint i=1; i<0x1FFF; i++) { cache.cacheWrite(i); } ``` -A função `testEncodeVal` acima somente escreve quatro valores na cache, então [a parte da função que lida com valores multi-byte](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) não é checada. Porém, esse código é complicado e sujeito a erros. +A função `testEncodeVal` acima apenas escreve quatro valores no cache, então [a parte da função que lida com valores de vários bytes](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) não é verificada. Mas esse código é complicado e propenso a erros. -A primeira parte dessa função é um loop que escreve todos os valores de 1 até 0x1FFF para o cache em ordem, a fim de podermos codificar esses valores e saber para onde eles estão indo. +A primeira parte desta função é um loop que escreve todos os valores de 1 a 0x1FFF no cache em ordem, para que possamos codificar esses valores e saber para onde eles estão indo. ```solidity . @@ -563,14 +560,14 @@ A primeira parte dessa função é um loop que escreve todos os valores de 1 at _callInput = bytes.concat( FOUR_PARAMS, - cache.encodeVal(0x000F), // One byte 0x0F - cache.encodeVal(0x0010), // Two bytes 0x1010 - cache.encodeVal(0x0100), // Two bytes 0x1100 - cache.encodeVal(0x1000) // Three bytes 0x201000 + cache.encodeVal(0x000F), // Um byte 0x0F + cache.encodeVal(0x0010), // Dois bytes 0x1010 + cache.encodeVal(0x0100), // Dois bytes 0x1100 + cache.encodeVal(0x1000) // Três bytes 0x201000 ); ``` -Teste valores de um byte, dois bytes e três bytes. Não testamos além disso, pois levaria tempo demais para escrever entradas de pilha suficientes (pelo menos 0x10000000, cerca de um quarto de bilhão). +Testa valores de um, dois e três bytes. Não testamos além disso porque levaria muito tempo para escrever entradas de pilha suficientes (pelo menos 0x10000000, aproximadamente um quarto de bilhão). ```solidity . @@ -580,11 +577,11 @@ Teste valores de um byte, dois bytes e três bytes. Não testamos além disso, p } // testEncodeValBig - // Test what with an excessively small buffer we get a revert + // Testa o que acontece com um buffer excessivamente pequeno para obter uma reversão function testShortCalldata() public { ``` -Teste o que acontece no caso anormal em que não há parâmetros suficientes. +Testa o que acontece no caso anormal em que não há parâmetros suficientes. ```solidity . @@ -595,10 +592,10 @@ Teste o que acontece no caso anormal em que não há parâmetros suficientes. } // testShortCalldata ``` -Como ele é revertido, o resultado deve ser `false`. +Como ele reverte, o resultado que devemos obter é `false`. ``` - // Call with cache keys that aren't there + // Chama com chaves de cache que não existem function testNoCacheKey() public { . . @@ -606,52 +603,52 @@ Como ele é revertido, o resultado deve ser `false`. _callInput = bytes.concat( FOUR_PARAMS, - // First value, add it to the cache + // Primeiro valor, adicione-o ao cache cache.INTO_CACHE(), bytes32(VAL_A), - // Second value + // Segundo valor bytes1(0x0F), bytes2(0x1234), bytes11(0xA10102030405060708090A) ); ``` -Esta função pega quatro parâmetros perfeitamente legítimos, exceto que a cache está vazia, então não há valores lá para ler. +Esta função obtém quatro parâmetros perfeitamente legítimos, exceto que o cache está vazio, então não há valores para ler. ```solidity . . . - // Test what with an excessively long buffer everything works file + // Testa o que acontece com um buffer excessivamente longo para ver se tudo funciona bem function testLongCalldata() public { address _cacheAddr = address(cache); bool _success; bytes memory _callInput; bytes memory _callOutput; - // First call, the cache is empty + // Primeira chamada, o cache está vazio _callInput = bytes.concat( FOUR_PARAMS, - // First value, add it to the cache + // Primeiro valor, adicione-o ao cache cache.INTO_CACHE(), bytes32(VAL_A), - // Second value, add it to the cache + // Segundo valor, adicione-o ao cache cache.INTO_CACHE(), bytes32(VAL_B), - // Third value, add it to the cache + // Terceiro valor, adicione-o ao cache cache.INTO_CACHE(), bytes32(VAL_C), - // Fourth value, add it to the cache + // Quarto valor, adicione-o ao cache cache.INTO_CACHE(), bytes32(VAL_D), - // And another value for "good luck" + // E outro valor para "dar sorte" bytes4(0x31112233) ); ``` -Esta função envia cinco valores. Sabemos que o quinto valor é ignorado porque não é uma entrada de cache válida, o que causaria uma reversão se não tivesse sido incluída. +Esta função envia cinco valores. Sabemos que o quinto valor é ignorado porque não é uma entrada de cache válida, o que teria causado uma reversão se não tivesse sido incluído. ```solidity (_success, _callOutput) = _cacheAddr.call(_callInput); @@ -665,13 +662,13 @@ Esta função envia cinco valores. Sabemos que o quinto valor é ignorado porque ``` -## Uma amostra do aplicativo {#a-sample-app} +## Um aplicativo de exemplo {#a-sample-app} -Escrever testes em Solidity é tudo muito bem, mas no final do dia, um dapp precisa ser capaz de processar requisições de fora da cadeia para ser útil. Este artigo demonstra como usar o cache em um dapp com `WORM`, que significa “escrever uma vez, ler várias” (em inglês, "Write Once, Read Many"). Se uma chave ainda não estiver escrita, você pode escrever um valor para ela. Se a chave já estiver escrita, você terá uma reversão. +Escrever testes em Solidity é muito bom, mas no final das contas um dapp precisa ser capaz de processar solicitações de fora da cadeia para ser útil. Este artigo demonstra como usar o cache em um dapp com `WORM`, que significa "Write Once, Read Many" (Escreva uma vez, leia muitas). Se uma chave ainda não foi escrita, você pode escrever um valor para ela. Se a chave já estiver escrita, você recebe uma reversão. ### O contrato {#the-contract} -[Este é o contrato](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol). Ele repete, em grande parte, o que já fizemos com `Cache` e `CacheTest`, então abrangeremos somente as partes que são interessantes. +[Este é o contrato](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol). Ele repete principalmente o que já fizemos com `Cache` e `CacheTest`, então abordaremos apenas as partes interessantes. ```solidity import "./Cache.sol"; @@ -679,7 +676,7 @@ import "./Cache.sol"; contract WORM is Cache { ``` -A maneira mais fácil de usar `Cache` é herdá-lo no seu próprio contrato. +A maneira mais fácil de usar o `Cache` é herdá-lo em nosso próprio contrato. ```solidity function writeEntryCached() external { @@ -688,59 +685,59 @@ A maneira mais fácil de usar `Cache` é herdá-lo no seu próprio contrato. } // writeEntryCached ``` -Essa função é similar a `fourParam` no `CacheTest` acima. Como nós não seguimos as especificações da ABI, é melhor não declarar nenhum parâmetro dentro da função. +Esta função é semelhante a `fourParam` em `CacheTest` acima. Como não seguimos as especificações da ABI, é melhor não declarar nenhum parâmetro na função. ```solidity - // Make it easier to call us - // Function signature for writeEntryCached(), courtesy of + // Facilita a chamada + // Assinatura da função para writeEntryCached(), cortesia de // https://www.4byte.directory/signatures/?bytes4_signature=0xe4e4f2d3 bytes4 constant public WRITE_ENTRY_CACHED = 0xe4e4f2d3; ``` -O código externo que chama `writeEntryCached` precisará construir manualmente o calldata, ao invés de usar `worm.writeEntryCached`, porque nós não seguimos as especificações da ABI. Tendo o valor desta constante só facilita escrevê-la. +O código externo que chama `writeEntryCached` precisará construir manualmente o calldata, em vez de usar `worm.writeEntryCached`, porque não seguimos as especificações da ABI. Ter esse valor constante apenas facilita a escrita. -Observe que, apesar de definirmos `WRITE_ENTRY_CACHED` como uma variável de estado, para lê-la externamente é necessário usar a função getter, `worm.WRITE_ENTRY_CACHED()`. +Observe que, embora definamos `WRITE_ENTRY_CACHED` como uma variável de estado, para lê-la externamente é necessário usar sua função getter, `worm.WRITE_ENTRY_CACHED()`. ```solidity function readEntry(uint key) public view returns (uint _value, address _writtenBy, uint _writtenAtBlock) ``` -A função de leitura é uma `view`, então ela não requer uma transação e não custa gas. Como resultado, não há benefício de usar cache para o parâmetro. Com funções view é melhor usar o mecanismo padrão, que é mais simples. +A função de leitura é uma `view`, portanto não requer uma transação e não custa gás. Como resultado, não há benefício em usar o cache para o parâmetro. Com funções de visualização, é melhor usar o mecanismo padrão que é mais simples. ### O código de teste {#the-testing-code} -[Este é o código de teste para o contrato](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol). Novamente, vamos ver somente o que é interessante. +[Este é o código de teste para o contrato](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol). Novamente, vamos olhar apenas para o que é interessante. ```solidity function testWReadWrite() public { worm.writeEntry(0xDEAD, 0x60A7); - vm.expectRevert(bytes("entry already written")); + vm.expectRevert(bytes("entrada já escrita")); worm.writeEntry(0xDEAD, 0xBEEF); ``` -[Este (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) é como especificamos em um teste Foundry que a próxima chamada deve falhar, assim como a razão dessa falha. Isto se aplica quando nós usamos a sintaxe `.()` ao invés de construir o calldata e chamar o contrato usando interface de baixo nível (`.call()`, etc.). +[Isso (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) é como especificamos em um teste da Foundry que a próxima chamada deve falhar e o motivo relatado para a falha. Isso se aplica quando usamos a sintaxe `.`() em vez de construir o calldata e chamar o contrato usando a interface de baixo nível (`.call()`, etc.). ```solidity function testReadWriteCached() public { uint cacheGoat = worm.cacheWrite(0x60A7); ``` -Aqui nós usamos o fato de `cacheWrite` retornar a chave da cache. Isto não é algo que nós esperaríamos usar em produção, porque `cacheWrite` altera o estado, e por isso pode ser chamado apenas durante a transação. Transações não têm valores de retorno. Se elas têm resultados, esses resultados devem ser supostamente emitidos como eventos. Assim, o valor de retorno de `cacheWrite` é somente acessível do código on-chain, e o código on-chain não precisa armazenar parâmetros em cache. +Aqui usamos o fato de que `cacheWrite` retorna a chave do cache. Isso não é algo que esperaríamos usar em produção, porque `cacheWrite` altera o estado e, portanto, só pode ser chamado durante uma transação. As transações não têm valores de retorno; se tiverem resultados, esses resultados devem ser emitidos como eventos. Portanto, o valor de retorno `cacheWrite` só é acessível a partir do código na cadeia (on-chain), e o código na cadeia não precisa de cache de parâmetros. ```solidity (_success,) = address(worm).call(_callInput); ``` -É assim que contamos ao Solidity que, enquanto `.call()` tem dois valores de retorno, só nos importamos com o primeiro. +É assim que dizemos ao Solidity que, embora `.call()` tenha dois valores de retorno, só nos importamos com o primeiro. ```solidity (_success,) = address(worm).call(_callInput); assertEq(_success, false); ``` -Como usamos a função de baixo nível `
.call()`, não podemos usar `vm.expectRevert()` e temos de olhar para o valor de êxito booleano que obtivemos da chamada. +Como usamos a função de baixo nível `
.call()`, não podemos usar `vm.expectRevert()` e temos que observar o valor de sucesso booleano que obtemos da chamada. ```solidity event EntryWritten(uint indexed key, uint indexed value); @@ -756,13 +753,13 @@ Como usamos a função de baixo nível `
.call()`, não podemos usar `vm (_success,) = address(worm).call(_callInput); ``` -Essa é a maneira que verificamos que o código [emite um evento corretamente](https://book.getfoundry.sh/cheatcodes/expect-emit) no Foundry. +É assim que verificamos se o código [emite um evento corretamente](https://getfoundry.sh/reference/cheatcodes/expect-emit/) na Foundry. ### O cliente {#the-client} -Uma coisa que você não obtém com testes no Solidity é código JavaScript, que você pode cortar e colar no seu próprio aplicativo. Para escrever este código, implantei WORM na [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli), a nova rede de teste da [Optimism](https://www.optimism.io/). Ela está no endereço [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a). +Uma coisa que você não obtém com os testes do Solidity é o código JavaScript que você pode cortar e colar em seu próprio aplicativo. Para escrever esse código, implantei o WORM na [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli), a nova [rede de teste](https://www.optimism.io/) da [Optimism](https://www.optimism.io/). Ele está no endereço [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a). -[Você pode ver o código JavaScript para o cliente aqui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js). Para usá-lo: +[Você pode ver o código JavaScript do cliente aqui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js). Para usá-lo: 1. Clone o repositório git: @@ -783,22 +780,22 @@ Uma coisa que você não obtém com testes no Solidity é código JavaScript, qu cp .env.example .env ``` -4. Edite `.env` para a sua configuração: +4. Edite o `.env` para sua configuração: - | Parâmetro | Valor | - | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | MNEMÔNICO | O mnemônico para uma conta que tem ETH suficiente para pagar por uma transação. [Você consegue ETH grátis para a rede Optimism Goerli aqui](https://optimismfaucet.xyz/). | - | OPTIMISM_GOERLI_URL | URL da Optimism Goerli. O endpoint público, `https://goerli.optimism.io`, tem taxa limitada mas suficiente para o que precisamos aqui | + | Parâmetro | Valor | + | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | + | MNEMÔNICO | O mnemônico de uma conta que tem ETH suficiente para pagar por uma transação. [Você pode obter ETH grátis para a rede Optimism Goerli aqui](https://optimismfaucet.xyz/). | + | OPTIMISM_GOERLI_URL | URL para a Optimism Goerli. O endpoint público, `https://goerli.optimism.io`, tem taxa limitada, mas é suficiente para o que precisamos aqui | -5. Rode `index.js`. +5. Execute o `index.js`. ```sh node index.js ``` - Primeiro, esse exemplo de aplicativo escreve uma entrada para WORM, exibindo o calldata e um link para a transação no Etherscan. Em seguida, ele lê novamente essa entrada e exibe a chave que usou e os valores na entrada (valor, bloco, número e autor). + Este aplicativo de exemplo primeiro escreve uma entrada no WORM, exibindo o calldata e um link para a transação no Etherscan. Em seguida, ele lê essa entrada e exibe a chave que usa e os valores na entrada (valor, número do bloco e autor). -A maioria dos clientes é Javascript Dapp normal. Então, novamente, passaremos apenas pelas partes interessantes. +A maior parte do cliente é JavaScript de Dapp normal. Então, novamente, vamos abordar apenas as partes interessantes. ```javascript . @@ -807,20 +804,20 @@ A maioria dos clientes é Javascript Dapp normal. Então, novamente, passaremos const main = async () => { const func = await worm.WRITE_ENTRY_CACHED() - // Need a new key every time + // Precisa de uma nova chave a cada vez const key = await worm.encodeVal(Number(new Date())) ``` -Um dado slot pode ser apenas escrito uma vez, então usamos o carimbo de data/hora para ter certeza de que não vamos reutilizar esses slots. +Um determinado slot só pode ser escrito uma vez, então usamos o carimbo de data/hora para garantir que não reutilizamos slots. ```javascript const val = await worm.encodeVal("0x600D") -// Write an entry +// Escreve uma entrada const calldata = func + key.slice(2) + val.slice(2) ``` -Ethers espera que o dado da chamada seja uma cadeia de caracteres hexadecimal, `0x` seguida de um número par de dígitos hexadecimais. Como `key` e `val` começam com `0x`, precisamos remover esses cabeçalhos. +O Ethers espera que os dados da chamada sejam uma string hexadecimal, `0x` seguido por um número par de dígitos hexadecimais. Como tanto `key` quanto `val` começam com `0x`, precisamos remover esses cabeçalhos. ```javascript const tx = await worm.populateTransaction.writeEntryCached() @@ -829,39 +826,42 @@ tx.data = calldata sentTx = await wallet.sendTransaction(tx) ``` -Como no código de teste Solidity, não podemos chamar uma função em cache normalmente. Ao invés disso, nós precisamos usar um mecanismo de nível mais baixo. +Assim como no código de teste do Solidity, não podemos chamar uma função em cache normalmente. Em vez disso, precisamos usar um mecanismo de nível inferior. ```javascript . . . - // Read the entry just written - const realKey = '0x' + key.slice(4) // remove the FF flag + // Lê a entrada que acabou de ser escrita + const realKey = '0x' + key.slice(4) // remove o sinalizador FF const entryRead = await worm.readEntry(realKey) . . . ``` -Para ler entradas, podemos usar o mecanismo normal. Não há necessidade de armazenar em cache parâmetros com funções `view`. +Para ler as entradas, podemos usar o mecanismo normal. Não há necessidade de usar cache de parâmetros com funções `view`. ## Conclusão {#conclusion} -O código neste artigo é uma prova de conceito, a finalidade é tornar a ideia fácil de entender. Para um sistema pronto para produção, recomenda-se implementar funcionalidades adicionais: +O código neste artigo é uma prova de conceito, o objetivo é tornar a ideia fácil de entender. Para um sistema pronto para produção, você pode querer implementar algumas funcionalidades adicionais: -- Manipular valores que não são `uint256`. Por exemplo, cadeias de caracteres. -- Em vez de um cache global, talvez ter um mapeamento entre usuários e caches. Usuários diferentes usam valores diferentes. -- Valores usados para endereços são distintos daqueles usados para outras finalidades. Pode fazer sentido ter um cache separado só para endereços. -- Atualmente, as chaves de cache estão em um algoritmo do tipo “o primeiro que chega tem a chave menor”. Os primeiros dezesseis valores podem ser enviados como um único byte. Os próximos 4.080 valores podem ser enviados como dois bytes. Os próximos milhões de valores são três bytes, etc. Um sistema de produção deveria manter contadores de uso nas entradas de cache e reorganizá-las para que os dezesseis _mais comuns_ valores sejam um byte, os próximos 4080 valores mais comuns sejam dois bytes, etc. +- Lidar com valores que não são `uint256`. Por exemplo, strings. +- Em vez de um cache global, talvez tenha um mapeamento entre usuários e caches. Diferentes usuários usam valores diferentes. +- Os valores usados para endereços são distintos daqueles usados para outros fins. Pode fazer sentido ter um cache separado apenas para endereços. +- Atualmente, as chaves do cache estão em um algoritmo "primeiro a chegar, chave menor". Os primeiros dezesseis valores podem ser enviados como um único byte. Os próximos 4080 valores podem ser enviados como dois bytes. Os próximos aproximadamente um milhão de valores são três bytes, etc. Um sistema de produção deve manter contadores de uso nas entradas de cache e reorganizá-los para que os dezesseis valores _mais comuns_ sejam de um byte, os próximos 4080 valores mais comuns de dois bytes, etc. No entanto, essa é uma operação potencialmente perigosa. Imagine a seguinte sequência de eventos: - 1. Noam Naive chama `encodeVal` para codificar o endereço para o qual ele quer enviar tokens. Este endereço é um dos primeiros usados na aplicação, então o valor codificado é 0x06. Trata-se de uma função `view`, e não uma transação, então ela diz respeito unicamente a Noam e ao nó que ele usa, e ninguém mais sabe disso + 1. Noam Naive chama `encodeVal` para codificar o endereço para o qual ele quer enviar tokens. Esse endereço é um dos primeiros usados no aplicativo, então o valor codificado é 0x06. Esta é uma função `view`, não uma transação, então é entre Noam e o nó que ele usa, e mais ninguém sabe sobre isso + + 2. Owen Owner executa a operação de reordenação do cache. Pouquíssimas pessoas realmente usam esse endereço, então ele agora é codificado como 0x201122. Um valor diferente, 1018, é atribuído a 0x06. + + 3. Noam Naive envia seus tokens para 0x06. Eles vão para o endereço `0x0000000000000000000000000de0b6b3a7640000`, e como ninguém conhece a chave privada para esse endereço, eles ficam presos lá. Noam _não está feliz_. - 2. Owen Owner executa a operação de reordenação de cache. Muito poucas pessoas realmente usam esse endereço, por isso, ele é agora codificado como 0x201122. Para um valor diferente, 1018, é atribuído 0x06. + Existem maneiras de resolver esse problema e o problema relacionado às transações que estão na mempool durante a reordenação do cache, mas você deve estar ciente disso. - 3. Noam Naive envia seus tokens para 0x06. Eles vão para o endereço `0x0000000000000000000000000de0b6b3a7640000`, e já que ninguém sabe a chave privada para esse endereço, eles ficam presos lá. Noam _não está contente_. +Demonstrei o cache aqui com a Optimism, porque sou um funcionário da Optimism e este é o rollup que conheço melhor. Mas deve funcionar com qualquer rollup que cobre um custo mínimo para processamento interno, de modo que, em comparação, escrever os dados da transação na L1 seja a maior despesa. - Existem maneiras de resolver esse problema, e o problema relacionado às transações que estão na mempool durante a reordenação do cache, mas você deve estar atento a isso. +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). -Demonstrei o processo de armazenamento em cache aqui com o Optimism, porque sou funcionário da Optimism e esse é o roll-up que conheço melhor. Mas deve funcionar com qualquer rollup que cobre um mínimo custo por processamento interno, de modo que em comparação com escrever os dados da transação na L1 é a maior despesa. diff --git a/public/content/translations/pt-br/developers/tutorials/app-plasma/index.md b/public/content/translations/pt-br/developers/tutorials/app-plasma/index.md new file mode 100644 index 00000000000..ec6068d089b --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/app-plasma/index.md @@ -0,0 +1,1261 @@ +--- +title: "Escreva um plasma específico de aplicativo que preserva a privacidade" +description: "Neste tutorial, criamos um banco semissecreto para depósitos. O banco é um componente centralizado; ele conhece o saldo de cada usuário. No entanto, esta informação não é armazenada na cadeia. Em vez disso, o banco publica um hash do estado. Sempre que uma transação ocorre, o banco publica o novo hash, juntamente com uma prova de conhecimento zero de que tem uma transação assinada que altera o estado do hash para o novo. Após ler este tutorial, você entenderá não apenas como usar provas de conhecimento zero, mas também por que você as usa e como fazê-lo com segurança." +author: Ori Pomerantz +tags: + [ + "conhecimento zero", + "servidor", + "fora da cadeia", + "privacidade" + ] +skill: advanced +lang: pt-br +published: 2025-10-15 +--- + +## Introdução {#introduction} + +Em contraste com [rollups](/developers/docs/scaling/zk-rollups/), [plasmas](/developers/docs/scaling/plasma) usam a mainnet do Ethereum para integridade, mas não para disponibilidade. Neste artigo, escrevemos um aplicativo que se comporta como um plasma, com o Ethereum garantindo integridade (sem alterações não autorizadas), mas não disponibilidade (um componente centralizado pode cair e desativar todo o sistema). + +O aplicativo que escrevemos aqui é um banco que preserva a privacidade. Diferentes endereços têm contas com saldos, e eles podem enviar dinheiro (ETH) para outras contas. O banco publica hashes do estado (contas e seus saldos) e transações, mas mantém os saldos reais fora da cadeia, onde eles podem permanecer privados. + +## Design {#design} + +Este não é um sistema pronto para produção, mas uma ferramenta de ensino. Como tal, é escrito com várias suposições simplificadoras. + +- Conjunto de contas fixo. Há um número específico de contas, e cada conta pertence a um endereço predeterminado. Isso torna o sistema muito mais simples, porque é difícil lidar com estruturas de dados de tamanho variável em provas de conhecimento zero. Para um sistema pronto para produção, podemos usar a [raiz de Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) como o hash de estado e fornecer provas de Merkle para os saldos necessários. + +- Armazenamento de memória. Em um sistema de produção, precisamos escrever todos os saldos das contas no disco para preservá-los em caso de reinicialização. Aqui, não há problema se a informação for simplesmente perdida. + +- Apenas transferências. Um sistema de produção exigiria uma maneira de depositar ativos no banco e retirá-los. Mas o objetivo aqui é apenas ilustrar o conceito, então este banco está limitado a transferências. + +### Provas de conhecimento zero {#zero-knowledge-proofs} + +Em um nível fundamental, uma prova de conhecimento zero mostra que o provador conhece alguns dados, _Dadosprivados_ de tal forma que existe uma relação _Relação_ entre alguns dados públicos, _Dadospúblicos_, e _Dadosprivados_. O verificador conhece a _Relação_ e os _Dadospúblicos_. + +Para preservar a privacidade, precisamos que os estados e as transações sejam privados. Mas para garantir a integridade, precisamos que o [hash criptográfico](https://en.wikipedia.org/wiki/Cryptographic_hash_function) dos estados seja público. Para provar às pessoas que enviam transações que essas transações realmente aconteceram, também precisamos publicar os hashes das transações. + +Na maioria dos casos, _Dadosprivados_ são a entrada para o programa de prova de conhecimento zero, e _Dadospúblicos_ são a saída. + +Estes campos em _Dadosprivados_: + +- _Estadon_, o estado antigo +- _Estadon+1_, o novo estado +- _Transação_, uma transação que muda do estado antigo para o novo. Essa transação precisa incluir estes campos: + - _Endereço de destino_ que recebe a transferência + - _Valor_ sendo transferido + - _Nonce_ para garantir que cada transação possa ser processada apenas uma vez. + O endereço de origem não precisa estar na transação, porque pode ser recuperado da assinatura. +- _Assinatura_, uma assinatura que está autorizada a realizar a transação. No nosso caso, o único endereço autorizado a realizar uma transação é o endereço de origem. Como nosso sistema de conhecimento zero funciona da maneira que funciona, também precisamos da chave pública da conta, além da assinatura do Ethereum. + +Estes são os campos em _Dadospúblicos_: + +- _Hash(Estadon)_ o hash do estado antigo +- _Hash(Estadon+1)_ o hash do novo estado +- _Hash(Transação)_ o hash da transação que muda o estado de _Estadon_ para _Estadon+1_. + +A relação verifica várias condições: + +- Os hashes públicos são de fato os hashes corretos para os campos privados. +- A transação, quando aplicada ao estado antigo, resulta no novo estado. +- A assinatura vem do endereço de origem da transação. + +Devido às propriedades das funções de hash criptográficas, provar essas condições é suficiente para garantir a integridade. + +### Estruturas de dados {#data-structures} + +A estrutura de dados primária é o estado mantido pelo servidor. Para cada conta, o servidor rastreia o saldo da conta e um [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce), usado para prevenir [ataques de repetição](https://en.wikipedia.org/wiki/Replay_attack). + +### Componentes {#components} + +Este sistema requer dois componentes: + +- O _servidor_ que recebe transações, as processa e publica os hashes na cadeia juntamente com as provas de conhecimento zero. +- Um _contrato inteligente_ que armazena os hashes e verifica as provas de conhecimento zero para garantir que as transições de estado sejam legítimas. + +### Fluxo de dados e controle {#flows} + +Estas são as maneiras como os vários componentes se comunicam para transferir de uma conta para outra. + +1. Um navegador da web envia uma transação assinada solicitando uma transferência da conta do signatário para uma conta diferente. + +2. O servidor verifica se a transação é válida: + + - O signatário tem uma conta no banco com saldo suficiente. + - O destinatário tem uma conta no banco. + +3. O servidor calcula o novo estado subtraindo o valor transferido do saldo do signatário e adicionando-o ao saldo do destinatário. + +4. O servidor calcula uma prova de conhecimento zero de que a mudança de estado é válida. + +5. O servidor envia ao Ethereum uma transação que inclui: + + - O novo hash de estado + - O hash da transação (para que o remetente da transação saiba que foi processada) + - A prova de conhecimento zero que comprova que a transição para o novo estado é válida + +6. O contrato inteligente verifica a prova de conhecimento zero. + +7. Se a prova de conhecimento zero for verificada, o contrato inteligente executa estas ações: + - Atualiza o hash do estado atual para o novo hash de estado + - Emite uma entrada de log com o novo hash de estado e o hash da transação + +### Ferramentas {#tools} + +Para o código do lado do cliente, vamos usar [Vite](https://vite.dev/), [React](https://react.dev/), [Viem](https://viem.sh/) e [Wagmi](https://wagmi.sh/). Estas são ferramentas padrão da indústria; se você não estiver familiarizado com elas, pode usar [este tutorial](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). + +A maior parte do servidor é escrita em JavaScript usando [Node](https://nodejs.org/en). A parte de conhecimento zero é escrita em [Noir](https://noir-lang.org/). Precisamos da versão `1.0.0-beta.10`, então depois de [instalar o Noir conforme as instruções](https://noir-lang.org/docs/getting_started/quick_start), execute: + +``` +noirup -v 1.0.0-beta.10 +``` + +A blockchain que usamos é a `anvil`, uma blockchain de teste local que faz parte da [Foundry](https://getfoundry.sh/introduction/installation). + +## Implementação {#implementation} + +Como este é um sistema complexo, vamos implementá-lo em etapas. + +### Etapa 1 - Conhecimento zero manual {#stage-1} + +Na primeira etapa, assinaremos uma transação no navegador e, em seguida, forneceremos manualmente as informações para a prova de conhecimento zero. O código de conhecimento zero espera obter essa informação em `server/noir/Prover.toml` (documentado [aqui](https://noir-lang.org/docs/getting_started/project_breakdown#provertoml-1)). + +Para ver em ação: + +1. Certifique-se de ter o [Node](https://nodejs.org/en/download) e o [Noir](https://noir-lang.org/install) instalados. De preferência, instale-os em um sistema UNIX como macOS, Linux ou [WSL](https://learn.microsoft.com/en-us/windows/wsl/install). + +2. Baixe o código da etapa 1 e inicie o servidor da web para servir o código do cliente. + + ```sh + git clone https://github.com/qbzzt/250911-zk-bank.git -b 01-manual-zk + cd 250911-zk-bank + cd client + npm install + npm run dev + ``` + + A razão pela qual você precisa de um servidor web aqui é que, para evitar certos tipos de fraude, muitas carteiras (como a MetaMask) não aceitam arquivos servidos diretamente do disco + +3. Abra um navegador com uma carteira. + +4. Na carteira, insira uma nova frase secreta. Observe que isso excluirá sua frase secreta existente, então _certifique-se de ter um backup_. + + A frase secreta é `test test test test test test test test test test test junk`, a frase secreta de teste padrão para o anvil. + +5. Acesse [o código do lado do cliente](http://localhost:5173/). + +6. Conecte-se à carteira e selecione sua conta de destino e o valor. + +7. Clique em **Assinar** e assine a transação. + +8. Sob o título **Prover.toml**, você encontrará um texto. Substitua `server/noir/Prover.toml` por esse texto. + +9. Execute a prova de conhecimento zero. + + ```sh + cd ../server/noir + nargo execute + ``` + + A saída deve ser semelhante a + + ``` + ori@CryptoDocGuy:~/noir/250911-zk-bank/server/noir$ nargo execute + + [zkBank] Circuit witness successfully solved + [zkBank] Witness saved to target/zkBank.gz + [zkBank] Circuit output: (0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b, 0x0cfc0a67cb7308e4e9b254026b54204e34f6c8b041be207e64c5db77d95dd82d, 0x450cf9da6e180d6159290554ae3d8787, 0x6d8bc5a15b9037e52fb59b6b98722a85) + ``` + +10. Compare os dois últimos valores com o hash que você vê no navegador da web para ver se a mensagem foi transformada em hash corretamente. + +#### `server/noir/Prover.toml` {#server-noir-prover-toml} + +[Este arquivo](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) mostra o formato de informação esperado pelo Noir. + +```toml +message="send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 500 finney (milliEth) 0 " +``` + +A mensagem está em formato de texto, o que facilita o entendimento do usuário (o que é necessário ao assinar) e a análise pelo código Noir. O valor é cotado em finneys para permitir transferências fracionárias, por um lado, e ser facilmente legível, por outro. O último número é o [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). + +A string tem 100 caracteres de comprimento. As provas de conhecimento zero não lidam bem com dados de tamanho variável, por isso muitas vezes é necessário preencher os dados. + +```toml +pubKeyX=["0x83",...,"0x75"] +pubKeyY=["0x35",...,"0xa5"] +signature=["0xb1",...,"0x0d"] +``` + +Esses três parâmetros são matrizes de bytes de tamanho fixo. + +```toml +[[accounts]] +address="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" +balance=100_000 +nonce=0 + +[[accounts]] +address="0x70997970C51812dc3A010C7d01b50e0d17dc79C8" +balance=100_000 +nonce=0 +``` + +Esta é a maneira de especificar uma matriz de estruturas. Para cada entrada, especificamos o endereço, o saldo (em milliETH, também conhecido como [finney](https://cryptovalleyjournal.com/glossary/finney/)), e o próximo valor do nonce. + +#### `client/src/Transfer.tsx` {#client-src-transfer-tsx} + +[Este arquivo](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/client/src/Transfer.tsx) implementa o processamento do lado do cliente e gera o arquivo `server/noir/Prover.toml` (aquele que inclui os parâmetros de conhecimento zero). + +Aqui está a explicação das partes mais interessantes. + +```tsx +export default attrs => { +``` + +Esta função cria o componente React `Transfer`, que outros arquivos podem importar. + +```tsx + const accounts = [ + "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + "0x70997970C51812dc3A010C7d01b50e0d17dc79C8", + "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC", + "0x90F79bf6EB2c4f870365E785982E1f101E93b906", + "0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65", + ] +``` + +Estes são os endereços das contas, os endereços criados pelo `test ...` frase secreta `test junk`. Se você quiser usar seus próprios endereços, basta modificar esta definição. + +```tsx + const account = useAccount() + const wallet = createWalletClient({ + transport: custom(window.ethereum!) + }) +``` + +Estes [hooks da Wagmi](https://wagmi.sh/react/api/hooks) nos permitem acessar a biblioteca [viem](https://viem.sh/) e a carteira. + +```tsx + const message = `send ${toAccount} ${ethAmount*1000} finney (milliEth) ${nonce}`.padEnd(100, " ") +``` + +Esta é a mensagem, preenchida com espaços. Toda vez que uma das variáveis [`useState`](https://react.dev/reference/react/useState) muda, o componente é redesenhado e a `message` é atualizada. + +```tsx + const sign = async () => { +``` + +Esta função é chamada quando o usuário clica no botão **Assinar**. A mensagem é atualizada automaticamente, mas a assinatura requer a aprovação do usuário na carteira, e não queremos pedi-la a menos que seja necessário. + +```tsx + const signature = await wallet.signMessage({ + account: fromAccount, + message, + }) +``` + +Peça à carteira para [assinar a mensagem](https://viem.sh/docs/accounts/local/signMessage). + +```tsx + const hash = hashMessage(message) +``` + +Obtenha o hash da mensagem. É útil fornecê-lo ao usuário para depuração (do código Noir). + +```tsx + const pubKey = await recoverPublicKey({ + hash, + signature + }) +``` + +[Obtenha a chave pública](https://viem.sh/docs/utilities/recoverPublicKey). Isso é necessário para a função `ecrecover` do [Noir](https://github.com/colinnielsen/ecrecover-noir). + +```tsx + setSignature(signature) + setHash(hash) + setPubKey(pubKey) +``` + +Defina as variáveis de estado. Fazer isso redesenha o componente (após a saída da função `sign`) e mostra ao usuário os valores atualizados. + +```tsx + let proverToml = ` +``` + +O texto para `Prover.toml`. + +```tsx +message="${message}" + +pubKeyX=${hexToArray(pubKey.slice(4,4+2*32))} +pubKeyY=${hexToArray(pubKey.slice(4+2*32))} +``` + +Viem nos fornece a chave pública como uma string hexadecimal de 65 bytes. O primeiro byte é `0x04`, um marcador de versão. Isso é seguido por 32 bytes para o `x` da chave pública e, em seguida, 32 bytes para o `y` da chave pública. + +No entanto, o Noir espera obter essa informação como duas matrizes de bytes, uma para `x` e outra para `y`. É mais fácil analisá-lo aqui no cliente do que como parte da prova de conhecimento zero. + +Observe que esta é uma boa prática em conhecimento zero em geral. O código dentro de uma prova de conhecimento zero é caro, então qualquer processamento que possa ser feito fora da prova de conhecimento zero _deve_ ser feito fora da prova de conhecimento zero. + +```tsx +signature=${hexToArray(signature.slice(2,-2))} +``` + +A assinatura também é fornecida como uma string hexadecimal de 65 bytes. No entanto, o último byte só é necessário para recuperar a chave pública. Como a chave pública já será fornecida ao código Noir, não precisamos dela para verificar a assinatura, e o código Noir não a exige. + +```tsx +${accounts.map(accountInProverToml).reduce((a,b) => a+b, "")} +` +``` + +Forneça as contas. + +```tsx + setProverToml(proverToml) + } + + return ( + <> +

Transferência

+``` + +Este é o formato HTML (mais precisamente, [JSX](https://react.dev/learn/writing-markup-with-jsx)) do componente. + +#### `server/noir/src/main.nr` {#server-noir-src-main-nr} + +[Este arquivo](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/src/main.nr) é o código de conhecimento zero real. + +``` +use std::hash::pedersen_hash; +``` + +O [hash de Pedersen](https://rya-sge.github.io/access-denied/2024/05/07/pedersen-hash-function/) é fornecido com a [biblioteca padrão do Noir](https://noir-lang.org/docs/noir/standard_library/cryptographic_primitives/hashes#pedersen_hash). As provas de conhecimento zero comumente usam esta função de hash. É muito mais fácil de calcular dentro de [circuitos aritméticos](https://rareskills.io/post/arithmetic-circuit) em comparação com as funções de hash padrão. + +``` +use keccak256::keccak256; +use dep::ecrecover; +``` + +Estas duas funções são bibliotecas externas, definidas em [`Nargo.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Nargo.toml). Elas são precisamente o que seus nomes indicam, uma função que calcula o [hash keccak256](https://emn178.github.io/online-tools/keccak_256.html) e uma função que verifica assinaturas do Ethereum e recupera o endereço Ethereum do signatário. + +``` +global ACCOUNT_NUMBER : u32 = 5; +``` + +Noir é inspirado em [Rust](https://www.rust-lang.org/). As variáveis, por padrão, são constantes. É assim que definimos constantes de configuração globais. Especificamente, `ACCOUNT_NUMBER` é o número de contas que armazenamos. + +Tipos de dados nomeados `u` são esse número de bits, sem sinal. Os únicos tipos suportados são `u8`, `u16`, `u32`, `u64` e `u128`. + +``` +global FLAT_ACCOUNT_FIELDS : u32 = 2; +``` + +Essa variável é usada para o hash de Pedersen das contas, como explicado abaixo. + +``` +global MESSAGE_LENGTH : u32 = 100; +``` + +Como explicado acima, o comprimento da mensagem é fixo. Ele é especificado aqui. + +``` +global ASCII_MESSAGE_LENGTH : [u8; 3] = [0x31, 0x30, 0x30]; +global HASH_BUFFER_SIZE : u32 = 26+3+MESSAGE_LENGTH; +``` + +As [assinaturas EIP-191](https://eips.ethereum.org/EIPS/eip-191) requerem um buffer com um prefixo de 26 bytes, seguido pelo comprimento da mensagem em ASCII e, finalmente, a própria mensagem. + +``` +struct Account { + balance: u128, + address: Field, + nonce: u32, +} +``` + +A informação que armazenamos sobre uma conta. [`Field`](https://noir-lang.org/docs/noir/concepts/data_types/fields) é um número, normalmente até 253 bits, que pode ser usado diretamente no [circuito aritmético](https://rareskills.io/post/arithmetic-circuit) que implementa a prova de conhecimento zero. Aqui usamos o `Field` para armazenar um endereço Ethereum de 160 bits. + +``` +struct TransferTxn { + from: Field, + to: Field, + amount: u128, + nonce: u32 +} +``` + +A informação que armazenamos para uma transação de transferência. + +``` +fn flatten_account(account: Account) -> [Field; FLAT_ACCOUNT_FIELDS] { +``` + +Uma definição de função. O parâmetro é a informação da `Conta`. O resultado é uma matriz de variáveis `Field`, cujo comprimento é `FLAT_ACCOUNT_FIELDS` + +``` + let flat = [ + account.address, + ((account.balance << 32) + account.nonce.into()).into(), + ]; +``` + +O primeiro valor na matriz é o endereço da conta. O segundo inclui tanto o saldo quanto o nonce. As chamadas `.into()` mudam um número para o tipo de dados que ele precisa ser. `account.nonce` é um valor `u32`, mas para adicioná-lo a `account.balance << 32`, um valor `u128`, ele precisa ser um `u128`. Esse é o primeiro `.into()`. O segundo converte o resultado `u128` em um `Field` para que ele se encaixe na matriz. + +``` + flat +} +``` + +No Noir, as funções só podem retornar um valor no final (não há retorno antecipado). Para especificar o valor de retorno, você o avalia pouco antes do colchete de fechamento da função. + +``` +fn flatten_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] { +``` + +Esta função transforma a matriz de contas em uma matriz `Field`, que pode ser usada como entrada para um Hash de Petersen. + +``` + let mut flat: [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] = [0; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER]; +``` + +Esta é a forma de especificar uma variável mutável, ou seja, _não_ uma constante. As variáveis no Noir devem sempre ter um valor, então inicializamos esta variável com todos os zeros. + +``` + for i in 0..ACCOUNT_NUMBER { +``` + +Este é um loop `for`. Note que os limites são constantes. Os loops do Noir precisam ter seus limites conhecidos em tempo de compilação. A razão é que os circuitos aritméticos não suportam o controle de fluxo. Ao processar um loop `for`, o compilador simplesmente coloca o código dentro dele várias vezes, uma para cada iteração. + +``` + let fields = flatten_account(accounts[i]); + for j in 0..FLAT_ACCOUNT_FIELDS { + flat[i*FLAT_ACCOUNT_FIELDS + j] = fields[j]; + } + } + + flat +} + +fn hash_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> Field { + pedersen_hash(flatten_accounts(accounts)) +} +``` + +Finalmente, chegamos à função que gera o hash da matriz de contas. + +``` +fn find_account(accounts: [Account; ACCOUNT_NUMBER], address: Field) -> u32 { + let mut account : u32 = ACCOUNT_NUMBER; + + for i in 0..ACCOUNT_NUMBER { + if accounts[i].address == address { + account = i; + } + } +``` + +Essa função encontra a conta com um endereço específico. Esta função seria terrivelmente ineficiente em código padrão porque itera sobre todas as contas, mesmo depois de ter encontrado o endereço. + +No entanto, em provas de conhecimento zero, não há controle de fluxo. Se precisarmos verificar uma condição, teremos que verificá-la todas as vezes. + +Algo semelhante acontece com as instruções `if`. A instrução `if` no loop acima é traduzida para estas declarações matemáticas. + +_resultadocondição = contas[i].endereço == endereço_ // um se forem iguais, zero caso contrário + +_contanova = resultadocondição\*i + (1-resultadocondição)\*contaantiga_ + +```rust + assert (account < ACCOUNT_NUMBER, f"{address} does not have an account"); + + account +} +``` + +A função [`assert`](https://noir-lang.org/docs/dev/noir/concepts/assert) faz com que a prova de conhecimento zero falhe se a asserção for falsa. Neste caso, se não conseguirmos encontrar uma conta com o endereço relevante. Para relatar o endereço, usamos uma [string de formatação](https://noir-lang.org/docs/noir/concepts/data_types/strings#format-strings). + +```rust +fn apply_transfer_txn(accounts: [Account; ACCOUNT_NUMBER], txn: TransferTxn) -> [Account; ACCOUNT_NUMBER] { +``` + +Esta função aplica uma transação de transferência e retorna a nova matriz de contas. + +```rust + let from = find_account(accounts, txn.from); + let to = find_account(accounts, txn.to); + + let (txnFrom, txnAmount, txnNonce, accountNonce) = + (txn.from, txn.amount, txn.nonce, accounts[from].nonce); +``` + +Não podemos acessar elementos da estrutura dentro de uma string de formato no Noir, então criamos uma cópia utilizável. + +```rust + assert (accounts[from].balance >= txn.amount, + f"{txnFrom} does not have {txnAmount} finney"); + + assert (accounts[from].nonce == txn.nonce, + f"Transaction has nonce {txnNonce}, but the account is expected to use {accountNonce}"); +``` + +Estas são duas condições que podem tornar uma transação inválida. + +```rust + let mut newAccounts = accounts; + + newAccounts[from].balance -= txn.amount; + newAccounts[from].nonce += 1; + newAccounts[to].balance += txn.amount; + + newAccounts +} +``` + +Crie a nova matriz de contas e, em seguida, retorne-a. + +```rust +fn readAddress(messageBytes: [u8; MESSAGE_LENGTH]) -> Field +``` + +Esta função lê o endereço da mensagem. + +```rust +{ + let mut result : Field = 0; + + for i in 7..47 { +``` + +O endereço tem sempre 20 bytes (ou seja, 40 dígitos hexadecimais) de comprimento e começa no caractere #7. + +```rust + result *= 0x10; + if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9 + result += (messageBytes[i]-48).into(); + } + if messageBytes[i] >= 65 & messageBytes[i] <= 70 { // A-F + result += (messageBytes[i]-65+10).into() + } + if messageBytes[i] >= 97 & messageBytes[i] <= 102 { // a-f + result += (messageBytes[i]-97+10).into() + } + } + + result +} + +fn readAmountAndNonce(messageBytes: [u8; MESSAGE_LENGTH]) -> (u128, u32) +``` + +Leia o valor e o nonce da mensagem. + +```rust +{ + let mut amount : u128 = 0; + let mut nonce: u32 = 0; + let mut stillReadingAmount: bool = true; + let mut lookingForNonce: bool = false; + let mut stillReadingNonce: bool = false; +``` + +Na mensagem, o primeiro número após o endereço é a quantidade de finney (também conhecido como milésimo de um ETH) a ser transferido. O segundo número é o nonce. Qualquer texto entre eles é ignorado. + +```rust + for i in 48..MESSAGE_LENGTH { + if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9 + let digit = (messageBytes[i]-48); + + if stillReadingAmount { + amount = amount*10 + digit.into(); + } + + if lookingForNonce { // We just found it + stillReadingNonce = true; + lookingForNonce = false; + } + + if stillReadingNonce { + nonce = nonce*10 + digit.into(); + } + } else { + if stillReadingAmount { + stillReadingAmount = false; + lookingForNonce = true; + } + if stillReadingNonce { + stillReadingNonce = false; + } + } + } + + (amount, nonce) +} +``` + +Retornar uma [tupla](https://noir-lang.org/docs/noir/concepts/data_types/tuples) é a maneira Noir de retornar múltiplos valores de uma função. + +```rust +fn readTransferTxn(message: str) -> TransferTxn +{ + let mut txn: TransferTxn = TransferTxn { from: 0, to: 0, amount:0, nonce:0 }; + let messageBytes = message.as_bytes(); + + txn.to = readAddress(messageBytes); + let (amount, nonce) = readAmountAndNonce(messageBytes); + txn.amount = amount; + txn.nonce = nonce; + + txn +} +``` + +Esta função converte a mensagem em bytes e, em seguida, converte os valores em um `TransferTxn`. + +```rust +// O equivalente a hashMessage do Viem +// https://viem.sh/docs/utilities/hashMessage#hashmessage +fn hashMessage(message: str) -> [u8;32] { +``` + +Conseguimos usar o Hash de Pedersen para as contas porque elas só são hasheadas dentro da prova de conhecimento zero. No entanto, neste código, precisamos verificar a assinatura da mensagem, que é gerada pelo navegador. Para isso, precisamos seguir o formato de assinatura do Ethereum no [EIP 191](https://eips.ethereum.org/EIPS/eip-191). Isso significa que precisamos criar um buffer combinado com um prefixo padrão, o comprimento da mensagem em ASCII e a própria mensagem, e usar o keccak256 padrão do Ethereum para gerar o hash. + +```rust + // ASCII prefix + let prefix_bytes = [ + 0x19, // \x19 + 0x45, // 'E' + 0x74, // 't' + 0x68, // 'h' + 0x65, // 'e' + 0x72, // 'r' + 0x65, // 'e' + 0x75, // 'u' + 0x6D, // 'm' + 0x20, // ' ' + 0x53, // 'S' + 0x69, // 'i' + 0x67, // 'g' + 0x6E, // 'n' + 0x65, // 'e' + 0x64, // 'd' + 0x20, // ' ' + 0x4D, // 'M' + 0x65, // 'e' + 0x73, // 's' + 0x73, // 's' + 0x61, // 'a' + 0x67, // 'g' + 0x65, // 'e' + 0x3A, // ':' + 0x0A // '\n' + ]; +``` + +Para evitar casos em que um aplicativo peça ao usuário para assinar uma mensagem que possa ser usada como uma transação ou para algum outro propósito, o EIP 191 especifica que todas as mensagens assinadas comecem com o caractere 0x19 (não é um caractere ASCII válido) seguido por `Ethereum Signed Message:` e uma nova linha. + +```rust + let mut buffer: [u8; HASH_BUFFER_SIZE] = [0u8; HASH_BUFFER_SIZE]; + for i in 0..26 { + buffer[i] = prefix_bytes[i]; + } + + let messageBytes : [u8; MESSAGE_LENGTH] = message.as_bytes(); + + if MESSAGE_LENGTH <= 9 { + for i in 0..1 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+1] = messageBytes[i]; + } + } + + if MESSAGE_LENGTH >= 10 & MESSAGE_LENGTH <= 99 { + for i in 0..2 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+2] = messageBytes[i]; + } + } + + if MESSAGE_LENGTH >= 100 { + for i in 0..3 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+3] = messageBytes[i]; + } + } + + assert(MESSAGE_LENGTH < 1000, "Messages whose length is over three digits are not supported"); +``` + +Lida com comprimentos de mensagem de até 999 e falha se for maior. Adicionei este código, embora o comprimento da mensagem seja uma constante, porque torna mais fácil alterá-lo. Em um sistema de produção, você provavelmente apenas assumiria que `MESSAGE_LENGTH` não muda para obter um melhor desempenho. + +```rust + keccak256::keccak256(buffer, HASH_BUFFER_SIZE) +} +``` + +Use a função `keccak256` padrão do Ethereum. + +```rust +fn signatureToAddressAndHash( + message: str, + pubKeyX: [u8; 32], + pubKeyY: [u8; 32], + signature: [u8; 64] + ) -> (Field, Field, Field) // address, first 16 bytes of hash, last 16 bytes of hash +{ +``` + +Esta função verifica a assinatura, o que requer o hash da mensagem. Em seguida, nos fornece o endereço que a assinou e o hash da mensagem. O hash da mensagem é fornecido em dois valores de `Field` porque eles são mais fáceis de usar no resto do programa do que uma matriz de bytes. + +Precisamos usar dois valores `Field` porque os cálculos de campo são feitos [módulo](https://en.wikipedia.org/wiki/Modulo) um número grande, mas esse número é tipicamente menor que 256 bits (caso contrário, seria difícil realizar esses cálculos no EVM). + +```rust + let hash = hashMessage(message); + + let mut (hash1, hash2) = (0,0); + + for i in 0..16 { + hash1 = hash1*256 + hash[31-i].into(); + hash2 = hash2*256 + hash[15-i].into(); + } +``` + +Especifique `hash1` e `hash2` como variáveis mutáveis e escreva o hash nelas byte a byte. + +```rust + ( + ecrecover::ecrecover(pubKeyX, pubKeyY, signature, hash), +``` + +Isto é semelhante ao `ecrecover` do [Solidity](https://docs.soliditylang.org/en/v0.8.30/cheatsheet.html#mathematical-and-cryptographic-functions), com duas diferenças importantes: + +- Se a assinatura não for válida, a chamada falha em um `assert` e o programa é abortado. +- Embora a chave pública possa ser recuperada da assinatura e do hash, este é um processamento que pode ser feito externamente e, portanto, não vale a pena fazer dentro da prova de conhecimento zero. Se alguém tentar nos enganar aqui, a verificação da assinatura falhará. + +```rust + hash1, + hash2 + ) +} + +fn main( + accounts: [Account; ACCOUNT_NUMBER], + message: str, + pubKeyX: [u8; 32], + pubKeyY: [u8; 32], + signature: [u8; 64], + ) -> pub ( + Field, // Hash of old accounts array + Field, // Hash of new accounts array + Field, // First 16 bytes of message hash + Field, // Last 16 bytes of message hash + ) +``` + +Finalmente, chegamos à função `main`. Precisamos provar que temos uma transação que altera validamente o hash das contas do valor antigo para o novo. Também precisamos provar que tem este hash de transação específico para que a pessoa que a enviou saiba que a sua transação foi processada. + +```rust +{ + let mut txn = readTransferTxn(message); +``` + +Precisamos que `txn` seja mutável porque não lemos o endereço de origem da mensagem, nós o lemos da assinatura. + +```rust + let (fromAddress, txnHash1, txnHash2) = signatureToAddressAndHash( + message, + pubKeyX, + pubKeyY, + signature); + + txn.from = fromAddress; + + let newAccounts = apply_transfer_txn(accounts, txn); + + ( + hash_accounts(accounts), + hash_accounts(newAccounts), + txnHash1, + txnHash2 + ) +} +``` + +### Estágio 2 - Adicionando um servidor {#stage-2} + +No segundo estágio, adicionamos um servidor que recebe e implementa transações de transferência do navegador. + +Para ver em ação: + +1. Pare o Vite se ele estiver em execução. + +2. Baixe o branch que inclui o servidor e certifique-se de que você tem todos os módulos necessários. + + ```sh + git checkout 02-add-server + cd client + npm install + cd ../server + npm install + ``` + + Não há necessidade de compilar o código Noir, é o mesmo código que você usou na etapa 1. + +3. Inicie o servidor. + + ```sh + npm run start + ``` + +4. Em uma janela de linha de comando separada, execute o Vite para servir o código do navegador. + + ```sh + cd client + npm run dev + ``` + +5. Acesse o código do cliente em [http://localhost:5173](http://localhost:5173) + +6. Antes de emitir uma transação, você precisa saber o nonce, bem como o valor que pode enviar. Para obter esta informação, clique em **Atualizar dados da conta** e assine a mensagem. + + Temos um dilema aqui. Por um lado, não queremos assinar uma mensagem que pode ser reutilizada (um [ataque de repetição](https://en.wikipedia.org/wiki/Replay_attack)), e é por isso que queremos um nonce em primeiro lugar. No entanto, ainda não temos um nonce. A solução é escolher um nonce que possa ser usado apenas uma vez e que já tenhamos em ambos os lados, como a hora atual. + + O problema com esta solução é que o tempo pode não estar perfeitamente sincronizado. Então, em vez disso, assinamos um valor que muda a cada minuto. Isso significa que nossa janela de vulnerabilidade a ataques de repetição é de no máximo um minuto. Considerando que em produção a solicitação assinada será protegida por TLS, e que o outro lado do túnel - o servidor - já pode divulgar o saldo e o nonce (ele precisa conhecê-los para funcionar), este é um risco aceitável. + +7. Uma vez que o navegador recebe de volta o saldo e o nonce, ele mostra o formulário de transferência. Selecione o endereço de destino e o valor e clique em **Transferir**. Assine este pedido. + +8. Para ver a transferência, **Atualize os dados da conta** ou olhe na janela onde você executa o servidor. O servidor registra o estado sempre que ele muda. + + ``` + ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start + + > server@1.0.0 start + > node --experimental-json-modules index.mjs + + Listening on port 3000 + Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 36000 finney (milliEth) 0 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 64000 (1) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 100000 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + Txn send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 7200 finney (milliEth) 1 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 56800 (2) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 3000 finney (milliEth) 2 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 53800 (3) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 139000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + ``` + +#### `server/index.mjs` {#server-index-mjs-1} + +[Este arquivo](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/index.mjs) contém o processo do servidor e interage com o código Noir em [`main.nr`](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/noir/src/main.nr). Aqui está uma explicação das partes interessantes. + +```js +import { Noir } from '@noir-lang/noir_js' +``` + +A biblioteca [noir.js](https://www.npmjs.com/package/@noir-lang/noir_js) faz a interface entre o código JavaScript e o código Noir. + +```js +const circuit = JSON.parse(await fs.readFile("./noir/target/zkBank.json")) +const noir = new Noir(circuit) +``` + +Carregue o circuito aritmético - o programa Noir compilado que criamos na etapa anterior - e prepare-se para executá-lo. + +```js +// Só fornecemos informações da conta em resposta a uma solicitação assinada +const accountInformation = async signature => { + const fromAddress = await recoverAddress({ + hash: hashMessage("Get account data " + Math.floor((new Date().getTime())/60000)), + signature + }) +``` + +Para fornecer informações da conta, só precisamos da assinatura. A razão é que já sabemos qual será a mensagem e, portanto, o hash da mensagem. + +```js +const processMessage = async (message, signature) => { +``` + +Processe uma mensagem e execute a transação que ela codifica. + +```js + // Obtenha a chave pública + const pubKey = await recoverPublicKey({ + hash, + signature + }) +``` + +Agora que executamos o JavaScript no servidor, podemos recuperar a chave pública lá, em vez de no cliente. + +```js + let noirResult + try { + noirResult = await noir.execute({ + message, + signature: signature.slice(2,-2).match(/.{2}/g).map(x => `0x${x}`), + pubKeyX, + pubKeyY, + accounts: Accounts + }) +``` + +`noir.execute` executa o programa Noir. Os parâmetros são equivalentes aos fornecidos em [`Prover.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml). Note que valores longos são fornecidos como um array de strings hexadecimais (`["0x60", "0xA7"]`), e não como um valor hexadecimal único (`0x60A7`), como faz o Viem. + +```js + } catch (err) { + console.log(`Noir error: ${err}`) + throw Error("Invalid transaction, not processed") + } +``` + +Se houver um erro, capture-o e, em seguida, retransmita uma versão simplificada para o cliente. + +```js + Accounts[fromAccountNumber].nonce++ + Accounts[fromAccountNumber].balance -= amount + Accounts[toAccountNumber].balance += amount +``` + +Aplique a transação. Já fizemos isso no código Noir, mas é mais fácil fazer de novo aqui do que extrair o resultado de lá. + +```js +let Accounts = [ + { + address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + balance: 5000, + nonce: 0, + }, +``` + +A estrutura `Contas` inicial. + +### Estágio 3 - Contratos inteligentes Ethereum {#stage-3} + +1. Pare os processos do servidor e do cliente. + +2. Baixe o branch com os contratos inteligentes e certifique-se de que você tem todos os módulos necessários. + + ```sh + git checkout 03-smart-contracts + cd client + npm install + cd ../server + npm install + ``` + +3. Execute `anvil` em uma janela de linha de comando separada. + +4. Gere a chave de verificação e o verificador solidity, em seguida, copie o código do verificador para o projeto Solidity. + + ```sh + cd noir + bb write_vk -b ./target/zkBank.json -o ./target --oracle_hash keccak + bb write_solidity_verifier -k ./target/vk -o ./target/Verifier.sol + cp target/Verifier.sol ../../smart-contracts/src + ``` + +5. Vá para os contratos inteligentes e defina as variáveis de ambiente para usar a blockchain `anvil`. + + ```sh + cd ../../smart-contracts + export ETH_RPC_URL=http://localhost:8545 + ETH_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 + ``` + +6. Implante `Verifier.sol` e armazene o endereço em uma variável de ambiente. + + ```sh + VERIFIER_ADDRESS=`forge create src/Verifier.sol:HonkVerifier --private-key $ETH_PRIVATE_KEY --optimize --broadcast | awk '/Deployed to:/ {print $3}'` + echo $VERIFIER_ADDRESS + ``` + +7. Implante o contrato `ZkBank`. + + ```sh + ZKBANK_ADDRESS=`forge create ZkBank --private-key $ETH_PRIVATE_KEY --broadcast --constructor-args $VERIFIER_ADDRESS 0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b | awk '/Deployed to:/ {print $3}'` + echo $ZKBANK_ADDRESS + ``` + + O valor `0x199..67b` é o hash Pederson do estado inicial de `Contas`. Se você modificar este estado inicial em `server/index.mjs`, você pode executar uma transação para ver o hash inicial relatado pela prova de conhecimento zero. + +8. Execute o servidor. + + ```sh + cd ../server + npm run start + ``` + +9. Execute o cliente em uma janela de linha de comando diferente. + + ```sh + cd client + npm run dev + ``` + +10. Execute algumas transações. + +11. Para verificar se o estado mudou na cadeia, reinicie o processo do servidor. Veja que o `ZkBank` não aceita mais transações, porque o valor original do hash nas transações difere do valor do hash armazenado na cadeia. + + Este é o tipo de erro esperado. + + ``` + ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start + + > server@1.0.0 start + > node --experimental-json-modules index.mjs + + Listening on port 3000 + Verification error: ContractFunctionExecutionError: The contract function "processTransaction" reverted with the following reason: + Wrong old state hash + + Contract Call: + address: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 + function: processTransaction(bytes _proof, bytes32[] _publicInputs) + args: (0x0000000000000000000000000000000000000000000000042ab5d6d1986846cf00000000000000000000000000000000000000000000000b75c020998797da7800000000000000000000000000000000000000000000000 + ``` + +#### `server/index.mjs` {#server-index-mjs-2} + +As mudanças neste arquivo se relacionam principalmente com a criação da prova real e seu envio na cadeia. + +```js +import { exec } from 'child_process' +import util from 'util' + +const execPromise = util.promisify(exec) +``` + +Precisamos usar [o pacote Barretenberg](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg) para criar a prova real a ser enviada na cadeia. Podemos usar este pacote executando a interface de linha de comando (`bb`) ou usando a [biblioteca JavaScript, `bb.js`](https://www.npmjs.com/package/@aztec/bb.js). A biblioteca JavaScript é muito mais lenta do que executar o código nativamente, então usamos [`exec`](https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback) aqui para usar a linha de comando. + +Note que se você decidir usar `bb.js`, você precisa usar uma versão que seja compatível com a versão do Noir que você está usando. No momento da escrita, a versão atual do Noir (1.0.0-beta.11) usa a versão 0.87 do `bb.js`. + +```js +const zkBankAddress = process.env.ZKBANK_ADDRESS || "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512" +``` + +O endereço aqui é o que você obtém quando começa com um `anvil` limpo e segue as instruções acima. + +```js +const walletClient = createWalletClient({ + chain: anvil, + transport: http(), + account: privateKeyToAccount("0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6") +}) +``` + +Esta chave privada é uma das contas pré-financiadas padrão em `anvil`. + +```js +const generateProof = async (witness, fileID) => { +``` + +Gere uma prova usando o executável `bb`. + +```js + const fname = `witness-${fileID}.gz` + await fs.writeFile(fname, witness) +``` + +Escreva a testemunha em um arquivo. + +```js + await execPromise(`bb prove -b ./noir/target/zkBank.json -w ${fname} -o ${fileID} --oracle_hash keccak --output_format fields`) +``` + +Realmente crie a prova. Este passo também cria um arquivo com as variáveis públicas, mas não precisamos disso. Já obtivemos essas variáveis de `noir.execute`. + +```js + const proof = "0x" + JSON.parse(await fs.readFile(`./${fileID}/proof_fields.json`)).reduce((a,b) => a+b, "").replace(/0x/g, "") +``` + +A prova é um array JSON de valores `Field`, cada um representado como um valor hexadecimal. No entanto, precisamos enviá-lo na transação como um único valor de `bytes`, que o Viem representa por uma grande string hexadecimal. Aqui, alteramos o formato concatenando todos os valores, removendo todos os `0x`'s e, em seguida, adicionando um no final. + +```js + await execPromise(`rm -r ${fname} ${fileID}`) + + return proof +} +``` + +Limpe e retorne a prova. + +```js +const processMessage = async (message, signature) => { + . + . + . + + const publicFields = noirResult.returnValue.map(x=>'0x' + x.slice(2).padStart(64, "0")) +``` + +Os campos públicos precisam ser uma matriz de valores de 32 bytes. No entanto, como precisávamos dividir o hash da transação entre dois valores de `Field`, ele aparece como um valor de 16 bytes. Aqui adicionamos zeros para que Viem entenda que na verdade são 32 bytes. + +```js + const proof = await generateProof(noirResult.witness, `${fromAddress}-${nonce}`) +``` + +Cada endereço usa cada nonce apenas uma vez, para que possamos usar uma combinação de `fromAddress` e `nonce` como um identificador único para o arquivo testemunha e o diretório de saída. + +```js + try { + await zkBank.write.processTransaction([ + proof, publicFields]) + } catch (err) { + console.log(`Verification error: ${err}`) + throw Error("Can't verify the transaction onchain") + } + . + . + . +} +``` + +Envie a transação para a cadeia. + +#### `smart-contracts/src/ZkBank.sol` {#smart-contracts-src-zkbank-sol} + +Este é o código na cadeia que recebe a transação. + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity >=0.8.21; + +import {HonkVerifier} from "./Verifier.sol"; + +contract ZkBank { + HonkVerifier immutable myVerifier; + bytes32 currentStateHash; + + constructor(address _verifierAddress, bytes32 _initialStateHash) { + currentStateHash = _initialStateHash; + myVerifier = HonkVerifier(_verifierAddress); + } +``` + +O código na cadeia precisa manter o controle de duas variáveis: o verificador (um contrato separado que é criado por `nargo`) e o hash do estado atual. + +```solidity + event TransactionProcessed( + bytes32 indexed transactionHash, + bytes32 oldStateHash, + bytes32 newStateHash + ); +``` + +Toda vez que o estado muda, emitimos um evento `TransactionProcessed`. + +```solidity + function processTransaction( + bytes calldata _proof, + bytes32[] calldata _publicFields + ) public { +``` + +Esta função processa transações. Ele obtém a prova (como `bytes`) e as entradas públicas (como uma matriz `bytes32`), no formato que o verificador exige (para minimizar o processamento na cadeia e, portanto, os custos de gás). + +```solidity + require(_publicInputs[0] == currentStateHash, + "Wrong old state hash"); +``` + +A prova de conhecimento zero precisa ser que a transação muda do nosso hash atual para um novo. + +```solidity + myVerifier.verify(_proof, _publicFields); +``` + +Chame o contrato do verificador para verificar a prova de conhecimento zero. Este passo reverte a transação se a prova de conhecimento zero estiver errada. + +```solidity + currentStateHash = _publicFields[1]; + + emit TransactionProcessed( + _publicFields[2]<<128 | _publicFields[3], + _publicFields[0], + _publicFields[1] + ); + } +} +``` + +Se tudo estiver correto, atualize o hash de estado para o novo valor e emita um evento `TransactionProcessed`. + +## Abusos pelo componente centralizado {#abuses} + +A segurança da informação consiste em três atributos: + +- _Confidencialidade_, os usuários não podem ler informações que não estão autorizados a ler. +- _Integridade_, as informações não podem ser alteradas, exceto por usuários autorizados de maneira autorizada. +- _Disponibilidade_, usuários autorizados podem usar o sistema. + +Neste sistema, a integridade é fornecida por meio de provas de conhecimento zero. A disponibilidade é muito mais difícil de garantir, e a confidencialidade é impossível, porque o banco precisa saber o saldo de cada conta e todas as transações. Não há como impedir que uma entidade que possui informações compartilhe essas informações. + +Pode ser possível criar um banco verdadeiramente confidencial usando [endereços furtivos](https://vitalik.eth.limo/general/2023/01/20/stealth.html), mas isso está além do escopo deste artigo. + +### Informações falsas {#false-info} + +Uma maneira pela qual o servidor pode violar a integridade é fornecer informações falsas quando [os dados são solicitados](https://github.com/qbzzt/250911-zk-bank/blob/03-smart-contracts/server/index.mjs#L278-L291). + +Para resolver isso, podemos escrever um segundo programa Noir que recebe as contas como uma entrada privada e o endereço para o qual as informações são solicitadas como uma entrada pública. A saída é o saldo e o nonce desse endereço e o hash das contas. + +Claro, essa prova não pode ser verificada na cadeia, porque não queremos publicar nonces e saldos na cadeia. No entanto, pode ser verificado pelo código do cliente em execução no navegador. + +### Transações forçadas {#forced-txns} + +O mecanismo usual para garantir a disponibilidade e prevenir a censura em L2s é o de [transações forçadas](https://docs.optimism.io/stack/transactions/forced-transaction). Mas as transações forçadas não combinam com as provas de conhecimento zero. O servidor é a única entidade que pode verificar transações. + +Podemos modificar `smart-contracts/src/ZkBank.sol` para aceitar transações forçadas e impedir que o servidor altere o estado até que sejam processadas. No entanto, isso nos abre a um simples ataque de negação de serviço. E se uma transação forçada for inválida e, portanto, impossível de processar? + +A solução é ter uma prova de conhecimento zero de que uma transação forçada é inválida. Isso dá ao servidor três opções: + +- Processe a transação forçada, fornecendo uma prova de conhecimento zero de que ela foi processada e o novo hash de estado. +- Rejeitar a transação forçada e fornecer uma prova de conhecimento zero ao contrato de que a transação é inválida (endereço desconhecido, nonce incorreto ou saldo insuficiente). +- Ignorar a transação forçada. Não há como forçar o servidor a realmente processar a transação, mas isso significa que todo o sistema está indisponível. + +#### Garantias de disponibilidade {#avail-bonds} + +Em uma implementação real, provavelmente haveria algum tipo de motivo de lucro para manter o servidor funcionando. Podemos fortalecer esse incentivo fazendo com que o servidor publique uma garantia de disponibilidade que qualquer pessoa pode queimar se uma transação forçada não for processada dentro de um determinado período. + +### Código Noir ruim {#bad-noir-code} + +Normalmente, para que as pessoas confiem em um contrato inteligente, carregamos o código-fonte em um [explorador de blocos](https://eth.blockscout.com/address/0x7D16d2c4e96BCFC8f815E15b771aC847EcbDB48b?tab=contract). No entanto, no caso de provas de conhecimento zero, isso é insuficiente. + +`Verifier.sol` contém a chave de verificação, que é uma função do programa Noir. No entanto, essa chave não nos diz qual era o programa Noir. Para realmente ter uma solução confiável, você precisa carregar o programa Noir (e a versão que o criou). Caso contrário, as provas de conhecimento zero podem refletir um programa diferente, um com uma porta dos fundos. + +Até que os exploradores de blocos comecem a nos permitir carregar e verificar programas Noir, você deve fazer isso sozinho (de preferência para [IPFS](/developers/tutorials/ipfs-decentralized-ui/)). Então, usuários sofisticados poderão baixar o código-fonte, compilá-lo, criar o `Verifier.sol` e verificar se ele é idêntico ao que está na cadeia. + +## Conclusão {#conclusion} + +Os aplicativos do tipo plasma requerem um componente centralizado como armazenamento de informações. Isso abre vulnerabilidades potenciais, mas, em troca, nos permite preservar a privacidade de maneiras não disponíveis na própria blockchain. Com as provas de conhecimento zero, podemos garantir a integridade e, possivelmente, torná-lo economicamente vantajoso para quem estiver executando o componente centralizado para manter a disponibilidade. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). + +## Agradecimentos {#acknowledgements} + +- Josh Crites leu um rascunho deste artigo e me ajudou com um problema espinhoso no Noir. + +Quaisquer erros remanescentes são de minha responsabilidade. diff --git a/public/content/translations/pt-br/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/translations/pt-br/developers/tutorials/calling-a-smart-contract-from-javascript/index.md index d56ba75f58f..b052d3edea3 100644 --- a/public/content/translations/pt-br/developers/tutorials/calling-a-smart-contract-from-javascript/index.md +++ b/public/content/translations/pt-br/developers/tutorials/calling-a-smart-contract-from-javascript/index.md @@ -1,12 +1,8 @@ --- title: Chamando um contrato inteligente a partir do JavaScript -description: Como chamar uma função do contrato inteligente a partir do JavaScript usando um token Dai como exemplo +description: "Como chamar uma função de um contrato inteligente a partir do JavaScript usando um token Dai como exemplo" author: jdourlens -tags: - - "transações" - - "front-end" - - "JavaScript" - - "web3.js" +tags: [ "transações", "front-end", "JavaScript", "web3.js" ] skill: beginner lang: pt-br published: 2020-04-19 @@ -15,15 +11,15 @@ sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -Neste tutorial, veremos como chamar uma função do [contrato inteligente](/developers/docs/smart-contracts/) a partir do JavaScript. Primeiro vamos ler o estado de um contrato inteligente (por exemplo, o saldo de um titular do ERC20) e logo vamos modificar o estado da blockchain fazendo uma transferência de token. Você já deve estar familiarizado com [configurando um ambiente JavaScript para interagir com a blockchain](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/). +Neste tutorial, veremos como chamar uma função de [contrato inteligente](/developers/docs/smart-contracts/) a partir do JavaScript. Primeiro, leremos o estado de um contrato inteligente (p. ex., o saldo de um detentor de ERC20), depois modificaremos o estado da cadeia de blocos fazendo uma transferência de token. Você já deve estar familiarizado com a [configuração de um ambiente JS para interagir com a cadeia de blocos](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/). -Para esses exemplos, vamos usar o token DAI. Para fins de teste, vamos fazer um fork do blockchain usando ganache-cli e desbloquear um endereço que já possui muitos DAI: +Para este exemplo, vamos interagir com o token DAI. Para fins de teste, faremos uma bifurcação da cadeia de blocos usando ganache-cli e desbloquearemos um endereço que já tenha muito DAI: ```bash ganache-cli -f https://mainnet.infura.io/v3/[YOUR INFURA KEY] -d -i 66 1 --unlock 0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81 ``` -Para interagir com um contrato inteligente, precisaremos do seu endereço e ABI: +Para interagir com um contrato inteligente, precisaremos de seu endereço e IAB: ```js const ERC20TransferABI = [ @@ -74,9 +70,9 @@ const ERC20TransferABI = [ const DAI_ADDRESS = "0x6b175474e89094c44da98b954eedeac495271d0f" ``` -Para este projeto, nós removemos parte do ERC20 ABI para manter apenas as funções `balanceOf` e `transfer`, mas você pode encontrar [aqui o ERC20 ABI completo](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/). +Para este projeto, removemos parte da IAB do ERC20 para manter apenas as funções `balanceOf` e `transfer`, mas você pode encontrar [a IAB completa do ERC20 aqui](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/). -Precisamos então instanciar nosso contrato inteligente: +Em seguida, precisamos instanciar nosso contrato inteligente: ```js const web3 = new Web3("http://localhost:8545") @@ -84,52 +80,52 @@ const web3 = new Web3("http://localhost:8545") const daiToken = new web3.eth.Contract(ERC20TransferABI, DAI_ADDRESS) ``` -Também vamos configurar dois endereços: +Também configuraremos dois endereços: -- quem receberá a transferência e -- o que nós já desbloqueamos que irá enviá-lo: +- aquele que receberá a transferência e +- aquele que já desbloqueamos e que fará o envio: ```js -const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CB3add6F279E81" +const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81" const receiverAddress = "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" ``` -Na próxima parte, chamaremos a função `balanceOf` para recuperar a quantidade atual de tokens que os dois endereços possuem. +Na próxima parte, chamaremos a função `balanceOf` para recuperar a quantidade atual de tokens que ambos os endereços possuem. -## Chamada: valor de leitura de um contrato inteligente {#call-reading-value-from-a-smart-contract} +## Chamada: lendo o valor de um contrato inteligente {#call-reading-value-from-a-smart-contract} -O primeiro exemplo chamará um método "constant" e executará seu método de contrato inteligente na EVM sem enviar qualquer transação. Para isso, vamos ler o saldo do ERC20 de um endereço. [Leia o nosso artigo sobre tokens ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/). +O primeiro exemplo chamará um método "constante" e executará seu método de contrato inteligente na EVM sem enviar nenhuma transação. Para isso, leremos o saldo ERC20 de um endereço. [Leia nosso artigo sobre tokens ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/). -Você pode acessar um método instanciado do contrato inteligente para o qual forneceu o ABI. Exemplo: `yourContract.methods.methodname`. Usando a função `call` você receberá o resultado da execução da função. +Você pode acessar os métodos de um contrato inteligente instanciado, para o qual você forneceu a IAB, da seguinte forma: `yourContract.methods.methodname`. Ao usar a função `call`, você receberá o resultado da execução da função. ```js -daiToken.methods.balanceOf(senderAddress).call(função (err, res) { +daiToken.methods.balanceOf(senderAddress).call(function (err, res) { if (err) { - console.log("Um erro ocorreu", err) + console.log("Ocorreu um erro", err) return } console.log("O saldo é: ", res) }) ``` -Lembre-se que DAI ERC20 tem 18 decimais, o que significa que você precisa remover 18 zeros para obter o valor correto. uint256 são retornados como cadeias de caracteres, pois o JavaScript não lida com grandes valores numéricos. Se não tiver certeza [de como lidar com grandes números em JS, verifique nosso tutorial sobre bignumber.js](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/). +Lembre-se de que o DAI ERC20 tem 18 casas decimais, o que significa que você precisa remover 18 zeros para obter o valor correto. Valores `uint256` são retornados como strings, pois o JavaScript não lida com valores numéricos grandes. Se você não tiver certeza de [como lidar com números grandes em JS, confira nosso tutorial sobre bignumber.js](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/). -## Enviar: enviando transação para uma função de contrato inteligente {#send-sending-a-transaction-to-a-smart-contract-function} +## Envio: enviando uma transação para uma função de contrato inteligente {#send-sending-a-transaction-to-a-smart-contract-function} -Para o segundo exemplo, chamaremos a função de transferência do contrato inteligente DAI para enviar 10 DAI para o nosso segundo endereço. A função de transferência aceita dois parâmetros: o endereço do destinatário e a quantidade de token para transferências: +Para o segundo exemplo, chamaremos a função de transferência do contrato inteligente DAI para enviar 10 DAI para nosso segundo endereço. A função de transferência aceita dois parâmetros: o endereço do destinatário e a quantidade de tokens a ser transferida: ```js daiToken.methods .transfer(receiverAddress, "100000000000000000000") .send({ from: senderAddress }, function (err, res) { if (err) { - console.log("An error occurred", err) + console.log("Ocorreu um erro", err) return } - console.log("Hash of the transaction: " + res) + console.log("Hash da transação: " + res) }) ``` -A função de chamada retorna o hash da transação que será minerada no blockchain. No Ethereum, hashes de transação são previsívei. É assim que podemos obter o hash da transação antes de ela ser executada ([saiba aqui como os hashes são calculados](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction)). +A função de chamada retorna o hash da transação que será minerada na cadeia de blocos. No Ethereum, os hashes de transação são previsíveis - é assim que podemos obter o hash da transação antes de ela ser executada ([aprenda como os hashes são calculados aqui](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction)). -Como função só envia a transação para a blockchain, não podemos ver o resultado até sabermos quando ela é minerada e incluída na blockchain. No próximo tutorial, aprenderemos [como aguardar por uma transação que será executada na blockchain com base no hash dela](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/). +Como a função apenas envia a transação para a cadeia de blocos, não podemos ver o resultado até sabermos quando ela for minerada e incluída na cadeia de blocos. No próximo tutorial, aprenderemos [como esperar que uma transação seja executada na cadeia de blocos, conhecendo seu hash](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/). diff --git a/public/content/translations/pt-br/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/pt-br/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md new file mode 100644 index 00000000000..19a99b020c8 --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md @@ -0,0 +1,585 @@ +--- +title: "Construindo uma interface de usuário para seu contrato" +description: "Usando componentes modernos como TypeScript, React, Vite e Wagmi, vamos abordar uma interface de usuário moderna, mas minimalista, e aprender como conectar uma carteira à interface do usuário, chamar um contrato inteligente para ler informações, enviar uma transação para um contrato inteligente e monitorar eventos de um contrato inteligente para identificar alterações." +author: Ori Pomerantz +tags: [ "TypeScript", "react", "vite", "wagmi", "front-end" ] +skill: beginner +published: 2023-11-01 +lang: pt-br +sidebarDepth: 3 +--- + +Você encontrou um recurso que precisamos no ecossistema Ethereum. Você escreveu os contratos inteligentes para implementá-lo, e talvez até algum código relacionado que é executado fora da cadeia. Isso é ótimo! Infelizmente, sem uma interface de usuário, você não terá nenhum usuário, e da última vez que você escreveu um site, as pessoas usavam modems de discagem e o JavaScript era novo. + +Este artigo é para você. Presumo que você saiba programar, e talvez um pouco de JavaScript e HTML, mas que suas habilidades de interface de usuário estejam enferrujadas e desatualizadas. Juntos, vamos analisar uma aplicação moderna simples para que você veja como isso é feito hoje em dia. + +## Por que isso é importante {#why-important} + +Na teoria, você poderia simplesmente fazer com que as pessoas usassem o [Etherscan](https://holesky.etherscan.io/address/0x432d810484add7454ddb3b5311f0ac2e95cecea8#writeContract) ou o [Blockscout](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=write_contract) para interagir com seus contratos. Isso será ótimo para os Ethereans experientes. Mas estamos tentando servir a [mais um bilhão de pessoas](https://blog.ethereum.org/2021/05/07/ethereum-for-the-next-billion). Isso não acontecerá sem uma ótima experiência do usuário, e uma interface de usuário amigável é uma grande parte disso. + +## Aplicação Greeter {#greeter-app} + +Há muita teoria por trás do funcionamento de uma UI moderna, e [muitos sites bons](https://react.dev/learn/thinking-in-react) [que explicam isso](https://wagmi.sh/core/getting-started). Em vez de repetir o bom trabalho feito por esses sites, vou presumir que você prefere aprender fazendo e começar com uma aplicação com a qual possa interagir. Você ainda precisa da teoria para fazer as coisas, e chegaremos lá — vamos apenas passar de arquivo fonte por arquivo fonte e discutir as coisas à medida que as encontrarmos. + +### Instalação {#installation} + +1. Se necessário, adicione a [cadeia de blocos Holesky](https://chainlist.org/?search=holesky&testnets=true) à sua carteira e [obtenha ETH de teste](https://www.holeskyfaucet.io/). + +2. Clone o repositório do github. + + ```sh + git clone https://github.com/qbzzt/20230801-modern-ui.git + ``` + +3. Instale os pacotes necessários. + + ```sh + cd 20230801-modern-ui + pnpm install + ``` + +4. Inicie a aplicação. + + ```sh + pnpm dev + ``` + +5. Navegue até o URL mostrado pela aplicação. Na maioria dos casos, é [http://localhost:5173/](http://localhost:5173/). + +6. Você pode ver o código-fonte do contrato, uma versão ligeiramente modificada do Greeter da Hardhat, [em um explorador de blockchain](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contract). + +### Passo a passo dos arquivos {#file-walk-through} + +#### `index.html` {#index-html} + +Este arquivo é um boilerplate HTML padrão, exceto por esta linha, que importa o arquivo de script. + +```html + +``` + +#### `src/main.tsx` {#main-tsx} + +A extensão do arquivo nos diz que este arquivo é um [componente React](https://www.w3schools.com/react/react_components.asp) escrito em [TypeScript](https://www.typescriptlang.org/), uma extensão do JavaScript que suporta [verificação de tipo](https://en.wikipedia.org/wiki/Type_system#Type_checking). O TypeScript é compilado para JavaScript, então podemos usá-lo para execução do lado do cliente. + +```tsx +import '@rainbow-me/rainbowkit/styles.css' +import { RainbowKitProvider } from '@rainbow-me/rainbowkit' +import * as React from 'react' +import * as ReactDOM from 'react-dom/client' +import { WagmiConfig } from 'wagmi' +import { chains, config } from './wagmi' +``` + +Importe o código da biblioteca que precisamos. + +```tsx +import { App } from './App' +``` + +Importe o componente React que implementa a aplicação (veja abaixo). + +```tsx +ReactDOM.createRoot(document.getElementById('root')!).render( +``` + +Crie o componente React raiz. O parâmetro para `render` é [JSX](https://www.w3schools.com/react/react_jsx.asp), uma linguagem de extensão que usa tanto HTML quanto JavaScript/TypeScript. O ponto de exclamação aqui diz ao componente TypeScript: "você não sabe que `document.getElementById('root')` será um parâmetro válido para `ReactDOM.createRoot`, mas não se preocupe - eu sou o desenvolvedor e estou lhe dizendo que haverá". + +```tsx + +``` + +A aplicação está dentro de um [componente `React.StrictMode`](https://react.dev/reference/react/StrictMode). Este componente diz à biblioteca React para inserir verificações de depuração adicionais, o que é útil durante o desenvolvimento. + +```tsx + +``` + +A aplicação também está dentro de um [componente `WagmiConfig`](https://wagmi.sh/react/api/WagmiProvider). [A biblioteca wagmi (we are going to make it)](https://wagmi.sh/) conecta as definições da UI do React com [a biblioteca viem](https://viem.sh/) para escrever um aplicativo descentralizado da Ethereum. + +```tsx + +``` + +E, finalmente, [um componente `RainbowKitProvider`](https://www.rainbowkit.com/). Este componente lida com o login e a comunicação entre a carteira e a aplicação. + +```tsx + +``` + +Agora podemos ter o componente para a aplicação, que realmente implementa a UI. O `/>` no final do componente diz ao React que este componente não tem nenhuma definição dentro dele, conforme o padrão XML. + +```tsx + + + , +) +``` + +Claro, temos que fechar os outros componentes. + +#### `src/App.tsx` {#app-tsx} + +```tsx +import { ConnectButton } from '@rainbow-me/rainbowkit' +import { useAccount } from 'wagmi' +import { Greeter } from './components/Greeter' + +export function App() { +``` + +Esta é a maneira padrão de criar um componente React - definir uma função que é chamada toda vez que precisa ser renderizada. Esta função normalmente tem algum código TypeScript ou JavaScript no início, seguido por uma declaração `return` que retorna o código JSX. + +```tsx + const { isConnected } = useAccount() +``` + +Aqui usamos [`useAccount`](https://wagmi.sh/react/api/hooks/useAccount) para verificar se estamos conectados a uma cadeia de blocos através de uma carteira ou não. + +Por convenção, em React, funções chamadas `use...` são [hooks](https://www.w3schools.com/react/react_hooks.asp) que retornam algum tipo de dado. Quando você usa esses hooks, não apenas seu componente obtém os dados, mas quando esses dados mudam, o componente é renderizado novamente com as informações atualizadas. + +```tsx + return ( + <> +``` + +O JSX de um componente React _tem_ que retornar um componente. Quando temos múltiplos componentes e não temos nada que os envolva "naturalmente", usamos um componente vazio (`<> ... `) para transformá-los em um único componente. + +```tsx +

Greeter

+ +``` + +Obtemos o [componente `ConnectButton`](https://www.rainbowkit.com/docs/connect-button) do RainbowKit. Quando não estamos conectados, ele nos dá um botão `Conectar Carteira` que abre um modal que explica sobre carteiras e permite que você escolha qual usar. Quando estamos conectados, ele exibe a cadeia de blocos que usamos, o endereço da nossa conta e nosso saldo de ETH. Podemos usar essas exibições para trocar de rede ou para desconectar. + +```tsx + {isConnected && ( +``` + +Quando precisamos inserir JavaScript real (ou TypeScript que será compilado para JavaScript) em um JSX, usamos chaves (`{}`). + +A sintaxe `a && b` é uma abreviação de [`a ? b : a`](https://www.w3schools.com/react/react_es6_ternary.asp). Ou seja, se `a` for verdadeiro, ele avalia para `b`, caso contrário, avalia para `a` (que pode ser `falso`, `0`, etc.). Esta é uma maneira fácil de dizer ao React que um componente só deve ser exibido se uma determinada condição for satisfeita. + +Neste caso, só queremos mostrar `Greeter` ao usuário se o usuário estiver conectado a uma cadeia de blocos. + +```tsx + + )} + + ) +} +``` + +#### `src/components/Greeter.tsx` {#greeter-tsx} + +Este arquivo contém a maior parte da funcionalidade da UI. Ele inclui definições que normalmente estariam em vários arquivos, mas como este é um tutorial, o programa é otimizado para ser fácil de entender na primeira vez, em vez de desempenho ou facilidade de manutenção. + +```tsx +import { useState, ChangeEventHandler } from 'react' +import { useNetwork, + useReadContract, + usePrepareContractWrite, + useContractWrite, + useContractEvent + } from 'wagmi' +``` + +Usamos estas funções de biblioteca. Novamente, elas são explicadas abaixo onde são usadas. + +```tsx +import { AddressType } from 'abitype' +``` + +[A biblioteca `abitype`](https://abitype.dev/) nos fornece definições TypeScript para vários tipos de dados do Ethereum, como [`AddressType`](https://abitype.dev/config#addresstype). + +```tsx +let greeterABI = [ + . + . + . +] as const // greeterABI +``` + +A ABI para o contrato `Greeter`. +Se você estiver desenvolvendo os contratos e a UI ao mesmo tempo, normalmente os colocaria no mesmo repositório e usaria a ABI gerada pelo compilador Solidity como um arquivo em sua aplicação. No entanto, isso não é necessário aqui porque o contrato já está desenvolvido e não vai mudar. + +```tsx +type AddressPerBlockchainType = { + [key: number]: AddressType +} +``` + +O TypeScript é fortemente tipado. Usamos essa definição para especificar o endereço em que o contrato `Greeter` é implantado em diferentes cadeias. A chave é um número (o chainId), e o valor é um `AddressType` (um endereço). + +```tsx +const contractAddrs: AddressPerBlockchainType = { + // Holesky + 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8', + + // Sepolia + 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0' +} +``` + +O endereço do contrato nas duas redes suportadas: [Holesky](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contact_code) e [Sepolia](https://eth-sepolia.blockscout.com/address/0x7143d5c190F048C8d19fe325b748b081903E3BF0?tab=contact_code). + +Nota: Existe na verdade uma terceira definição, para Redstone Holesky, que será explicada abaixo. + +```tsx +type ShowObjectAttrsType = { + name: string, + object: any +} +``` + +Este tipo é usado como um parâmetro para o componente `ShowObject` (explicado mais adiante). Ele inclui o nome do objeto e seu valor, que são exibidos para fins de depuração. + +```tsx +type ShowGreetingAttrsType = { + greeting: string | undefined +} +``` + +A qualquer momento, podemos saber qual é a saudação (porque a lemos da cadeia de blocos) ou não saber (porque ainda não a recebemos). Portanto, é útil ter um tipo que pode ser uma string ou nada. + +##### Componente `Greeter` {#greeter-component} + +```tsx +const Greeter = () => { +``` + +Finalmente, chegamos à definição do componente. + +```tsx + const { chain } = useNetwork() +``` + +Informações sobre a cadeia que estamos usando, cortesia de [wagmi](https://wagmi.sh/react/hooks/useNetwork). +Como isso é um hook (`use...`), toda vez que essa informação muda, o componente é redesenhado. + +```tsx + const greeterAddr = chain && contractAddrs[chain.id] +``` + +O endereço do contrato Greeter, que varia por cadeia (e que é `undefined` se não tivermos informações da cadeia ou estivermos em uma cadeia sem esse contrato). + +```tsx + const readResults = useReadContract({ + address: greeterAddr, + abi: greeterABI, + functionName: "greet" , // Sem argumentos + watch: true + }) +``` + +[O hook `useReadContract`](https://wagmi.sh/react/api/hooks/useReadContract) lê informações de um contrato. Você pode ver exatamente quais informações ele retorna expandindo `readResults` na UI. Neste caso, queremos que ele continue verificando para sermos informados quando a saudação mudar. + +**Nota:** Poderíamos escutar os [eventos `setGreeting`](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=logs) para saber quando a saudação muda e atualizar dessa forma. No entanto, embora possa ser mais eficiente, não se aplicará em todos os casos. Quando o usuário muda para uma cadeia diferente, a saudação também muda, mas essa mudança não é acompanhada por um evento. Poderíamos ter uma parte do código escutando eventos e outra para identificar mudanças de cadeia, mas isso seria mais complicado do que apenas definir [o parâmetro `watch`](https://wagmi.sh/react/api/hooks/useReadContract#watch-optional). + +```tsx + const [ newGreeting, setNewGreeting ] = useState("") +``` + +O [hook `useState`](https://www.w3schools.com/react/react_usestate.asp) do React nos permite especificar uma variável de estado, cujo valor persiste de uma renderização do componente para outra. O valor inicial é o parâmetro, neste caso, a string vazia. + +O hook `useState` retorna uma lista com dois valores: + +1. O valor atual da variável de estado. +2. Uma função para modificar a variável de estado quando necessário. Como este é um hook, toda vez que ele é chamado, o componente é renderizado novamente. + +Neste caso, estamos usando uma variável de estado para a nova saudação que o usuário deseja definir. + +```tsx + const greetingChange : ChangeEventHandler = (evt) => + setNewGreeting(evt.target.value) +``` + +Este é o manipulador de eventos para quando o campo de entrada da nova saudação muda. O tipo, [`ChangeEventHandler`](https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/forms_and_events/), especifica que este é um manipulador para uma mudança de valor de um elemento de entrada HTML. A parte `` é usada porque este é um [tipo genérico](https://www.w3schools.com/typescript/typescript_basic_generics.php). + +```tsx + const preparedTx = usePrepareContractWrite({ + address: greeterAddr, + abi: greeterABI, + functionName: 'setGreeting', + args: [ newGreeting ] + }) + const workingTx = useContractWrite(preparedTx.config) +``` + +Este é o processo para enviar uma transação de blockchain da perspectiva do cliente: + +1. Envie a transação para um nó na cadeia de blocos usando [`eth_estimateGas`](https://docs.alchemy.com/reference/eth-estimategas). +2. Aguarde uma resposta do nó. +3. Quando a resposta for recebida, peça ao usuário para assinar a transação através da carteira. Esta etapa _tem_ que acontecer depois que a resposta do nó for recebida, porque o custo do gás da transação é mostrado ao usuário antes que ele a assine. +4. Aguarde a aprovação do usuário. +5. Envie a transação novamente, desta vez usando [`eth_sendRawTransaction`](https://docs.alchemy.com/reference/eth-sendrawtransaction). + +A etapa 2 provavelmente levará um tempo perceptível, durante o qual os usuários se perguntariam se seu comando foi realmente recebido pela interface do usuário e por que ainda não lhes foi pedido para assinar a transação. Isso gera uma má experiência do usuário (UX). + +A solução é usar [hooks de preparação](https://wagmi.sh/react/prepare-hooks). Toda vez que um parâmetro muda, envie imediatamente ao nó a solicitação `eth_estimateGas`. Então, quando o usuário realmente quer enviar a transação (neste caso, pressionando **Atualizar saudação**), o custo do gás é conhecido e o usuário pode ver a página da carteira imediatamente. + +```tsx + return ( +``` + +Agora podemos finalmente criar o HTML real para retornar. + +```tsx + <> +

Greeter

+ { + !readResults.isError && !readResults.isLoading && + + } +
+``` + +Crie um componente `ShowGreeting` (explicado abaixo), mas somente se a saudação for lida com sucesso da cadeia de blocos. + +```tsx + +``` + +Este é o campo de texto de entrada onde o usuário pode definir uma nova saudação. Toda vez que o usuário pressiona uma tecla, chamamos `greetingChange`, que chama `setNewGreeting`. Como `setNewGreeting` vem do hook `useState`, ele faz com que o componente `Greeter` seja renderizado novamente. Isso significa que: + +- Precisamos especificar `value` para manter o valor da nova saudação, porque, caso contrário, ele voltaria ao padrão, a string vazia. +- `usePrepareContractWrite` é chamado toda vez que `newGreeting` muda, o que significa que ele sempre terá o `newGreeting` mais recente na transação preparada. + +```tsx + +``` + +Se não houver `workingTx.write`, ainda estamos aguardando as informações necessárias para enviar a atualização da saudação, então o botão está desabilitado. Se houver um valor `workingTx.write`, essa é a função a ser chamada para enviar a transação. + +```tsx +
+ + + + + ) +} +``` + +Finalmente, para ajudar você a ver o que estamos fazendo, mostramos os três objetos que usamos: + +- `readResults` +- `preparedTx` +- `workingTx` + +##### Componente `ShowGreeting` {#showgreeting-component} + +Este componente mostra + +```tsx +const ShowGreeting = (attrs : ShowGreetingAttrsType) => { +``` + +A função de um componente recebe um parâmetro com todos os atributos do componente. + +```tsx + return {attrs.greeting} +} +``` + +##### Componente `ShowObject` {#showobject-component} + +Para fins informativos, usamos o componente `ShowObject` para mostrar os objetos importantes (`readResults` para ler a saudação e `preparedTx` e `workingTx` para as transações que criamos). + +```tsx +const ShowObject = (attrs: ShowObjectAttrsType ) => { + const keys = Object.keys(attrs.object) + const funs = keys.filter(k => typeof attrs.object[k] == "function") + return <> +
+``` + +Não queremos poluir a UI com todas as informações, então para tornar possível visualizá-las ou fechá-las, usamos uma tag [`details`](https://www.w3schools.com/tags/tag_details.asp). + +```tsx + {attrs.name} + 
+        {JSON.stringify(attrs.object, null, 2)}
+```
+
+A maioria dos campos é exibida usando [`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp).
+
+```tsx
+
+ { funs.length > 0 && + <> + Functions: +
    +``` + +A exceção são as funções, que não fazem parte do [padrão JSON](https://www.json.org/json-en.html), então elas têm que ser exibidas separadamente. + +```tsx + {funs.map((f, i) => +``` + +Dentro do JSX, o código dentro de chaves `{` `}` é interpretado como JavaScript. Então, o código dentro dos parênteses `(` `)`, é interpretado novamente como JSX. + +```tsx + (
  • {f}
    • ) + )} +``` + +O React requer que as tags na [Árvore DOM](https://www.w3schools.com/js/js_htmldom.asp) tenham identificadores distintos. Isso significa que os filhos da mesma tag (neste caso, [a lista não ordenada](https://www.w3schools.com/tags/tag_ul.asp)), precisam de atributos `key` diferentes. + +```tsx +
+ + } +
+ +} +``` + +Finalize as várias tags HTML. + +##### O `export` final {#the-final-export} + +```tsx +export { Greeter } +``` + +O componente `Greeter` é o que precisamos exportar para a aplicação. + +#### `src/wagmi.ts` {#wagmi-ts} + +Finalmente, várias definições relacionadas ao WAGMI estão em `src/wagmi.ts`. Não vou explicar tudo aqui, porque a maior parte é boilerplate que você provavelmente não precisará mudar. + +O código aqui não é exatamente o mesmo que [no github](https://github.com/qbzzt/20230801-modern-ui/blob/main/src/wagmi.ts) porque mais adiante no artigo adicionamos outra cadeia ([Redstone Holesky](https://redstone.xyz/docs/network-info)). + +```ts +import { getDefaultWallets } from '@rainbow-me/rainbowkit' +import { configureChains, createConfig } from 'wagmi' +import { holesky, sepolia } from 'wagmi/chains' +``` + +Importe as blockchains que a aplicação suporta. Você pode ver a lista de cadeias suportadas [no github do viem](https://github.com/wagmi-dev/viem/tree/main/src/chains/definitions). + +```ts +import { publicProvider } from 'wagmi/providers/public' + +const walletConnectProjectId = 'c96e690bb92b6311e8e9b2a6a22df575' +``` + +Para poder usar o [WalletConnect](https://walletconnect.com/), você precisa de um ID de projeto para sua aplicação. Você pode obtê-lo em [cloud.walletconnect.com](https://cloud.walletconnect.com/sign-in). + +```ts +const { chains, publicClient, webSocketPublicClient } = configureChains( + [ holesky, sepolia ], + [ + publicProvider(), + ], +) + +const { connectors } = getDefaultWallets({ + appName: 'My wagmi + RainbowKit App', + chains, + projectId: walletConnectProjectId, +}) + +export const config = createConfig({ + autoConnect: true, + connectors, + publicClient, + webSocketPublicClient, +}) + +export { chains } +``` + +### Adicionando outra blockchain {#add-blockchain} + +Hoje em dia há muitas [soluções de escalabilidade L2](/layer-2/), e você pode querer suportar algumas que o viem ainda não suporta. Para fazer isso, você modifica `src/wagmi.ts`. Estas instruções explicam como adicionar a [Redstone Holesky](https://redstone.xyz/docs/network-info). + +1. Importe o tipo `defineChain` do viem. + + ```ts + import { defineChain } from 'viem' + ``` + +2. Adicione a definição de rede. + + ```ts + const redstoneHolesky = defineChain({ + id: 17_001, + name: 'Redstone Holesky', + network: 'redstone-holesky', + nativeCurrency: { + decimals: 18, + name: 'Ether', + symbol: 'ETH', + }, + rpcUrls: { + default: { + http: ['https://rpc.holesky.redstone.xyz'], + webSocket: ['wss://rpc.holesky.redstone.xyz/ws'], + }, + public: { + http: ['https://rpc.holesky.redstone.xyz'], + webSocket: ['wss://rpc.holesky.redstone.xyz/ws'], + }, + }, + blockExplorers: { + default: { name: 'Explorer', url: 'https://explorer.holesky.redstone.xyz' }, + }, + }) + ``` + +3. Adicione a nova cadeia à chamada `configureChains`. + + ```ts + const { chains, publicClient, webSocketPublicClient } = configureChains( + [ holesky, sepolia, redstoneHolesky ], + [ publicProvider(), ], + ) + ``` + +4. Certifique-se de que a aplicação saiba o endereço para seus contratos na nova rede. Neste caso, modificamos `src/components/Greeter.tsx`: + + ```ts + const contractAddrs : AddressPerBlockchainType = { + // Holesky + 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8', + + // Redstone Holesky + 17001: '0x4919517f82a1B89a32392E1BF72ec827ba9986D3', + + // Sepolia + 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0' + } + ``` + +## Conclusão {#conclusion} + +Claro, você não se importa realmente em fornecer uma interface de usuário para o `Greeter`. Você quer criar uma interface de usuário para seus próprios contratos. Para criar sua própria aplicação, siga estes passos: + +1. Especifique para criar uma aplicação wagmi. + + ```sh copy + pnpm create wagmi + ``` + +2. Nomeie a aplicação. + +3. Selecione a estrutura **React**. + +4. Selecione a variante **Vite**. + +5. Você pode [adicionar o kit Rainbow](https://www.rainbowkit.com/docs/installation#manual-setup). + +Agora vá e torne seus contratos utilizáveis para o mundo inteiro. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). + diff --git a/public/content/translations/pt-br/developers/tutorials/deploying-your-first-smart-contract/index.md b/public/content/translations/pt-br/developers/tutorials/deploying-your-first-smart-contract/index.md index 4d78c0a3e2e..b2c0a9b3b21 100644 --- a/public/content/translations/pt-br/developers/tutorials/deploying-your-first-smart-contract/index.md +++ b/public/content/translations/pt-br/developers/tutorials/deploying-your-first-smart-contract/index.md @@ -1,12 +1,8 @@ --- -title: Implementando seu primeiro contrato inteligente -description: Uma introdução à implantação do seu primeiro contrato inteligente em uma rede de teste Ethereum +title: Implantando seu primeiro contrato inteligente +description: "Uma introdução à implantação do seu primeiro contrato inteligente em uma rede de teste Ethereum" author: "jdourlens" -tags: - - "contratos inteligentes" - - "remix" - - "solidity" - - "implementação" +tags: [ "smart contracts", "Remix", "Solidity", "implantação" ] skill: beginner lang: pt-br published: 2020-04-03 @@ -15,17 +11,17 @@ sourceUrl: https://ethereumdev.io/deploying-your-first-smart-contract/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -Acho que você está tão animado quanto nós para [implantar](/developers/docs/smart-contracts/deploying/) e interagir com o seu primeiro [contrato inteligente](/developers/docs/smart-contracts/) na blockchain Ethereum. +Imagino que você esteja tão animado quanto nós para [implantar](/developers/docs/smart-contracts/deploying/) e interagir com seu primeiro [contrato inteligente](/developers/docs/smart-contracts/) na blockchain Ethereum. -Não se preocupe, pois como este é o nosso primeiro contrato inteligente, vamos publicá-lo em uma [rede de testes local](/developers/docs/networks/), assim não custa nada para você implementar e brincar com ele o quanto quiser. +Não se preocupe, pois como este é o nosso primeiro contrato inteligente, vamos implantá-lo em uma [rede de teste local](/developers/docs/networks/) para que não custe nada para você implantar e brincar com ele o quanto quiser. ## Escrevendo nosso contrato {#writing-our-contract} -O primeiro passo é [visitar a Remix](https://remix.ethereum.org/) e criar um novo arquivo. Na parte superior esquerda da interface Remix adicione um novo arquivo e digite o nome do arquivo desejado. +O primeiro passo é [visitar o Remix](https://remix.ethereum.org/) e criar um novo arquivo. Na parte superior esquerda da interface do Remix, adicione um novo arquivo e digite o nome do arquivo que desejar. -![Adicionando um novo arquivo na interface Remix](./remix.png) +![Adicionando um novo arquivo na interface do Remix](./remix.png) -No novo arquivo, vamos colar o seguinte código. +No novo arquivo, colaremos o código a seguir. ```solidity // SPDX-License-Identifier: MIT @@ -33,15 +29,15 @@ pragma solidity >=0.5.17; contract Counter { - // Public variable of type unsigned int to keep the number of counts + // Variável pública do tipo inteiro não assinado para manter o número de contagens uint256 public count = 0; - // Function that increments our counter + // Função que incrementa nosso contador function increment() public { count += 1; } - // Not necessary getter to get the count value + // Getter não necessário para obter o valor da contagem function getCount() public view returns (uint256) { return count; } @@ -49,51 +45,51 @@ contract Counter { } ``` -Se você está acostumado com programação, você pode facilmente adivinhar o que este programa faz. Aqui está uma explicação linha a linha: +Se você tem experiência com programação, pode adivinhar facilmente o que este programa faz. Aqui está uma explicação linha por linha: - Linha 4: Definimos um contrato com o nome `Counter`. -- Linha 7: Nosso contrato armazena um inteiro não assinado chamado `count` começando com 0. -- Linha 10: A primeira função vai modificar o estado do contrato e `increment()` nossa variável `count`. -- Linha 15: A segunda função é apenas um getter para ser capaz de ler o valor da variável `count` fora do contrato inteligente. Observe que, como definimos nossa variável `count` como pública, isso não é necessário, mas é mostrado como um exemplo. +- Linha 7: Nosso contrato armazena um inteiro sem sinal chamado `count` começando em 0. +- Linha 10: A primeira função modificará o estado do contrato e `increment()` nossa variável `count`. +- Linha 15: A segunda função é apenas um getter para poder ler o valor da variável `count` fora do contrato inteligente. Observe que, como definimos nossa variável `count` como pública, isso não é necessário, mas é mostrado como um exemplo. -Tudo isso para o nosso primeiro contrato inteligente simples. Como você deve saber, ele se parece com uma classe de linguagens OOP (Object-Oriented Programming, programação orientada a objetos) como Java ou C++. Agora é hora de brincar com o nosso contrato. +Isto é tudo para o nosso primeiro contrato inteligente simples. Como você deve saber, ele se parece com uma classe de linguagens OOP (Programação Orientada a Objetos) como Java ou C++. Agora é hora de brincar com o nosso contrato. ## Implantando nosso contrato {#deploying-our-contract} -Como escrevemos nosso primeiro contrato inteligente, nós agora faremos deploy para a blockchain para poder brincar com ele. +Como escrevemos nosso primeiro contrato inteligente, agora vamos implantá-lo na blockchain para podermos brincar com ele. -[Implantar o contrato inteligente no blockchain](/developers/docs/smart-contracts/deploying/) é, na verdade, apenas enviar uma transação que contém o código do contrato inteligente compilado sem especificar os destinatários. +[Implantar o contrato inteligente na blockchain](/developers/docs/smart-contracts/deploying/) é, na verdade, apenas enviar uma transação que contém o código do contrato inteligente compilado sem especificar nenhum destinatário. Primeiro, vamos [compilar o contrato](/developers/docs/smart-contracts/compiling/) clicando no ícone de compilação no lado esquerdo: -![O ícone de compilação na barra de ferramentas Remix](./remix-compile-button.png) +![O ícone de compilação na barra de ferramentas do Remix](./remix-compile-button.png) Em seguida, clique no botão de compilação: -![O botão de compilação no compilador do solidity Remix](./remix-compile.png) +![O botão de compilação no compilador Solidity do Remix](./remix-compile.png) -Você pode escolher selecionar a opção "Compilação automática", para que o contrato sempre seja compilado quando você salvar o conteúdo no editor de texto. +Você pode selecionar a opção "Compilação automática" para que o contrato seja sempre compilado quando você salvar o conteúdo no editor de texto. -Em seguida, navegue para a tela de implantação e execução de transações: +Em seguida, navegue para a tela "DEPLOY & RUN TRANSACTIONS": -![O ícone de compilação na barra de ferramentas do Remix](./remix-deploy.png) +![O ícone de implantação na barra de ferramentas do Remix](./remix-deploy.png) -Assim que você estiver na tela de transações "deploy and run" verifique se o nome do seu contrato aparece e clique em Deploy. Como você pode ver no topo da página, o ambiente atual é o "Javascript VM", o que significa que iremos implantar e interagir com nosso contrato inteligente em uma blockchain de teste local para podermos testar mais rápido e sem quaisquer custos. +Quando estiver na tela "DEPLOY & RUN TRANSACTIONS", verifique se o nome do seu contrato aparece e clique em Deploy. Como você pode ver na parte superior da página, o ambiente atual é "JavaScript VM", o que significa que vamos implantar e interagir com nosso contrato inteligente em uma blockchain de teste local para podermos testar mais rápido e sem nenhuma taxa. -![O botão de deploy no compilador do solidity Remix](./remix-deploy-button.png) +![O botão de implantação no compilador Solidity do Remix](./remix-deploy-button.png) -Quando você clicar no botão "Deploy", você verá seu contrato aparecer abaixo. Clique na seta à esquerda para expandi-la, para que possamos ver o conteúdo de nosso contrato. Esta é nossa variável `counter`, nossa função `increment()` e a getter `getCounter()`. +Depois de clicar no botão "Deploy", você verá seu contrato aparecer na parte inferior. Clique na seta à esquerda para expandi-lo para vermos o conteúdo do nosso contrato. Esta é a nossa variável `counter`, a nossa função `increment()` e o getter `getCounter()`. Se você clicar no botão `count` ou `getCount`, ele recuperará o conteúdo da variável `count` do contrato e o exibirá. Como ainda não chamamos a função `increment`, ela deve exibir 0. -![O botão de função no compilador do solidity Remix](./remix-function-button.png) +![O botão de função no compilador Solidity do Remix](./remix-function-button.png) -Vamos agora chamar a função `increment` clicando no botão. Você verá logs das transações que são feitas aparecendo no parte inferior da janela. Você verá que os logs são diferentes quando estiver pressionando o botão para recuperar os dados em vez do botão `increment`. Isso porque a leitura de dados na blockchain não necessita de quaisquer transações (escritas) ou taxas. Porque somente modificar o estado do blockchain requer fazer uma transação: +Vamos agora chamar a função `increment` clicando no botão. Você verá os logs das transações realizadas aparecendo na parte inferior da janela. Você verá que os logs são diferentes quando você pressiona o botão para recuperar os dados em vez do botão `increment`. Isso porque a leitura de dados na blockchain não precisa de nenhuma transação (escrita) ou taxa. Porque apenas a modificação do estado da blockchain exige a realização de uma transação: ![Um log de transações](./transaction-log.png) -Após pressionar o botão de incremento que gerará uma transação para chamar nossa função `increment()` se clicarmos novamente nos botões count ou getCount, iremos ler o estado recém-atualizado de nosso contrato inteligente com a variável de contagem maior que 0. +Depois de pressionar o botão de incremento que irá gerar uma transação para chamar nossa função `increment()`, se clicarmos de volta nos botões `count` ou `getCount`, leremos o estado recém-atualizado de nosso contrato inteligente com a variável de contagem sendo maior que 0. -![Estado recentemente atualizado do contrato inteligente](./updated-state.png) +![Estado recém-atualizado do contrato inteligente](./updated-state.png) -No próximo tutorial, explicaremos [como você pode adicionar eventos aos seus contratos inteligentes](/developers/tutorials/logging-events-smart-contracts/). Eventos de registro são uma maneira conveniente para depurar seu contrato inteligente e entender o que está acontecendo durante a chamada de uma função. +No próximo tutorial, abordaremos [como você pode adicionar eventos aos seus contratos inteligentes](/developers/tutorials/logging-events-smart-contracts/). Registrar eventos é uma maneira conveniente de depurar seu contrato inteligente e entender o que está acontecendo ao chamar uma função. diff --git a/public/content/translations/pt-br/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md b/public/content/translations/pt-br/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md new file mode 100644 index 00000000000..db6a6ad0e50 --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md @@ -0,0 +1,372 @@ +--- +title: Como desenvolver e testar um dApp em uma rede de teste local multicliente +description: "Este guia primeiro o guiará por como instanciar e configurar uma rede de teste local multicliente do Ethereum antes de usar a rede de teste para implantar e testar um dApp." +author: "Tedi Mitiku" +tags: + [ + "clientes", + "nós", + "smart contracts", + "componibilidade", + "camada de consenso", + "camada de execução", + "testando" + ] +skill: intermediate +lang: pt-br +published: 2023-04-11 +--- + +## Introdução {#introduction} + +Este guia o orienta no processo de instanciar uma rede de teste local configurável do Ethereum, implantar um contrato inteligente nela e usar a rede de teste para executar testes em seu dApp. Este guia foi elaborado para desenvolvedores de dApps que queiram desenvolver e testar seus dApps localmente em diferentes configurações de rede antes de implantar em uma rede de teste ativa ou na rede principal. + +Neste guia, você irá: + +- Instanciar uma rede de teste local do Ethereum com o [`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) usando [Kurtosis](https://www.kurtosis.com/), +- Conectar seu ambiente de desenvolvimento de dApp Hardhat à rede de teste local para compilar, implantar e testar um dApp, e +- Configurar a rede de teste local, incluindo parâmetros como o número de nós e pares de clientes EL/CL específicos, para permitir fluxos de trabalho de desenvolvimento e teste em várias configurações de rede. + +### O que é Kurtosis? {#what-is-kurtosis} + +[Kurtosis](https://www.kurtosis.com/) é um sistema de compilação componível projetado para configurar ambientes de teste de múltiplos contêineres. Ele permite especificamente que os desenvolvedores criem ambientes reprodutíveis que exigem lógica de configuração dinâmica, como redes de teste de blockchain. + +Neste guia, o eth-network-package da Kurtosis inicia uma rede de teste local do Ethereum com suporte para o cliente da Camada de Execução (EL) [`geth`](https://geth.ethereum.org/), bem como para os clientes da Camada de Consenso (CL) [`teku`](https://consensys.io/teku), [`lighthouse`](https://lighthouse.sigmaprime.io/) e [`lodestar`](https://lodestar.chainsafe.io/). Este pacote serve como uma alternativa configurável e componível para redes em frameworks como Hardhat Network, Ganache e Anvil. O Kurtosis oferece aos desenvolvedores maior controle e flexibilidade sobre as redes de teste que utilizam, que é uma das principais razões pelas quais a [Ethereum Foundation usou o Kurtosis para testar a Fusão](https://www.kurtosis.com/blog/testing-the-ethereum-merge) e continua a usá-lo para testar atualizações de rede. + +## Configurando o Kurtosis {#setting-up-kurtosis} + +Antes de prosseguir, certifique-se de que você tenha: + +- [Instalado e iniciado o motor Docker](https://docs.kurtosis.com/install/#i-install--start-docker) em sua máquina local +- [Instalado o Kurtosis CLI](https://docs.kurtosis.com/install#ii-install-the-cli) (ou o atualizou para a versão mais recente, se você já tiver o CLI instalado) +- Instalado [Node.js](https://nodejs.org/en), [yarn](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable) e [npx](https://www.npmjs.com/package/npx) (para o seu ambiente dApp) + +## Instanciando uma rede de teste local do Ethereum {#instantiate-testnet} + +Para iniciar uma rede de teste local do Ethereum, execute: + +```python +kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package +``` + +Observação: Este comando nomeia sua rede: "local-eth-testnet" usando a flag `--enclave`. + +O Kurtosis imprimirá os passos que está a tomar internamente enquanto trabalha para interpretar, validar e executar as instruções. Ao final, você deverá ver um resultado semelhante ao seguinte: + +```python +INFO[2023-04-04T18:09:44-04:00] ====================================================== +INFO[2023-04-04T18:09:44-04:00] || Enclave criado: local-eth-testnet || +INFO[2023-04-04T18:09:44-04:00] ====================================================== +Nome: local-eth-testnet +UUID: 39372d756ae8 +Status: EM EXECUÇÃO +Horário da criação: Ter, 04 Abr 2023 18:09:03 EDT + +========================================= Artefatos de Arquivos ========================================= +UUID Nome +d4085a064230 cl-genesis-data +1c62cb792e4c el-genesis-data +bd60489b73a7 genesis-generation-config-cl +b2e593fe5228 genesis-generation-config-el +d552a54acf78 geth-prefunded-keys +5f7e661eb838 prysm-password +054e7338bb59 validator-keystore-0 + +========================================== Serviços de Usuário ========================================== +UUID Nome Portas Status +e20f129ee0c5 cl-client-0-beacon http: 4000/tcp -> EM EXECUÇÃO + metrics: 5054/tcp -> + tcp-discovery: 9000/tcp -> 127.0.0.1:54263 + udp-discovery: 9000/udp -> 127.0.0.1:60470 +a8b6c926cdb4 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:54267 EM EXECUÇÃO + metrics: 5064/tcp -> +d7b802f623e8 el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:54253 EM EXECUÇÃO + rpc: 8545/tcp -> 127.0.0.1:54251 + tcp-discovery: 30303/tcp -> 127.0.0.1:54254 + udp-discovery: 30303/udp -> 127.0.0.1:53834 + ws: 8546/tcp -> 127.0.0.1:54252 +514a829c0a84 prelaunch-data-generator-1680646157905431468 PARADO +62bd62d0aa7a prelaunch-data-generator-1680646157915424301 PARADO +05e9619e0e90 prelaunch-data-generator-1680646157922872635 PARADO + +``` + +Parabéns! Você usou o Kurtosis para instanciar uma rede de teste local do Ethereum, com um cliente CL (`lighthouse`) e um cliente EL (`geth`), sobre Docker. + +### Revisão {#review-instantiate-testnet} + +Nesta seção, você executou um comando que instruiu o Kurtosis a usar o [`eth-network-package` hospedado remotamente no GitHub](https://github.com/kurtosis-tech/eth-network-package) para iniciar uma rede de teste local do Ethereum dentro de um [Enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/) do Kurtosis. Dentro do seu enclave, você encontrará "artefatos de arquivo" e "serviços de usuário". + +Os [Artefatos de arquivo](https://docs.kurtosis.com/advanced-concepts/files-artifacts/) no seu enclave incluem todos os dados gerados e utilizados para inicializar os clientes EL e CL. Os dados foram criados usando o serviço `prelaunch-data-generator` construído a partir desta [imagem Docker](https://github.com/ethpandaops/ethereum-genesis-generator) + +Os serviços de usuário exibem todos os serviços em contêineres operando no seu enclave. Você notará que um único nó, com um cliente EL e um cliente CL, foi criado. + +## Conecte seu ambiente de desenvolvimento de dApp à rede de teste local do Ethereum {#connect-your-dapp} + +### Configure o ambiente de desenvolvimento de dApp {#set-up-dapp-env} + +Agora que você tem uma rede de teste local em execução, você pode conectar seu ambiente de desenvolvimento de dApp para usar sua rede de teste local. O framework Hardhat será usado neste guia para implantar um dApp de blackjack na sua rede de teste local. + +Para configurar seu ambiente de desenvolvimento de dApp, clone o repositório que contém nosso dApp de exemplo e instale suas dependências, execute: + +```python +git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn +``` + +A pasta [smart-contract-example](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example) usada aqui contém a configuração típica para um desenvolvedor de dApp usando o framework [Hardhat](https://hardhat.org/): + +- [`contracts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/contracts) contém alguns contratos inteligentes simples para um dApp de Blackjack +- [`scripts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/scripts) contém um script para implantar um contrato de token em sua rede Ethereum local +- [`test/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/test) contém um teste .js simples para seu contrato de token para confirmar que cada jogador em nosso dApp de Blackjack tem 1000 tokens emitidos para eles +- [`hardhat.config.ts`](https://github.com/kurtosis-tech/awesome-kurtosis/blob/main/smart-contract-example/hardhat.config.ts) configura sua instalação do Hardhat + +### Configurar o Hardhat para usar a rede de teste local {#configure-hardhat} + +Com seu ambiente de desenvolvimento de dApp configurado, você agora conectará o Hardhat para usar a rede de teste local do Ethereum gerada usando o Kurtosis. Para fazer isso, substitua `<$YOUR_PORT>` na estrutura `localnet` no seu arquivo de configuração `hardhat.config.ts` pela porta da saída do URI rpc de qualquer serviço `el-client-`. Neste caso de exemplo, a porta seria `64248`. Sua porta será diferente. + +Exemplo em `hardhat.config.ts`: + +```js +localnet: { +url: 'http://127.0.0.1:<$YOUR_PORT>',// TODO: SUBSTITUA $YOUR_PORT PELA PORTA DE UM URI DE NÓ PRODUZIDO PELO PACOTE DE REDE ETH KURTOSIS + +// Estas são chaves privadas associadas a contas de teste pré-financiadas criadas pelo eth-network-package +// +accounts: [ + "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2", + "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567", + "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31", + "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35", + "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f", + "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6", + ], +}, +``` + +Depois de salvar seu arquivo, seu ambiente de desenvolvimento de dApp Hardhat está agora conectado à sua rede de teste local do Ethereum! Você pode verificar se sua rede de teste está funcionando executando: + +```python +npx hardhat balances --network localnet +``` + +A saída deve ser algo como: + +```python +0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000 +0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000 +0xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000 +0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000 +0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000 +0x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000 +``` + +Isso confirma que o Hardhat está usando sua rede de teste local e detecta as contas pré-financiadas criadas pelo `eth-network-package`. + +### Implantar e testar seu dApp localmente {#deploy-and-test-dapp} + +Com o ambiente de desenvolvimento de dApp totalmente conectado à rede de teste local do Ethereum, agora você pode executar fluxos de trabalho de desenvolvimento e teste em seu dApp usando a rede de teste local. + +Para compilar e implantar o contrato inteligente `ChipToken.sol` para prototipagem e desenvolvimento local, execute: + +```python +npx hardhat compile +npx hardhat run scripts/deploy.ts --network localnet +``` + +A saída deve se parecer com: + +```python +ChipToken implantado em: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d +``` + +Agora tente executar o teste `simple.js` em seu dApp local para confirmar que cada jogador em nosso dApp de Blackjack tem 1000 tokens emitidos para eles: + +A saída deve ser algo como: + +```python +npx hardhat test --network localnet +``` + +A saída deve ser algo como: + +```python +ChipToken + emissão + ✔ deve emitir 1000 fichas para o JOGADOR UM + + 1 aprovado (654ms) +``` + +### Revisão {#review-dapp-workflows} + +Neste ponto, você configurou um ambiente de desenvolvimento de dApp, conectou-o a uma rede Ethereum local criada pelo Kurtosis e compilou, implantou e executou um teste simples em seu dApp. + +Agora vamos explorar como você pode configurar a rede subjacente para testar nossos dApps sob várias configurações de rede. + +## Configurando a rede de teste local do Ethereum {#configure-testnet} + +### Alterando as configurações do cliente e o número de nós {#configure-client-config-and-num-nodes} + +Sua rede de teste local do Ethereum pode ser configurada para usar diferentes pares de clientes EL e CL, bem como um número variável de nós, dependendo do cenário e da configuração de rede específica que você deseja desenvolver ou testar. Isso significa que, uma vez configurado, você pode iniciar uma rede de teste local personalizada e usá-la para executar os mesmos fluxos de trabalho (implantação, testes, etc.) sob várias configurações de rede para garantir que tudo funcione como esperado. Para saber mais sobre os outros parâmetros que você pode modificar, visite este link. + +Experimente! Você pode passar várias opções de configuração para o `eth-network-package` através de um arquivo JSON. Este arquivo JSON de parâmetros de rede fornece as configurações específicas que o Kurtosis usará para configurar a rede Ethereum local. + +Pegue o arquivo de configuração padrão e edite-o para iniciar três nós com pares EL/CL diferentes: + +- Nó 1 com `geth`/`lighthouse` +- Nó 2 com `geth`/`lodestar` +- Nó 3 com `geth`/`teku` + +Essa configuração cria uma rede heterogênea de implementações de nós Ethereum para testar seu dApp. Seu arquivo de configuração deve ficar assim: + +```yaml +{ + "participants": + [ + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "lighthouse", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "lodestar", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "teku", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + ], + "network_params": + { + "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete", + "num_validator_keys_per_node": 64, + "network_id": "3151908", + "deposit_contract_address": "0x4242424242424242424242424242424242424242", + "seconds_per_slot": 12, + "genesis_delay": 120, + "capella_fork_epoch": 5, + }, +} +``` + +Cada estrutura `participants` mapeia para um nó na rede, portanto, 3 estruturas `participants` instruirão o Kurtosis a iniciar 3 nós em sua rede. Cada estrutura `participants` permitirá que você especifique o par EL e CL usado para aquele nó específico. + +A estrutura `network_params` configura as definições de rede que são usadas para criar os arquivos de gênese para cada nó, bem como outras configurações, como os segundos por slot da rede. + +Salve seu arquivo de parâmetros editado em qualquer diretório que desejar (no exemplo abaixo, ele é salvo na área de trabalho) e, em seguida, use-o para executar seu pacote Kurtosis executando: + +```python +kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package "$(cat ~/eth-network-params.json)" +``` + +Observação: o comando `kurtosis clean -a` é usado aqui para instruir o Kurtosis a destruir a antiga rede de teste e seu conteúdo antes de iniciar uma nova. + +Novamente, o Kurtosis trabalhará por um tempo e imprimirá os passos individuais que estão ocorrendo. Eventualmente, a saída deve ser algo como: + +```python +Código Starlark executado com sucesso. Nenhum resultado foi retornado. +INFO[2023-04-07T11:43:16-04:00] ========================================================== +INFO[2023-04-07T11:43:16-04:00] || Enclave criado: local-eth-testnet || +INFO[2023-04-07T11:43:16-04:00] ========================================================== +Nome: local-eth-testnet +UUID: bef8c192008e +Status: EM EXECUÇÃO +Horário de criação: Sex, 07 Abr 2023 11:41:58 EDT + +========================================= Artefatos de Arquivos ========================================= +UUID Nome +cc495a8e364a cl-genesis-data +7033fcdb5471 el-genesis-data +a3aef43fc738 genesis-generation-config-cl +8e968005fc9d genesis-generation-config-el +3182cca9d3cd geth-prefunded-keys +8421166e234f prysm-password +d9e6e8d44d99 validator-keystore-0 +23f5ba517394 validator-keystore-1 +4d28dea40b5c validator-keystore-2 + +========================================== Serviços de Usuário ========================================== +UUID Nome Portas Status +485e6fde55ae cl-client-0-beacon http: 4000/tcp -> http://127.0.0.1:65010 EM EXECUÇÃO + metrics: 5054/tcp -> http://127.0.0.1:65011 + tcp-discovery: 9000/tcp -> 127.0.0.1:65012 + udp-discovery: 9000/udp -> 127.0.0.1:54455 +73739bd158b2 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:65016 EM EXECUÇÃO + metrics: 5064/tcp -> http://127.0.0.1:65017 +1b0a233cd011 cl-client-1-beacon http: 4000/tcp -> 127.0.0.1:65021 EM EXECUÇÃO + metrics: 8008/tcp -> 127.0.0.1:65023 + tcp-discovery: 9000/tcp -> 127.0.0.1:65024 + udp-discovery: 9000/udp -> 127.0.0.1:56031 + validator-metrics: 5064/tcp -> 127.0.0.1:65022 +949b8220cd53 cl-client-1-validator http: 4000/tcp -> 127.0.0.1:65028 EM EXECUÇÃO + metrics: 8008/tcp -> 127.0.0.1:65030 + tcp-discovery: 9000/tcp -> 127.0.0.1:65031 + udp-discovery: 9000/udp -> 127.0.0.1:60784 + validator-metrics: 5064/tcp -> 127.0.0.1:65029 +c34417bea5fa cl-client-2 http: 4000/tcp -> 127.0.0.1:65037 EM EXECUÇÃO + metrics: 8008/tcp -> 127.0.0.1:65035 + tcp-discovery: 9000/tcp -> 127.0.0.1:65036 + udp-discovery: 9000/udp -> 127.0.0.1:63581 +e19738e6329d el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:64986 EM EXECUÇÃO + rpc: 8545/tcp -> 127.0.0.1:64988 + tcp-discovery: 30303/tcp -> 127.0.0.1:64987 + udp-discovery: 30303/udp -> 127.0.0.1:55706 + ws: 8546/tcp -> 127.0.0.1:64989 +e904687449d9 el-client-1 engine-rpc: 8551/tcp -> 127.0.0.1:64993 EM EXECUÇÃO + rpc: 8545/tcp -> 127.0.0.1:64995 + tcp-discovery: 30303/tcp -> 127.0.0.1:64994 + udp-discovery: 30303/udp -> 127.0.0.1:58096 + ws: 8546/tcp -> 127.0.0.1:64996 +ad6f401126fa el-client-2 engine-rpc: 8551/tcp -> 127.0.0.1:65003 EM EXECUÇÃO + rpc: 8545/tcp -> 127.0.0.1:65001 + tcp-discovery: 30303/tcp -> 127.0.0.1:65000 + udp-discovery: 30303/udp -> 127.0.0.1:57269 + ws: 8546/tcp -> 127.0.0.1:65002 +12d04a9dbb69 prelaunch-data-generator-1680882122181135513 PARADO +5b45f9c0504b prelaunch-data-generator-1680882122192182847 PARADO +3d4aaa75e218 prelaunch-data-generator-1680882122201668972 PARADO +``` + +Parabéns! Você configurou com sucesso sua rede de teste local para ter 3 nós em vez de 1. Para executar os mesmos fluxos de trabalho que você fez antes em seu dApp (implantar e testar), realize as mesmas operações que fizemos antes, substituindo `<$YOUR_PORT>` na estrutura `localnet` em seu arquivo de configuração `hardhat.config.ts` pela porta da saída do URI rpc de qualquer serviço `el-client-` em sua nova rede de teste local de 3 nós. + +## Conclusão {#conclusion} + +E é isso! Para recapitular este breve guia, você: + +- Criou uma rede de teste local do Ethereum sobre Docker usando o Kurtosis +- Conectou seu ambiente de desenvolvimento de dApp local à rede Ethereum local +- Implantou um dApp e executou um teste simples nele na rede Ethereum local +- Configurou a rede Ethereum subjacente para ter 3 nós + +Gostaríamos muito de saber sua opinião sobre o que deu certo para você, o que poderia ser melhorado, ou para responder a qualquer uma de suas perguntas. Não hesite em nos contatar via [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose) ou [envie-nos um e-mail](mailto:feedback@kurtosistech.com)! + +### Outros exemplos e guias {#other-examples-guides} + +Nós o encorajamos a conferir nosso [início rápido](https://docs.kurtosis.com/quickstart) (onde você construirá um banco de dados Postgres e uma API sobre ele) e nossos outros exemplos em nosso [repositório awesome-kurtosis](https://github.com/kurtosis-tech/awesome-kurtosis) onde você encontrará ótimos exemplos, incluindo pacotes para: + +- [Iniciar a mesma rede de teste local do Ethereum](https://github.com/kurtosis-tech/eth2-package), mas com serviços adicionais conectados, como um spammer de transações (para simular transações), um monitor de bifurcação e uma instância conectada do Grafana e do Prometheus +- Executar um [teste de sub-rede](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/ethereum-network-partition-test) na mesma rede Ethereum local diff --git a/public/content/translations/pt-br/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md b/public/content/translations/pt-br/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md index 1772d38da05..664674597b9 100644 --- a/public/content/translations/pt-br/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md +++ b/public/content/translations/pt-br/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md @@ -1,60 +1,55 @@ --- title: "Reduzir contratos para combater o limite de tamanho do contrato" -description: O que você pode fazer para evitar que seus contratos inteligentes fiquem muito grandes? +description: "O que você pode fazer para evitar que seus contratos inteligentes se tornem muito grandes?" author: Markus Waas lang: pt-br -tags: - - "solidez" - - "smart contracts" - - "armazenamento" +tags: [ "Solidity", "smart contracts", "armazenamento" ] skill: intermediate published: 2020-06-26 source: soliditydeveloper.com sourceUrl: https://soliditydeveloper.com/max-contract-size --- -## Por que há um limite? {#why-is-there-a-limit} +## Por que existe um limite? {#why-is-there-a-limit} -Em [22 de novembro de 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon) o fork Spurius Dragon introduziu a [EIP-170](https://eips.ethereum.org/EIPS/eip-170) que adicionou um limite de tamanho do contrato inteligente de 24.576 kb. Para você como desenvolvedor de Solidity isso significa que quando você adiciona mais e mais funcionalidade ao seu contrato, em algum momento você alcançará o limite e quando implantado verá o erro: +Em [22 de novembro de 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/), o hard-fork Spurious Dragon introduziu o [EIP-170](https://eips.ethereum.org/EIPS/eip-170), que adicionou um limite de tamanho de contrato inteligente de 24.576 kb. Para você, como um desenvolvedor de Solidity, isso significa que, quando você adiciona cada vez mais funcionalidades ao seu contrato, em algum momento você atingirá o limite e, ao implantar, verá o erro: -`Aviso: O código do contrato excede 24576 bytes (um limite introduzido no Dragão Purioso). This contract may not be deployable on Mainnet. Considere habilitar o otimizador (com um valor baixo de "execução"!), desligar as strings de reverter ou usar bibliotecas.` +`Warning: Contract code size exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.` -Este limite foi introduzido para impedir ataques de negação de serviço (DOS). Qualquer apelo a um contrato é relativamente barato. No entanto, o impacto de uma chamada de contrato para os nós da Ethereum aumenta de forma desproporcionada, dependendo do tamanho do código do contrato chamado (lendo o código do disco, pré-processando o código, adicionando dados à prova de Merkle). Sempre que você tiver uma situação em que o agressor requer poucos recursos para causar muito trabalho para os outros, você tem o potencial para ataques DOS. +Este limite foi introduzido para evitar ataques de negação de serviço (denial-of-service, DOS). Qualquer chamada para um contrato é relativamente barata em termos de gás. No entanto, o impacto de uma chamada de contrato para os nós do Ethereum aumenta desproporcionalmente, dependendo do tamanho do código do contrato chamado (leitura do código do disco, pré-processamento do código, adição de dados à prova de Merkle). Sempre que você tiver uma situação em que o invasor requer poucos recursos para causar muito trabalho para outros, você tem o potencial para ataques de DOS. -Originalmente, tratava-se de um problema menor, porque um limite de tamanho natural do contrato é o limite de gas por bloco. Obviamente, um contrato precisa ser implementado dentro de uma transação que tenha todo o bytecode do contrato. Se você incluir apenas essa transação em um bloco, você pode usar todo esse gas, mas não é infinito. Desde a [London Upgrade](/ethereum-forks/#london), o limite de gas de bloco tem sido capaz de variar entre 15M e 30M de unidades, de acordo com a demanda da rede. +Originalmente, isso era um problema menor porque um limite de tamanho de contrato natural é o limite de gás do bloco. Obviamente, um contrato deve ser implantado dentro de uma transação que contenha todo o bytecode do contrato. Se você incluir apenas essa transação em um bloco, poderá usar todo esse gás, mas não é infinito. Desde a [Atualização London](/ethereum-forks/#london), o limite de gás do bloco tem variado entre 15 e 30 milhões de unidades, dependendo da demanda da rede. -A seguir, analisaremos alguns métodos ordenados pelo seu potencial impacto. Pense nisso em termos de perda de peso. A melhor estratégia para alguém atingir o seu peso alvo (no nosso caso 24kb) é concentrar-se primeiro nos grandes métodos de impacto. Na maioria dos casos, só de ajustar a sua dieta já ajudará, mas às vezes é necessário de um pouco mais. Então você pode adicionar algum exercício (impacto médio) ou até suplementos (impacto pequeno). +A seguir, veremos alguns métodos ordenados por seu potencial impacto. Pense nisso em termos de perda de peso. A melhor estratégia para alguém atingir seu peso-alvo (em nosso caso, 24 kb) é focar primeiro nos métodos de grande impacto. Na maioria dos casos, apenas ajustar sua dieta o levará lá, mas às vezes você precisa de um pouco mais. Então você pode adicionar algum exercício (impacto médio) ou até mesmo suplementos (pequeno impacto). ## Grande impacto {#big-impact} -### Separe os seus contratos {#separate-your-contracts} +### Separe seus contratos {#separate-your-contracts} -Esta deve ser sempre sua primeira abordagem. Como você pode separar o contrato em vários contratos menores? Geralmente isso te força a criar uma boa arquitetura para seus contratos. Os contratos menores são sempre preferidos por uma perspectiva de legibilidade de código. Para dividir contratos, pergunte a si mesmo: +Essa deve ser sempre sua primeira abordagem. Como você pode separar o contrato em vários outros menores? Geralmente, isso o força a criar uma boa arquitetura para seus contratos. Contratos menores são sempre preferíveis do ponto de vista da legibilidade do código. Para dividir contratos, pergunte-se: -- Quais as funções que devem estar juntas? Cada conjunto de funções pode ser o melhor em seu próprio contrato. -- Que funções não requerem leitura do estado do contrato ou apenas um subconjunto específico do estado? +- Quais funções pertencem umas às outras? Cada conjunto de funções pode funcionar melhor em seu próprio contrato. +- Quais funções não exigem a leitura do estado do contrato ou apenas um subconjunto específico do estado? - Você pode dividir o armazenamento e a funcionalidade? ### Bibliotecas {#libraries} -Uma maneira simples de mover o código de funcionalidade para longe do armazenamento é usando [uma biblioteca](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries). Não declarar as funções da biblioteca como internas, como essas, serão [adicionadas ao contrato](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking) diretamente durante a compilação. Mas se usarmos funções públicas, elas estarão então de fato, num contrato separado de biblioteca. Considere [o uso de](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for) para fazer o uso de bibliotecas mais convenientes. +Uma maneira simples de mover o código de funcionalidade para longe do armazenamento é usando uma [biblioteca](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries). Não declare as funções da biblioteca como `internal`, pois elas serão [adicionadas ao contrato](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking) diretamente durante a compilação. Mas se você usar funções públicas, elas estarão de fato em um contrato de biblioteca separado. Considere usar [using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for) para tornar o uso de bibliotecas mais conveniente. ### Proxies {#proxies} -Uma estratégia mais avançada seria um sistema de procuração. As bibliotecas usam `DELEGATECALL` na parte traseira, que simplesmente executa a função de outro contrato com o estado do contrato de chamada. Confira [esta postagem no blog](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2) para saber mais sobre sistemas de proxy. Eles lhe dão mais funcionalidade, por exemplo, permitem a atualização, mas também adicionam muita complexidade. Eu não adicionaria aquelas apenas para reduzir os tamanhos dos contratos, a menos que fosse a sua única opção por qualquer motivo. +Uma estratégia mais avançada seria um sistema de proxy. As bibliotecas usam `DELEGATECALL` nos bastidores, o que simplesmente executa a função de outro contrato com o estado do contrato que está chamando. Confira [esta postagem do blog](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2) para saber mais sobre sistemas de proxy. Eles dão a você mais funcionalidade, por exemplo, eles permitem a capacidade de atualização, mas também adicionam muita complexidade. Eu não os adicionaria apenas para reduzir o tamanho dos contratos, a menos que seja sua única opção por algum motivo. -## Médio impacto {#medium-impact} +## Impacto médio {#medium-impact} -### Remover funções {#remove-functions} +### Remova funções {#remove-functions} -Este deveria ser óbvio. Funções aumentam um pouco o tamanho de um contrato. +Isso deve ser óbvio. As funções aumentam um pouco o tamanho de um contrato. -- **Externo**: Frequentemente adicionamos muitas funções de exibição por motivos de conveniência. Está perfeitamente tudo bem até que você atinja o limite de tamanho. Então talvez queiram realmente pensar na eliminação de todos que não os absolutamente essenciais. -- **Interno**: Você também pode remover funções internas/privadas e simplesmente inserir o código, desde que a função seja chamada apenas uma vez. +- **Externas**: muitas vezes, adicionamos muitas funções de visualização por conveniência. Isso é perfeitamente normal até você atingir o limite de tamanho. Então, você pode querer realmente pensar em remover todas, exceto as absolutamente essenciais. +- **Internas**: você também pode remover funções internas/privadas e simplesmente embutir o código, desde que a função seja chamada apenas uma vez. -### Evitar variáveis adicionais {#avoid-additional-variables} - -Uma mudança simples assim: +### Evite variáveis adicionais {#avoid-additional-variables} ```solidity function get(uint id) returns (address,address) { @@ -69,24 +64,23 @@ function get(uint id) returns (address,address) { } ``` -faz diferença de **0.28kb**. Você pode encontrar muitas situações semelhantes nos seus contratos e isso pode realmente somar quantias significativas. +Uma simples alteração como essa faz uma diferença de **0.28kb**. É provável que você encontre muitas situações semelhantes em seus contratos e elas podem realmente somar valores significativos. -### Encurtar mensagem de erro {#shorten-error-message} +### Encurte as mensagens de erro {#shorten-error-message} -Mensagens de reversão longa e, em particular, muitas mensagens de reversão diferentes podem bloquear o contrato. Em vez disso, use códigos de erro curtos e decodifique-os no contrato. Uma mensagem longa poderia ser muito mais curta: +Mensagens de reversão longas e, em particular, muitas mensagens de reversão diferentes podem inchar o contrato. Em vez disso, use códigos de erro curtos e decodifique-os em seu contrato. Uma mensagem longa pode se tornar muito mais curta: ```solidity require(msg.sender == owner, "Only the owner of this contract can call this function"); - ``` ```solidity require(msg.sender == owner, "OW1"); ``` -### Use erros personalizados ao invés de mensagens de erro +### Use erros personalizados em vez de mensagens de erro -Erros personalizados foram introduzidos no [Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/). Eles são uma ótima maneira de reduzir o tamanho de seus contratos, porque são codificados por ABI como seletores (assim como as funções são). +Erros personalizados foram introduzidos no [Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/). Eles são uma ótima maneira de reduzir o tamanho de seus contratos, porque são codificados pela ABI como seletores (assim como as funções). ```solidity error Unauthorized(); @@ -96,15 +90,15 @@ if (msg.sender != owner) { } ``` -### Considere um valor de baixa execução no otimizador {#consider-a-low-run-value-in-the-optimizer} +### Considere um valor baixo de execução no otimizador {#consider-a-low-run-value-in-the-optimizer} -Você também pode alterar as configurações do otimizador. O valor padrão de 200 significa que está tentando otimizar o bytecode como se uma função fosse chamada 200 vezes. Se você alterá-lo para 1, basicamente diga ao otimizador para otimizar em caso de executar cada função apenas uma vez. Uma função otimizada para rodar apenas uma vez significa que ela é otimizada para a própria implantação. Esteja ciente de que **isso aumenta o custo do [gás](/developers/docs/gas/) por executar as funções**, então você pode querer não otimizá-la. +Você também pode alterar as configurações do otimizador. O valor padrão de 200 significa que ele está tentando otimizar o bytecode como se uma função fosse chamada 200 vezes. Se você alterá-lo para 1, basicamente diz ao otimizador para otimizar para o caso de executar cada função apenas uma vez. Uma função otimizada para ser executada apenas uma vez significa que ela é otimizada para a própria implantação. Esteja ciente de que **isso aumenta os [custos de gás](/developers/docs/gas/) para executar as funções**, então talvez você não queira fazer isso. ## Pequeno impacto {#small-impact} -### Evite passar instruções para funções {#avoid-passing-structs-to-functions} +### Evite passar structs para funções {#avoid-passing-structs-to-functions} -Se você estiver usando o [ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2), ele pode ajudar a não passar de structs para uma função. Em vez de passar o parâmetro como uma estrutura... +Se você estiver usando o [ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2), pode ajudar não passar structs para uma função. Em vez de passar o parâmetro como um struct, passe os parâmetros necessários diretamente. Neste exemplo, economizamos mais **0.1kb**. ```solidity function get(uint id) returns (address,address) { @@ -126,16 +120,14 @@ function _get(address addr1, address addr2) private view returns(address,address } ``` -... passe os parâmetros necessários diretamente. Neste exemplo, salvamos outro **0.1kb**. - -### Declarar a visibilidade correta para funções e variáveis {#declare-correct-visibility-for-functions-and-variables} +### Declare a visibilidade correta para funções e variáveis {#declare-correct-visibility-for-functions-and-variables} -- Funções ou variáveis que são chamadas apenas do lado de fora? Declará-las como `externas` em vez de `públicas`. -- Funções ou variáveis apenas chamadas dentro do contrato? Declará-las como `private` ou `internal` em vez de `public`. +- Funções ou variáveis que são chamadas apenas de fora? Declare-as como `external` em vez de `public`. +- Funções ou variáveis chamadas apenas de dentro do contrato? Declare-as como `private` ou `internal` em vez de `public`. -### Remover modificadores {#remove-modifiers} +### Remova modificadores {#remove-modifiers} -Os modificadores, especialmente quando usados intencionalmente, podem ter um impacto significativo no tamanho do contrato. Considere removê-los e, em vez disso, usar funções. +Modificadores, especialmente quando usados intensamente, podem ter um impacto significativo no tamanho do contrato. Considere removê-los e, em vez disso, usar funções. ```solidity modifier checkStuff() {} @@ -149,4 +141,4 @@ function checkStuff() private {} function doSomething() { checkStuff(); } ``` -Essas dicas devem ajudá-lo a reduzir significativamente o tamanho do contrato. Mais uma vez, nunca é demais salientar que se foca sempre na divisão dos contratos, se possível para o maior impacto. +Essas dicas devem ajudá-lo a reduzir significativamente o tamanho do contrato. Mais uma vez, não custa reforçar: sempre se concentre em dividir os contratos, se possível, para obter o maior impacto. diff --git a/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md index fd950d155e5..a3e2ce0f281 100644 --- a/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md +++ b/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md @@ -1,20 +1,22 @@ --- title: "EIP-1271: Assinatura e verificação de contratos inteligentes" -description: Uma visão geral de geração de assinatura de contratos inteligentes e verificação com a EIP-1271. Também passaremos pela implementação da EIP-1271 usada no Safe (anteriormente Gnosis Safe) para fornecer um exemplo concreto de contrato inteligente para que desenvolvedores possam construir por cima dele. +description: "Uma visão geral de geração de assinatura de contratos inteligentes e verificação com a EIP-1271. Também passaremos pela implementação da EIP-1271 usada no Safe (anteriormente Gnosis Safe) para fornecer um exemplo concreto de contrato inteligente para que desenvolvedores possam construir por cima dele." author: Nathan H. Leung lang: pt-br tags: - - "eip-1271" - - "contratos inteligentes" - - "verificando" - - "assinatura" + [ + "eip-1271", + "smart contracts", + "verificando", + "signing" + ] skill: intermediate published: 2023-01-12 --- -A norma [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) permite a contratos inteligentes verificarem assinaturas. +O padrão [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) permite que contratos inteligentes verifiquem assinaturas. -Neste tutorial, forneceremos uma visão geral das assinaturas digitais, noções básicas sobre a EIP-1271, e a implementação específica da EIP-1271 usada pelo [Safe](https://safe.global/) (previamente Gnosis Safe). Tudo isso pode servir como ponto de partida para a implementação da EIP-1271 nos seus próprios contratos. +Neste tutorial, damos uma visão geral de assinaturas digitais, o histórico do EIP-1271 e a implementação específica do EIP-1271 usada pelo [Safe](https://safe.global/) (anteriormente Gnosis Safe). Tudo isso pode servir como ponto de partida para a implementação da EIP-1271 nos seus próprios contratos. ## O que é assinatura? @@ -24,7 +26,7 @@ Por exemplo, uma assinatura digital pode se parecer com isto: 1. Mensagem: “Quero me conectar a este website com minha carteira Ethereum.” 2. Assinante: Meu endereço é `0x000…` -3. Prova: Aqui está uma prova de que eu, `0x000…`, realmente criei esta mensagem inteira (isto é geralmente algo criptográfico). +3. Prova: aqui está uma prova de que eu, `0x000…`, realmente criei esta mensagem inteira (geralmente é algo criptográfico). É importante observar que uma assinatura digital inclui ambos, uma “mensagem” e uma “assinatura”. @@ -36,11 +38,11 @@ Da mesma maneira, uma assinatura digital não significa nada sem uma mensagem as Para criar uma assinatura digital para uso em blockchains baseados em Ethereum, você geralmente precisa de uma chave secreta que ninguém mais conhece. Isto é o que faz sua assinatura, sua (ninguém mais pode criar a mesma assinatura sem o conhecimento da chave secreta). -Sua conta Ethereum (ou seja, conta de propriedade externa / EOA) tem uma chave privada associada a ela quando um website ou dapp pergunta por sua assinatura (por exemplo: “Log in with Ethereum”). +Sua conta Ethereum (ou seja, sua conta de propriedade externa/EOA) tem uma chave privada associada a ela, e essa é a chave privada que normalmente é usada quando um site ou dapp solicita sua assinatura (por exemplo, para “Fazer login com a Ethereum”). -Um app pode [verificar uma assinatura](https://docs.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum) que você criou usando uma biblioteca de terceiros, como ethers.js [sem conhecer sua chave privada](https://en.wikipedia.org/wiki/Public-key_cryptography) e estar confiante de que foi _você_ quem criou a assinatura. +Um aplicativo pode [verificar uma assinatura](https://www.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum) que você cria usando uma biblioteca de terceiros como o ethers.js [sem saber sua chave privada](https://en.wikipedia.org/wiki/Public-key_cryptography) e ter a certeza de que foi _você_ quem criou a assinatura. -> De fato, como as assinaturas digitais EOA usam criptografia de chave pública, elas podem ser geradas e verificadas **off-chain**! É assim que a votação em DAO sem gás funciona — em vez de submeter votos on-chain, as assinaturas digitais podem ser criadas e verificadas off-chain usando bibliotecas criptográficas. +> Na verdade, como as assinaturas digitais de EOA usam criptografia de chave pública, elas podem ser geradas e verificadas **fora da cadeia**! É assim que a votação em DAO sem gás funciona — em vez de enviar votos na cadeia, as assinaturas digitais podem ser criadas e verificadas fora da cadeia usando bibliotecas criptográficas. Enquanto as contas EOA têm uma chave privada, as contas de contrato inteligente não têm nenhum tipo de chave privada ou secreta (portanto, “Entrar com Ethereum”, etc. não pode funcionar nativamente com contas de contratos inteligentes). @@ -50,17 +52,17 @@ O problema que a EIP-1271 visa resolver: como podemos dizer que uma assinatura d Contratos inteligentes não têm chaves privadas que possam ser usadas para assinar mensagens. Então, como podemos saber se uma assinatura é autêntica? -Bem, uma ideia é que podemos _perguntar_ ao contrato inteligente se uma assinatura é autêntica! +Bem, uma ideia é que podemos simplesmente _perguntar_ ao contrato inteligente se uma assinatura é autêntica! O que o EIP-1271 faz é padronizar a ideia de "perguntar" ao contrato inteligente se uma dada assinatura é válida. -Um contrato que implementa EIP-1271 deve ter uma função chamada `isValidSignature` que recebe a mensagem e a assinatura. O contrato pode então executar alguma lógica de validação (a especificação não força nada específico aqui) e então retornar um valor indicando se a assinatura é válida ou não. +Um contrato que implementa o EIP-1271 deve ter uma função chamada `isValidSignature` que recebe uma mensagem e uma assinatura. O contrato pode então executar alguma lógica de validação (a especificação não força nada específico aqui) e então retornar um valor indicando se a assinatura é válida ou não. -Se `isValidSignature` retornar um resultado válido, isso é basicamente o contrato dizendo “sim, eu aprovo esta assinatura + mensagem!” +Se `isValidSignature` retornar um resultado válido, é basicamente o contrato dizendo: “sim, eu aprovo esta assinatura + mensagem!” ### Interface -Aqui está a interface exata na especificação da EIP-1271 (falaremos sobre o parâmetro `_hash` abaixo, mas por enquanto, pense nele como a mensagem que está sendo verificada): +Aqui está a interface exata na especificação do EIP-1271 (falaremos sobre o parâmetro `_hash` abaixo, mas, por enquanto, pense nele como a mensagem que está sendo verificada): ```jsx pragma solidity ^0.5.0; @@ -71,13 +73,13 @@ contract ERC1271 { bytes4 constant internal MAGICVALUE = 0x1626ba7e; /** - * @dev Should return whether the signature provided is valid for the provided hash - * @param _hash Hash of the data to be signed - * @param _signature Signature byte array associated with _hash + * @dev Deve retornar se a assinatura fornecida é válida para o hash fornecido + * @param _hash Hash dos dados a serem assinados + * @param _signature Array de bytes de assinatura associado a _hash * - * MUST return the bytes4 magic value 0x1626ba7e when function passes. - * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5) - * MUST allow external calls + * DEVE retornar o valor mágico bytes4 0x1626ba7e quando a função for bem-sucedida. + * NÃO DEVE modificar o estado (usando STATICCALL para solc < 0.5, modificador view para solc > 0.5) + * DEVE permitir chamadas externas */ function isValidSignature( bytes32 _hash, @@ -90,28 +92,28 @@ contract ERC1271 { ## Exemplo de implementação da EIP-1271: Safe -Os contratos podem implementar `isValidSignature` de várias maneiras — a especificação somente não diz muito sobre a implementação exata. +Os contratos podem implementar `isValidSignature` de muitas maneiras — a especificação não diz muito sobre a implementação exata. Um contrato importante que implementa a EIP-1271 é o Safe (anteriormente Gnosis Safe). -No código do Safe, `isValidSignature` [ é implementada](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol) para que assinaturas possam ser criadas e verificadas de [duas maneiras](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support): +No código do Safe, `isValidSignature` [é implementado](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol) para que as assinaturas possam ser criadas e verificadas de [duas maneiras](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support): -1. Mensagens on-chain - 1. Criação: um proprietário Safe cria uma nova transação Safe para “assinar” a mensagem, passando a mensagem como um dado na transação. Uma vez que proprietários suficientes assinam a transação para alcançar o limite multisig, a transação é enviada e executada. Na transação, há uma função Safe chamada, que adiciona a mensagem à lista de mensagens “aprovadas”. - 2. Verificação: chame `isValidSignature` no contrato Safe, e transmita a mensagem para verificar enquanto parâmetro da mensagem e [ um parâmetro vazio como parâmetro da assinatura](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (i.e., `0x`). O Safe verá que o parâmetro da assinatura está vazio e, em vez de verificar a assinatura criptograficamente, ele saberá que deve prosseguir e verificar se a mensagem está na lista de mensagens “aprovadas”. -2. Mensagens off-chain: - 1. Criação: um proprietário Safe cria uma mensagem off-chain, e então consegue outros proprietários Safe para assinar a mensagem, cada um individualmente, até que haja assinaturas suficientes para conseguir a aprovação pelo limite do multisig. - 2. Verificação: chama `isValidSignature`. No parâmetro da mensagem, passa a mensagem para ser verificada. No parâmetro da assinatura, passa cada assinatura individual de proprietário Safe todas concatenadas juntas. O Safe irá checar que há assinaturas suficientes para atingir o limite **e** que cada assinatura é válida. Acontecendo isso, ele retornará um valor indicando verificação da assinatura com sucesso. +1. Mensagens na cadeia + 1. Criação: um proprietário Safe cria uma nova transação Safe para “assinar” a mensagem, passando a mensagem como um dado na transação. Uma vez que proprietários suficientes assinam a transação para alcançar o limite multisig, a transação é enviada e executada. Na transação, há uma função do Safe chamada (`signMessage(bytes calldata _data)`) que adiciona a mensagem a uma lista de mensagens “aprovadas”. + 2. Verificação: chame `isValidSignature` no contrato Safe e passe a mensagem a ser verificada como o parâmetro da mensagem e [um valor vazio para o parâmetro da assinatura](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (ou seja, `0x`). O Safe verá que o parâmetro da assinatura está vazio e, em vez de verificar a assinatura criptograficamente, ele saberá que deve prosseguir e verificar se a mensagem está na lista de mensagens “aprovadas”. +2. Mensagens fora da cadeia: + 1. Criação: um proprietário do Safe cria uma mensagem fora da cadeia, em seguida, faz com que outros proprietários do Safe assinem a mensagem individualmente, até que haja assinaturas suficientes para atingir o limite de aprovação da multisig. + 2. Verificação: chame `isValidSignature`. No parâmetro da mensagem, passa a mensagem para ser verificada. No parâmetro da assinatura, passa cada assinatura individual de proprietário Safe todas concatenadas juntas. O Safe verificará se há assinaturas suficientes para atingir o limite **e** se cada assinatura é válida. Acontecendo isso, ele retornará um valor indicando verificação da assinatura com sucesso. ## O que é exatamente o parâmetro `_hash`? Por que não passar a mensagem inteira? -Você pode ter notado que a função `isValidSignature` na interface [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) não pega a mensagem propriamente dita, mas, em vezés disso, um parâmetro `_hash`. O que isto significa é que ao invés de passar a mensagem inteira de tamanho arbitrário para `isValidSignature`, nós passamos um hash de 32-bytes da mensagem (geralmente keccak256). +Você deve ter notado que a função `isValidSignature` na [interface do EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) não recebe a mensagem em si, mas sim um parâmetro `_hash`. O que isso significa é que, em vez de passar a mensagem completa de tamanho arbitrário para `isValidSignature`, nós passamos um hash de 32 bytes da mensagem (geralmente keccak256). -Cada byte de calldata — ou seja, dados de parâmetro da função passados para uma função de contrato inteligente — [custa16 gás (4 gás se zero byte)](https://eips.ethereum.org/EIPS/eip-2028), então, isso pode economizar um monte de gás se a mensagem for longa. +Cada byte de calldata — ou seja, dados de parâmetro de função passados para uma função de contrato inteligente — [custa 16 de gás (4 de gás se for um byte zero)](https://eips.ethereum.org/EIPS/eip-2028), então isso pode economizar muito gás se uma mensagem for longa. ### Especificações EIP-1271 anteriores -Existem outras especificações EIP-1271 por aí, que têm uma função `isValidSignature` com um primeiro parâmetro do tipo `bytes` (tamanho arbitrário, em vez de tamanho fixo `bytes32`) e nome de parâmetro `message`. Essa é uma [versão mais antiga](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206) da norma EIP-1271. +Existem especificações EIP-1271 por aí que têm uma função `isValidSignature` com um primeiro parâmetro do tipo `bytes` (comprimento arbitrário, em vez de um `bytes32` de comprimento fixo) e o nome de parâmetro `message`. Esta é uma [versão mais antiga](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206) do padrão EIP-1271. ## Como o EIP-1271 poderia ser implementado nos meus próprios contratos? @@ -124,4 +126,4 @@ No final, depende de você, como desenvolvedor do contrato! ## Conclusão -A [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) é uma norma versátil que permite contratos inteligentes verificar assinaturas. Ele abre a porta para contratos inteligentes que funcionam mais como EOAs - por exemplo fornecendo uma maneira de se "conectar via Ethereum" para trabalhar com contratos inteligentes - e ele pode ser implementado de várias maneiras (Safe tendo uma implementação interessante e não trivial a se considerar). +O [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) é um padrão versátil que permite que contratos inteligentes verifiquem assinaturas. Ele abre a porta para contratos inteligentes que funcionam mais como EOAs - por exemplo fornecendo uma maneira de se "conectar via Ethereum" para trabalhar com contratos inteligentes - e ele pode ser implementado de várias maneiras (Safe tendo uma implementação interessante e não trivial a se considerar). diff --git a/public/content/translations/pt-br/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/pt-br/developers/tutorials/erc-721-vyper-annotated-code/index.md index b782878b951..ea4bb6c680f 100644 --- a/public/content/translations/pt-br/developers/tutorials/erc-721-vyper-annotated-code/index.md +++ b/public/content/translations/pt-br/developers/tutorials/erc-721-vyper-annotated-code/index.md @@ -1,31 +1,34 @@ --- -title: "Passo a passo do contrato Vyper ERC-721" -description: Ryuya Nakamura's ERC-721 contrato e como funciona +title: "Passo a passo do Contrato Vyper ERC-721" +description: Contrato ERC-721 de Ryuya Nakamura e como ele funciona author: Ori Pomerantz lang: pt-br -tags: - - "vyper" - - "erc-721" - - "python" +tags: [ "Vyper", "erc-721", "Python" ] skill: beginner published: 2021-04-01 --- ## Introdução {#introduction} -O [ERC-721](/developers/docs/standards/tokens/erc-721/) padrão é usado para manter a propriedade de tokens não fungíveis (NFT). [ERC-20](/developers/docs/standards/tokens/erc-20/) os tokens se comportam como uma mercadoria, porque não há diferença entre os totens individuais. Em contraste com isso, ERC-721 tokens são projetados para ativos semelhantes, mas não idênticos, como diferentes [cat cartoons](https://www.cryptokitties.co/) ou títulos de diferentes imóveis. +O padrão [ERC-721](/developers/docs/standards/tokens/erc-721/) é usado para manter a propriedade de Tokens Não Fungíveis (NFT). +Os tokens [ERC-20](/developers/docs/standards/tokens/erc-20/) se comportam como uma commodity, porque não há diferença entre tokens individuais. +Em contraste com isso, os tokens ERC-721 são projetados para ativos que são semelhantes, mas não idênticos, como diferentes [desenhos de gatos](https://www.cryptokitties.co/) +ou títulos para diferentes peças de imóveis. -Neste artigo, vamos analisar o [contrato ERC-721 de Ryuya Nakamura](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy). Este contrato é escrito em [Vyper](https://vyper.readthedocs.io/en/latest/index.html), a Python-like linguagem de contrato projetada para tornar é mais difícil escrever código inseguro do que na solidez. +Neste artigo, analisaremos o [contrato ERC-721 de Ryuya Nakamura](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy). +Este contrato é escrito em [Vyper](https://vyper.readthedocs.io/en/latest/index.html), uma linguagem de contrato semelhante ao Python, projetada para tornar mais difícil escrever código inseguro do que em Solidity. ## O Contrato {#contract} ```python -# @dev Implementation of ERC-721 non-fungible token standard. +# @dev Implementação do padrão de token não fungível ERC-721. # @author Ryuya Nakamura (@nrryuya) -# Modified from: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy +# Modificado de: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy ``` -Comentários em Vyper, como em Python, começam com um hash (`#`) e continuam até o final da linha. Comentários que incluem `@` são usados ​​por [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) para produzir documentação legível para humanos. +Comentários em Vyper, como em Python, começam com um hash (`#`) e continuam até o final da linha. Comentários que incluem +`@` são usados pelo [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) para produzir documentação legível +por humanos. ```python from vyper.interfaces import ERC721 @@ -33,155 +36,192 @@ from vyper.interfaces import ERC721 implements: ERC721 ``` -A interface ERC-721 é construída na linguagem Vyper. [você pode ver o código definido aqui](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py). A definição da interface é escrita em Python, em vez de Vyper, porque as interfaces são usadas não apenas dentro da blockchain, mas também ao enviar à blockchain uma transação de um cliente externo, que pode ser escrito em Python. +A interface ERC-721 é integrada à linguagem Vyper. +[Você pode ver a definição do código aqui](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py). +A definição da interface é escrita em Python, em vez de Vyper, porque as interfaces são usadas não apenas dentro da +blockchain, mas também ao enviar uma transação para a blockchain a partir de um cliente externo, que pode ser escrito em +Python. -A primeira linha importa a ‘interface’, e o segundo especifica o que estamos incrementando aqui. +A primeira linha importa a interface, e a segunda especifica que estamos implementando-a aqui. ### A interface ERC721Receiver {#receiver-interface} ```python -# Interface for the contract called by safeTransferFrom() +# Interface para o contrato chamado por safeTransferFrom() interface ERC721Receiver: def onERC721Received( ``` -ERC-721 suporta dois tipos de transferência: +O ERC-721 suporta dois tipos de transferência: -- ` transfere de `, que permite ao remetente especifique qualquer endereço de destino e coloca a responsabilidade para a transferência no remetente. Isso significa que você pode transferir para um endereço inválido, caso em que o NFT será perdido para sempre. -- `safeTransferFrom`, que verifica se o endereço de destino é um contrato. Se for assim, o contrato ERC-721 pergunta ao contrato receptor se deseja receber o NFT. +- `transferFrom`, que permite ao remetente especificar qualquer endereço de destino e coloca a responsabilidade + da transferência no remetente. Isso significa que você pode transferir para um endereço inválido, caso em que + o NFT é perdido para sempre. +- `safeTransferFrom`, que verifica se o endereço de destino é um contrato. Se for, o contrato ERC-721 + pergunta ao contrato receptor se ele quer receber o NFT. -Para responder ` transferência segura de ` solicita um recebimento contrato deve implementar `ERC721 recebedor `. +Para responder às solicitações de `safeTransferFrom`, um contrato de recebimento precisa implementar o `ERC721Receiver`. ```python _operator: address, _from: address, ``` -O endereço `_de ` é o proprietário atual do token. O endereço `_operador` é aquele que solicitou a transferência (esses dois podem não ser o mesmo devido às provisões). +O endereço `_from` é o proprietário atual do token. O endereço `_operator` é aquele que +solicitou a transferência (esses dois podem não ser os mesmos, por causa das permissões). ```python _tokenId: uint256, ``` -ERC-721 token IDs está 256 bits. Normalmente, elas são criados por meio de uma execução de hash da descrição que o token representa. +Os IDs de token ERC-721 são de 256 bits. Normalmente, eles são criados por hashing de uma descrição do que +o token representa. ```python _data: Bytes[1024] ``` -O requerimento pode ter até 1024 bytes de dados do usuário. +A solicitação pode ter até 1024 bytes de dados do usuário. ```python ) -> bytes32: view ``` -Para evitar casos em que um contrato acidentalmente aceita uma transferência o valor de retorno não é um booleano, mas 256 bits com um valor específico. +Para evitar casos em que um contrato aceite acidentalmente uma transferência, o valor de retorno não é um booleano, +mas 256 bits com um valor específico. Essa função é uma `view`, o que significa que pode ler o estado da blockchain, mas não modificá-lo. ### Eventos {#events} -Os [eventos](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e) são emitidos para informar usuários e servidores fora da blockchain de eventos. Observe que o conteúdo dos eventos não está disponível para contratos na blockchain. +[Eventos](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e) +são emitidos para informar usuários e servidores fora da blockchain sobre os eventos. Observe que o conteúdo dos eventos +não está disponível para contratos na blockchain. ```python -# @dev Emits when ownership of any NFT changes by any mechanism. This event emits when NFTs are -# created (`from` == 0) and destroyed (`to` == 0). Exception: during contract creation, any -# number of NFTs may be created and assigned without emitting Transfer. At the time of any -# transfer, the approved address for that NFT (if any) is reset to none. -# @param _from Sender of NFT (if address is zero address it indicates token creation). -# @param _to Receiver of NFT (if address is zero address it indicates token destruction). -# @param _tokenId The NFT that got transferred. +# @dev Emite quando a propriedade de qualquer NFT muda por qualquer mecanismo. Este evento é emitido quando os NFTs são +# criados (`from` == 0) e destruídos (`to` == 0). Exceção: durante a criação do contrato, qualquer +# número de NFTs pode ser criado e atribuído sem emitir Transfer. No momento de qualquer +# transferência, o endereço aprovado para esse NFT (se houver) é redefinido para nenhum. +# @param _from Remetente do NFT (se o endereço for o endereço zero, isso indica a criação do token). +# @param _to Receptor do NFT (se o endereço for o endereço zero, indica a destruição do token). +# @param _tokenId O NFT que foi transferido. event Transfer: sender: indexed(address) receiver: indexed(address) tokenId: indexed(uint256) ``` -Isso é similar para o evento ERC-20 Transfer, exceto que informamos um `tokenId` em vez de um valor. Ninguém possui o endereço zero, portanto, por convenção, o usamos para relatar a criação e a destruição de tokens. +Isso é semelhante ao evento Transfer do ERC-20, exceto que relatamos um `tokenId` em vez de um valor. +Ninguém é dono do endereço zero, então, por convenção, nós o usamos para relatar a criação e a destruição de tokens. ```python -# @dev This emits when the approved address for an NFT is changed or reaffirmed. The zero -# address indicates there is no approved address. When a Transfer event emits, this also -# indicates that the approved address for that NFT (if any) is reset to none. -# @param _owner Owner of NFT. -# @param _approved Address that we are approving. -# @param _tokenId NFT which we are approving. +# @dev Isto emite quando o endereço aprovado para um NFT é alterado ou reafirmado. O endereço +# zero indica que não há endereço aprovado. Quando um evento Transfer emite, isso também +# indica que o endereço aprovado para esse NFT (se houver) é redefinido para nenhum. +# @param _owner Proprietário do NFT. +# @param _approved Endereço que estamos aprovando. +# @param _tokenId NFT que estamos aprovando. event Approval: owner: indexed(address) approved: indexed(address) tokenId: indexed(uint256) ``` -Uma aprovação ERC-721 é semelhante a uma permissão ERC-20. Um endereço específico é autorizado a transferir um determinado símbolo. Isso fornece um mecanismo para os contratos responderem quando aceitam um token. Os contratos não podem ouvir os eventos, portanto, se você apenas transferir o token para eles, eles não “saberão” disso. Desta forma, primeiro, o proprietário envia uma aprovação e, em seguida, envia uma solicitação ao contrato: “Aprovei para você transferir o token X, faça…”. +Uma aprovação ERC-721 é semelhante a uma permissão ERC-20. Um endereço específico tem permissão para transferir um token +específico. Isso dá um mecanismo para os contratos responderem quando aceitam um token. Contratos não podem +escutar eventos, então se você apenas transferir o token para eles, eles não "sabem" sobre isso. Dessa forma, o +proprietário primeiro envia uma aprovação e, em seguida, envia uma solicitação ao contrato: "Eu aprovei que você transfira o token +X, por favor, faça ...". -Esse é o designe escolhido por fazer o ERC-721 padrão semelhante ao padrão ERC-20. Como os tokens ERC-721 não são fungíveis, um contrato também pode identificar que obteve um token específico olhando a propriedade do token. +Esta é uma escolha de design para tornar o padrão ERC-721 semelhante ao padrão ERC-20. Como +os tokens ERC-721 não são fungíveis, um contrato também pode identificar que obteve um token específico +observando a propriedade do token. ```python -# @dev This emits when an operator is enabled or disabled for an owner. The operator can manage -# all NFTs of the owner. -# @param _owner Owner of NFT. -# @param _operator Address to which we are setting operator rights. -# @param _approved Status of operator rights(true if operator rights are given and false if -# revoked). +# @dev Isto emite quando um operador é habilitado ou desabilitado para um proprietário. O operador pode gerenciar +# todos os NFTs do proprietário. +# @param _owner Proprietário do NFT. +# @param _operator Endereço para o qual estamos definindo os direitos do operador. +# @param _approved Status dos direitos do operador (verdadeiro se os direitos do operador forem concedidos e falso se +# revogado). event ApprovalForAll: owner: indexed(address) operator: indexed(address) approved: bool ``` -Às vezes, é útil ter um _operador_ que pode gerenciar todos os tokens da conta de um tipo específico (aqueles gerenciados por um contrato específico), semelhante a uma procuração. Por exemplo, eu posso querer dar tal poder a um contrato que verifica se Eu não tenho contatado ele por seis meses, e se assim for distribuo os meus bens aos meus herdeiros (se um deles o pedir, contrata não pode fazer nada sem ser chamado por uma transação). No ERC-20, podemos simplesmente atribuir uma provisão alta a um contrato de herança, mas isso não funciona para ERC-721, pois os tokens não são fungíveis. Isso é o equivalente. +Às vezes é útil ter um _operador_ que pode gerenciar todos os tokens de um tipo específico de uma conta (aqueles que são gerenciados por +um contrato específico), semelhante a uma procuração. Por exemplo, eu talvez queira dar esse poder a um contrato que verifica se +eu não o contatei por seis meses e, em caso afirmativo, distribui meus ativos para meus herdeiros (se um deles pedir, os contratos +não podem fazer nada sem serem chamados por uma transação). No ERC-20, podemos simplesmente dar uma alta permissão a um contrato de herança, +mas isso não funciona para o ERC-721 porque os tokens não são fungíveis. Este é o equivalente. -O valor `approved` nos informa se o evento é para uma aprovação ou a retirada de uma aprovação. +O valor `aprovado` nos diz se o evento é para uma aprovação ou a retirada de uma aprovação. -### Variáveis ​​de Estado {#state-vars} +### Variáveis de Estado {#state-vars} -Essas variáveis contêm o estado atual dos tokens: os quais estão disponíveis e a quem os possui. A maioria delas são objetos `HashMap`, [mapeamentos unidirecionais que existem entre dois tipos](https://vyper.readthedocs.io/en/latest/types.html#mappings). +Essas variáveis contêm o estado atual dos tokens: quais estão disponíveis e quem os possui. A maioria deles +são objetos `HashMap`, [mapeamentos unidirecionais que existem entre dois tipos](https://vyper.readthedocs.io/en/latest/types.html#mappings). ```python -# @dev Mapping from NFT ID to the address that owns it. +# @dev Mapeamento do ID do NFT para o endereço que o possui. idToOwner: HashMap[uint256, address] -# @dev Mapping from NFT ID to approved address. +# @dev Mapeamento do ID do NFT para o endereço aprovado. idToApprovals: HashMap[uint256, address] ``` -As identidades de usuários e contratos no Ethereum são representados por endereços de 160 bits. Essas duas variáveis mapeiam IDs de tokens para seus proprietários e aqueles aprovados a transferi-los (no máximo um para cada). No Ethereum, os dados não inicializados são sempre zero, pois, se não houver proprietário ou transferidor aprovado, o valor desse token será zero. +As identidades de usuários e contratos no Ethereum são representadas por endereços de 160 bits. Essas duas variáveis mapeiam +de IDs de token para seus proprietários e aqueles aprovados para transferi-los (no máximo um para cada). No Ethereum, +os dados não inicializados são sempre zero, então se não houver proprietário ou transferidor aprovado, o valor para aquele token +será zero. ```python -# @dev Mapping from owner address to count of his tokens. +# @dev Mapeamento do endereço do proprietário para a contagem de seus tokens. ownerToNFTokenCount: HashMap[address, uint256] ``` -Essa variável possui a contagem de tokens para cada proprietário. Não há mapeamento de proprietários para tokens, então, a única forma de identificar os tokens que um proprietário específico possui é olhar para trás no histórico de eventos da blockchain e ver os eventos `Transfer` apropriados. Podemos usar essa variável para saber quando temos todos os NFTs e não precisaremos mais olhar ainda mais no tempo. +Esta variável contém a contagem de tokens para cada proprietário. Não há mapeamento de proprietários para tokens, então +a única maneira de identificar os tokens que um proprietário específico possui é olhar para trás no histórico de eventos da blockchain +e ver os eventos `Transfer` apropriados. Podemos usar essa variável para saber quando temos todos os NFTs e não +precisamos procurar ainda mais no tempo. -Observe que esse algoritmo funciona apenas para interfaces do usuário e servidores externos. Código em execução na blockchain em si não pode ler eventos passados. +Note que este algoritmo funciona apenas para interfaces de usuário e servidores externos. Código rodando na blockchain +em si não pode ler eventos passados. ```python -# @dev Mapping from owner address to mapping of operator addresses. +# @dev Mapeamento de endereço de proprietário para mapeamento de endereços de operador. ownerToOperators: HashMap[address, HashMap[address, bool]] ``` -Uma conta pode ter mais de um único operador. Um simples `HashMap` é insuficiente para mantê-los, pois cada chave gera um único valor. Em vez disso, você pode usar `HashMap[address, bool]` como valor. Por padrão, o valor para cada endereço é `False`, o que significa que ele não é um operador. Você pode definir valores como `True` conforme necessário. +Uma conta pode ter mais de um único operador. Um simples `HashMap` é insuficiente para +rastreá-los, porque cada chave leva a um único valor. Em vez disso, você pode usar +`HashMap[address, bool]` como o valor. Por padrão, o valor para cada endereço é `False`, o que significa que ele +não é um operador. Você pode definir os valores como `True` conforme necessário. ```python -# @dev Address of minter, who can mint a token +# @dev Endereço do minter, que pode cunhar um token minter: address ``` -Novos tokens têm de ser criados de alguma forma. Neste contrato há uma única entidade que está autorizada a fazê-lo, o `minter`. É provável que isso seja suficiente para um jogo, por exemplo. Para outros propósitos, pode ser necessário criar uma lógica de negócio mais complicada. +Novos tokens precisam ser criados de alguma forma. Neste contrato, há uma única entidade que tem permissão para fazer isso, o +`minter`. Isso provavelmente é suficiente para um jogo, por exemplo. Para outros fins, pode ser necessário +criar uma lógica de negócios mais complicada. ```python -# @dev Mapping of interface id to bool about whether or not it's supported +# @dev Mapeamento do ID da interface para bool sobre se é ou não suportado supportedInterfaces: HashMap[bytes32, bool] -# @dev ERC165 interface ID of ERC165 +# @dev ID da interface ERC165 do ERC165 ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7 -# @dev ERC165 interface ID of ERC721 +# @dev ID da interface ERC165 do ERC721 ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd ``` -[ERC-165](https://eips.ethereum.org/EIPS/eip-165) especifica um mecanismo para um contrato divulgar como aplicações podem se comunicar com ele, com os quais ERCs ele está em conformidade. Neste caso, o contrato está em conformidade com ERC-165 e ERC-721. +O [ERC-165](https://eips.ethereum.org/EIPS/eip-165) especifica um mecanismo para um contrato divulgar como os aplicativos +podem se comunicar com ele, e a quais ERCs ele se conforma. Nesse caso, o contrato está em conformidade com o ERC-165 e o ERC-721. ### Funções {#functions} @@ -198,11 +238,13 @@ No Vyper, assim como no Python, a função construtora é chamada `__init__`. ```python """ - @dev Contract constructor. + @dev Construtor do contrato. """ ``` -No Python e no Vyper, você também pode criar um comentário especificando uma string de múltiplas linhas (que começa e termina com `"""`), e não usá-lo de qualquer forma. Esses comentários também podem incluir [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html). +Em Python, e em Vyper, você também pode criar um comentário especificando uma string de várias linhas (que começa e termina +com `"""`), e não usá-la de forma alguma. Esses comentários também podem incluir +[NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html). ```python self.supportedInterfaces[ERC165_INTERFACE_ID] = True @@ -210,57 +252,65 @@ No Python e no Vyper, você também pode criar um comentário especificando uma self.minter = msg.sender ``` -Para acessar variáveis de estado, você usa `self.` (novamente, o mesmo que em Python). +Para acessar as variáveis de estado, você usa `self.` (novamente, como em Python). -#### Exibir funções {#views} +#### Funções de Visualização {#views} -São funções que não modificam o estado da blockchain e, por isso, podem ser executadas gratuitamente se chamadas externamente. Se as funções de exibição forem chamadas por um contrato, elas ainda têm de ser executadas em cada nó e, portanto, custam gás. +Estas são funções que não modificam o estado da blockchain e, portanto, podem ser executadas +gratuitamente se forem chamadas externamente. Se as funções de visualização forem chamadas por um contrato, elas ainda precisarão ser executadas em +cada nó e, portanto, custarão gás. ```python @view @external ``` -Essas palavras-chave anteriores a uma definição de função que começam com um sinal de (`@`) são chamadas de _decoradores_. Elas especificam as circunstâncias em que uma função pode ser chamada. +Essas palavras-chave antes de uma definição de função que começam com um sinal de arroba (`@`) são chamadas de _decorações_. Elas +especificam as circunstâncias em que uma função pode ser chamada. -- `@view` especifica que esta função é um modo de exibição. -- `@external` especifica que essa função em particular pode ser chamada por transações e por outros contratos. +- `@view` especifica que esta função é uma visualização. +- `@external` especifica que esta função específica pode ser chamada por transações e por outros contratos. ```python def supportsInterface(_interfaceID: bytes32) -> bool: ``` -Ao contrário do Python, o Vyper é uma [linguagem de tipo estática](https://wikipedia.org/wiki/Type_system#Static_type_checking). Você não pode declarar uma variável ou um parâmetro de função, sem identificar os tipos de [dados](https://vyper.readthedocs.io/en/latest/types.html). Neste caso, o parâmetro de entrada é `bytes32`, um valor de 256 bits (256 bits é o tamanho da palavra nativa da [Máquina Virtual do Ethereum](/developers/docs/evm/)). A saída é um booleano valor. Por convenção, os nomes dos parâmetros da função começam com um sublinhado (`_`). +Ao contrário do Python, o Vyper é uma [linguagem de tipagem estática](https://wikipedia.org/wiki/Type_system#Static_type_checking). +Você não pode declarar uma variável, ou um parâmetro de função, sem identificar o [tipo de dados](https://vyper.readthedocs.io/en/latest/types.html). Nesse caso, o parâmetro de entrada é `bytes32`, um valor de 256 bits +(256 bits é o tamanho de palavra nativo da [Máquina Virtual Ethereum](/developers/docs/evm/)). A saída é um valor +booleano. Por convenção, os nomes dos parâmetros da função começam com um sublinhado (`_`). ```python """ - @dev Interface identification is specified in ERC-165. - @param _interfaceID Id of the interface + @dev A identificação da interface é especificada no ERC-165. + @param _interfaceID Id da interface """ return self.supportedInterfaces[_interfaceID] ``` -Retorne o valor do `self.supportedInterfaces` HashMap, o qual é definido no construtor (`__init__`). +Retorne o valor do HashMap `self.supportedInterfaces`, que é definido no construtor (`__init__`). ```python -### VIEW FUNCTIONS ### +### FUNÇÕES DE VISUALIZAÇÃO ### + ``` -Estas são as funções de visualização que fornecem informações sobre os tokens disponíveis para usuários e outros contratos. +Estas são as funções de visualização que disponibilizam informações sobre os tokens para usuários e outros contratos. ```python @view @external def balanceOf(_owner: address) -> uint256: """ - @dev Returns the number of NFTs owned by `_owner`. - Throws if `_owner` is the zero address. NFTs assigned to the zero address are considered invalid. - @param _owner Address for whom to query the balance. + @dev Retorna o número de NFTs de propriedade de `_owner`. + Lança uma exceção se `_owner` for o endereço zero. NFTs atribuídos ao endereço zero são considerados inválidos. + @param _owner Endereço para o qual consultar o saldo. """ assert _owner != ZERO_ADDRESS ``` -Esta linha [afirma](https://vyper.readthedocs.io/en/latest/statements.html#assert) que `_owner` não é zero. Se for zero, há um erro e a operação é anulada. +Esta linha [afirma](https://vyper.readthedocs.io/en/latest/statements.html#assert) que `_owner` não é +zero. Se for, há um erro e a operação é revertida. ```python return self.ownerToNFTokenCount[_owner] @@ -269,47 +319,51 @@ Esta linha [afirma](https://vyper.readthedocs.io/en/latest/statements.html#asser @external def ownerOf(_tokenId: uint256) -> address: """ - @dev Returns the address of the owner of the NFT. - Throws if `_tokenId` is not a valid NFT. - @param _tokenId The identifier for an NFT. + @dev Retorna o endereço do proprietário do NFT. + Lança uma exceção se `_tokenId` não for um NFT válido. + @param _tokenId O identificador para um NFT. """ owner: address = self.idToOwner[_tokenId] - # Throws if `_tokenId` is not a valid NFT + # Lança uma exceção se `_tokenId` não for um NFT válido assert owner != ZERO_ADDRESS return owner ``` -Na Máquina Virtual do Ethereum (EVM) qualquer armazenamento que não tenha um valor armazenado nele é zero. Se não houver token em `_tokenId`, o valor de `self.idToOwner[_tokenId]` é zero. Naquilo caso a função reverta. +Na Máquina Virtual Ethereum (EVM), qualquer armazenamento que não tenha um valor armazenado nele é zero. +Se não houver token em `_tokenId`, o valor de `self.idToOwner[_tokenId]` será zero. Nesse +caso, a função é revertida. ```python @view @external def getApproved(_tokenId: uint256) -> address: """ - @dev Get the approved address for a single NFT. - Throws if `_tokenId` is not a valid NFT. - @param _tokenId ID of the NFT to query the approval of. + @dev Obtenha o endereço aprovado para um único NFT. + Lança uma exceção se `_tokenId` não for um NFT válido. + @param _tokenId ID do NFT para consultar a aprovação. """ - # Throws if `_tokenId` is not a valid NFT + # Lança uma exceção se `_tokenId` não for um NFT válido assert self.idToOwner[_tokenId] != ZERO_ADDRESS return self.idToApprovals[_tokenId] ``` -Observe que `getApproved` _pode_ retornar zero. Se o token for válido, ele retorna `self.idToApprovals[_tokenId]`. Se não houver aprovador, esse valor é zero. +Observe que `getApproved` _pode_ retornar zero. Se o token for válido, ele retorna `self.idToApprovals[_tokenId]`. +Se não houver aprovador, esse valor é zero. ```python @view @external def isApprovedForAll(_owner: address, _operator: address) -> bool: """ - @dev Checks if `_operator` is an approved operator for `_owner`. - @param _owner The address that owns the NFTs. - @param _operator The address that acts on behalf of the owner. + @dev Verifica se `_operator` é um operador aprovado para `_owner`. + @param _owner O endereço que possui os NFTs. + @param _operator O endereço que atua em nome do proprietário. """ return (self.ownerToOperators[_owner])[_operator] ``` -Esta função checa se `_operator` tem permissão para gerenciar todos os tokens de `_owner` neste contrato. Como pode haver vários operadores, este é um Hashmap de dois níveis. +Esta função verifica se o `_operator` tem permissão para gerenciar todos os tokens do `_owner` neste contrato. +Como pode haver vários operadores, este é um HashMap de dois níveis. #### Funções Auxiliares de Transferência {#transfer-helpers} @@ -317,22 +371,23 @@ Essas funções implementam operações que fazem parte da transferência ou ger ```python -### TRANSFER FUNCTION HELPERS ### +### FUNÇÕES AUXILIARES DE TRANSFERÊNCIA ### @view @internal ``` -Este decorador, `@internal`, significa que a função é somente acessível de outras funções dentro do mesmo contrato. Por convenção, estes nomes de função também começam com um sublinhado (`_`). +Esta decoração, `@internal`, significa que a função só é acessível a partir de outras funções dentro do +mesmo contrato. Por convenção, esses nomes de função também começam com um sublinhado (`_`). ```python def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool: """ - @dev Returns whether the given spender can transfer a given token ID - @param spender address of the spender to query - @param tokenId uint256 ID of the token to be transferred - @return bool whether the msg.sender is approved for the given token ID, - is an operator of the owner, or is the owner of the token + @dev Retorna se o gastador informado pode transferir um determinado ID de token + @param spender endereço do gastador para consultar + @param tokenId uint256 ID do token a ser transferido + @return bool se o msg.sender está aprovado para o ID de token informado, + é um operador do proprietário ou é o proprietário do token """ owner: address = self.idToOwner[_tokenId] spenderIsOwner: bool = owner == _spender @@ -341,117 +396,123 @@ def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool: return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAll ``` -Há três maneiras na qual um endereço pode ser permitido a transferir um token: +Há três maneiras pelas quais um endereço pode ter permissão para transferir um token: 1. O endereço é o proprietário do token -2. O endereço é aprovado a gastar o token -3. O endereço é um operador do proprietário do token +2. O endereço é aprovado para gastar esse token +3. O endereço é um operador para o proprietário do token -A função acima pode ser uma view porque ela não muda o estado. Para reduzir custos operacionais, qualquer função que _possa_ ser uma view, _deve_ ser uma view. +A função acima pode ser uma visualização porque não altera o estado. Para reduzir os custos operacionais, qualquer +função que _possa_ ser uma visualização _deve_ ser uma visualização. ```python @internal def _addTokenTo(_to: address, _tokenId: uint256): """ - @dev Add a NFT to a given address - Throws if `_tokenId` is owned by someone. + @dev Adiciona um NFT a um determinado endereço + Lança uma exceção se `_tokenId` for de propriedade de alguém. """ - # Throws if `_tokenId` is owned by someone + # Lança uma exceção se `_tokenId` for de propriedade de alguém assert self.idToOwner[_tokenId] == ZERO_ADDRESS - # Change the owner + # Altera o proprietário self.idToOwner[_tokenId] = _to - # Change count tracking + # Altera o rastreamento da contagem self.ownerToNFTokenCount[_to] += 1 @internal def _removeTokenFrom(_from: address, _tokenId: uint256): """ - @dev Remove a NFT from a given address - Throws if `_from` is not the current owner. + @dev Remove um NFT de um determinado endereço + Lança uma exceção se `_from` não for o proprietário atual. """ - # Throws if `_from` is not the current owner + # Lança uma exceção se `_from` não for o proprietário atual assert self.idToOwner[_tokenId] == _from - # Change the owner + # Altera o proprietário self.idToOwner[_tokenId] = ZERO_ADDRESS - # Change count tracking + # Altera o rastreamento da contagem self.ownerToNFTokenCount[_from] -= 1 ``` -Quando há um problema com uma transferência, anulamos a chamada. +Quando há um problema com uma transferência, revertemos a chamada. ```python @internal def _clearApproval(_owner: address, _tokenId: uint256): """ - @dev Clear an approval of a given address - Throws if `_owner` is not the current owner. + @dev Limpa a aprovação de um determinado endereço + Lança uma exceção se `_owner` não for o proprietário atual. """ - # Throws if `_owner` is not the current owner + # Lança uma exceção se `_owner` não for o proprietário atual assert self.idToOwner[_tokenId] == _owner if self.idToApprovals[_tokenId] != ZERO_ADDRESS: - # Reset approvals + # Redefinir aprovações self.idToApprovals[_tokenId] = ZERO_ADDRESS ``` -Altere o valor apenas se necessário. Variáveis de estado vivem no armazenamento. Escrever para o storage é uma das operações mais caras que a EVM (Máquina Virtual Ethereum) faz (em termos de [gas](/developers/docs/gas/)). Portanto, é uma boa ideia minimizá-lo, mesmo escrevendo o valor existente tem um custo alto. +Altere o valor apenas se necessário. As variáveis de estado ficam no armazenamento. Gravar no armazenamento é +uma das operações mais caras que a EVM (Máquina Virtual Ethereum) faz (em termos de +[gás](/developers/docs/gas/)). Portanto, é uma boa ideia minimizá-la, mesmo que a escrita do +valor existente tenha um custo alto. ```python @internal def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address): """ - @dev Execute transfer of a NFT. - Throws unless `msg.sender` is the current owner, an authorized operator, or the approved - address for this NFT. (NOTE: `msg.sender` not allowed in private function so pass `_sender`.) - Throws if `_to` is the zero address. - Throws if `_from` is not the current owner. - Throws if `_tokenId` is not a valid NFT. + @dev Executa a transferência de um NFT. + Lança uma exceção, a menos que `msg.sender` seja o proprietário atual, um operador autorizado ou o endereço + aprovado para este NFT. (NOTA: `msg.sender` não é permitido em função privada, então passe `_sender`.) + Lança uma exceção se `_to` for o endereço zero. + Lança uma exceção se `_from` não for o proprietário atual. + Lança uma exceção se `_tokenId` não for um NFT válido. """ ``` -Nós temos esta função interna porque há duas maneiras de transferir tokens (normal e segura), mas nós queremos somente uma única localização no código onde nós fazemos isso para facilitar auditoria. +Temos essa função interna porque há duas maneiras de transferir tokens (regular e segura), mas +queremos apenas um único local no código onde fazemos isso para facilitar a auditoria. ```python - # Check requirements + # Verificar requisitos assert self._isApprovedOrOwner(_sender, _tokenId) - # Throws if `_to` is the zero address + # Lança uma exceção se `_to` for o endereço zero assert _to != ZERO_ADDRESS - # Clear approval. Throws if `_from` is not the current owner + # Limpar aprovação. Lança uma exceção se `_from` não for o proprietário atual self._clearApproval(_from, _tokenId) - # Remove NFT. Throws if `_tokenId` is not a valid NFT + # Remover NFT. Lança uma exceção se `_tokenId` não for um NFT válido self._removeTokenFrom(_from, _tokenId) - # Add NFT + # Adicionar NFT self._addTokenTo(_to, _tokenId) - # Log the transfer + # Registrar a transferência log Transfer(_from, _to, _tokenId) ``` -Para emitir um evento em Vyper você usa uma declaração de `log` ([veja aqui para mais detalhes](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging)). +Para emitir um evento em Vyper, você usa uma instrução `log` ([veja aqui para mais detalhes](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging)). #### Funções de Transferência {#transfer-funs} ```python -### TRANSFER FUNCTIONS ### +### FUNÇÕES DE TRANSFERÊNCIA ### @external def transferFrom(_from: address, _to: address, _tokenId: uint256): """ - @dev Throws unless `msg.sender` is the current owner, an authorized operator, or the approved - address for this NFT. - Throws if `_from` is not the current owner. - Throws if `_to` is the zero address. - Throws if `_tokenId` is not a valid NFT. - @notice The caller is responsible to confirm that `_to` is capable of receiving NFTs or else - they maybe be permanently lost. - @param _from The current owner of the NFT. - @param _to The new owner. - @param _tokenId The NFT to transfer. + @dev Lança uma exceção, a menos que `msg.sender` seja o proprietário atual, um operador autorizado ou o + endereço aprovado para este NFT. + Lança uma exceção se `_from` não for o proprietário atual. + Lança uma exceção se `_to` for o endereço zero. + Lança uma exceção se `_tokenId` não for um NFT válido. + @notice O chamador é responsável por confirmar que `_to` é capaz de receber NFTs, caso contrário + eles podem ser permanentemente perdidos. + @param _from O proprietário atual do NFT. + @param _to O novo proprietário. + @param _tokenId O NFT a ser transferido. """ self._transferFrom(_from, _to, _tokenId, msg.sender) ``` -Esta função deixa você transferir para um endereço arbitrário. A não ser que o endereço é um usuário, ou um contrato que sabe como transferir tokens, qualquer token que você transferir ficará preso no endereço e inútil. +Esta função permite que você transfira para um endereço arbitrário. A menos que o endereço seja de um usuário ou de um contrato que +saiba como transferir tokens, qualquer token que você transferir ficará preso nesse endereço e será inútil. ```python @external @@ -462,75 +523,80 @@ def safeTransferFrom( _data: Bytes[1024]=b"" ): """ - @dev Transfers the ownership of an NFT from one address to another address. - Throws unless `msg.sender` is the current owner, an authorized operator, or the - approved address for this NFT. - Throws if `_from` is not the current owner. - Throws if `_to` is the zero address. - Throws if `_tokenId` is not a valid NFT. - If `_to` is a smart contract, it calls `onERC721Received` on `_to` and throws if - the return value is not `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`. - NOTE: bytes4 is represented by bytes32 with padding - @param _from The current owner of the NFT. - @param _to The new owner. - @param _tokenId The NFT to transfer. - @param _data Additional data with no specified format, sent in call to `_to`. + @dev Transfere a propriedade de um NFT de um endereço para outro. + Lança uma exceção, a menos que `msg.sender` seja o proprietário atual, um operador autorizado ou o + endereço aprovado para este NFT. + Lança uma exceção se `_from` não for o proprietário atual. + Lança uma exceção se `_to` for o endereço zero. + Lança uma exceção se `_tokenId` não for um NFT válido. + Se `_to` for um contrato inteligente, ele chama `onERC721Received` em `_to` e lança uma exceção se + o valor de retorno não for `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`. + NOTA: bytes4 é representado por bytes32 com preenchimento + @param _from O proprietário atual do NFT. + @param _to O novo proprietário. + @param _tokenId O NFT a ser transferido. + @param _data Dados adicionais sem formato especificado, enviados na chamada para `_to`. """ self._transferFrom(_from, _to, _tokenId, msg.sender) ``` -Tudo bem fazer a transferência primeiro, porque se der um problema, vamos revertê-la de qualquer maneira, a fim de anular tudo o que foi feito durante a chamada. +Não há problema em fazer a transferência primeiro porque, se houver um problema, vamos reverter de qualquer maneira, +então tudo o que for feito na chamada será cancelado. ```python - if _to.is_contract: # check if `_to` is a contract address + if _to.is_contract: # verifica se `_to` é um endereço de contrato ``` -Primeiro cheque para ver se o endereço é um contrato (se ele tem código). Se não, assuma que ele é um endereço de usuário e o usuário será capaz de usar o token ou transferi-lo. Mas não deixe que isso engane você com uma falsa sensação de segurança. Você pode perder tokens, mesmo com `safeTransferFrom`, se você transferi-los para um endereço que ninguém conhece a chave privada. +Primeiro, verifique se o endereço é um contrato (se ele tem código). Caso contrário, presuma que é um endereço de +usuário e que o usuário poderá usar o token ou transferi-lo. Mas não deixe que isso o iluda +com uma falsa sensação de segurança. Você pode perder tokens, mesmo com `safeTransferFrom`, se os transferir +para um endereço cuja chave privada ninguém conhece. ```python returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data) ``` -Chame o contrato-alvo para ver se ele pode receber tokens ERC-721. +Chame o contrato de destino para ver se ele pode receber tokens ERC-721. ```python - # Throws if transfer destination is a contract which does not implement 'onERC721Received' + # Lança uma exceção se o destino da transferência for um contrato que não implementa 'onERC721Received' assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32) ``` -Se o destino é um contrato, mas um que não aceita tokens ERC-721 (ou que decide não aceitar esta transferência em particular), reverta. +Se o destino for um contrato, mas um que não aceita tokens ERC-721 (ou que decidiu não aceitar esta +transferência em particular), reverta. ```python @external def approve(_approved: address, _tokenId: uint256): """ - @dev Set or reaffirm the approved address for an NFT. The zero address indicates there is no approved address. - Throws unless `msg.sender` is the current NFT owner, or an authorized operator of the current owner. - Throws if `_tokenId` is not a valid NFT. (NOTE: This is not written the EIP) - Throws if `_approved` is the current owner. (NOTE: This is not written the EIP) - @param _approved Address to be approved for the given NFT ID. - @param _tokenId ID of the token to be approved. + @dev Define ou reafirma o endereço aprovado para um NFT. O endereço zero indica que não há endereço aprovado. + Lança uma exceção, a menos que `msg.sender` seja o proprietário atual do NFT ou um operador autorizado do proprietário atual. + Lança uma exceção se `_tokenId` não for um NFT válido. (NOTA: Isso não está escrito no EIP) + Lança uma exceção se `_approved` for o proprietário atual. (NOTA: Isso não está escrito no EIP) + @param _approved Endereço a ser aprovado para o ID de NFT fornecido. + @param _tokenId ID do token a ser aprovado. """ owner: address = self.idToOwner[_tokenId] - # Throws if `_tokenId` is not a valid NFT + # Lança uma exceção se `_tokenId` não for um NFT válido assert owner != ZERO_ADDRESS - # Throws if `_approved` is the current owner + # Lança uma exceção se `_approved` for o proprietário atual assert _approved != owner ``` -Por convenção, se você não quiser ter um aprovador, designe o endereço zero, não você mesmo. +Por convenção, se você não quiser ter um aprovador, você nomeia o endereço zero, não a si mesmo. ```python - # Check requirements + # Verificar requisitos senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender] assert (senderIsOwner or senderIsApprovedForAll) ``` -Para configurar um aprovador você pode ou ser o proprietário, ou um operador autorizado pelo proprietário. +Para definir uma aprovação, você pode ser o proprietário ou um operador autorizado pelo proprietário. ```python - # Set the approval + # Definir a aprovação self.idToApprovals[_tokenId] = _approved log Approval(owner, _approved, _tokenId) @@ -538,25 +604,27 @@ Para configurar um aprovador você pode ou ser o proprietário, ou um operador a @external def setApprovalForAll(_operator: address, _approved: bool): """ - @dev Enables or disables approval for a third party ("operator") to manage all of - `msg.sender`'s assets. It also emits the ApprovalForAll event. - Throws if `_operator` is the `msg.sender`. (NOTE: This is not written the EIP) - @notice This works even if sender doesn't own any tokens at the time. - @param _operator Address to add to the set of authorized operators. - @param _approved True if the operators is approved, false to revoke approval. + @dev Habilita ou desabilita a aprovação para um terceiro ("operador") gerenciar todos os + ativos de `msg.sender`. Também emite o evento ApprovalForAll. + Lança uma exceção se `_operator` for o `msg.sender`. (NOTA: Isso não está escrito no EIP) + @notice Isso funciona mesmo que o remetente não possua nenhum token no momento. + @param _operator Endereço a ser adicionado ao conjunto de operadores autorizados. + @param _approved Verdadeiro se os operadores forem aprovados, falso para revogar a aprovação. """ - # Throws if `_operator` is the `msg.sender` + # Lança uma exceção se `_operator` for o `msg.sender` assert _operator != msg.sender self.ownerToOperators[msg.sender][_operator] = _approved log ApprovalForAll(msg.sender, _operator, _approved) ``` -#### Cunhar novos tokens e destruir os existentes {#mint-burn} +#### Cunhar Novos Tokens e Destruir os Existentes {#mint-burn} -A conta que criou o contrato é o `minter`, o superusuário autorizado a cunhar novos NFTs. No entanto, mesmo isso não é autorizado para queimar tokens existentes. Somente o proprietário, ou uma entidade autorizada pelo proprietário, podem fazer isso. +A conta que criou o contrato é o `minter`, o superusuário que está autorizado a cunhar +novos NFTs. No entanto, mesmo ele não tem permissão para queimar tokens existentes. Apenas o proprietário, ou uma entidade +autorizada pelo proprietário, pode fazer isso. ```python -### MINT & BURN FUNCTIONS ### +### FUNÇÕES DE CUNHAGEM E QUEIMA ### @external def mint(_to: address, _tokenId: uint256) -> bool: @@ -566,24 +634,27 @@ Esta função sempre retorna `True`, porque se a operação falhar, ela é rever ```python """ - @dev Function to mint tokens - Throws if `msg.sender` is not the minter. - Throws if `_to` is zero address. - Throws if `_tokenId` is owned by someone. - @param _to The address that will receive the minted tokens. - @param _tokenId The token id to mint. - @return A boolean that indicates if the operation was successful. + @dev Função para cunhar tokens + Lança uma exceção se `msg.sender` não for o minter. + Lança uma exceção se `_to` for o endereço zero. + Lança uma exceção se `_tokenId` for de propriedade de alguém. + @param _to O endereço que receberá os tokens cunhados. + @param _tokenId O id do token a ser cunhado. + @return Um booleano que indica se a operação foi bem-sucedida. """ - # Throws if `msg.sender` is not the minter + # Lança uma exceção se `msg.sender` não for o minter assert msg.sender == self.minter ``` -Somente o minter (a conta que criou o contrato ERC-721) pode cunhar novos tokens. Isso pode ser um problema no futuro se você quiser mudar a identidade do minter. Em um contrato de produção, provavelmente seria desejável ter uma função que permita ao minter transferir privilégios de minter para uma outra pessoa. +Apenas o minter (a conta que criou o contrato ERC-721) pode cunhar novos tokens. Isso pode ser um +problema no futuro se quisermos mudar a identidade do minter. Em +um contrato de produção, você provavelmente desejaria uma função que permitisse ao minter transferir +os privilégios de minter para outra pessoa. ```python - # Throws if `_to` is zero address + # Lança uma exceção se `_to` for o endereço zero assert _to != ZERO_ADDRESS - # Add NFT. Throws if `_tokenId` is owned by someone + # Adicionar NFT. Lança uma exceção se `_tokenId` for de propriedade de alguém self._addTokenTo(_to, _tokenId) log Transfer(ZERO_ADDRESS, _to, _tokenId) return True @@ -596,37 +667,48 @@ Por convenção, a cunhagem de novos tokens conta como uma transferência do end @external def burn(_tokenId: uint256): """ - @dev Burns a specific ERC721 token. - Throws unless `msg.sender` is the current owner, an authorized operator, or the approved - address for this NFT. - Throws if `_tokenId` is not a valid NFT. - @param _tokenId uint256 id of the ERC721 token to be burned. + @dev Queima um token ERC721 específico. + Lança uma exceção, a menos que `msg.sender` seja o proprietário atual, um operador autorizado ou o endereço + aprovado para este NFT. + Lança uma exceção se `_tokenId` não for um NFT válido. + @param _tokenId id uint256 do token ERC721 a ser queimado. """ - # Check requirements + # Verificar requisitos assert self._isApprovedOrOwner(msg.sender, _tokenId) owner: address = self.idToOwner[_tokenId] - # Throws if `_tokenId` is not a valid NFT + # Lança uma exceção se `_tokenId` não for um NFT válido assert owner != ZERO_ADDRESS self._clearApproval(owner, _tokenId) self._removeTokenFrom(owner, _tokenId) log Transfer(owner, ZERO_ADDRESS, _tokenId) ``` -Qualquer pessoa autorizada a transferir um token, tem permissão para queimá-lo. Enquanto uma queima aparece equivalente à transferência para o endereço zero, o endereço zero não recebe de verdade o token. Isso permite-nos liberar todo o armazenamento usado pelo token, o que pode reduzir o custo de gás da transação. +Qualquer pessoa que tenha permissão para transferir um token tem permissão para queimá-lo. Embora uma queima pareça equivalente a uma +transferência para o endereço zero, o endereço zero na verdade não recebe o token. Isso nos permite +liberar todo o armazenamento que foi usado para o token, o que pode reduzir o custo de gás da transação. + +## Usando este Contrato {#using-contract} + +Em contraste com o Solidity, o Vyper não tem herança. Essa é uma escolha de design deliberada para tornar o +código mais claro e, portanto, mais fácil de proteger. Então, para criar seu próprio contrato Vyper ERC-721, você pega este +contrato e o modifica +para implementar a lógica de negócios que você deseja. -## Usando este contrato {#using-contract} +## Conclusão {#conclusion} -Ao contrário do Solidity, o Vyper não tem herança. Esta é uma escolha de design deliberada para tornar o código mais claro e, com isso, mais fácil de proteger. Portanto, para criar seu próprio contrato Vyper ERC-721, você usa [este contrato](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) e o modifica para implementar a lógica comercial que você desejar. +Para revisão, aqui estão algumas das ideias mais importantes deste contrato: -### Conclusão {#conclusion} +- Para receber tokens ERC-721 com uma transferência segura, os contratos precisam implementar a interface `ERC721Receiver`. +- Mesmo se você usar a transferência segura, os tokens ainda podem ficar presos se você os enviar para um endereço cuja chave privada + é desconhecida. +- Quando há um problema com uma operação, é uma boa ideia `reverter` a chamada, em vez de apenas retornar + um valor de falha. +- Os tokens ERC-721 existem quando têm um proprietário. +- Existem três maneiras de ser autorizado a transferir um NFT. Você pode ser o proprietário, ser aprovado para um token específico + ou ser um operador para todos os tokens do proprietário. +- Eventos passados são visíveis apenas fora da blockchain. O código em execução dentro da blockchain não pode visualizá-los. -Recapitulando, aqui estão algumas das ideias mais importantes neste contrato: +Agora, vá e implemente contratos Vyper seguros. -- Para receber os tokens ERC-721 com uma transferência segura, os contratos têm de implementar a interface `ERC721Receiver`. -- Mesmo que você use a transferência segura, os tokens ainda podem ficar presos se você os enviar para um endereço cuja chave privada. -- Quando há um problema com uma operação, é uma boa ideia fazer o `revert` da chamada, em vez de apenas retornar um valor de falha. -- Os tokens ERC-721 existem quando eles têm um proprietário. -- Existem três formas de ser autorizado a transferir um NFT. Você pode ser o proprietário, ser aprovado para um token específico, ou ser um operador para todos os tokens do proprietário. -- Eventos passados são visíveis apenas fora da blockchain. O código executando dentro da blockchain não pode visualizá-los. +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). -Agora, você está pronto para implementar contratos Vyper seguros. diff --git a/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md index bd328aaf93c..2754dd3f9cb 100644 --- a/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md @@ -1,30 +1,39 @@ --- -title: "Demonstração do Contrato ERC-20" -description: O que é o contrato OpenZeppelin ERC-20 e por que está lá? +title: "Passo a passo do contrato ERC-20" +description: "O que está no contrato ERC-20 da OpenZeppelin e por que está lá?" author: Ori Pomerantz lang: pt-br -tags: - - "solidez" - - "erc-20" +tags: [ "Solidity", "erc-20" ] skill: beginner published: 2021-03-09 --- ## Introdução {#introduction} -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. Essas moedas seguem a norma [ERC-20](/developers/docs/standards/tokens/erc-20/). Essa norma possibilita a criação de ferramentas, como os pools de liquidez e carteiras, que funcionam com todos os tokens ERC-20. Neste artigo, analisaremos a [Implementação do OpenZeppelin Solidity ERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol), assim como a [definição de interface](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol). +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 geralmente seguem um padrão, +o [ERC-20](/developers/docs/standards/tokens/erc-20/). Esse padrão possibilita escrever ferramentas, como pools de liquidez e carteiras, que funcionam com todos os tokens +ERC-20. Neste artigo, analisaremos a +implementação [ERC20 em Solidity da OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol), bem como a +[definição da interface](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol). -Este é o código-fonte anotado. Se você deseja implementar ERC-20, [leia este tutorial](https://docs.openzeppelin.com/contracts/2.x/erc20-supply). +Este é um código-fonte anotado. Se você quiser implementar o ERC-20, +[leia este tutorial](https://docs.openzeppelin.com/contracts/2.x/erc20-supply). -## A 'Interface' {#the-interface} +## A interface {#the-interface} -O objetivo de uma norma como a ERC-20 é permitir que as implementações das várias moedas sejam interoperáveis entre aplicativos, como carteiras e corretoras descentralizadas. Para atingirmos tal objetivo, criamos uma ['interface'](https://www.geeksforgeeks.org/solidity-basics-of-interface/). Qualquer código que necessite utilizar o contrato pode usar as mesmas definições de interface e ser compatível com todos os contratos de token que o usem, seja uma carteira de criptomoedas como a MetaMask, um aplicativo descentralizado como o Etherscan.io, ou um contrato diferente como um pool de liquidez. +O objetivo de um padrão como o ERC-20 é permitir que muitas implementações de tokens sejam interoperáveis entre aplicativos, como carteiras e corretoras descentralizadas. Para conseguir isso, criamos uma +[interface](https://www.geeksforgeeks.org/solidity/solidity-basics-of-interface/). Qualquer código que precise usar o contrato de token +pode usar as mesmas definições na interface e ser compatível com todos os contratos de token que a utilizam, seja uma carteira como a +MetaMask, um dapp como o etherscan.io ou um contrato diferente, como um pool de liquidez. ![Ilustração da interface ERC-20](erc20_interface.png) -Se você é um programador experiente, provavelmente se lembra de ver constructos semelhantes em [Java](https://www.w3schools.com/java/java_interface.asp) ou mesmo em [arquivos de cabeçalho em C](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html). +Se você é um programador experiente, provavelmente se lembra de ter visto construções semelhantes em [Java](https://www.w3schools.com/java/java_interface.asp) +ou até mesmo em [arquivos de cabeçalho C](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html). -Essa é a definição da [interface ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) do OpenZeppelin. Ela é uma tradução do [padrão legível para humanos](https://eips.ethereum.org/EIPS/eip-20) em código Solidity. Obviamente, a interface por si só não define _como_ fazer algo. Isso é explicado no código-fonte do contrato abaixo. +Esta é uma definição da [Interface ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) +da OpenZeppelin. É uma tradução do [padrão legível por humanos](https://eips.ethereum.org/EIPS/eip-20) para o código Solidity. Claro, a +interface em si não define _como_ fazer nada. Isso é explicado no código-fonte do contrato abaixo.   @@ -32,7 +41,8 @@ Essa é a definição da [interface ERC-20](https://github.com/OpenZeppelin/open // SPDX-License-Identifier: MIT ``` -Os arquivos Solidity devem incluir um identificador de licença. [Você pode ver a lista de licenças aqui](https://spdx.org/licenses/). Se você necessitar de uma licença diferente, explique nos comentários. +Os arquivos Solidity devem incluir um identificador de licença. [Você pode ver a lista de licenças aqui](https://spdx.org/licenses/). Se você precisar de uma licença +diferente, basta explicá-la nos comentários.   @@ -40,17 +50,20 @@ Os arquivos Solidity devem incluir um identificador de licença. [Você pode ver pragma solidity >=0.6.0 <0.8.0; ``` -A linguagem Solidity continua evoluindo rapidamente, e novas versões podem não ser compatíveis com o código antigo. ([confira aqui](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html)). Portanto, é uma boa ideia especificar não apenas uma versão mínima da linguagem, mas também uma versão máxima com a qual você testou o código. +A linguagem Solidity ainda está evoluindo rapidamente, e novas versões podem não ser compatíveis com códigos antigos +([veja aqui](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html)). Portanto, é uma boa ideia especificar não apenas uma versão mínima +da linguagem, mas também uma versão máxima, a mais recente com a qual você testou o código.   ```solidity /** - * @dev Interface of the ERC20 standard as defined in the EIP. + * @dev Interface do padrão ERC20, conforme definido na EIP. */ ``` -O `@dev` no comentário faz parte do [formato NatSpec](https://docs.soliditylang.org/en/develop/natspec-format.html), usado para produzir a documentação a partir de um código-fonte. +O `@dev` no comentário faz parte do [formato NatSpec](https://docs.soliditylang.org/en/develop/natspec-format.html), usado para produzir +documentação a partir do código-fonte.   @@ -58,134 +71,164 @@ O `@dev` no comentário faz parte do [formato NatSpec](https://docs.soliditylang interface IERC20 { ``` -Convenientemente, nomes de Interface começam com `I`. +Por convenção, os nomes de interface começam com `I`.   ```solidity /** - * @dev Returns the amount of tokens in existence. + * @dev Retorna a quantidade de tokens existentes. */ function totalSupply() external view returns (uint256); ``` -Essa função é `external`, ou seja, [só pode ser chamada de fora do contrato](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2). Ela retorna o fornecimento total de tokens no contrato. Esse valor é retornado usando o tipo mais comum no Ethereum, 256 bits não assinado (256 bits é o tamanho de fonte nativo da EVM). Essa função também é uma `view`, ou seja, ela não pode alterar o estado, portanto, ela pode ser executada em apenas um nó em vez de fazer com que todos os nós da blockchain a executem. Esse tipo de função não gera transação e não custa [gás](/developers/docs/Gas/). +Esta função é `external`, o que significa que [só pode ser chamada de fora do contrato](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2). +Ela retorna o fornecimento total de tokens no contrato. Este valor é retornado usando o tipo mais comum no Ethereum, 256 bits sem sinal (256 bits é o +tamanho nativo da palavra da EVM). Essa função também é uma `view`, o que significa que ela não altera o estado, portanto, pode ser executada em um único nó, em vez de fazer com que +todos os nós da blockchain a executem. Esse tipo de função não gera uma transação e não custa [gás](/developers/docs/gas/). -**Observação:** Em teoria, pode-se ter a impressão de que o criador do contrato conseguiria trapacear retornando uma quantia menor do fornecimento total do que a quantia real, fazendo com que cada moeda valha mais do que realmente vale. De qualquer forma, este medo ignora a verdadeira natureza da blockchain. Tudo que acontece na blockchain pode ser verificado em cada nó. Para conseguir isso, cada contrato da linguagem de código e armazenamento esta disponível em cada nó. Embora não seja obrigatório publicar o código Solidity, mas ninguém confiará em você a menos que publique o código-fonte e a versão do Solidity usados na compilação, para que ele possa ser comparado com o código de linguagem da máquina que você forneceu. Por exemplo, confira [este contrato](https://etherscan.io/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD#code). +**Observação:** em teoria, pode parecer que o criador de um contrato poderia trapacear retornando um fornecimento total menor que o valor real, fazendo com que cada token pareça +mais valioso do que realmente é. No entanto, esse medo ignora a verdadeira natureza da blockchain. Tudo o que acontece na blockchain pode ser verificado por +todos os nós. Para conseguir isso, o código de linguagem de máquina e o armazenamento de cada contrato estão disponíveis em todos os nós. Embora você não seja obrigado a publicar o código Solidity +do seu contrato, ninguém o levaria a sério, a menos que você publique o código-fonte e a versão do Solidity com a qual ele foi compilado, para que possa +ser verificado com o código de linguagem de máquina que você forneceu. +Por exemplo, veja [este contrato](https://eth.blockscout.com/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD?tab=contract).   ```solidity /** - * @dev Returns the amount of tokens owned by `account`. + * @dev Retorna a quantidade de tokens de propriedade de `account`. */ function balanceOf(address account) external view returns (uint256); ``` -Como o próprio nome já diz, `balanceOf` retorna o saldo de uma conta. Contas de Ethereum são identificadas em Solidity usando `address`, que contem 160 bits. Também são `external` e `view`. +Como o nome diz, `balanceOf` retorna o saldo de uma conta. As contas Ethereum são identificadas no Solidity usando o tipo `address`, que contém 160 bits. +Ela também é `external` e `view`.   ```solidity /** - * @dev Moves `amount` tokens from the caller's account to `recipient`. + * @dev Move a quantidade `amount` de tokens da conta do chamador para o `recipient`. * - * Returns a boolean value indicating whether the operation succeeded. + * Retorna um valor booleano que indica se a operação foi bem-sucedida. * - * Emits a {Transfer} event. + * Emite um evento {Transfer}. */ function transfer(address recipient, uint256 amount) external returns (bool); ``` -A função `transfer` transfere as moedas de um chamador para outro endereço. Isso envolve uma mudança de estado, então não é um `view`. Quando um usuário chama essa função, ele cria uma transação a um custo cobrada em gás. Ele também emite um evento, `Transfer`, para informar a todos na blockchain sobre esse evento. +A função `transfer` transfere tokens do chamador para um endereço diferente. Isso envolve uma mudança de estado, então não é uma `view`. +Quando um usuário chama essa função, ela cria uma transação e custa gás. Ela também emite um evento, `Transfer`, para informar a todos na +blockchain sobre o evento. -Essa função possui duas saídas para dois chamadores diferentes: +A função tem dois tipos de saída para dois tipos diferentes de chamadores: -- Os usuários que chamam a função diretamente de uma interface de usuário. Normalmente o usuário envia uma transação e não espera por uma resposta, que pode demorar uma quantidade indefinida de tempo. O usuário pode ver o que ocorreu procurando pelo recibo da transação (identificado pela transação hash) ou procurando pelo evento `transfer`. -- Outros contratos, nos quais chamam a função como parte de uma transação inteira. Esses contratos obtêm o resultado imediatamente, pois eles executam a mesma transação, para usar o valor de retorno da função. +- Usuários que chamam a função diretamente de uma interface de usuário. Normalmente, o usuário envia uma transação + e não espera por uma resposta, que pode levar um tempo indefinido. O usuário pode ver o que aconteceu + procurando o recibo da transação (que é identificado pelo hash da transação) ou procurando pelo + evento `Transfer`. +- Outros contratos, que chamam a função como parte de uma transação geral. Esses contratos obtêm o resultado imediatamente, + porque são executados na mesma transação, para que possam usar o valor de retorno da função. -O mesmo tipo de saída é criado por outras funções que mudam o estado do contrato. +O mesmo tipo de saída é criado pelas outras funções que alteram o estado do contrato.   -As provisões permitem que uma conta gaste tokens que pertencem a um proprietário diferente. Isso é útil, por exemplo, para contratos que agem como vendedores. Contratos não podem monitorar eventos, portanto, se um comprador quiser transferir diretamente, tokens para o contrato do vendedor, esse contrato não saberá se foi pago. Em vez disso, o comprador permite que o contrato do vendedor gaste uma certa quantia, e o vendedor transfere essa quantia. Isso é feito por meio de uma função do contrato do vendedor, para que o contrato do vendedor possa saber se a operação foi bem-sucedida. +As permissões (allowances) permitem que uma conta gaste alguns tokens que pertencem a um proprietário diferente. +Isso é útil, por exemplo, para contratos que atuam como vendedores. Os contratos não podem +monitorar eventos; portanto, se um comprador transferisse tokens para o contrato do vendedor +diretamente, esse contrato não saberia que foi pago. Em vez disso, o comprador permite que o contrato do +vendedor gaste uma certa quantia, e o vendedor transfere essa quantia. +Isso é feito por meio de uma função que o contrato do vendedor chama, para que o contrato do vendedor +possa saber se foi bem-sucedido. ```solidity /** - * @dev Returns the remaining number of tokens that `spender` will be - * allowed to spend on behalf of `owner` through {transferFrom}. Isso é - * zero por padrão. + * @dev Retorna o número restante de tokens que o `spender` terá + * permissão para gastar em nome do `owner` por meio de {transferFrom}. O padrão + * é zero. * - * This value changes when {approve} or {transferFrom} are called. + * Esse valor muda quando {approve} ou {transferFrom} são chamados. */ function allowance(address owner, address spender) external view returns (uint256); ``` -A função `allowance` permite que qualquer pessoa consulte qual é a provisão que um endereço (`owner`) permite que outro endereço (`spender`) gaste. +A função `allowance` permite que qualquer pessoa consulte para ver qual é a permissão que um +endereço (`owner`) permite que outro endereço (`spender`) gaste.   ```solidity /** - * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. + * @dev Define `amount` como a permissão de `spender` sobre os tokens do chamador. * - * Returns a boolean value indicating whether the operation succeeded. + * Retorna um valor booleano que indica se a operação foi bem-sucedida. * - * IMPORTANT: Beware that changing an allowance with this method brings the risk - * that someone may use both the old and the new allowance by unfortunate - * transaction ordering. Uma solução possível para mitigar esta corrida - * é primeiramente reduzir a tolerância do remetente para 0 e definir o - * valor desejado depois: + * IMPORTANTE: Cuidado, pois alterar uma permissão com este método traz o risco + * de que alguém possa usar tanto a permissão antiga quanto a nova por meio de uma + * ordem de transação infeliz. Uma solução possível para mitigar essa condição + * de corrida é primeiro reduzir a permissão do gastador para 0 e depois definir o + * valor desejado: * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 * - * Emite um evento de {Approval}. + * Emite um evento {Approval}. */ function approve(address spender, uint256 amount) external returns (bool); ``` -A função `approve` cria uma provisão. Certifique-se de ler a mensagem sobre como ela pode ser usada indevidamente. No Ethereum, você controla a ordem de suas próprias transações, mas não é possível controlar a ordem na qual as transações de outras pessoas serão executadas, a menos que você não envie sua própria transação até ver a transação de outro lado ser executada. +A função `approve` cria uma permissão. Certifique-se de ler a mensagem sobre +como ela pode ser usada indevidamente. No Ethereum, você controla a ordem de suas próprias transações, +mas não pode controlar a ordem em que as transações de outras pessoas serão +executadas, a menos que você não envie sua própria transação até ver que a +transação da outra parte aconteceu.   ```solidity /** - * @dev Moves `amount` tokens from `sender` to `recipient` using the - * allowance mechanism. O valor é então deduzido do rendimento do chamador. + * @dev Move `amount` tokens de `sender` para `recipient` usando o + * mecanismo de permissão. `amount` é então deduzido da + * permissão do chamador. * - * Returns a boolean value indicating whether the operation succeeded. + * Retorna um valor booleano que indica se a operação foi bem-sucedida. * - * Emits a {Transfer} event. + * Emite um evento {Transfer}. */ function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); ``` -Por fim, `transferFrom` é utilizado pelo cliente para realmente gastar a provisão. +Finalmente, `transferFrom` é usado pelo gastador para realmente gastar a permissão.   ```solidity /** - * @dev Emitted when `value` tokens are moved from one account (`from`) to - * another (`to`). + * @dev Emitido quando `value` tokens são movidos de uma conta (`from`) para + * outra (`to`). * - * Note that `value` may be zero. + * Note que `value` pode ser zero. */ event Transfer(address indexed from, address indexed to, uint256 value); /** - * @dev Emitted when the allowance of a `spender` for an `owner` is set by - * a call to {approve}. `Valor` é a nova permissão. + * @dev Emitido quando a permissão de um `spender` para um `owner` é definida por + * uma chamada para {approve}. `value` é a nova permissão. */ event Approval(address indexed owner, address indexed spender, uint256 value); } ``` -Esses eventos são emitidos quando o estado do contrato ERC-20 é alterado. +Esses eventos são emitidos quando o estado do contrato ERC-20 muda. ## O contrato real {#the-actual-contract} -Este é o contrato que implementa o padrão ERC-20, [retirado daqui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). Ele não é destinado a ser usado tal como é, mas você pode [herdar](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm) dele para estendê-lo para algo utilizável. +Este é o contrato real que implementa o padrão ERC-20, +[retirado daqui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). +Ele não se destina a ser usado como está, mas você pode +[herdar](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm) dele para estendê-lo para algo utilizável. ```solidity // SPDX-License-Identifier: MIT @@ -194,9 +237,9 @@ pragma solidity >=0.6.0 <0.8.0;   -### Importar declarações {#import-statements} +### Declarações de importação {#import-statements} -Além das definições de interface acima, o contrato de definição importa outros dois arquivos: +Além das definições de interface acima, a definição do contrato importa dois outros arquivos: ```solidity @@ -205,8 +248,13 @@ import "./IERC20.sol"; import "../../math/SafeMath.sol"; ``` -- `GSN/Context.sol` são as definições necessárias para usar [OpenGSN](https://www.opengsn.org/), um sistema que permite que usuários sem ether possam usar a blockchain. Observe que esta é uma versão antiga. Se você quiser integrá-la com o OpenGSN [use este tutorial](https://docs.opengsn.org/javascript-client/tutorial.html). -- [A biblioteca SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-‘overflows’/), que é usada para fazer adições e subtrações sem estouros. Isso é necessário, pois, do contrário, uma pessoa pode ter um token, dois tokens, e então ter 2^256-1 tokens. +- `GSN/Context.sol` são as definições necessárias para usar o [OpenGSN](https://www.opengsn.org/), um sistema que permite que usuários sem ether + usem a blockchain. Observe que esta é uma versão antiga; se você quiser integrar com o OpenGSN, + [use este tutorial](https://docs.opengsn.org/javascript-client/tutorial.html). +- [A biblioteca SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/), que impede + estouros/subfluxos aritméticos para versões do Solidity **<0.8.0**. No Solidity ≥0.8.0, as operações aritméticas revertem + automaticamente em caso de estouro/subfluxo, tornando o SafeMath desnecessário. Este contrato usa o SafeMath para compatibilidade com versões anteriores + de compiladores mais antigos.   @@ -214,33 +262,33 @@ Este comentário explica o propósito do contrato. ```solidity /** - * @dev Implementation of the {IERC20} interface. + * @dev Implementação da interface {IERC20}. * - * This implementation is agnostic to the way tokens are created. Isto significa -* que um mecanismo de oferta deve ser adicionado em um contrato derivado usando {_mint}. - * For a generic mechanism see {ERC20PresetMinterPauser}. + * Esta implementação é agnóstica à forma como os tokens são criados. Isso significa + * que um mecanismo de fornecimento deve ser adicionado em um contrato derivado usando {_mint}. + * Para um mecanismo genérico, veja {ERC20PresetMinterPauser}. * - * TIP: For a detailed writeup see our guide - * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How - * to implement supply mechanisms]. + * DICA: Para um artigo detalhado, consulte nosso guia + * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[Como + * implementar mecanismos de fornecimento]. * - * We have followed general OpenZeppelin guidelines: functions revert instead - * of returning `false` on failure. Esse comportamento é, no entanto, convencional - * e não entra em conflito com as expectativas das aplicações do ERC20. + * Seguimos as diretrizes gerais da OpenZeppelin: as funções são revertidas em vez + * de retornar `false` em caso de falha. Esse comportamento, no entanto, é convencional + * e não entra em conflito com as expectativas dos aplicativos ERC20. * - * Additionally, an {Approval} event is emitted on calls to {transferFrom}. - * This allows applications to reconstruct the allowance for all accounts just - * by listening to said events. Outras implementações do EIP podem não emitir + * Além disso, um evento {Approval} é emitido em chamadas para {transferFrom}. + * Isso permite que os aplicativos reconstruam a permissão para todas as contas apenas + * ouvindo esses eventos. Outras implementações da EIP podem não emitir * esses eventos, pois não é exigido pela especificação. * - * Finally, the non-standard {decreaseAllowance} and {increaseAllowance} - * functions have been added to mitigate the well-known issues around setting - * allowances. Veja {IERC20-approve}. + * Finalmente, as funções não padrão {decreaseAllowance} e {increaseAllowance} + * foram adicionadas para mitigar os problemas conhecidos em torno da definição + * de permissões. Veja {IERC20-approve}. */ ``` -### Definição de contrato {#contract-definition} +### Definição do Contrato {#contract-definition} ```solidity contract ERC20 is Context, IERC20 { @@ -256,19 +304,27 @@ Esta linha especifica a herança, neste caso de `IERC20` acima e `Context`, para ``` -Essa linha anexa a biblioteca `SafeMath` ao tipo `uint256`. Você pode encontrar essa biblioteca [aqui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol). +Essa linha anexa a biblioteca `SafeMath` ao tipo `uint256`. Você pode encontrar esta biblioteca +[aqui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol). -### Definições de variáveis {#variable-definitions} +### Definições de Variáveis {#variable-definitions} -Essas definições especificam as variáveis de estado do contrato. Existem variáveis declaradas como `private`, mas isso apenas significa que outros contratos na blockchain não as podem ler. _Não há segredos na blockchain_, o software em cada nó possui o estado de cada contrato em cada bloco. Por convenção, as variáveis de estado são denominadas `_`. +Essas definições especificam as variáveis de estado do contrato. Essas variáveis são declaradas como `private`, mas +isso significa apenas que outros contratos na blockchain não podem lê-las. _Não há +segredos na blockchain_, o software em cada nó tem o estado de cada contrato +em cada bloco. Por convenção, as variáveis de estado são nomeadas `_`. -As duas primeiras variáveis são [mapeamentos](https://www.tutorialspoint.com/solidity/solidity_mappings.htm), ou seja, se comportam mais ou menos da mesma forma que [matrizes associativas](https://wikipedia.org/wiki/Associative_array), com exceção das chaves, que são valores numéricos. O armazenamento é alocado apenas para as entradas que possuem valores diferentes do padrão (zero). +As duas primeiras variáveis são [mapeamentos](https://www.tutorialspoint.com/solidity/solidity_mappings.htm), +, o que significa que elas se comportam de forma semelhante a [matrizes associativas](https://wikipedia.org/wiki/Associative_array), +, exceto que as chaves são valores numéricos. O armazenamento só é alocado para entradas que têm valores diferentes +do padrão (zero). ```solidity mapping (address => uint256) private _balances; ``` -O primeiro mapeamento, `_balances`, é composta por endereços e seus respectivos saldos desse token. Para acessar o saldo, utilize a sintaxe: `_balances[
]`. +O primeiro mapeamento, `_balances`, são os endereços e seus respectivos saldos deste token. Para acessar +o saldo, use esta sintaxe: `_balances[]`.   @@ -276,7 +332,9 @@ O primeiro mapeamento, `_balances`, é composta por endereços e seus respectivo mapping (address => mapping (address => uint256)) private _allowances; ``` -Esta variável, `_allowances`, armazena as margens explicadas anteriormente. O primeiro índice é o proprietário das moedas, e o segundo é o contrato com a provisão. Para acessar a quantia que o endereço A pode gastar na conta do endereço B, use `_allowances[B][A]`. +Essa variável, `_allowances`, armazena as permissões explicadas anteriormente. O primeiro índice é o proprietário +dos tokens, e o segundo é o contrato com a permissão. Para acessar a quantia que o endereço A pode +gastar da conta do endereço B, use `_allowances[B][A]`.   @@ -284,7 +342,7 @@ Esta variável, `_allowances`, armazena as margens explicadas anteriormente. O p uint256 private _totalSupply; ``` -Como o nome sugere, essa variável mantém registro do fornecimento total de tokens. +Como o nome sugere, essa variável acompanha o fornecimento total de tokens.   @@ -294,90 +352,102 @@ Como o nome sugere, essa variável mantém registro do fornecimento total de tok uint8 private _decimals; ``` -Essas três variáveis são usadas para melhorar a legibilidade. As duas primeiras são autoexplicativas, mas `_decimals` não. +Essas três variáveis são usadas para melhorar a legibilidade. As duas primeiras são autoexplicativas, mas `_decimals` +não é. -De um lado, o Ethereum não possui ponto flutuante ou variáveis fracionadas. De outro, as pessoas gostam de poder dividir tokens. Uma das razões pelas quais as pessoas estabeleceram o uso do ouro como moeda foi devido à dificuldade de trocá-lo quando alguém queria, por exemplo, comprar vaca pelo valor de um pato. +Por um lado, o Ethereum não tem variáveis de ponto flutuante ou fracionárias. Por outro lado, +os humanos gostam de poder dividir tokens. Uma das razões pelas quais as pessoas optaram pelo ouro como moeda foi porque +era difícil dar troco quando alguém queria comprar o equivalente a um pato em uma vaca. -A solução é manter o registro dos inteiros, mas em vez de contar o token real, contar o token fracionário, que praticamente não tem valor. No caso do ether, a moeda fracionária é chamada de wei, e 10^18 WEI é igual a um ETH. No momento da criação deste artigo, 10.000.000.000.000 WEI equivalem a cerca de um centavo de Dólar ou Euro. +A solução é manter o controle de números inteiros, mas contar, em vez do token real, um token fracionário que é +quase sem valor. No caso do ether, o token fracionário é chamado de wei, e 10^18 wei é igual a um +ETH. No momento em que este artigo foi escrito, 10.000.000.000.000 wei equivalem a aproximadamente um centavo de dólar americano ou euro. -Os aplicativos precisam saber como exibir o saldo do token. Se um usuário tiver 3.141.000.000.000.000.000 WEI, seria equivalente a 3,14 ETH? 31,41 ETH? 3,141 ETH? No caso do ETH, é definido 10^18 WEI para o ETH, mas para sua moeda, você pode escolher um valor diferente. Se dividir uma moeda não fizer sentido, você pode usar um valor `_decimals` de zero. Se você quiser utilizar o mesmo padrão utilizado em ETH, use o valor **18**. +Os aplicativos precisam saber como exibir o saldo do token. Se um usuário tiver 3.141.000.000.000.000.000 wei, isso é +3,14 ETH? 31,41 ETH? 3.141 ETH? No caso do ether, é definido 10^18 wei para o ETH, mas para o seu +token você pode selecionar um valor diferente. Se a divisão do token não fizer sentido, você pode usar um +valor `_decimals` de zero. Se você quiser usar o mesmo padrão do ETH, use o valor **18**. -### O Constructor {#the-constructor} +### O construtor {#the-constructor} ```solidity /** - * @dev Sets the values for {name} and {symbol}, initializes {decimals} with - * a default value of 18. + * @dev Define os valores para {name} e {symbol}, inicializa {decimals} com + * um valor padrão de 18. * - * To select a different value for {decimals}, use {_setupDecimals}. + * Para selecionar um valor diferente para {decimals}, use {_setupDecimals}. * - * All three of these values are immutable: they can only be set once during - * construction. + * Todos esses três valores são imutáveis: eles só podem ser definidos uma vez durante + * a construção. */ constructor (string memory name_, string memory symbol_) public { + // No Solidity ≥0.7.0, 'public' é implícito e pode ser omitido. + _name = name_; _symbol = symbol_; _decimals = 18; } ``` -O construtor é chamado quando o contrato é criado pela primeira vez. Por convenção, os parâmetros da função são denominados `_`. +O construtor é chamado quando o contrato é criado pela primeira vez. Por convenção, os parâmetros da função são nomeados `_`. -### Funções da interface do usuário {#user-interface-functions} +### Funções da Interface do Usuário {#user-interface-functions} ```solidity /** - * @dev Returns the name of the token. + * @dev Retorna o nome do token. */ function name() public view returns (string memory) { return _name; } /** - * @dev Returns the symbol of the token, usually a shorter version of the - * name. + * @dev Retorna o símbolo do token, geralmente uma versão mais curta do + * nome. */ function symbol() public view returns (string memory) { return _symbol; } /** - * @dev Returns the number of decimals used to get its user representation. - * For example, if `decimals` equals `2`, a balance of `505` tokens should - * be displayed to a user as `5,05` (`505 / 10 ** 2`). + * @dev Retorna o número de casas decimais usadas para obter sua representação de usuário. + * Por exemplo, se `decimals` for igual a `2`, um saldo de `505` tokens deve + * ser exibido para um usuário como `5,05` (`505 / 10 ** 2`). * - * Tokens usually opt for a value of 18, imitating the relationship between - * ether and wei. Esse é o valor {ERC20} usado, a menos que {_setupDecimals} seja + * Geralmente, os tokens optam por um valor de 18, imitando a relação entre + * ether e wei. Este é o valor que {ERC20} usa, a menos que {_setupDecimals} seja * chamado. * - * NOTE: This information is only used for _display_ purposes: it in - * no way affects any of the arithmetic of the contract, including - * {IERC20-balanceOf} and {IERC20-transfer}. + * OBSERVAÇÃO: esta informação é usada apenas para fins de _exibição_: ela + * não afeta de forma alguma a aritmética do contrato, incluindo + * {IERC20-balanceOf} e {IERC20-transfer}. */ function decimals() public view returns (uint8) { return _decimals; } ``` -Essas funções, `nome`, `symbol` e `decimals`, ajudam as interfaces do usuário a conhecer o seu contrato para poderem exibi-lo corretamente. +Essas funções, `name`, `symbol` e `decimals` ajudam as interfaces de usuário a saber sobre o seu contrato para que possam exibi-lo corretamente. -O tipo do retorno é `string memory`, o que significa que retorna uma string que é armazenada na memória. Variáveis, como ‘strings’, podem ser armazenadas em três locais: +O tipo de retorno é `string memory`, o que significa retornar uma string que é armazenada na memória. Variáveis, como +strings, podem ser armazenadas em três locais: -| | Tempo de vida | Acesso ao contrato | Custo em gás | -| ------------- | ----------------- | ------------------ | ------------------------------------------------------------------------ | -| Memória | Chamada da função | Leitura/gravação | Dezenas ou centenas (maior para locais mais altos) | -| Calldata | Chamar Função | Somente leitura | Não pode ser usada como retorno, apenas como tipo de parâmetro de função | -| Armazenamento | Até ser alterado | Ler/Escrever | Alto (800 para leitura, 20 mil para gravação) | +| | Tempo de vida | Acesso ao contrato | Custo de gás | +| ------------- | ----------------- | ------------------ | --------------------------------------------------------------------------------- | +| Memória | Chamada de função | Leitura/Escrita | Dezenas ou centenas (maior para locais mais altos) | +| Calldata | Chamada de função | Somente leitura | Não pode ser usado como um tipo de retorno, apenas um tipo de parâmetro de função | +| Armazenamento | Até ser alterado | Leitura/Escrita | Alto (800 para leitura, 20 mil para escrita) | Neste caso, `memory` é a melhor escolha. -### Informação de leitura do token {#read-token-information} +### Ler informações do token {#read-token-information} -Essas funções fornecem informações sobre o token, seja o fornecimento total ou o saldo de uma conta. +Estas são funções que fornecem informações sobre o token, seja o fornecimento total ou o +saldo de uma conta. ```solidity /** - * @dev See {IERC20-totalSupply}. + * @dev Ver {IERC20-totalSupply}. */ function totalSupply() public view override returns (uint256) { return _totalSupply; @@ -390,30 +460,34 @@ A função `totalSupply` retorna o fornecimento total de tokens. ```solidity /** - * @dev See {IERC20-balanceOf}. + * @dev Ver {IERC20-balanceOf}. */ function balanceOf(address account) public view override returns (uint256) { return _balances[account]; } ``` -Leia o saldo de uma conta. Observe que qualquer um pode obter o saldo da conta de outra pessoa. Não há motivo para esconder essa informação, pois ela está disponível em todos os nós. _Não há segredos na blockchain._ +Leia o saldo de uma conta. Observe que qualquer um pode obter o saldo da conta +de qualquer outra pessoa. Não faz sentido tentar esconder essa informação, porque ela está disponível em todos os +nós de qualquer maneira. _Não há segredos na blockchain._ -### Transferência de tokens {#transfer-tokens} +### Transferir Tokens {#transfer-tokens} ```solidity /** - * @dev See {IERC20-transfer}. + * @dev Ver {IERC20-transfer}. * - * Requirements: + * Requisitos: * - * - `recipient` cannot be the zero address. - * - the caller must have a balance of at least `amount`. + * - `recipient` não pode ser o endereço zero. + * - o chamador deve ter um saldo de pelo menos `amount`. */ function transfer(address recipient, uint256 amount) public virtual override returns (bool) { ``` -A função `transfer` é chamada para transferir os tokens do remetente para um destinatário. Observe que mesmo que ela retorne um valor booleano, o valor é sempre **true**. Se a transferência falhar, o contrato anulará a chamada. +A função `transfer` é chamada para transferir tokens da conta do remetente para uma diferente. Observe +que, embora retorne um valor booleano, esse valor é sempre **verdadeiro**. Se a transferência +falhar, o contrato reverte a chamada.   @@ -423,71 +497,80 @@ A função `transfer` é chamada para transferir os tokens do remetente para um } ``` -A função `_transfer` faz o trabalho real. Ela é uma função privada que só pode ser chamada por outras funções de contrato. Por convenção, funções privadas são denominadas `_`, assim como as variáveis de estado. +A função `_transfer` faz o trabalho real. É uma função privada que só pode ser chamada por +outras funções do contrato. Por convenção, as funções privadas são nomeadas como `_`, da mesma forma que as variáveis +de estado. -Normalmente, usamos `msg.sender` no Solidity para o remetente de mensagens. No entanto, isso rompe a [OpenGSN](http://opengsn.org/). Caso queiramos permitir transações sem Eth com nosso token, precisamos usar `_msgSender()`. Ela retornará `msg.sender` para transações normais, mas para transações sem Eth, ela indicará o signatário original e não o contrato que repassou a mensagem. +Normalmente no Solidity, usamos `msg.sender` para o remetente da mensagem. No entanto, isso quebra o +[OpenGSN](http://opengsn.org/). Se quisermos permitir transações sem ether com nosso token, precisamos +usar `_msgSender()`. Ele retorna `msg.sender` para transações normais, mas para as sem ether +retorna o assinante original e não o contrato que retransmitiu a mensagem. -### Funções de margem {#allowance-functions} +### Funções de Permissão {#allowance-functions} -Estas são as funções que implementam a funcionalidade da margem: `allowance`, `approve`, `transferFrom`, e `_approve`. Além disso, a implementação do OpenZeppelin vai além do padrão básico, para poder incluir alguns recursos que melhoram a segurança: `increaseAllowance`, e `decreaseAllowance`. +Estas são as funções que implementam a funcionalidade de permissão: `allowance`, `approve`, `transferFrom` +e `_approve`. Além disso, a implementação do OpenZeppelin vai além do padrão básico para incluir alguns recursos que melhoram +a segurança: `increaseAllowance` e `decreaseAllowance`. #### A função allowance {#allowance} ```solidity /** - * @dev See {IERC20-allowance}. + * @dev Ver {IERC20-allowance}. */ function allowance(address owner, address spender) public view virtual override returns (uint256) { return _allowances[owner][spender]; } ``` -A função `allowance` permite que todo mundo confira qualquer margem. +A função `allowance` permite que todos verifiquem qualquer permissão. #### A função approve {#approve} ```solidity /** - * @dev See {IERC20-approve}. + * @dev Ver {IERC20-approve}. * - * Requirements: + * Requisitos: * - * - `spender` cannot be the zero address. + * - `spender` não pode ser o endereço zero. */ function approve(address spender, uint256 amount) public virtual override returns (bool) { ``` -Essa função é chamada para criar uma provisão. Ela é semelhante à função `transfer` acima: +Esta função é chamada para criar uma permissão. É semelhante à função `transfer` acima: -- A função apenas chama uma função interna (neste caso, `_approve`) que realmente faz o trabalho. -- A função retorna `true` (se for bem-sucedida) ou é revertida (se falhar). +- A função apenas chama uma função interna (neste caso, `_approve`) que faz o trabalho real. +- A função ou retorna `true` (se for bem-sucedida) ou reverte (se não for).   ```solidity _approve(_msgSender(), spender, amount); - return tu; -} + return true; + } ``` -Usamos funções internas para minimizar a quantidade de lugares onde as mudanças de estado ocorrem. _Qualquer_ função que mude o estado constitui um risco de segurança em potencial que precisa ser auditado para segurança. Dessa forma, temos menos chances de errar. +Usamos funções internas para minimizar o número de locais onde ocorrem mudanças de estado. Qualquer função que altere o +estado é um risco potencial de segurança que precisa ser auditado para segurança. Dessa forma, temos menos chances de errar. #### A função transferFrom {#transferFrom} -Essa é a função que um gastador chama para gastar uma margem. Isso requer duas operações: transfira o valor sendo gasto e reduza a margem nesse valor. +Esta é a função que um gastador chama para gastar uma permissão. Isso requer duas operações: transferir o valor +gasto e reduzir a permissão por esse valor. ```solidity /** - * @dev See {IERC20-transferFrom}. + * @dev Ver {IERC20-transferFrom}. * - * Emits an {Approval} event indicating the updated allowance. Isso não é - * necessário para o EIP. Veja a nota no início do {ERC20}. + * Emite um evento {Approval} indicando a permissão atualizada. Isso não + * é exigido pela EIP. Veja a nota no início de {ERC20}. * - * Requirements: + * Requisitos: * - * - `sender` and `recipient` cannot be the zero address. - * - `sender` must have a balance of at least `amount`. - * - the caller must have allowance for ``sender``'s tokens of at least + * - `sender` e `recipient` não podem ser o endereço zero. + * - `sender` deve ter um saldo de pelo menos `amount`. + * - o chamador deve ter permissão para os tokens de ``sender`` de pelo menos * `amount`. */ function transferFrom(address sender, address recipient, uint256 amount) public virtual @@ -497,7 +580,9 @@ Essa é a função que um gastador chama para gastar uma margem. Isso requer dua   -A chamada da função `a.sub(b, "message")` faz duas coisas. Primeiro, ela calcula `a-b`, que é a nova margem. Em seguida, ela verifica se esse resultado não é negativo. Se for negativo, a chamada é revertida com a mensagem fornecida. Observe que, quando uma chamada reverte qualquer processamento feito anteriormente a essa chamada, ela é ignorada para não precisarmos desfazer a `_transfer`. +A chamada da função `a.sub(b, "mensagem")` faz duas coisas. Primeiro, calcula `a-b`, que é a nova permissão. +Segundo, verifica se esse resultado não é negativo. Se for negativo, a chamada reverte com a mensagem fornecida. Observe que, quando uma chamada reverte, qualquer processamento feito anteriormente durante essa chamada é ignorado, então não precisamos +desfazer a `_transfer`. ```solidity _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, @@ -506,50 +591,62 @@ A chamada da função `a.sub(b, "message")` faz duas coisas. Primeiro, ela calcu } ``` -#### Adições de segurança do OpenZeppelin {#openzeppelin-safety-additions} +#### Adições de segurança da OpenZeppelin {#openzeppelin-safety-additions} -É perigoso definir uma margem que não seja zero como outro valor que não seja zero, porque você só controla a ordem de suas próprias transações, mas não as de outras pessoas. Imagine que você tenha dois usuários: Alice, que é ingênua, e Bill, que é desonesto. Alice quer solicitar um serviço de Bill que, segundo ela, custa cinco tokens — então, ela dá a Bill uma provisão de cinco tokens. +É perigoso definir uma permissão diferente de zero para outro valor diferente de zero, +porque você só controla a ordem de suas próprias transações, não a de mais ninguém. Imagine que você +tenha dois usuários, Alice, que é ingênua, e Bill, que é desonesto. Alice quer algum serviço de +Bill, que ela acha que custa cinco tokens — então ela dá a Bill uma permissão de cinco tokens. -Então, algo muda e o preço de Bill aumenta para dez tokens. Alice, que ainda quer o serviço, envia uma transação que define a provisão de Bill para dez. No momento em que Bill vê essa nova transação no pool de transações, ele envia uma transação que gasta os cinco tokens de Alice e com uma tarifa de gás muito mais alta que, portanto, será minerada mais rápido. Dessa forma, Bill pode gastar os cinco primeiros tokens e, quando a nova provisão de Alice for minerada, pode gastar mais dez por um preço total de quinze tokens, mais do que Alice queria autorizar. Essa técnica é chamada de [front-running](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running) +Então algo muda e o preço de Bill sobe para dez tokens. Alice, que ainda quer o serviço, +envia uma transação que define a permissão de Bill para dez. No momento em que Bill vê essa nova transação +no pool de transações, ele envia uma transação que gasta os cinco tokens de Alice e tem um +preço de gás muito mais alto para que seja minerado mais rápido. Dessa forma, Bill pode gastar primeiro cinco tokens e, em seguida, +uma vez que a nova permissão de Alice seja minerada, gastar mais dez por um preço total de quinze tokens, mais do que +Alice pretendia autorizar. Essa técnica é chamada de +[front-running](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running) -| Transação de Alice | Nonce de Alice | Transação de Bill | Nonce de Bill | A provisão de Bill | Total faturado por Bill de Alice | -| ------------------ | -------------- | ----------------------------- | ------------- | ------------------ | -------------------------------- | -| approve(Bill, 5) | 10 | | | 5 | 0 | -| | | transferFrom(Alice, Bill, 5) | 10.123 | 0 | 5 | -| approve(Bill, 10) | 11 | | | 10 | 5 | -| | | transferFrom(Alice, Bill, 10) | 10.124 | 0 | 15 | +| Transação de Alice | Nonce de Alice | Transação de Bill | Nonce de Bill | Permissão de Bill | Renda Total de Bill vinda de Alice | +| ------------------------------------ | -------------- | ------------------------------------------------ | ---------------------- | ----------------- | ---------------------------------- | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| | | transferFrom(Alice, Bill, 5) | 10.123 | 0 | 5 | +| approve(Bill, 10) | 11 | | | 10 | 5 | +| | | transferFrom(Alice, Bill, 10) | 10.124 | 0 | 15 | -Para evitar esse problema, essas duas funções (`increaseAllowance` e `reduaseAllowance`) permitem que você modifique a provisão por um valor específico. Então, se Bill já tinha gastado cinco tokens, ele só poderá gastar mais cinco tokens. Dependendo do tempo disponível, há duas maneiras de proceder, sendo que as duas acabam com Bill obtendo os dez tokens: +Para evitar esse problema, essas duas funções (`increaseAllowance` e `decreaseAllowance`) permitem que você +modifique a permissão por um valor específico. Então, se Bill já gastou cinco tokens, ele só +conseguirá gastar mais cinco. Dependendo do tempo, existem duas maneiras de isso funcionar, ambas +terminando com Bill recebendo apenas dez tokens: A: -| Transação de Alice | Nonce de Alice | Transação de Bill | Nonce de Bill | Permissão de Bill | Cobrança Total de Alice | -| -------------------------- | --------------:| ---------------------------- | -------------:| -----------------:| ----------------------- | -| approve(Bill, 5) | 10 | | | 5 | 0 | -| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | -| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 | -| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 | +| Transação de Alice | Nonce de Alice | Transação de Bill | Nonce de Bill | Permissão de Bill | Renda Total de Bill vinda de Alice | +| --------------------------------------------- | -------------: | ----------------------------------------------- | ---------------------: | ----------------: | ---------------------------------- | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| | | transferFrom(Alice, Bill, 5) | 10.123 | 0 | 5 | +| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 | +| | | transferFrom(Alice, Bill, 5) | 10.124 | 0 | 10 | B: -| Transação de Alice | Nonce de Alice | Transação de Bill | Nonce de Bill | Permissão de Bill | Cobrança Total de Alice | -| -------------------------- | --------------:| ----------------------------- | -------------:| -----------------:| -----------------------:| -| approve(Bill, 5) | 10 | | | 5 | 0 | -| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 | -| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 | +| Transação de Alice | Nonce de Alice | Transação de Bill | Nonce de Bill | Permissão de Bill | Renda Total de Bill vinda de Alice | +| --------------------------------------------- | -------------: | ------------------------------------------------ | ---------------------: | ----------------: | ---------------------------------: | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 | +| | | transferFrom(Alice, Bill, 10) | 10.124 | 0 | 10 | ```solidity /** - * @dev Atomically increases the allowance granted to `spender` by the caller. + * @dev Aumenta atomicamente a permissão concedida ao `spender` pelo chamador. * - * This is an alternative to {approve} that can be used as a mitigation for - * problems described in {IERC20-approve}. + * Esta é uma alternativa para {approve} que pode ser usada como uma mitigação para + * os problemas descritos em {IERC20-approve}. * - * Emits an {Approval} event indicating the updated allowance. + * Emite um evento {Approval} indicando a permissão atualizada. * - * Requirements: + * Requisitos: * - * - `spender` cannot be the zero address. + * - `spender` não pode ser o endereço zero. */ function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) { _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue)); @@ -557,22 +654,23 @@ B: } ``` -A função `a.add(b)` é uma adição segura. No caso improvável de `um`+`b`>=`2^256`, ele não é contornado da mesma maneira que uma adição normal. +A função `a.add(b)` é uma adição segura. No caso improvável de `a`+`b`>=`2^256`, ele não dá a volta +como a adição normal faz. ```solidity /** - * @dev Atomically decreases the allowance granted to `spender` by the caller. + * @dev Diminui atomicamente a permissão concedida ao `spender` pelo chamador. * - * This is an alternative to {approve} that can be used as a mitigation for - * problems described in {IERC20-approve}. + * Esta é uma alternativa para {approve} que pode ser usada como uma mitigação para + * os problemas descritos em {IERC20-approve}. * - * Emits an {Approval} event indicating the updated allowance. + * Emite um evento {Approval} indicando a permissão atualizada. * - * Requirements: + * Requisitos: * - * - `spender` cannot be the zero address. - * - `spender` must have allowance for the caller of at least + * - `spender` não pode ser o endereço zero. + * - `spender` deve ter uma permissão para o chamador de pelo menos * `subtractedValue`. */ function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) { @@ -582,31 +680,33 @@ A função `a.add(b)` é uma adição segura. No caso improvável de `um`+`b`>=` } ``` -### Funções que modificam informações do token {#functions-that-modify-token-information} +### Funções que modificam as informações do token {#functions-that-modify-token-information} -Essas são as quatro funções que realmente funcionam: `_transfer`, `_mint`, `_burn`, e `_appro`. +Estas são as quatro funções que fazem o trabalho real: `_transfer`, `_mint`, `_burn` e `_approve`. -#### A função \_transfer {#_transfer} +#### A função _transfer {#_transfer} ```solidity /** - * @dev Moves tokens `amount` from `sender` to `recipient`. + * @dev Move `amount` de tokens de `sender` para `recipient`. * - * This is internal function is equivalent to {transfer}, and can be used to - * e.g., implement automatic token fees, slashing mechanisms, etc. + * Esta função interna é equivalente a {transfer} e pode ser usada para + * implementar, por exemplo, taxas automáticas de tokens, mecanismos de slashing, etc. * - * Emits a {Transfer} event. + * Emite um evento {Transfer}. * - * Requirements: + * Requisitos: * - * - `sender` cannot be the zero address. - * - `recipient` cannot be the zero address. - * - `sender` must have a balance of at least `amount`. + * - `sender` não pode ser o endereço zero. + * - `recipient` não pode ser o endereço zero. + * - `sender` deve ter um saldo de pelo menos `amount`. */ function _transfer(address sender, address recipient, uint256 amount) internal virtual { ``` -Esta função, `_transfer`, transfere moedas de uma conta para outra. Ela é chamada por `transfer` (para transferências da própria conta do remetente) e `transferFrom` (para usar as provisões a serem transferidas da conta de outra pessoa). +Esta função, `_transfer`, transfere tokens de uma conta para outra. Ela é chamada tanto por +`transfer` (para transferências da própria conta do remetente) quanto por `transferFrom` (para usar permissões +para transferir da conta de outra pessoa).   @@ -615,7 +715,9 @@ Esta função, `_transfer`, transfere moedas de uma conta para outra. Ela é cha require(recipient != address(0), "ERC20: transfer to the zero address"); ``` -Na verdade, ninguém possui o endereço zero no Ethereum (ou seja, ninguém conhece uma chave privada cuja chave pública correspondente tenha sido transformada no endereço zero). Quando as pessoas usam esse endereço, geralmente se trata de um bug de software, portanto, falhamos se o endereço zero é usado como o remetente ou o destinatário. +Ninguém realmente possui o endereço zero no Ethereum (ou seja, ninguém conhece uma chave privada cuja chave pública correspondente +seja transformada no endereço zero). Quando as pessoas usam esse endereço, geralmente é um bug de software — então, +falhamos se o endereço zero for usado como remetente ou destinatário.   @@ -627,11 +729,14 @@ Na verdade, ninguém possui o endereço zero no Ethereum (ou seja, ninguém conh Existem duas maneiras de usar esse contrato: 1. Use-o como um modelo para o seu próprio código -1. [Herde a partir daqui](https://www.bitdegree.org/learn/solidity-inheritance) e substitua apenas as funções que você precisa modificar +2. [Herdar dele](https://www.bitdegree.org/learn/solidity-inheritance), e substituir apenas as funções que você precisa modificar -O segundo método é muito melhor, porque o código OpenZeppelin ERC-20 já foi auditado e comprovado como seguro. Ao usar a herança, é fácil distinguir quais são as funções que você modificou e, para confiar nos seus contratos, as pessoas só precisam auditar essas funções específicas. +O segundo método é muito melhor porque o código ERC-20 da OpenZeppelin já foi auditado e demonstrou ser seguro. Quando você usa herança, +fica claro quais são as funções que você modifica, e para confiar em seu contrato, as pessoas só precisam auditar essas funções específicas. -Geralmente, é útil executar uma função toda vez que os tokens mudam de mãos. No entanto,`_transfer` é uma função muito importante e é possível escrevê-la de forma não segura (veja abaixo). Portanto, é melhor não substituí-la. A solução é `_beforeTokenTransfer`, uma [função hook](https://wikipedia.org/wiki/Hooking). Você pode substituir essa função e ela será chamada em cada transferência. +Muitas vezes, é útil executar uma função cada vez que os tokens trocam de mãos. No entanto, `_transfer` é uma função muito importante e é +possível escrevê-la de forma insegura (veja abaixo), então é melhor não substituí-la. A solução é `_beforeTokenTransfer`, uma +[função de gancho (hook)](https://wikipedia.org/wiki/Hooking). Você pode substituir essa função e ela será chamada em cada transferência.   @@ -640,7 +745,10 @@ Geralmente, é útil executar uma função toda vez que os tokens mudam de mãos _balances[recipient] = _balances[recipient].add(amount); ``` -Essas são as linhas que realmente executam a transferência. Observe que não há **nada** entre elas, e que subtraímos o valor transferido do remetente antes de adicioná-lo ao destinatário. Isso é importante, pois se tivesse ocorrido uma chamada para um contrato diferente nesse meio tempo, ela poderia ter sido utilizada para enganar esse contrato. Dessa forma, a transferência é atômica, ou seja, nada pode acontecer enquanto ela está em execução. +Estas são as linhas que realmente fazem a transferência. Note que não há **nada** entre elas, e que subtraímos +o valor transferido do remetente antes de adicioná-lo ao destinatário. Isso é importante porque, se houvesse uma +chamada para um contrato diferente no meio, isso poderia ter sido usado para enganar este contrato. Desta forma, a transferência +é atômica, nada pode acontecer no meio dela.   @@ -649,23 +757,31 @@ Essas são as linhas que realmente executam a transferência. Observe que não h } ``` -Essa função emite o evento `Transfer`. Os eventos não são acessíveis para contratos inteligentes, mas o código executado fora da blockchain pode ouvir os eventos e reagir a eles. Por exemplo, uma carteira pode monitorar quando o proprietário obtém mais tokens. +Finalmente, emita um evento `Transfer`. Eventos não são acessíveis a contratos inteligentes, mas o código executado fora da blockchain +pode ouvir eventos e reagir a eles. Por exemplo, uma carteira pode acompanhar quando o proprietário recebe mais tokens. -#### As funções \_mint e \_burn {#_mint-and-_burn} +#### As funções _mint e _burn {#_mint-and-_burn} -Essas duas funções (`_mint` e `_burn`) modificam o fornecimento total de moedas. Elas são internas e não há nenhuma função que as chame nesse contrato, portanto, elas só são úteis se você herdar do contrato e adicionar sua própria lógica para decidir em que condições gerar novos tokens ou usar os tokens já existentes. +Essas duas funções (`_mint` e `_burn`) modificam o fornecimento total de tokens. +Elas são internas e não há nenhuma função que as chame neste contrato, +então elas só são úteis se você herdar do contrato e adicionar sua própria +lógica para decidir sob quais condições criar (mint) novos tokens ou queimar (burn) os existentes. -**OBSERVAÇÃO:** Todos os tokens ERC-20 têm sua própria lógica comercial que dita o gerenciamento de tokens. Por exemplo, um contrato de fornecimento fixo só pode chamar `_mint` no construtor e nunca chamar `_burn`. Um contrato que vende tokens chamará `_mint` quando for pago, e provavelmente chamará `_burn` em algum momento para evitar hiperinflação. +**NOTA:** todo token ERC-20 tem sua própria lógica de negócios que dita o gerenciamento de tokens. +Por exemplo, um contrato de fornecimento fixo pode chamar `_mint` apenas +no construtor e nunca chamar `_burn`. Um contrato que vende tokens +chamará `_mint` quando for pago e, presumivelmente, chamará `_burn` em algum momento +para evitar uma inflação descontrolada. ```solidity - /** @dev Creates `amount` tokens and assigns them to `account`, increasing - * the total supply. + /** @dev Cria `amount` de tokens e os atribui a `account`, aumentando + * o fornecimento total. * - * Emits a {Transfer} event with `from` set to the zero address. + * Emite um evento {Transfer} com `from` definido para o endereço zero. * - * Requirements: + * Requisitos: * - * - `to` cannot be the zero address. + * - `to` não pode ser o endereço zero. */ function _mint(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: mint to the zero address"); @@ -676,21 +792,21 @@ Essas duas funções (`_mint` e `_burn`) modificam o fornecimento total de moeda } ``` -Certifique-se de atualizar o `_totalSupply` quando o número total de tokens mudar. +Certifique-se de atualizar `_totalSupply` quando o número total de tokens mudar.   -``` +```solidity /** - * @dev Destroys `amount` tokens from `account`, reducing the - * total supply. + * @dev Destrói `amount` de tokens da `account`, reduzindo o + * fornecimento total. * - * Emits a {Transfer} event with `to` set to the zero address. + * Emite um evento {Transfer} com `to` definido para o endereço zero. * - * Requirements: + * Requisitos: * - * - `account` cannot be the zero address. - * - `account` must have at least `amount` tokens. + * - `account` não pode ser o endereço zero. + * - `account` deve ter pelo menos `amount` de tokens. */ function _burn(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: burn from the zero address"); @@ -703,25 +819,28 @@ Certifique-se de atualizar o `_totalSupply` quando o número total de tokens mud } ``` -A função `_burn` é quase idêntica à `_mint`, exceto que ela funciona na direção inversa. +A função `_burn` é quase idêntica a `_mint`, exceto que vai na outra direção. -#### A função \_approve {#_approve} +#### A função _approve {#_approve} -Essa é a função que especifica as provisões. Observe que ela permite que um proprietário especifique uma provisão superior ao saldo atual do proprietário. Isso não tem problema, pois o saldo é verificado no momento da transferência, quando ele poderia diferir do saldo no momento da criação da provisão. +Esta é a função que realmente especifica as permissões. Observe que ela permite que um proprietário especifique +uma permissão que é maior que o saldo atual do proprietário. Isso não é um problema, porque o saldo é +verificado no momento da transferência, quando poderia ser diferente do saldo quando a permissão foi +criada. ```solidity /** - * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. + * @dev Define `amount` como a permissão de `spender` sobre os tokens do `owner`. * - * This internal function is equivalent to `approve`, and can be used to - * e.g., set automatic allowances for certain subsystems, etc. + * Essa função interna é equivalente a `approve` e pode ser usada para + * por exemplo, definir permissões automáticas para certos subsistemas, etc. * - * Emits an {Approval} event. + * Emite um evento {Approval}. * - * Requirements: + * Requisitos: * - * - `owner` cannot be the zero address. - * - `spender` cannot be the zero address. + * - `owner` não pode ser o endereço zero. + * - `spender` não pode ser o endereço zero. */ function _approve(address owner, address spender, uint256 amount) internal virtual { require(owner != address(0), "ERC20: approve from the zero address"); @@ -732,7 +851,8 @@ Essa é a função que especifica as provisões. Observe que ela permite que um   -Emita um evento `Approval`. Dependendo de como o aplicativo é escrito, o contrato do gastador pode ser informado sobre a aprovação, seja pelo proprietário, seja pelo servidor que realiza esses eventos. +Emita um evento `Approval`. Dependendo de como o aplicativo é escrito, o contrato do gastador pode ser informado sobre a +aprovação pelo proprietário ou por um servidor que escuta esses eventos. ```solidity emit Approval(owner, spender, amount); @@ -740,57 +860,74 @@ Emita um evento `Approval`. Dependendo de como o aplicativo é escrito, o contra ``` -### Modificando as variáveis decimais {#modify-the-decimals-variable} +### Modificar a variável Decimals {#modify-the-decimals-variable} ```solidity /** - * @dev Sets {decimals} to a value other than the default one of 18. + * @dev Define {decimals} para um valor diferente do padrão de 18. * - * WARNING: This function should only be called from the constructor. A maioria dos - * aplicativos que interagem com contratos das moedas não esperarão que - * {decimals} altere, e pode funcionar incorretamente se ele o fizer. + * AVISO: Esta função só deve ser chamada a partir do construtor. A maioria dos + * aplicativos que interagem com contratos de token não esperam que + * {decimals} mude, e podem funcionar incorretamente se isso acontecer. */ function _setupDecimals(uint8 decimals_) internal { _decimals = decimals_; } ``` -Essa função modifica a variável `_decimals` utilizada para dizer às ‘interfaces’ de usuário como interpretar o valor. Você deve chamá-la a partir do construtor. Seria desonesto chamá-la em qualquer ponto subsequente, ainda mais que aplicativos não são projetados para lidar com isso. +Esta função modifica a variável `_decimals`, que é usada para dizer às interfaces de usuário como interpretar o valor. +Você deve chamá-la a partir do construtor. Seria desonesto chamá-la em qualquer ponto subsequente, e os aplicativos +não são projetados para lidar com isso. ### Ganchos {#hooks} ```solidity /** - * @dev Hook that is called before any transfer of tokens. This includes - * minting and burning. + * @dev Gancho (hook) que é chamado antes de qualquer transferência de tokens. Isso inclui + * criação (minting) e queima (burning). * - * Calling conditions: + * Condições de chamada: * - * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens - * will be to transferred to `to`. - * - when `from` is zero, `amount` tokens will be minted for `to`. - * - when `to` is zero, `amount` of ``from``'s tokens will be burned. - * - `from` and `to` are never both zero. + * - quando `from` e `to` são ambos diferentes de zero, `amount` dos tokens de `from` + * serão transferidos para `to`. + * - quando `from` é zero, `amount` de tokens serão criados (minted) para `to`. + * - quando `to` é zero, `amount` dos tokens de `from` serão queimados (burned). + * - `from` e `to` nunca são ambos zero. * - * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]. + * Para saber mais sobre ganchos (hooks), acesse xref:ROOT:extending-contracts.adoc#using-hooks[Usando Ganchos (Hooks)]. */ function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { } } ``` -Essa é a função hook a ser chamada durante as transferências. Ela está vazia, mas se precisar dela para fazer algo, basta sobrescrevê-la. +Esta é a função de gancho (hook) a ser chamada durante as transferências. Está vazia aqui, mas se você precisar +que ela faça algo, basta substituí-la. ## Conclusão {#conclusion} -Resumindo, aqui estão algumas das ideias mais importantes neste contrato (na minha opinião, pode ser que as suas não sejam as mesmas): - -- _Não há segredos na blockchain_. Qualquer informação que um contrato inteligente possa acessar está disponível para o mundo inteiro. -- Você pode controlar a ordem de suas transações, mas não quando transações de outras pessoas estão em andamento. É por isso que alterar uma provisão pode ser perigoso, porque permite que o gastador gaste a soma das duas provisões. -- Valores do tipo `uint256` aproximados. Em outras palavras, _0-1=2^256-1_. Se esse não for o comportamento desejado, você precisa verificá-lo (ou usar a biblioteca SafeMath que faz isso por você). Observe que isso foi alterado em [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html). -- Faça todas as mudanças de estado de um tipo específico e em um local específico, pois isso facilita a auditoria. Esse é o motivo pelo qual temos, por exemplo, `_approve`, chamado por `approve`, `transferFrom`, `increaseAllowance` e `decreaseAllowance` -- Mudanças de estado devem ser atômicas, sem qualquer outra ação no meio (como se pode ver em `_transfer`). Isso ocorre, pois, durante a mudança de estado, o estado é inconsistente. Por exemplo, entre o tempo que você deduz do saldo do remetente e o tempo de adicionar ao saldo do beneficiário, há menos tokens existentes do que deveria haver. Isto pode ser potencialmente explorado mal-intencionadamente se houver operações entre eles, especialmente chamadas para um contrato diferente. - -Agora que você já viu como o contrato do OpenZeppelin ERC-20 é escrito, e especialmente como ele se tornou mais seguro, escreva seus próprios contratos e aplicativos seguros. +Para revisar, aqui estão algumas das ideias mais importantes neste contrato (na minha opinião, a sua provavelmente irá variar): + +- _Não há segredos na blockchain_. Qualquer informação que um contrato inteligente possa acessar + está disponível para o mundo todo. +- Você pode controlar a ordem de suas próprias transações, mas não quando as transações de outras pessoas + acontecem. Esta é a razão pela qual alterar uma permissão pode ser perigoso, porque permite + que o gastador gaste a soma de ambas as permissões. +- Valores do tipo `uint256` dão a volta (wrap around). Em outras palavras, _0-1=2^256-1_. Se esse não for o comportamento + desejado, você deve verificá-lo (ou usar a biblioteca SafeMath que faz isso por você). Observe que isso mudou no + [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html). +- Faça todas as mudanças de estado de um tipo específico em um local específico, porque isso facilita a auditoria. + Esta é a razão pela qual temos, por exemplo, `_approve`, que é chamado por `approve`, `transferFrom`, + `increaseAllowance` e `decreaseAllowance` +- As mudanças de estado devem ser atômicas, sem qualquer outra ação no meio delas (como você pode ver + em `_transfer`). Isso ocorre porque, durante a mudança de estado, você tem um estado inconsistente. Por exemplo, + entre o momento em que você deduz do saldo do remetente e o momento em que adiciona ao saldo do + destinatário, existem menos tokens em existência do que deveria haver. Isso poderia ser potencialmente explorado se houver + operações entre eles, especialmente chamadas para um contrato diferente. + +Agora que você viu como o contrato ERC-20 da OpenZeppelin é escrito, e especialmente como ele é +tornado mais seguro, vá e escreva seus próprios contratos e aplicativos seguros. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/pt-br/developers/tutorials/erc20-with-safety-rails/index.md index 71039047adb..c9ebdfe9fb1 100644 --- a/public/content/translations/pt-br/developers/tutorials/erc20-with-safety-rails/index.md +++ b/public/content/translations/pt-br/developers/tutorials/erc20-with-safety-rails/index.md @@ -1,62 +1,64 @@ --- -title: ERC-20 com Trilhos de Segurança -description: Como ajudar pessoas para evitar erros tolos +title: "ERC-20 com Trilhos de Segurança" +description: Como ajudar as pessoas a evitar erros bobos author: Ori Pomerantz lang: pt-br -tags: - - "erc-20" -skill: intermediate +tags: [ "erc-20" ] +skill: beginner published: 2022-08-15 --- ## Introdução {#introduction} -Uma das melhores coisas sobre o Ethereum é que não há autoridade central que possa modificar ou desfazer transações. Um dos maiores problemas do Ethereum é que não há autoridade central com o poder de desfazer erros de usuário ou transações ilícitas. Neste artigo, você aprenderá sobre alguns dos erros comuns que usuários cometem com tokens [ERC-20](/developers/docs/standards/tokens/erc-20/), assim como criar contratos ERC-20 que ajudam usuários a evitar esses erros, ou que dão a uma autoridade central algum poder (por exemplo, congelar contas). +Uma das grandes vantagens do Ethereum é que não existe uma autoridade central que possa modificar ou desfazer suas transações. Um dos maiores problemas do Ethereum é que não há autoridade central com o poder de desfazer erros de usuário ou transações ilícitas. Neste artigo, você aprenderá sobre alguns dos erros comuns que os usuários cometem com tokens [ERC-20](/developers/docs/standards/tokens/erc-20/), bem como a criar contratos ERC-20 que ajudam os usuários a evitar esses erros ou que dão a uma autoridade central algum poder (por exemplo, para congelar contas). -Observe que, apesar de usarmos o [contrato de token ERC-20 da OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20), este artigo não o explica em maiores detalhes. Você pode encontrar esta informação [aqui](/developers/tutorials/erc20-annotated-code). +Observe que, embora usemos o [contrato de token ERC-20 da OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20), este artigo não o explica em grandes detalhes. Você pode encontrar esta informação [aqui](/developers/tutorials/erc20-annotated-code). Se você quiser ver o código-fonte completo: 1. Abra o [Remix IDE](https://remix.ethereum.org/). -2. Clique o ícone de clonar o github (![clone github icon](icon-clone.png)). -3. Clone o repositório github `https://github.com/qbzzt/20220815-erc20-safety-rails`. +2. Clique no ícone de clonagem do GitHub (![clone github icon](icon-clone.png)). +3. Clone o repositório do GitHub `https://github.com/qbzzt/20220815-erc20-safety-rails`. 4. Abra **contracts > erc20-safety-rails.sol**. ## Criando um contrato ERC-20 {#creating-an-erc-20-contract} -Antes que nós possamos adicionar funcionalidade de trilhos de segurança, nós precisamos de um contrato ERC-20. Neste artigo, usaremos o [o Assistente de contratos da OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/wizard). Abra-o em outro navegador e siga estas instruções: +Antes de podermos adicionar a funcionalidade de trilhos de segurança, precisamos de um contrato ERC-20. Neste artigo, usaremos o [Assistente de Contratos da OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/wizard). Abra-o em outro navegador e siga estas instruções: 1. Selecione **ERC20**. -2. Entre estas configurações: + +2. Insira estas configurações: | Parâmetro | Valor | | ------------------------- | ---------------- | | Nome | SafetyRailsToken | | Símbolo | SAFE | - | Pré-cunhagem | 1.000 | + | Pré-cunhagem | 1000 | | Recursos | Nenhum | - | Controle de acesso | Proprietário | + | Controle de acesso | Ownable | | Capacidade de atualização | Nenhum | -3. Suba e clique **Open in Remix** (para o Remix) ou **Download** para usar um ambiente diferente. Vou presumir que você está usando o Remix. Se você estiver usando algo diferente, faça as mudanças apropriadas. -4. Agora, temos um contrato ERC-20 totalmente funcional. Você pode expandir `.deps` e `npm` para ver o código importado. -5. Compile, implante e brinque com o contrato para ver se ele funciona como um contrato ERC-20. Se você precisar aprender como usar o Remix, [use este tutorial](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth). +3. Role para cima e clique em **Abrir no Remix** (para o Remix) ou **Download** para usar um ambiente diferente. Vou presumir que você está usando o Remix. Se estiver usando algo diferente, faça as alterações apropriadas. + +4. Agora, temos um contrato ERC-20 totalmente funcional. Você pode expandir `.deps` > `npm` para ver o código importado. + +5. Compile, implante e interaja com o contrato para ver que ele funciona como um contrato ERC-20. Se precisar aprender a usar o Remix, [use este tutorial](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth). ## Erros comuns {#common-mistakes} ### Os erros {#the-mistakes} -Às vezes, os usuários enviam tokens para o endereço errado. Embora não consigamos ler a mente dos usuários para saber o que querem fazer, há dois tipos de erros que ocorrem muitas vezes e são fáceis de detectar: +Às vezes, os usuários enviam tokens para o endereço errado. Embora não possamos ler suas mentes para saber o que eles pretendiam fazer, existem dois tipos de erro que acontecem com frequência e são fáceis de detectar: -1. Enviar os tokens para o próprio endereço do contrato. Por exemplo, [token Optimism's OP](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) acabou acumulando [mais de 120.000](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000042#tokentxns) tokens OP em menos de dois meses. Isso representa uma quantia de dinheiro significativa, que presumimos que as pessoas tenham simplesmente perdido. +1. Enviar os tokens para o próprio endereço do contrato. Por exemplo, o [token OP da Optimism](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) conseguiu acumular [mais de 120.000](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000042) tokens OP em menos de dois meses. Isso representa uma quantia significativa de riqueza que, presumivelmente, as pessoas simplesmente perderam. -2. Enviar os tokens para um endereço vazio, um que não corresponde a uma [conta de propriedade externa](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) ou um [contrato inteligente](/developers/docs/smart-contracts). Enquanto eu não tenho estatísticas de quão frequente isso acontece, [um incidente poderia ter custado 20.000.000 de tokens](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595). +2. Enviar os tokens para um endereço vazio, um que não corresponde a uma [conta de propriedade externa](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) ou a um [contrato inteligente](/developers/docs/smart-contracts). Embora eu não tenha estatísticas sobre a frequência com que isso acontece, [um incidente poderia ter custado 20.000.000 de tokens](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595). -### Evitando transferências {#preventing-transfers} +### Impedindo transferências {#preventing-transfers} -O contrato OpenZeppelin ERC-20 inclui [um hook, `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368), que é chamado antes de um token ser transferido. Por padrão, esse hook não faz nada, mas podemos pendurar nossas próprias funcionalidades, como verificações que são anuladas se houver um problema. +O contrato ERC-20 da OpenZeppelin inclui [um hook, `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368), que é chamado antes da transferência de um token. Por padrão, este hook não faz nada, mas podemos vincular nossa própria funcionalidade a ele, como verificações que revertem a transação se houver um problema. -Para usar o hook, adicione esta função depois do construtor: +Para usar o hook, adicione esta função após o construtor: ```solidity function _beforeTokenTransfer(address from, address to, uint256 amount) @@ -73,36 +75,36 @@ Algumas partes desta função podem ser novas se você não estiver muito famili internal virtual ``` -A palavra-chave `virtual` significa que conforme herdamos funcionalidades do `ERC20` e substituímos essa função, outros contratos podem herdar de nós e substituir essa função. +A palavra-chave `virtual` significa que, assim como herdamos a funcionalidade do `ERC20` e substituímos essa função, outros contratos podem herdar de nós e substituir essa função. ```solidity override(ERC20) ``` -Temos que especificar explicitamente que estamos [substituindo](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) a definição de token ERC20 de `_beforeTokenTransfer`. Em geral, definições explícitas são muito melhores, do ponto de vista da segurança, do que as implícitas — você não pode se esquecer de que fez algo se isso estive bem na sua frente. Esta também é a razão que nós precisamos para especificar que superclasses `_beforeTokenTransfer` nós estamos sobrepondo. +Temos que especificar explicitamente que estamos [substituindo](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) a definição do token ERC20 de `_beforeTokenTransfer`. Em geral, definições explícitas são muito melhores, do ponto de vista da segurança, do que as implícitas — você não pode se esquecer de que fez algo se estiver bem na sua frente. Essa também é a razão pela qual precisamos especificar qual `_beforeTokenTransfer` da superclasse estamos substituindo. ```solidity super._beforeTokenTransfer(from, to, amount); ``` -Esta linha chama a função `_beforeTokenTransfer` do contrato ou contratos que herdamos e que a possui. Neste caso, isto é somente `ERC20`, `Ownable` não tem esse hook. Mesmo que, atualmente, o `ERC20._beforeTokenTransfer` não faça nada, nós o chamamos caso a funcionalidade seja adicionada no futuro (e nós então decidimos reimplantar o contrato, porque contratos não mudam depois da implantação). +Esta linha chama a função `_beforeTokenTransfer` do contrato ou contratos dos quais herdamos que a possuem. Neste caso, é apenas o `ERC20`, o `Ownable` não tem este hook. Mesmo que atualmente o `ERC20._beforeTokenTransfer` não faça nada, nós o chamamos caso uma funcionalidade seja adicionada no futuro (e então decidirmos reimplantar o contrato, porque os contratos não mudam após a implantação). ### Codificando os requisitos {#coding-the-requirements} -Nós queremos adicionar estes requisitos para a função: +Queremos adicionar estes requisitos à função: -- O endereço `to` não pode ser igual a `address(this)`, o endereço do contrato ERC-20 propriamente dito. -- O endereço `to` não pode ser vazio, ele tem de ser: - - Uma conta de propriedade externa (EOA). Nós não podemos checar se um endereço é um EOA diretamente, mas nós podemos checar o saldo em ETH de um endereço. EOAs quase sempre têm um saldo, mesmo que não estejam mais sendo usados — é difícil esvaziá-los até o último wei. - - Um contrato inteligente. Testar se um endereço é um contrato inteligente é um pouco mais difícil. Há um opcode que checa o tamanho do código externo, chamado [`EXTCODESIZE`](https://www.evm.codes/#3b), mas ele não é disponível diretamente em Solidity. Para isso, temos que usar [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html), que é um assembly da EVM. Há outros valores do Solidity que poderíamos usar ([`
.code` e `
.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)), mas eles são mais caros. +- O endereço `to` não pode ser igual a `address(this)`, o endereço do próprio contrato ERC-20. +- O endereço `to` não pode ser vazio, tem que ser: + - Uma conta de propriedade externa (EOA). Não podemos verificar diretamente se um endereço é uma EOA, mas podemos verificar o saldo em ETH de um endereço. As EOAs quase sempre têm um saldo, mesmo que não sejam mais usadas — é difícil limpá-las até o último wei. + - Um contrato inteligente. Testar se um endereço é um contrato inteligente é um pouco mais difícil. Existe um opcode que verifica o tamanho do código externo, chamado [`EXTCODESIZE`](https://www.evm.codes/#3b), mas ele não está disponível diretamente no Solidity. Temos que usar o [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html), que é o assembly da EVM, para isso. Existem outros valores que poderíamos usar do Solidity ([`
.code` e `
.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)), mas eles custam mais. -Vamos passar sobre o código novo, linha a linha: +Vamos analisar o novo código linha por linha: ```solidity - require(to != address(this), "Can't send tokens to the contract address"); + require(to != address(this), "Não é possível enviar tokens para o endereço do contrato"); ``` -Este é o primeiro requisito, verificar se `to` e `this(address)` não são a mesma coisa. +Este é o primeiro requisito, verificar que `to` e `this(address)` não são a mesma coisa. ```solidity bool isToContract; @@ -111,53 +113,53 @@ Este é o primeiro requisito, verificar se `to` e `this(address)` não são a me } ``` -É assim que verificamos se um endereço é um contrato. Não podemos receber saídas diretamente do Yul, então, em vez disso, definimos uma variável para manter o resultado (`isToContract` neste caso). A maneira como o Yul trabalha é considerando cada opcode como uma função. Então, primeiro chamamos [`EXTCODESIZE`](https://www.evm.codes/#3b) para obter o tamanho do contrato e, em seguida, usamos [`GT`](https://www.evm.codes/#11) para verificar se não é zero (estamos lidando com inteiros sem sinal, então claro que ele não pode ser negativo). Então, escrevemos o resultado em `isToContract`. +É assim que verificamos se um endereço é um contrato. Não podemos receber saídas diretamente do Yul, então, em vez disso, definimos uma variável para manter o resultado (`isToContract` neste caso). A maneira como o Yul funciona é que cada opcode é considerado uma função. Então, primeiro chamamos o [`EXTCODESIZE`](https://www.evm.codes/#3b) para obter o tamanho do contrato e, em seguida, usamos o [`GT`](https://www.evm.codes/#11) para verificar se não é zero (estamos lidando com inteiros sem sinal, então, claro, ele não pode ser negativo). Em seguida, escrevemos o resultado em `isToContract`. ```solidity - require(to.balance != 0 || isToContract, "Can't send tokens to an empty address"); + require(to.balance != 0 || isToContract, "Não é possível enviar tokens para um endereço vazio"); ``` -Por fim, temos a verificação real de endereços vazios. +E, finalmente, temos a verificação real para endereços vazios. ## Acesso administrativo {#admin-access} -Algumas vezes é útil ter um administrador que pode desfazer erros. Para reduzir o potencial de abuso, esse administrador pode ser um [multisig](https://blog.logrocket.com/security-choices-multi-signature-wallets/) para que várias pessoas tenham que concordar com uma ação. Neste artigo, teremos dois recursos administrativos: +Às vezes, é útil ter um administrador que possa desfazer erros. Para reduzir o potencial de abuso, este administrador pode ser uma [multisig](https://blog.logrocket.com/security-choices-multi-signature-wallets/) para que várias pessoas tenham que concordar com uma ação. Neste artigo, teremos dois recursos administrativos: -1. Congelar e descongelar contas. Isto pode ser útil, por exemplo, quando uma conta for comprometida. +1. Congelar e descongelar contas. Isso pode ser útil, por exemplo, quando uma conta pode ser comprometida. 2. Limpeza de ativos. - Às vezes, fraudadores enviam tokens fraudulentos para o contrato do token real para ganhar legitimidade. Por exemplo, [veja aqui](https://optimistic.etherscan.io/token/0x2348b1a1228ddcd2db668c3d30207c3e1852fbbe?a=0x4200000000000000000000000000000000000042). O contrato ERC-20 legítimo é [0x4200....0042](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000042). A fraude que finge ser o contrato é [0x234....bbe](https://optimistic.etherscan.io/address/0x2348b1a1228ddcd2db668c3d30207c3e1852fbbe). + Às vezes, fraudadores enviam tokens fraudulentos para o contrato do token real para ganhar legitimidade. Por exemplo, [veja aqui](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe?tab=holders). O contrato ERC-20 legítimo é [0x4200....0042](https://optimism.blockscout.com/token/0x4200000000000000000000000000000000000042). O golpe que finge ser ele é [0x234....bbe](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe). - Também é possível que pessoas enviem tokens ERC-20 legítimos para nosso contrato por erro, que é outra razão para querer ter uma maneira de tirá-los de lá. + Também é possível que as pessoas enviem tokens ERC-20 legítimos para nosso contrato por engano, que é outra razão para querer ter uma maneira de retirá-los. -OpenZeppelin fornece dois mecanismos para habilitar acesso administrativo: +O OpenZeppelin fornece dois mecanismos para habilitar o acesso administrativo: -- [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) contratos tem um único priprietário. Funções que tem o [modifier](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `onlyOwner` só podem ser chamadas por este proprietário. Os proprietários podem transferir a propriedade para outra pessoa ou renunciar a ela completamente. Os direitos de todas as outras contas são geralmente idênticas. -- Os contratos [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) têm [controle de acesso baseado em função (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control). +- Contratos [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) têm um único proprietário. Funções que têm o [modificador](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `onlyOwner` só podem ser chamadas por esse proprietário. Os proprietários podem transferir a propriedade para outra pessoa ou renunciá-la completamente. Os direitos de todas as outras contas são normalmente idênticos. +- Contratos [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) têm [controle de acesso baseado em função (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control). -Por simplicidade, neste artigo usamos `Ownable`. +Por uma questão de simplicidade, neste artigo usamos o `Ownable`. ### Congelando e descongelando contratos {#freezing-and-thawing-contracts} Congelar e descongelar contratos requer várias mudanças: -- Um [mapeamento](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) de endereços em [booleanos](https://en.wikipedia.org/wiki/Boolean_data_type) para manter o controle de quais endereços estão congelados. Todos os valores são inicialmente zero, o que, para valores booleanos, é interpretado como falso. Isto é o que queremos porque, por padrão, as contas não são congeladas. +- Um [mapeamento](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) de endereços para [booleanos](https://en.wikipedia.org/wiki/Boolean_data_type) para rastrear quais endereços estão congelados. Todos os valores são inicialmente zero, o que para valores booleanos é interpretado como falso. É isso que queremos, porque, por padrão, as contas não são congeladas. ```solidity mapping(address => bool) public frozenAccounts; ``` -- [Eventos](https://www.tutorialspoint.com/solidity/solidity_events.htm) para informar qualquer pessoa interessada, quando uma conta é congelada ou descongelada. Tecnicamente falando, os eventos não são necessários para essas ações, mas ajuda o código fora da cadeia a ser capaz de ouvir esses eventos e saber o que está acontecendo. É considerado uma boa conduta para um contrato inteligente emiti-los quando acontece algo que pode ser relevante para outra pessoa. +- [Eventos](https://www.tutorialspoint.com/solidity/solidity_events.htm) para informar a qualquer pessoa interessada quando uma conta é congelada ou descongelada. Tecnicamente falando, eventos não são necessários para essas ações, mas ajuda o código off-chain a ser capaz de escutar esses eventos e saber o que está acontecendo. É considerado uma boa prática que um contrato inteligente os emita quando algo que possa ser relevante para outra pessoa acontecer. - Os eventos são indexados, então, será possível pesquisar todas as vezes que uma conta foi congelada ou descongelada. + Os eventos são indexados, portanto, será possível pesquisar todas as vezes que uma conta foi congelada ou descongelada. ```solidity - // When accounts are frozen or unfrozen + // Quando as contas são congeladas ou descongeladas event AccountFrozen(address indexed _addr); event AccountThawed(address indexed _addr); ``` -- Funções para congelar e descongelar contas. Essas duas funções são praticamente idênticas, por isso, analisaremos apenas a função de congelamento. +- Funções para congelar e descongelar contas. Essas duas funções são quase idênticas, então analisaremos apenas a função de congelamento. ```solidity function freezeAccount(address addr) @@ -165,27 +167,27 @@ Congelar e descongelar contratos requer várias mudanças: onlyOwner ``` - As funções marcadas como [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm) podem ser chamadas a partir de outros contratos inteligentes ou diretamente por uma transação. + Funções marcadas como [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm) podem ser chamadas de outros contratos inteligentes ou diretamente por uma transação. ```solidity { - require(!frozenAccounts[addr], "Account already frozen"); + require(!frozenAccounts[addr], "Conta já congelada"); frozenAccounts[addr] = true; emit AccountFrozen(addr); } // freezeAccount ``` - Se a conta já estiver congelada, reverta-a. Caso contrário, congele-a e envie um evento `emit`. + Se a conta já estiver congelada, a transação será revertida. Caso contrário, congele-a e emita um evento com `emit`. -- Mude o `_beforeTokenTransfer` para evitar que o dinheiro seja movido de uma conta congelada. Note que o dinheiro ainda pode ser transferido para a conta congelada. +- Altere o `_beforeTokenTransfer` para impedir que o dinheiro seja movido de uma conta congelada. Observe que o dinheiro ainda pode ser transferido para a conta congelada. ```solidity - require(!frozenAccounts[from], "The account is frozen"); + require(!frozenAccounts[from], "A conta está congelada"); ``` ### Limpeza de ativos {#asset-cleanup} -Para liberar os tokens ERC-20 mantidos por este contrato, precisamos chamar uma função no contrato do token ao qual eles fazem parte, [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) ou [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve). Nesse caso, não faz sentido desperdiçar gás em provisões. Vale mais a pena transferir diretamente. +Para liberar os tokens ERC-20 mantidos por este contrato, precisamos chamar uma função no contrato do token ao qual eles pertencem, seja [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) ou [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve). Não faz sentido desperdiçar gás neste caso com aprovações; é melhor transferir diretamente. ```solidity function cleanupERC20( @@ -198,7 +200,7 @@ Para liberar os tokens ERC-20 mantidos por este contrato, precisamos chamar uma IERC20 token = IERC20(erc20); ``` -Essa é a sintaxe para criar um objeto para um contrato quando recebemos o endereço. Podemos fazer isso porque temos a definição de tokens ERC20 como parte do código-fonte (veja a linha 4) e esse arquivo inclui [a definição para IERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol), a interface para um contrato OpenZeppelin ERC-20. +Essa é a sintaxe para criar um objeto para um contrato quando recebemos o endereço. Podemos fazer isso porque temos a definição para tokens ERC-20 como parte do código-fonte (consulte a linha 4), e esse arquivo inclui [a definição para IERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol), a interface para um contrato ERC-20 da OpenZeppelin. ```solidity uint balance = token.balanceOf(address(this)); @@ -206,8 +208,10 @@ Essa é a sintaxe para criar um objeto para um contrato quando recebemos o ender } ``` -Esta é uma função de limpeza, portanto, provavelmente não queremos deixar nenhum token. Em vez de obter o saldo do usuário manualmente, podemos também automatizar o processo. +Esta é uma função de limpeza, portanto, presumivelmente não queremos deixar nenhum token. Em vez de obter o saldo do usuário manually, podemos também automatizar o processo. ## Conclusão {#conclusion} -Esta não é uma solução perfeita — não há solução perfeita para o problema do “usuário que cometeu um erro”. No entanto, usar esses tipos de verificações pode, pelo menos, evitar alguns erros. A capacidade de congelar contas, embora seja perigosa, pode ser usada para limitar os danos de certos ataques ao negar ao hacker os fundos roubados. +Esta não é uma solução perfeita — não há solução perfeita para o problema do "usuário cometeu um erro". No entanto, o uso desses tipos de verificação pode, pelo menos, evitar alguns erros. A capacidade de congelar contas, embora perigosa, pode ser usada para limitar os danos de certos hacks, negando ao hacker os fundos roubados. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/pt-br/developers/tutorials/ethereum-for-web2-auth/index.md new file mode 100644 index 00000000000..1d7e3700541 --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/ethereum-for-web2-auth/index.md @@ -0,0 +1,888 @@ +--- +title: "Usando Ethereum para autenticação web2" +description: "Depois de ler este tutorial, um desenvolvedor poderá integrar o login do Ethereum (web3) com o login SAML, um padrão usado na web2 para fornecer single sign-on e outros serviços relacionados. Isso permite que o acesso aos recursos da web2 seja autenticado por meio de assinaturas do Ethereum, com os atributos do usuário provenientes de atestados." +author: Ori Pomerantz +tags: [ "web2", "autenticação", "eas" ] +skill: beginner +lang: pt-br +published: 2025-04-30 +--- + +## Introdução + +[SAML](https://www.onelogin.com/learn/saml) é um padrão usado na web2 para permitir que um [provedor de identidade (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) forneça informações do usuário para [provedores de serviço (SP)](https://en.wikipedia.org/wiki/Service_provider_\(SAML\)). + +Neste tutorial, você aprenderá como integrar assinaturas do Ethereum com SAML para permitir que os usuários usem suas carteiras Ethereum para se autenticarem em serviços da web2 que ainda não suportam o Ethereum nativamente. + +Observe que este tutorial foi escrito para dois públicos distintos: + +- Pessoas do Ethereum que entendem o Ethereum e precisam aprender sobre SAML +- Pessoas da Web2 que entendem de SAML e autenticação da web2 e precisam aprender sobre Ethereum + +Como resultado, ele conterá muito material introdutório que você já conhece. Sinta-se à vontade para pulá-lo. + +### SAML para pessoas do Ethereum + +SAML é um protocolo centralizado. Um provedor de serviço (SP) só aceita afirmações (como \"este é o meu usuário João, ele deve ter permissões para fazer A, B e C\") de um provedor de identidade (IdP) se tiver uma relação de confiança preexistente com ele, ou com a [autoridade certificadora](https://www.ssl.com/article/what-is-a-certificate-authority-ca/) que assinou o certificado daquele IdP. + +Por exemplo, o SP pode ser uma agência de viagens que presta serviços de viagens a empresas, e o IdP pode ser o site interno de uma empresa. Quando os funcionários precisam reservar uma viagem de negócios, a agência de viagens os envia para autenticação pela empresa antes de permitir que eles realmente reservem a viagem. + +![Passo a passo do processo SAML](./fig-01-saml.png) + +Esta é a forma como as três entidades, o navegador, o SP e o IdP, negociam o acesso. O SP não precisa saber nada sobre o usuário que está usando o navegador com antecedência, apenas confiar no IdP. + +### Ethereum para pessoas do SAML + +Ethereum é um sistema descentralizado. + +![Logon do Ethereum](./fig-02-eth-logon.png) + +Os usuários possuem uma chave privada (geralmente mantida em uma extensão do navegador). A partir da chave privada, você pode derivar uma chave pública e, a partir dela, um endereço de 20 bytes. Quando os usuários precisam fazer login em um sistema, eles são solicitados a assinar uma mensagem com um nonce (um valor de uso único). O servidor pode verificar se a assinatura foi criada por esse endereço. + +![Obtendo dados extras de atestados](./fig-03-eas-data.png) + +A assinatura verifica apenas o endereço do Ethereum. Para obter outros atributos do usuário, você normalmente usa [atestados](https://attest.org/). Um atestado normalmente tem estes campos: + +- **Atestador**, o endereço que fez o atestado +- **Destinatário**, o endereço ao qual o atestado se aplica +- **Dados**, os dados que estão sendo atestados, como nome, permissões, etc. +- **Esquema**, o ID do esquema usado para interpretar os dados. + +Devido à natureza descentralizada do Ethereum, qualquer usuário pode fazer atestados. A identidade do atestador é importante para identificar quais atestados consideramos confiáveis. + +## Configuração + +O primeiro passo é ter um SP SAML e um IdP SAML comunicando-se entre si. + +1. Baixe o software. O software de exemplo para este artigo está [no github](https://github.com/qbzzt/250420-saml-ethereum). Diferentes estágios são armazenados em diferentes branches, para este estágio você quer `saml-only` + + ```sh + git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only + cd 250420-saml-ethereum + pnpm install + ``` + +2. Crie chaves com certificados autoassinados. Isso significa que a chave é sua própria autoridade de certificação e precisa ser importada manualmente para o provedor de serviços. Consulte [a documentação do OpenSSL](https://docs.openssl.org/master/man1/openssl-req/) para obter mais informações. + + ```sh + mkdir keys + cd keys + openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/ + openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/ + cd .. + ``` + +3. Inicie os servidores (tanto o SP quanto o IdP) + + ```sh + pnpm start + ``` + +4. Acesse o SP na URL [http://localhost:3000/](http://localhost:3000/) e clique no botão para ser redirecionado para o IdP (porta 3001). + +5. Forneça ao IdP seu endereço de e-mail e clique em **Login no provedor de serviços**. Veja que você é redirecionado de volta para o provedor de serviços (porta 3000) e que ele o reconhece pelo seu endereço de e-mail. + +### Explicação detalhada + +Isto é o que acontece, passo a passo: + +![Logon SAML normal sem Ethereum](./fig-04-saml-no-eth.png) + +#### src/config.mts + +Este arquivo contém a configuração tanto para o Provedor de Identidade quanto para o Provedor de Serviços. Normalmente, essas duas seriam entidades diferentes, mas aqui podemos compartilhar código para simplificar. + +```typescript +const fs = await import("fs") + +const protocol="http" +``` + +Por enquanto estamos apenas testando, então não há problema em usar HTTP. + +```typescript +export const spCert = fs.readFileSync("keys/saml-sp.crt").toString() +export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString() +``` + +Leia as chaves públicas, que normalmente estão disponíveis para ambos os componentes (e são confiáveis diretamente ou assinadas por uma autoridade de certificação confiável). + +```typescript +export const spPort = 3000 +export const spHostname = "localhost" +export const spDir = "sp" + +export const idpPort = 3001 +export const idpHostname = "localhost" +export const idpDir = "idp" + +export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}` +export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}` +``` + +As URLs para ambos os componentes. + +```typescript +export const spPublicData = { +``` + +Os dados públicos para o provedor de serviços. + +```typescript + entityID: `${spUrl}/metadata`, +``` + +Por convenção, em SAML, o `entityID` é a URL onde os metadados da entidade estão disponíveis. Esses metadados correspondem aos dados públicos aqui, exceto que estão em formato XML. + +```typescript + wantAssertionsSigned: true, + authnRequestsSigned: false, + signingCert: spCert, + allowCreate: true, + assertionConsumerService: [{ + Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST', + Location: `${spUrl}/assertion`, + }] + } +``` + +A definição mais importante para nossos propósitos é o `assertionConsumerServer`. Isso significa que para afirmar algo (por exemplo, \"o usuário que lhe envia esta informação é somebody@example.com\") para o provedor de serviços, precisamos usar [HTTP POST](https://www.w3schools.com/tags/ref_httpmethods.asp) para a URL `http://localhost:3000/sp/assertion`. + +```typescript +export const idpPublicData = { + entityID: `${idpUrl}/metadata`, + signingCert: idpCert, + wantAuthnRequestsSigned: false, + singleSignOnService: [{ + Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", + Location: `${idpUrl}/login` + }], + singleLogoutService: [{ + Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", + Location: `${idpUrl}/logout` + }], + } +``` + +Os dados públicos do provedor de identidade são semelhantes. Ele especifica que, para fazer login de um usuário, você envia um POST para `http://localhost:3001/idp/login` e para fazer logout de um usuário, você envia um POST para `http://localhost:3001/idp/logout`. + +#### src/sp.mts + +Este é o código que implementa um provedor de serviços. + +```typescript +import * as config from "./config.mts" +const fs = await import("fs") +const saml = await import("samlify") +``` + +Usamos a biblioteca [`samlify`](https://www.npmjs.com/package/samlify) para implementar o SAML. + +```typescript +import * as validator from "@authenio/samlify-node-xmllint" +saml.setSchemaValidator(validator) +``` + +A biblioteca `samlify` espera ter um pacote que valide se o XML está correto, assinado com a chave pública esperada, etc. Usamos [`@authenio/samlify-node-xmllint`](https://www.npmjs.com/package/@authenio/samlify-node-xmllint) para essa finalidade. + +```typescript +const express = (await import("express")).default +const spRouter = express.Router() +const app = express() +``` + +Um [`Router`](https://expressjs.com/en/5x/api.html#router) do [`express`](https://expressjs.com/) é um "mini site" que pode ser montado dentro de um site. Nesse caso, nós o usamos para agrupar todas as definições do provedor de serviços. + +```typescript +const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString() + +const sp = saml.ServiceProvider({ + privateKey: spPrivateKey, + ...config.spPublicData +}) +``` + +A representação do próprio provedor de serviços de si mesmo são todos os dados públicos e a chave privada que ele usa para assinar informações. + +```typescript +const idp = saml.IdentityProvider(config.idpPublicData); +``` + +Os dados públicos contêm tudo o que o provedor de serviços precisa saber sobre o provedor de identidade. + +```typescript +spRouter.get(`/metadata`, + (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata()) +) +``` + +Para permitir a interoperabilidade com outros componentes SAML, os provedores de serviços e de identidade devem ter seus dados públicos (chamados de metadados) disponíveis em formato XML em `/metadata`. + +```typescript +spRouter.post(`/assertion`, +``` + +Esta é a página acessada pelo navegador para se identificar. A afirmação inclui o identificador do usuário (aqui usamos o endereço de e-mail) e pode incluir atributos adicionais. Este é o manipulador para a etapa 7 no diagrama de sequência acima. + +```typescript + async (req, res) => { + // console.log(`SAML response:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`) +``` + +Você pode usar o comando comentado para ver os dados XML fornecidos na asserção. Ele é [codificado em base64](https://en.wikipedia.org/wiki/Base64). + +```typescript + try { + const loginResponse = await sp.parseLoginResponse(idp, 'post', req); +``` + +Analise a solicitação de login do servidor de identidade. + +```typescript + res.send(` + + +

Hello ${loginResponse.extract.nameID}

+ + + `) + res.send(); +``` + +Envie uma resposta HTML, apenas para mostrar ao usuário que recebemos o login. + +```typescript + } catch (err) { + console.error('Error processing SAML response:', err); + res.status(400).send('SAML authentication failed'); + } + } +) +``` + +Informe o usuário em caso de falha. + +```typescript +spRouter.get('/login', +``` + +Crie uma solicitação de login quando o navegador tentar obter esta página. Este é o manipulador para a etapa 1 no diagrama de sequência acima. + +```typescript + async (req, res) => { + const loginRequest = await sp.createLoginRequest(idp, "post") +``` + +Obtenha as informações para postar uma solicitação de login. + +```typescript + res.send(` + + + +``` + +Esta página envia o formulário (veja abaixo) automaticamente. Dessa forma, o usuário não precisa fazer nada para ser redirecionado. Esta é a etapa 2 no diagrama de sequência acima. + +```typescript +
+``` + +Poste para `loginRequest.entityEndpoint` (a URL do ponto de extremidade do provedor de identidade). + +```typescript + +``` + +O nome da entrada é `loginRequest.type` (`SAMLRequest`). O conteúdo para esse campo é `loginRequest.context`, que é novamente XML codificado em base64. + +```typescript +
+ + + `) + } +) + +app.use(express.urlencoded({extended: true})) +``` + +[Este middleware](https://expressjs.com/en/5x/api.html#express.urlencoded) lê o corpo da [requisição HTTP](https://www.tutorialspoint.com/http/http_requests.htm). Por padrão, o express o ignora, porque a maioria das requisições não o exige. Nós precisamos dele porque o POST usa o corpo. + +```typescript +app.use(`/${config.spDir}`, spRouter) +``` + +Monte o roteador no diretório do provedor de serviços (`/sp`). + +```typescript +app.get("/", (req, res) => { + res.send(` + + + + + + `) +}) +``` + +Se um navegador tentar obter o diretório raiz, forneça a ele um link para a página de login. + +```typescript +app.listen(config.spPort, () => { + console.log(`service provider is running on http://${config.spHostname}:${config.spPort}`) +}) +``` + +Escute a `spPort` com este aplicativo express. + +#### src/idp.mts + +Este é o provedor de identidade. É muito semelhante ao provedor de serviços, as explicações abaixo são para as partes que são diferentes. + +```typescript +const xmlParser = new (await import("fast-xml-parser")).XMLParser( + { + ignoreAttributes: false, // Preserve attributes + attributeNamePrefix: "@_", // Prefix for attributes + } +) +``` + +Precisamos ler e entender a solicitação XML que recebemos do provedor de serviços. + +```typescript +const getLoginPage = requestId => ` +``` + +Esta função cria a página com o formulário enviado automaticamente que é retornado na etapa 4 do diagrama de sequência acima. + +```typescript + + + Página de login + + +

Página de login

+
+ + Endereço de e-mail: +
+ +``` + +Há dois campos que enviamos ao provedor de serviços: + +1. O `requestId` ao qual estamos respondendo. +2. O identificador do usuário (usamos o endereço de e-mail que o usuário fornece por enquanto). + +```typescript +
+ + + +const idpRouter = express.Router() + +idpRouter.post("/loginSubmitted", async (req, res) => { + const loginResponse = await idp.createLoginResponse( +``` + +Este é o manipulador para a etapa 5 no diagrama de sequência acima. [`idp.createLoginResponse`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L73-L125) cria a resposta de login. + +```typescript + sp, + { + authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport', + audience: sp.entityID, +``` + +O público é o provedor de serviços. + +```typescript + extract: { + request: { + id: req.body.requestId + } + }, +``` + +Informações extraídas da solicitação. O único parâmetro que nos interessa na solicitação é o requestId, que permite ao provedor de serviços corresponder as solicitações e suas respostas. + +```typescript + signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert } // Ensure signing +``` + +Precisamos que o `signingKey` tenha os dados para assinar a resposta. O provedor de serviços não confia em solicitações não assinadas. + +```typescript + }, + "post", + { + email: req.body.email +``` + +Este é o campo com as informações do usuário que enviamos de volta ao provedor de serviços. + +```typescript + } + ); + + res.send(` + + + + +
+ +
+ + + `) +}) +``` + +Novamente, use um formulário enviado automaticamente. Esta é a etapa 6 do diagrama de sequência acima. + +```typescript + +// Ponto de extremidade do IdP para solicitações de login +idpRouter.post(`/login`, +``` + +Este é o ponto de extremidade que recebe uma solicitação de login do provedor de serviços. Este é o manipulador da etapa 3 do diagrama de sequência acima. + +```typescript + async (req, res) => { + try { + // Workaround because I couldn't get parseLoginRequest to work. + // const loginRequest = await idp.parseLoginRequest(sp, 'post', req) + const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8')) + res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"])) +``` + +Deveríamos ser capazes de usar [`idp.parseLoginRequest`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L127-L144) para ler o ID da solicitação de autenticação. No entanto, não consegui fazê-lo funcionar e não valia a pena gastar muito tempo nisso, então eu apenas uso um [analisador de XML de propósito geral](https://www.npmjs.com/package/fast-xml-parser). A informação que precisamos é o atributo `ID` dentro da tag ``, que está no nível superior do XML. + +## Usando assinaturas do Ethereum + +Agora que podemos enviar uma identidade de usuário para o provedor de serviços, o próximo passo é obter a identidade do usuário de uma maneira confiável. O Viem nos permite apenas solicitar à carteira o endereço do usuário, mas isso significa solicitar a informação ao navegador. Nós não controlamos o navegador, então não podemos confiar automaticamente na resposta que recebemos dele. + +Em vez disso, o IdP enviará ao navegador uma string para assinar. Se a carteira no navegador assinar esta string, significa que é realmente aquele endereço (ou seja, ele conhece a chave privada que corresponde ao endereço). + +Para ver isso em ação, pare o IdP e o SP existentes e execute estes comandos: + +```sh +git checkout eth-signatures +pnpm install +pnpm start +``` + +Em seguida, acesse [o SP](http://localhost:3000) e siga as instruções. + +Note que, neste momento, não sabemos como obter o endereço de e-mail a partir do endereço do Ethereum, então, em vez disso, relatamos `@bad.email.address` para o SP. + +### Explicação detalhada + +As alterações estão nas etapas 4-5 no diagrama anterior. + +![SAML com uma assinatura do Ethereum](./fig-05-saml-w-signature.png) + +O único arquivo que alteramos foi `idp.mts`. Aqui estão as partes alteradas. + +```typescript +import { v4 as uuidv4 } from 'uuid' +import { verifyMessage } from 'viem' +``` + +Precisamos dessas duas bibliotecas adicionais. Usamos [`uuid`](https://www.npmjs.com/package/uuid) para criar o valor [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). O valor em si não importa, apenas o fato de ser usado uma única vez. + +A biblioteca [`viem`](https://viem.sh/) nos permite usar definições do Ethereum. Aqui precisamos dela para verificar se a assinatura é realmente válida. + +```typescript +const loginPrompt = "Para acessar o provedor de serviços, assine este nonce: " +``` + +A carteira pede permissão ao usuário para assinar a mensagem. Uma mensagem que é apenas um nonce pode confundir os usuários, por isso incluímos esta solicitação. + +```typescript +// Manter requestIDs aqui +let nonces = {} +``` + +Precisamos das informações da solicitação para poder respondê-la. Poderíamos enviá-lo com a solicitação (etapa 4) e recebê-lo de volta (etapa 5). No entanto, não podemos confiar nas informações que obtemos do navegador, que está sob o controle de um usuário potencialmente hostil. Portanto, é melhor armazená-lo aqui, com o nonce como chave. + +Observe que estamos fazendo isso aqui como uma variável para simplificar. No entanto, isso tem várias desvantagens: + +- Estamos vulneráveis a um ataque de negação de serviço. Um usuário mal-intencionado pode tentar fazer login várias vezes, enchendo nossa memória. +- Se o processo do IdP precisar ser reiniciado, perdemos os valores existentes. +- Não podemos balancear a carga entre vários processos, porque cada um teria sua própria variável. + +Em um sistema de produção, usaríamos um banco de dados e implementaríamos algum tipo de mecanismo de expiração. + +```typescript +const getSignaturePage = requestId => { + const nonce = uuidv4() + nonces[nonce] = requestId +``` + +Crie um nonce e armazene o `requestId` para uso futuro. + +```typescript + return ` + + + + + +

Por favor, assine

+ +
+ + + +` +} +``` + +O resto é apenas HTML padrão. + +```typescript +idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => { +``` + +Este é o manipulador para a etapa 5 no diagrama de sequência. + +```typescript + const requestId = nonces[req.params.nonce] + if (requestId === undefined) { + res.send("Bad nonce") + return ; + } + + nonces[req.params.nonce] = undefined +``` + +Obtenha o ID da solicitação e exclua o nonce de `nonces` para garantir que ele não possa ser reutilizado. + +```typescript + try { +``` + +Como há muitas maneiras pelas quais a assinatura pode ser inválida, envolvemos isso em um bloco `try ... catch` para capturar quaisquer erros lançados. + +```typescript + const validSignature = await verifyMessage({ + address: req.params.account, + message: `${loginPrompt}${req.params.nonce}`, + signature: req.params.signature + }) +``` + +Use [`verifyMessage`](https://viem.sh/docs/actions/public/verifyMessage#verifymessage) para implementar a etapa 5.5 no diagrama de sequência. + +```typescript + if (!validSignature) + throw("Bad signature") + } catch (err) { + res.send("Error:" + err) + return ; + } +``` + +O restante do manipulador é equivalente ao que fizemos no manipulador `/loginSubmitted` anteriormente, exceto por uma pequena alteração. + +```typescript + const loginResponse = await idp.createLoginResponse( + . + . + . + { + email: req.params.account + "@bad.email.address" + } + ); +``` + +Não temos o endereço de e-mail real (o obteremos na próxima seção), então, por enquanto, retornamos o endereço do Ethereum e o marcamos claramente como não sendo um endereço de e-mail. + +```typescript +// Ponto de extremidade do IdP para solicitações de login +idpRouter.post(`/login`, + async (req, res) => { + try { + // Solução alternativa porque não consegui fazer o parseLoginRequest funcionar. + // const loginRequest = await idp.parseLoginRequest(sp, 'post', req) + const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8')) + res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"])) +``` + +Em vez de `getLoginPage`, agora use `getSignaturePage` no manipulador da etapa 3. + +## Obtendo o endereço de e-mail + +O próximo passo é obter o endereço de e-mail, o identificador solicitado pelo provedor de serviços. Para fazer isso, usamos o [Ethereum Attestation Service (EAS)](https://attest.org/). + +A maneira mais fácil de obter atestados é usar a [API GraphQL](https://docs.attest.org/docs/developer-tools/api). Usamos esta consulta: + +``` +query GetAttestationsByRecipient { + attestations( + where: { + recipient: { equals: "${getAddress(ethAddr)}" } + schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" } + } + take: 1 + ) { + data + id + attester + } +} +``` + +Este [`schemaId`](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977) inclui apenas um endereço de e-mail. Esta consulta solicita atestados deste esquema. O sujeito do atestado é chamado de `destinatário`. É sempre um endereço do Ethereum. + +Aviso: a maneira como estamos obtendo os atestados aqui tem dois problemas de segurança. + +- Estamos indo para o ponto de extremidade da API, `https://optimism.easscan.org/graphql`, que é um componente centralizado. Podemos obter o atributo `id` e, em seguida, fazer uma pesquisa na cadeia para verificar se um atestado é real, mas o ponto de extremidade da API ainda pode censurar atestados ao não nos informar sobre eles. + + Este problema não é impossível de resolver, poderíamos executar nosso próprio ponto de extremidade GraphQL e obter os atestados dos registros da cadeia, mas isso é excessivo para nossos propósitos. + +- Nós não olhamos para a identidade do atestador. Qualquer um pode nos fornecer informações falsas. Em uma implementação do mundo real, teríamos um conjunto de atestadores confiáveis e olharíamos apenas para seus atestados. + +Para ver isso em ação, pare o IdP e o SP existentes e execute estes comandos: + +```sh +git checkout email-address +pnpm install +pnpm start +``` + +Em seguida, forneça seu endereço de e-mail. Você tem duas maneiras de fazer isso: + +- Importe uma carteira usando uma chave privada e use a chave privada de teste `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80`. + +- Adicione um atestado para seu próprio endereço de e-mail: + + 1. Navegue até [o esquema no explorador de atestados](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977). + + 2. Clique em **Atestar com Esquema**. + + 3. Insira seu endereço Ethereum como destinatário, seu endereço de e-mail como endereço de e-mail e selecione **Onchain**. Em seguida, clique em **Fazer Atestado**. + + 4. Aprove a transação na sua carteira. Você precisará de um pouco de ETH na [Blockchain da Optimism](https://app.optimism.io/bridge/deposit) para pagar pelo gás. + +De qualquer forma, depois de fazer isso, navegue até [http://localhost:3000](http://localhost:3000) e siga as instruções. Se você importou a chave privada de teste, o e-mail que você recebe é `test_addr_0@example.com`. Se você usou seu próprio endereço, deve ser o que você atestou. + +### Explicação detalhada + +![Obtendo do endereço Ethereum para o e-mail](./fig-06-saml-sig-n-email.png) + +Os novos passos são a comunicação GraphQL, passos 5.6 e 5.7. + +Novamente, aqui estão as partes alteradas de `idp.mts`. + +```typescript +import { GraphQLClient } from 'graphql-request' +import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk' +``` + +Importe as bibliotecas que precisamos. + +```typescript +const graphqlEndpointUrl = "https://optimism.easscan.org/graphql" +``` + +Existe [um endpoint separado para cada cadeia de blocos](https://docs.attest.org/docs/developer-tools/api). + +```typescript +Crie um novo cliente `GraphQLClient` que podemos usar para consultar o ponto de extremidade. +``` + +Para entendê-lo, precisamos do esquema. + +```typescript +Uma função para ir de um endereço Ethereum para um endereço de e-mail. +``` + +Esta é uma consulta GraphQL. attestations( + +```typescript +Estamos procurando por atestados. +``` + +``` + where: { + recipient: { equals: "${getAddress(ethAddr)}" } + schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" } + } +``` + +```typescript +Os atestados que queremos são aqueles em nosso esquema, onde o destinatário é `getAddress(ethAddr)`. +``` + +A função [`getAddress`](https://viem.sh/docs/utilities/getAddress#getaddress) garante que nosso endereço tenha o [checksum](https://github.com/ethereum/ercs/blob/master/ERCS/erc-55.md) correto. + +```typescript + atestações( +``` + +Isto é necessário porque GraphQL diferencia maiúsculas e minúsculas. + +```typescript +"0xBAD060A7", "0xBad060A7", and "0xbad060a7" são valores diferentes. +``` + +```typescript + take: 1 +``` + +Independentemente de quantos atestados encontrarmos, queremos apenas o primeiro. + +```typescript + ) { + data + id + attester + } + }` +``` + +Os campos que queremos receber. + +- `attester`: O endereço que enviou o atestado. Normalmente, isso é usado para decidir se confia no atestado ou não. +- `id`: O ID do atestado. Você pode usar este valor para [ler o atestado on-chain](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000021?tab=read_proxy&source_address=0x4E0275Ea5a89e7a3c1B58411379D1a0eDdc5b088#0xa3112a64) para verificar se a informação da consulta GraphQL está correta. +- `data`: Os dados do esquema (neste caso, o endereço de e-mail). + +```typescript + const queryResult = await graphqlClient.request(query) + + if (queryResult.attestations.length == 0) + return "no_address@available.is" +``` + +Se não houver atestado, retorne um valor que seja obviamente incorreto, mas que pareça válido para o provedor de serviços. + +```typescript + const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data) + return attestationDataFields[0].value.value +} +``` + +Se houver um valor, use `decodeData` para decodificar os dados. Não precisamos dos metadados que ele fornece, apenas do valor em si. + +```typescript +const loginResponse = await idp.createLoginResponse( +sp, +{ +. +. +. +}, +"post", +{ +email: await ethereumAddressToEmail(req.params.account) +} +); +``` + +```typescript +Use a nova função para obter o endereço de e-mail. +``` + +E a descentralização? Nesta configuração, os usuários não podem fingir ser alguém que não são, desde que confiemos em atestadores confiáveis para o mapeamento do endereço Ethereum para o endereço de e-mail. + +```typescript +No entanto, nosso provedor de identidade ainda é um componente centralizado. +``` + +Quem tiver a chave privada do provedor de identidade pode enviar informações falsas para o provedor de serviços. + +## Pode haver uma solução usando [computação multipartidária (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation). + +Espero escrever sobre isso em um futuro tutorial. Adoção de um padrão de logon, como assinaturas Ethereum, enfrenta um problema de ovo e galinha. Os provedores de serviços querem atrair o mercado mais amplo possível. + +Os usuários querem poder acessar serviços sem ter que se preocupar em suportar seu padrão de logon. A criação de adaptadores, como um IdP do Ethereum, pode nos ajudar a superar esse obstáculo. + +## Conclusão + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). [Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). Os usuários têm uma chave privada (normalmente mantida em uma extensão de navegador). +Criar adaptadores, como um IdP da Ethereum, pode nos ajudar a superar este obstáculo. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/pt-br/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md index 922ce204baa..cecb8e8e32f 100644 --- a/public/content/translations/pt-br/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md +++ b/public/content/translations/pt-br/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md @@ -1,60 +1,62 @@ --- -title: Introdução ao Desenvolvimento Ethereum -description: "Este é um guia para iniciantes no desenvolvimento do Ethereum. Iremos levá-lo desde a criação de um endpoint de API, para fazer uma solicitação de linha de comando, para escrever seu primeiro script web3! Não é necessário ter experiência em desenvolvimento de blockchain!" +title: "Introdução ao Desenvolvimento na Ethereum" +description: "Este é um guia para iniciantes no desenvolvimento na Ethereum. Vamos guiar você desde a criação de um ponto de extremidade de API, passando pela criação de uma solicitação de linha de comando, até a escrita de seu primeiro script web3! Não é necessária experiência em desenvolvimento de cadeia de blocos!" author: "Elan Halpern" tags: - - "javascript" - - "ethers.js" - - "nódulos" - - "consultando" - - "alchemy" + [ + "JavaScript", + "ethers.js", + "nós", + "consultando", + "Alchemy" + ] skill: beginner lang: pt-br published: 2020-10-30 -source: Médio +source: Medium sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f --- -![Logos do Ethereum e Alchemy](./ethereum-alchemy.png) +![Logos do Ethereum e da Alchemy](./ethereum-alchemy.png) -Este é um guia de iniciantes para começar com o desenvolvimento na Ethereum. Neste tutorial, usaremos a [Alchemy](https://alchemyapi.io/), a plataforma líder de desenvolvedores de blockchain, capacitando milhões de usuários em 70% dos principais aplicativos de blockchain, incluindo Maker, 0x, MyEtherWallet, Dharma e Kyber. A Alchemy nos dará acesso a um ponto de extremidade de API na cadeia do Ethereum para que possamos ler e escrever transações. +Este é um guia para iniciantes para começar o desenvolvimento na Ethereum. Para este tutorial, usaremos a [Alchemy](https://alchemyapi.io/), a plataforma líder para desenvolvedores de cadeia de blocos que atende a milhões de usuários de 70% dos principais aplicativos de cadeia de blocos, incluindo Maker, 0x, MyEtherWallet, Dharma e Kyber. A Alchemy nos dará acesso a um ponto de extremidade de API na cadeia Ethereum para que possamos ler e escrever transações. -Ajudaremos você a se inscrever na Alchemy para escrever o seu primeiro script web3! Não é necessário ter experiência em desenvolvimento de blockchain! +Vamos guiar você desde a inscrição na Alchemy até a escrita do seu primeiro script web3! Não é necessária experiência em desenvolvimento de cadeia de blocos! ## 1. Inscreva-se para obter uma conta gratuita da Alchemy {#sign-up-for-a-free-alchemy-account} -Criar uma conta em Alchemy é fácil, [inscreva-se gratuitamente aqui](https://auth.alchemyapi.io/signup). +Criar uma conta na Alchemy é fácil, [inscreva-se gratuitamente aqui](https://auth.alchemy.com/). -## 2. Criar um app Alchemy {#create-an-alchemy-app} +## 2. Crie um aplicativo da Alchemy {#create-an-alchemy-app} -Para se comunicar com a chain da Ethereum e usar os produtos da Alchemy, você precisa de uma chave de API para autenticar as suas solicitações. +Para se comunicar com a cadeia Ethereum e usar os produtos da Alchemy, você precisa de uma chave de API para autenticar suas solicitações. -Você pode [criar chaves de API a partir do painel de controle](http://dashboard.alchemyapi.io/). Para fazer uma nova chave, navegue até "Create app" como mostrado abaixo: +Você pode [criar chaves de API a partir do painel](https://dashboard.alchemy.com/). Para criar uma nova chave, navegue até "Create App", como mostrado abaixo: -Um agradecimento especial ao [_ShapeShift_](https://shapeshift.com/) _por nos permitir mostrar seu painel!_ +Agradecimentos especiais à [_ShapeShift_](https://shapeshift.com/) _por nos permitir mostrar o painel deles!_ -![Painel de controle Alchemy](./alchemy-dashboard.png) +![Painel da Alchemy](./alchemy-dashboard.png) -Preencha os detalhes em "Create app" para obter sua nova chave. Aqui você também pode ver os apps criados anteriormente, bem como os criados pela sua equipe. Pegue chaves existentes clicando em "View Key" para qualquer app. +Preencha os detalhes em "Create App" para obter sua nova chave. Você também pode ver aqui os aplicativos que criou anteriormente e os que foram feitos pela sua equipe. Obtenha chaves existentes clicando em "View Key" para qualquer aplicativo. -![Criar app com um Alchemy screenshot](./create-app.png) +![Captura de tela da criação de um aplicativo com a Alchemy](./create-app.png) -Você também pode extrair chaves de API existentes, passando o mouse sobre “Aplicativos” e selecionando uma. Você pode “Visualizar chave” aqui, bem como “Editar aplicativo” na lista de permissões de domínios específicos, ver várias ferramentas de desenvolvedor e visualizar análises. +Você também pode obter chaves de API existentes passando o mouse sobre "Apps" e selecionando uma. Você pode usar o "View Key" aqui, bem como o "Edit App" para adicionar domínios específicos à lista de permissões, ver várias ferramentas de desenvolvedor e visualizar as análises. -![Gif mostrando a um usuário como requisitar chaves API](./pull-api-keys.gif) +![Gif mostrando um usuário obtendo chaves de API](./pull-api-keys.gif) -## 3. Fazer uma requisição via Command line {#make-a-request-from-the-command-line} +## 3. Faça uma solicitação a partir da linha de comando {#make-a-request-from-the-command-line} -Interagir com a blockchain Ethereum através de Alchemy, usando JSON-RPC e curl. +Interaja com a cadeia de blocos Ethereum através da Alchemy usando JSON-RPC e curl. -Para solicitações manuais, recomendamos interagir com `JSON-RPC` via solicitações de `POST`. Simplesmente passe no header `Content-Type: application/json` e sua query como corpo do `POST` com os seguintes campos: +Para solicitações manuais, recomendamos interagir com o `JSON-RPC` por meio de solicitações `POST`. Basta passar o cabeçalho `Content-Type: application/json` e sua consulta como o corpo do `POST` com os seguintes campos: -- `jsonrpc`: Atualmente, somente a versão `2.0` do JSON-RPC é suportada. -- `method`: O método ETH API. [Veja a referência da API.](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc) -- `params`: Uma lista de parâmetros para passar ao método. -- `id`: A ID da sua solicitação. Será retornado pela resposta para que você possa manter o controle sobre qual solicitação uma resposta pertence. +- `jsonrpc`: a versão do JSON-RPC — atualmente, apenas a `2.0` é suportada. +- `method`: o método da API ETH. [Consulte a referência da API.](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc) +- `params`: uma lista de parâmetros a serem passados para o método. +- `id`: o ID da sua solicitação. Ele será retornado pela resposta para que você possa rastrear a qual solicitação uma resposta pertence. -Aqui está um exemplo que você pode executar a partir da linha de comando, para recuperar o preço atual do gás: +Aqui está um exemplo que você pode executar na linha de comando para obter o preço atual do gás: ```bash curl https://eth-mainnet.alchemyapi.io/v2/demo \ @@ -63,7 +65,7 @@ curl https://eth-mainnet.alchemyapi.io/v2/demo \ -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' ``` -_**NOTA:** Substitua [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) por sua própria chave de API `https://eth-mainnet.alchemyapi.io/v2/**sua-chave-api`._ +_**OBSERVAÇÃO:** substitua [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) pela sua própria chave de API `https://eth-mainnet.alchemyapi.io/v2/**your-api-key`._ **Resultados:** @@ -71,17 +73,17 @@ _**NOTA:** Substitua [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mai { "id": 73,"jsonrpc": "2.0","result": "0x09184e72a000" // 10000000000000 } ``` -## 4. Configure seu Cliente Web3 {#set-up-your-web3-client} +## 4. Configure seu cliente Web3 {#set-up-your-web3-client} -**Se você tem um cliente existente,** mude o URL do seu provedor de nó atual para uma URL de Alchemy com a sua chave API: `“https://eth-mainnet.alchemyapi.io/v2/your-api-key"` +**Se você já tiver um cliente,** altere o URL do provedor do nó atual para um URL da Alchemy com sua chave de API: `"https://eth-mainnet.alchemyapi.io/v2/your-api-key"` -**_NOTA:_** Os scripts abaixo precisam ser executados em um **contexto de nó** ou **salvo em um arquivo**. Não é executado na linha de comando. Se você ainda não instalou o Node ou o NPM, confira este rápido [guia de configuração para macs](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs). +**_OBSERVAÇÃO:_** os scripts abaixo precisam ser executados em um **contexto de nó** ou **salvos em um arquivo**, e não executados a partir da linha de comando. Se você ainda não tiver o Node ou o npm instalado, confira este [guia de configuração rápida para Macs](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs). -Há inúmeras [bibliotecas Web3](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries) que você pode integrar com Alchemy. No entanto, nós recomendamos usar [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), um drop-in substituto para web3.js, construída e configurada para trabalhar sem interrupções com Alchemy. Isto fornece múltiplas vantagens, tais como novas tentativas automáticas e um suporte robusto a WebSocket. +Existem inúmeras [bibliotecas Web3](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries) que você pode integrar com a Alchemy. No entanto, recomendamos o uso da [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), um substituto direto para web3.js, criado e configurado para funcionar perfeitamente com a Alchemy. Isso oferece várias vantagens, como novas tentativas automáticas e suporte robusto a WebSocket. -Para instalar AlchemyWeb3.js, **navegue até o diretório do seu projeto** e execute: +Para instalar o AlchemyWeb3.js, **navegue até o diretório do seu projeto** e execute: -**Com o Yarn:** +**Com Yarn:** ``` yarn add @alch/alchemy-web3 @@ -90,10 +92,10 @@ yarn add @alch/alchemy-web3 **Com NPM:** ``` -yarn add @alch/alchemy-web3 +npm install @alch/alchemy-web3 ``` -Para interagir com a infraestrutura dos nós de Alchemy, execute em NodeJS ou adicione isso a um arquivo JavaScript: +Para interagir com a infraestrutura de nós da Alchemy, execute no NodeJS ou adicione isto a um arquivo JavaScript: ```js const { createAlchemyWeb3 } = require("@alch/alchemy-web3") @@ -102,18 +104,18 @@ const web3 = createAlchemyWeb3( ) ``` -## 5. Escreva seu primeiro script Web3! {#write-your-first-web3-script} +## 5. Escreva seu primeiro Script Web3! {#write-your-first-web3-script} -Agora vamos colocar a mão na massa com um pouco de programação na Web3. Vamos escrever um script simples que exibe o número de bloco mais recente da Rede principal do Ethereum. +Agora, para pôr a mão na massa com um pouco de programação web3, escreveremos um script simples que imprime o número do bloco mais recente da Mainnet do Ethereum. -**1. Se você ainda não fez, no seu terminal, crie um novo diretório e cd do projeto dentro dele:** +**1. Se ainda não o fez, crie um novo diretório de projeto em seu terminal e acesse-o com o comando cd:** ``` mkdir web3-example cd web3-example ``` -**2. Instale a dependência do Alchemy web3 (ou qualquer web3) em seu projeto, se você ainda não tiver:** +**2. Instale a dependência do Alchemy web3 (ou qualquer web3) em seu projeto, caso ainda não o tenha feito:** ``` npm install @alch/alchemy-web3 @@ -121,34 +123,34 @@ npm install @alch/alchemy-web3 **3. Crie um arquivo chamado `index.js` e adicione o seguinte conteúdo:** -> Por fim, você deve substituir `demo` pela sua chave de API HTTP do Alchemy. +> Você deve, por fim, substituir `demo` por sua chave de API HTTP da Alchemy. ```js async function main() { const { createAlchemyWeb3 } = require("@alch/alchemy-web3") - const web3 = createAlchemyWeb3("https://eth- mainnet.alchemyapi.io/v2/demo") + const web3 = createAlchemyWeb3("https://eth-mainnet.alchemyapi.io/v2/demo") const blockNumber = await web3.eth.getBlockNumber() - console.log("The latest block number is " + blockNumber) + console.log("O número do bloco mais recente é " + blockNumber) } main() ``` -Não está familiarizado com programação assíncrona? Confira este [post no Medium](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c). +Não está familiarizado com programação assíncrona? Confira esta [publicação no Medium](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c). -**4. Executá-lo em seu terminal usando o nó** +\*\*4. Execute-o no seu terminal usando **node** ``` node index.js ``` -**5. Agora você deve ver a saída do último número de bloco no seu console!** +**5. Agora você deve ver o número do bloco mais recente exibido em seu console!** ``` -O último número de bloco é 11043912 +O número do bloco mais recente é 11043912 ``` -**Eba! Parabéns! Você acabou de escrever o seu primeiro script web3 usando Alchemy 🎉** +**Eba!** Parabéns! Você acabou de escrever seu primeiro script web3 usando a Alchemy 🎉\*\* -Não tem certeza do que fazer a seguir? Experimente implementar seu primeiro contrato inteligente e colocar a mão na massa com um pouco de programação Solidity em nosso [Guia de contratos inteligentes “Olá, mundo”](https://docs.alchemyapi.io/tutorials/hello-world-smart-contract), ou teste seus conhecimentos sobre painel de controle com o [Aplicativo de demonstração do painel](https://docs.alchemyapi.io/tutorials/demo-app)! +Não sabe o que fazer a seguir? Tente implantar seu primeiro contrato inteligente e se aventurar um pouco na programação em Solidity com nosso [Guia de Contrato Inteligente Hello World](https://www.alchemy.com/docs/hello-world-smart-contract), ou teste seus conhecimentos sobre o painel com o [Aplicativo de Demonstração do Painel](https://docs.alchemyapi.io/tutorials/demo-app)! -_[Cadastre-se com o Alchemy](https://auth.alchemyapi.io/signup) gratuitamente, confira [a nossa documentação](https://docs.alchemyapi.io/), e para receber as últimas notícias, siga-nos no [Twitter](https://twitter.com/AlchemyPlatform)_. +_[Inscreva-se na Alchemy gratuitamente](https://auth.alchemy.com/), confira nossa [documentação](https://www.alchemy.com/docs/) e, para receber as notícias mais recentes, siga-nos no [Twitter](https://twitter.com/AlchemyPlatform)_. diff --git a/public/content/translations/pt-br/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/pt-br/developers/tutorials/guide-to-smart-contract-security-tools/index.md index 5d23724b65e..7701dac09bc 100644 --- a/public/content/translations/pt-br/developers/tutorials/guide-to-smart-contract-security-tools/index.md +++ b/public/content/translations/pt-br/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -1,105 +1,102 @@ --- -title: Um guia para ferramentas de segurança de contratos inteligentes -description: Uma visão geral de três diferentes técnicas de análise de testes e programas +title: "Um guia para ferramentas de segurança de contratos inteligentes" +description: "Uma visão geral de três técnicas diferentes de teste e análise de programas" author: "Trailofbits" lang: pt-br -tags: - - "solidez" - - "smart contracts" - - "segurança" +tags: [ "Solidity", "smart contracts", "segurança" ] skill: intermediate published: 2020-09-07 -source: Construindo contratos seguros +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis --- -We are going to use three distinctive testing and program analysis techniques: +Usaremos três técnicas distintas de teste e análise de programas: -- **Análise estática com [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** Todos os caminhos do programa são aproximados e analisados ao mesmo tempo, por meio de diferentes apresentações de programa (por exemplo, um control-flow-graph) -- **Fuzzing com [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/).** O código é executado com uma geração pseudo-aleatória de transações. O fuzzer tentará encontrar uma sequência de transações para violar uma determinada propriedade. -- **A execução simbólica com a [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/).** Uma técnica de verificação formal, que traduz cada caminho de execução para uma fórmula matemática, na qual as restrições de cima podem ser verificadas. +- **Análise estática com [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** Todos os caminhos do programa são aproximados e analisados ao mesmo tempo, através de diferentes apresentações do programa (p. ex., gráfico de fluxo de controle) +- **Fuzzing com [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/).** O código é executado com uma geração pseudorrandômica de transações. O fuzzer tentará encontrar uma sequência de transações para violar uma determinada propriedade. +- **Execução simbólica com [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/).** Uma técnica de verificação formal, que traduz cada caminho de execução para uma fórmula matemática, sobre a qual as restrições podem ser verificadas. -Cada técnica tem vantagens e armadilhas, e será útil em [casos específicos](#determining-security-properties): +Cada técnica tem vantagens e desvantagens e será útil em [casos específicos](#determining-security-properties): -| Técnica | Ferramenta | Uso | Velocidade | Erros perdidos | Alarmes falso | -| ------------------ | ---------- | ------------------------------------ | ---------- | -------------- | ------------- | -| Análise estática | Slither | CLI & scripts | segundos | moderado | baixo | -| Fuzzing | Echidna | Propriedades da Solidity | minutos | baixo | nenhum | -| Execução simbólica | Manticore | Propriedades & scripts & da Solidity | horas | nenhum\* | nenhum | +| Técnica | Ferramenta | Uso | Velocidade | Bugs não detectados | Alarmes Falsos | +| ------------------ | ---------- | ---------------------------------- | ---------- | ------------------- | -------------- | +| Análise Estática | Slither | CLI e scripts | segundos | moderado | baixo | +| Fuzzing | Echidna | Propriedades do Solidity | minutos | baixo | nenhum | +| Execução Simbólica | Manticore | Propriedades do Solidity e scripts | horas | nenhum\* | nenhum | \* se todos os caminhos forem explorados sem tempo limite -**Slither** analisa contratos em poucos segundos, no entanto análise estática pode levar a alarmes falsos e será menos adequada para verificações complexas (e.. verificações aritméticas). Execute o Slither por meio da API para acesso com botão de comando para detectores internos ou por meio da API para verificações definidas pelo usuário. +**O Slither** analisa contratos em segundos, no entanto, a análise estática pode levar a alarmes falsos e será menos adequada para verificações complexas (p. ex., verificações aritméticas). Execute o Slither pela API para ter acesso fácil aos detectores integrados ou pela API para verificações definidas pelo usuário. -O **Echidna** precisa ser executado por vários minutos e só produzirá verdadeiros positivos. O Echidna verifica as propriedades de segurança fornecidas pelo usuário escritas em Solidity. Ele pode perder erros, pois é baseado em exploração aleatória. +**O Echidna** precisa ser executado por vários minutos e só produzirá verdadeiros positivos. O Echidna verifica as propriedades de segurança fornecidas pelo usuário, escritas em Solidity. Ele pode não encontrar bugs, pois se baseia em exploração aleatória. -O **Manticore** executa a análise com maior peso. Como o Echidna, o Manticore verifica as propriedades fornecidas pelo usuário. Será necessário mais tempo de execução, mas isso poderá comprovar a validade de uma propriedade e não relatará alarmes falsos. +**O Manticore** realiza a análise "mais pesada". Assim como o Echidna, o Manticore verifica as propriedades fornecidas pelo usuário. Ele precisará de mais tempo para ser executado, mas pode provar a validade de uma propriedade e não relatará alarmes falsos. ## Fluxo de trabalho sugerido {#suggested-workflow} -Comece com os detectores internos do Slither para garantir que nenhum bug simples esteja presente agora ou seja introduzido mais tarde. Use o Slither para verificar propriedades relacionadas a herança, dependências de variáveis e questões estruturais. À medida que a base de código cresce, use o Echidna para testar propriedades mais complexas da máquina de estado. Revisite o Slither para desenvolver verificações personalizadas de proteções indisponíveis na Solidity, como proteger contra uma função que está sendo substituída. Finalmente, use o Manticore para realizar a verificação direcionada de propriedades de segurança críticas, por exemplo, operações aritméticas. +Comece com os detectores integrados do Slither para garantir que nenhum bug simples esteja presente ou seja introduzido mais tarde. Use o Slither para verificar propriedades relacionadas à herança, dependências de variáveis e problemas estruturais. À medida que a base de código cresce, use o Echidna para testar propriedades mais complexas da máquina de estado. Revisite o Slither para desenvolver verificações personalizadas para proteções indisponíveis no Solidity, como a proteção contra a sobrescrita de uma função. Finalmente, use o Manticore para realizar a verificação direcionada de propriedades de segurança críticas, p. ex., operações aritméticas. -- Use a CLI do Slither para capturar problemas comuns +- Use a CLI do Slither para detectar problemas comuns - Use o Echidna para testar as propriedades de segurança de alto nível do seu contrato - Use o Slither para escrever verificações estáticas personalizadas - Use o Manticore quando quiser uma garantia aprofundada de propriedades de segurança críticas -**Uma nota sobre testes de unidade**. Testes de unidade são necessários para construir softwares de alta qualidade. No entanto, estas técnicas não são as mais adequadas para encontrar falhas de segurança. Normalmente, eles são usados para testar comportamentos positivos de código (ou seja, o código funciona conforme o esperado no contexto normal), enquanto as falhas de segurança tendem a residir em casos de risco que os desenvolvedores não consideraram. No nosso estudo sobre dezenas de revisões inteligentes de segurança do contrato, a [cobertura do teste de unidade não teve efeito sobre o número ou gravidade das falhas de segurança](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) que encontramos no código do nosso cliente. +**Uma nota sobre testes de unidade**. Testes de unidade são necessários para criar software de alta qualidade. No entanto, essas técnicas não são as mais adequadas para encontrar falhas de segurança. Eles são normalmente usados para testar comportamentos positivos do código (ou seja, o código funciona como esperado em um contexto normal), enquanto as falhas de segurança tendem a residir em casos extremos que os desenvolvedores não consideraram. Em nosso estudo de dezenas de revisões de segurança de contratos inteligentes, a [cobertura de testes de unidade não teve efeito sobre o número ou a gravidade das falhas de segurança](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) que encontramos no código de nossos clientes. -## Determinando propriedades de segurança {#determining-security-properties} +## Determinação de propriedades de segurança {#determining-security-properties} -Para testar e verificar efetivamente seu código, você deve identificar as áreas que precisam de atenção. Como seus recursos gastos com a segurança são limitados, é importante otimizar seus esforços para determinar o escopo das partes fracas ou de grande valor da sua base de código. A modelagem de ameaças pode ajudar nisso. Considere revisar: +Para testar e verificar seu código de forma eficaz, você deve identificar as áreas que precisam de atenção. Como seus recursos gastos em segurança são limitados, definir o escopo das partes fracas ou de alto valor de sua base de código é importante para otimizar seu esforço. A modelagem de ameaças pode ajudar. Considere analisar: -- [Avaliação de risco rápida](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (nossa abordagem preferida quando o tempo é curto) -- [Guia de modelagem de ameaças do sistema centralizado de dados](https://csrc.nist.gov/publications/detail/sp/800-154/draft) (também conhecido como NIST 800-154) -- [Modelagem de ameaças Shostack](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998) -- [STRIDE](https://wikipedia.org/wiki/STRIDE_(security)) / [DREAD](https://wikipedia.org/wiki/DREAD_(risk_assessment_model)) +- [Rapid Risk Assessments](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (nossa abordagem preferida quando o tempo é curto) +- [Guide to Data-Centric System Threat Modeling](https://csrc.nist.gov/pubs/sp/800/154/ipd) (também conhecido como NIST 800-154) +- [Shostack threat modeling](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998) +- [STRIDE](https://wikipedia.org/wiki/STRIDE_\(security\)) / [DREAD](https://wikipedia.org/wiki/DREAD_\(risk_assessment_model\)) - [PASTA](https://wikipedia.org/wiki/Threat_model#P.A.S.T.A.) -- [Uso de asserções](https://blog.regehr.org/archives/1091) +- [Use of Assertions](https://blog.regehr.org/archives/1091) ### Componentes {#components} -Saber o que você deseja verificar também ajudará a escolher a ferramenta certa. +Saber o que você quer verificar também o ajudará a selecionar a ferramenta certa. -As vastas áreas que são frequentemente relevantes para os contratos inteligentes incluem: +As áreas gerais que são frequentemente relevantes para contratos inteligentes incluem: -- **Máquina de estado.** A maioria dos contratos pode ser representada como uma máquina de estado. Recomendamos verificar que: (1) nenhum estado inválido pode ser alcançado, (2) se um estado é válido, que ele seja alcançável e (3) nenhum estado bloqueia o contrato. +- **Máquina de estado.** A maioria dos contratos pode ser representada como uma máquina de estado. Considere verificar se (1) nenhum estado inválido pode ser alcançado, (2) se um estado é válido, ele pode ser alcançado e (3) nenhum estado prende o contrato. - - Echidna e Manticore são as ferramentas para testar as especificações da máquina. + - Echidna e Manticore são as ferramentas a serem favorecidas para testar especificações de máquinas de estado. -- **Controles de acesso.** Se o seu sistema tiver usuários privilegiados (por exemplo, um proprietário, controladores, …), você deve garantir que (1) cada usuário pode executar apenas as ações autorizadas e (2) nenhum usuário pode bloquear ações de um usuário com mais privilégios. +- **Controles de acesso.** Se seu sistema tiver usuários privilegiados (p. ex., um proprietário, controladores, ...) você deve garantir que (1) cada usuário só possa realizar as ações autorizadas e (2) nenhum usuário possa bloquear ações de um usuário mais privilegiado. - - Slither, Echidna e Manticore podem verificar se há controles de acesso corretos. Por exemplo, o Slither pode verificar que apenas as funções da lista de permissões não possuem o modificador onlyOwner. O Echidna e a Manticore são úteis para um controle de acesso mais complexo, como uma autorização dada apenas se o contrato atingir um determinado estado. + - Slither, Echidna e Manticore podem verificar os controles de acesso corretos. Por exemplo, o Slither pode verificar que apenas as funções da lista de permissões não possuem o modificador onlyOwner. Echidna e Manticore são úteis para um controle de acesso mais complexo, como uma permissão concedida apenas se o contrato atingir um determinado estado. -- **Operações aritméticas.** É essencial verificar a solidez das operações aritméticas. Usar o `SafeMath` em todo lugar é um bom passo para evitar overflow/underflow, no entanto, ainda é importante considerar outras falhas aritméticas, incluindo problemas de arredondamento e falhas que atrapalham o contrato. +- **Operações aritméticas.** Verificar a solidez das operações aritméticas é fundamental. Usar o `SafeMath` em todos os lugares é um bom passo para evitar overflow/underflow, no entanto, você ainda deve considerar outras falhas aritméticas, incluindo problemas de arredondamento e falhas que prendem o contrato. - - A Manticore é a melhor escolha aqui. O Echidna pode ser utilizado se a aritmética estiver fora do escopo da solução SMT. + - O Manticore é a melhor escolha aqui. O Echidna pode ser usado se a aritmética estiver fora do escopo do solucionador SMT. -- **Exatidão da herança.** Os contratos do Solidity dependem fortemente de várias heranças. Erros como uma função de sombreamento faltando uma chamada `super` e uma ordem de linearização c3 interpretada erradamente podem ser facilmente introduzidos. +- **Correção da herança.** Contratos em Solidity dependem muito de herança múltipla. Erros como uma função de sombreamento sem uma chamada `super` e uma ordem de linearização c3 mal interpretada podem ser facilmente introduzidos. - - O Slither é a ferramenta que garante a detecção desses problemas. + - O Slither é a ferramenta para garantir a detecção desses problemas. -- **Interações externas.** Os contratos interagem entre si, e não se deve confiar em alguns contratos externos. Por exemplo, se o seu contrato depende de oráculos externos, ele permanecerá seguro se metade dos oráculos disponíveis estiverem comprometidos? +- **Interações externas.** Os contratos interagem entre si, e alguns contratos externos não devem ser confiáveis. Por exemplo, se seu contrato depende de oráculos externos, ele permanecerá seguro se metade dos oráculos disponíveis for comprometida? - - A Manticore e o Echidna são a melhor escolha para testar as interações externas com seus contratos. A Manticore possui um mecanismo integrado para o stub de contratos externos. + - Manticore e Echidna são a melhor escolha para testar interações externas com seus contratos. O Manticore tem um mecanismo integrado para criar stubs de contratos externos. -- **Conformidade padrão.** As normas do Ethereum (por exemplo, ERC20) têm um histórico de falhas em seu design. Esteja ciente das limitações da norma no qual você está construindo. - - Slither, Echidna e Manticore vão ajudar você a detectar desvios de uma determinada norma. +- **Conformidade com padrões.** Os padrões da Ethereum (p. ex., ERC20) têm um histórico de falhas em seu design. Esteja ciente das limitações do padrão sobre o qual você está construindo. + - Slither, Echidna e Manticore ajudarão você a detectar desvios de um determinado padrão. -### Folha de dicas de ferramentas {#tool-selection-cheatsheet} +### Guia rápido de seleção de ferramentas {#tool-selection-cheatsheet} -| Componentes | Ferramentas | Exemplos | -| --------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Máquina de estado | Echidna, Manticore | | -| Controle de acesso | Slither, Echidna, Manticore | [Slither exercise 2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md), [Echidna exercício 2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) | -| Operações aritméticas | Manticore, Echidna | [Echidna exercício 1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md), [Manticore exercícios 1 a 3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) | -| Exatidão da herança | Slither | [Slither exercício 1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) | -| Interações externas | Manticore, Echidna | | -| Conformidade padrão | Slither, Echidna, Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) | +| Componente | Ferramentas | Exemplos | +| ------------------------ | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Máquina de estado | Echidna, Manticore | | +| Controle de acesso | Slither, Echidna, Manticore | [Slither exercise 2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md), [Echidna exercise 2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) | +| Operações aritméticas | Manticore, Echidna | [Echidna exercise 1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md), [Manticore exercises 1 - 3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) | +| Correção da herança | Slither | [Slither exercise 1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) | +| Interações externas | Manticore, Echidna | | +| Conformidade com padrões | Slither, Echidna, Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) | -Outras áreas terão de ser verificadas dependendo dos seus objetivos, mas essas áreas gerais são um bom começo para qualquer sistema de contrato inteligente. +Outras áreas precisarão ser verificadas dependendo de seus objetivos, mas essas áreas de foco gerais são um bom começo para qualquer sistema de contrato inteligente. -Nossas auditorias públicas contêm exemplos de propriedades verificadas ou testadas. Considere a leitura das seções `Teste Automatizado e Verificação` dos seguintes relatórios para revisar as propriedades de segurança em situações reais: +Nossas auditorias públicas contêm exemplos de propriedades verificadas ou testadas. Considere ler as seções de `Teste e Verificação Automatizados` dos relatórios a seguir para analisar as propriedades de segurança do mundo real: - [0x](https://github.com/trailofbits/publications/blob/master/reviews/0x-protocol.pdf) -- [Balanceador](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf) +- [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf) diff --git a/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract-fullstack/index.md index 17aee9e6820..e817b7591ca 100644 --- a/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract-fullstack/index.md +++ b/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract-fullstack/index.md @@ -1,107 +1,110 @@ --- title: Contrato inteligente "Hello World" para iniciantes - Fullstack -description: Tutorial introdutório sobre como escrever e implementar um contrato inteligente simples no Ethereum. +description: "Tutorial introdutório sobre como escrever e implantar um contrato inteligente simples no Ethereum." author: "nstrike2" tags: - - "solidity" - - "hardhat" - - "alchemy" - - "contratos inteligentes" - - "implementação" - - "blockexplorer" - - "front-end" - - "transações" + [ + "Solidity", + "Hardhat", + "Alchemy", + "smart contracts", + "implantação", + "explorador de blocos", + "front-end", + "transações" + ] skill: beginner lang: pt-br published: 2021-10-25 --- -Este guia é para você que é iniciante em desenvolvimento de blockchain e não sabe por onde começar ou como implantar e interagir com contratos inteligentes. Nós iremos passar por criação e implantação de um contrato inteligente simples na rede de teste Goerli, usando [MetaMask](https://metamask.io), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org), e [Alchemy](https://alchemyapi.io/eth). +Este guia é para você que é iniciante em desenvolvimento de blockchain e não sabe por onde começar ou como implantar e interagir com contratos inteligentes. Vamos percorrer a criação e implantação de um contrato inteligente simples na rede de teste Goerli usando [MetaMask](https://metamask.io), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org) e [Alchemy](https://alchemy.com/eth). -Você irá precisar de uma conta Alchemy para completar este tutorial. [Registre-se para uma conta grátis](https://www.alchemy.com/). +Você precisará de uma conta Alchemy para concluir este tutorial. [Cadastre-se para obter uma conta gratuita](https://www.alchemy.com/). -E claro, se você tiver alguma dúvida em qualquer momento, não hesite em entrar no [Discord da Alchemy](https://discord.gg/gWuC7zB)! +Se você tiver dúvidas a qualquer momento, sinta-se à vontade para entrar em contato no [Discord da Alchemy](https://discord.gg/gWuC7zB)! -## Parte 1 - Criando e Implantando seu Contrato Inteligente usando Hardhat {#part-1} +## Parte 1 - Criar e implantar seu contrato inteligente usando Hardhat {#part-1} -### Conectar-se à rede Ethereum {#connect-to-the-ethereum-network} +### Conectar à rede Ethereum {#connect-to-the-ethereum-network} -Existem muitas maneiras de fazer solicitações à cadeia de Ethereum. Para simplificar, usaremos uma conta gratuita na Alchemy, uma plataforma de desenvolvedores de blockchain e API que nos permite comunicar com a cadeia Ethereum sem termos que executar nosso próprio nó. A Alchemy também possui ferramentas de desenvolvedor para monitoração e análise. Neste tutorial, vamos aproveitá-las para entender o que está acontecendo nos bastidores da implantação do nosso contrato inteligente. +Existem muitas maneiras de fazer solicitações para a cadeia Ethereum. Para simplificar, usaremos uma conta gratuita na Alchemy, uma plataforma de desenvolvedores de blockchain e API que nos permite comunicar com a cadeia Ethereum sem termos que executar nosso próprio nó. A Alchemy também possui ferramentas de desenvolvedor para monitoração e análise. Neste tutorial, vamos aproveitá-las para entender o que está acontecendo nos bastidores da implantação do nosso contrato inteligente. -### Crie o seu app e sua chave API {#create-your-app-and-api-key} +### Crie seu aplicativo e sua chave de API {#create-your-app-and-api-key} -Assim que criar uma conta na Alchemy, você poderá gerar uma chave API criando um app. Isso nos permitirá fazer solicitações na rede de teste Goerli. Se você não estiver familiarizado com redes de teste, você pode [ler o guia da Alchemy para escolher uma rede](https://docs.alchemyapi.io/guides/choosing-a-network). +Assim que criar uma conta na Alchemy, você poderá gerar uma chave de API criando um aplicativo. Isso permitirá que você faça solicitações à rede de teste Goerli. Se você não está familiarizado com redes de teste, pode [ler o guia da Alchemy para escolher uma rede](https://www.alchemy.com/docs/choosing-a-web3-network). -No painel da Alchemy, encontre o item **Apps** no menu suspenso na barra de navegação e selecione **Criar aplicativo**. +No painel da Alchemy, encontre o menu suspenso **Apps** na barra de navegação e clique em **Criar App**. -![Criar um aplicativo Hello World](./hello-world-create-app.png) +![Hello world criar aplicativo](./hello-world-create-app.png) -Dê ao seu app o nome “_Olá, Mundo_” e escreva uma breve descrição. Selecione **Staging** como o seu ambiente, e **Goerli** como a sua rede. +Dê ao seu aplicativo o nome '_Hello World_' e escreva uma breve descrição. Selecione **Staging** como seu ambiente e **Goerli** como sua rede. -![criar uma visualização do app hello world](./create-app-view-hello-world.png) +![visualização de criação de aplicativo hello world](./create-app-view-hello-world.png) _Observação: certifique-se de selecionar **Goerli**, ou este tutorial não funcionará._ -Clique em **Criar app**. Seu app aparecerá na tabela abaixo. +Clique em **Create app**. Seu aplicativo aparecerá na tabela abaixo. -### Cria uma conta Ethereum {#create-an-ethereum-account} +### Crie uma conta Ethereum {#create-an-ethereum-account} -Você precisa de uma conta Ethereum para enviar e receber transações. Nós usaremos MetaMask, a carteira virtual no navegador que permite usuários gerenciarem o endereço da sua conta Ethereum. +Você precisa de uma conta Ethereum para enviar e receber transações. Usaremos o MetaMask, uma carteira virtual no navegador que permite aos usuários gerenciar o endereço de sua conta Ethereum. -Você pode baixar e criar uma conta MetaMask gratuitamente [neste link](https://metamask.io/download). Quando você estiver criando uma conta, ou se já tiver uma conta, certifique-se de mudar para a “Rede de teste Goerli”, no canto superior direito (para que não estejamos lidando com dinheiro real). +Você pode baixar e criar uma conta MetaMask gratuitamente [aqui](https://metamask.io/download). Quando você estiver criando uma conta, ou se já tiver uma, certifique-se de mudar para a “Rede de Teste Goerli” no canto superior direito (para não lidarmos com dinheiro real). -### Etapa 4: Adicionar ether de um faucet {#step-4-add-ether-from-a-faucet} +### Etapa 4: Adicione ether de um Faucet {#step-4-add-ether-from-a-faucet} -Para implantar nosso contrato inteligente na rede de teste, precisaremos de alguns ETHs falsos. Para conseguir ETH da rede Goerli, vá para o Goerli faucet e entre o endereço da sua conta Goerli. Note that Goerli faucets can be a bit unreliable recently - see the [test networks page](/developers/docs/networks/#goerli) for a list of options to try: +Para implantar nosso contrato inteligente na rede de teste, precisaremos de um pouco de ETH falso. Para obter ETH na rede Goerli, vá a um faucet da Goerli e insira o endereço de sua conta Goerli. Observe que as faucets da Goerli podem ser um pouco instáveis recentemente - consulte a [página de redes de teste](/developers/docs/networks/#goerli) para uma lista de opções para tentar: -_Nota: devido a tráfego de rede, isto pode demorar um pouco._ +_Observação: devido ao congestionamento da rede, isso pode demorar um pouco._ +`` -### Etapa 5: Verificar seu saldo {#step-5-check-your-balance} +### Passo 5: Verifique seu saldo {#step-5-check-your-balance} -Para garantir que o ETH está na sua carteira, vamos fazer uma chamada [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando a [ferramenta de composição da Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ele mostrará a quantidade de ETH em nossa carteira. Para saber mais, confira o [Breve tutorial da Alchemy sobre como usar a ferramenta de composição](https://youtu.be/r6sjRxBZJuU). +Para verificar se o ETH está em sua carteira, vamos fazer uma solicitação [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando a [ferramenta de composição da Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ele mostrará a quantidade de ETH em nossa carteira. Para saber mais, confira o [breve tutorial da Alchemy sobre como usar a ferramenta de composição](https://youtu.be/r6sjRxBZJuU). -Insira o endereço da sua conta MetaMask e clique em **Send Request**. Você verá a resposta que se parece com o pedação de código abaixo. +Insira o endereço da sua conta MetaMask e clique em **Send Request**. Você verá uma resposta que se parece com o trecho de código abaixo. ```json { "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" } ``` -> _Nota: Este resultado é em wei, não ETH. Lembre-se de que "Wei" é a menor unidade de ether._ +> _Observação: Este resultado está em wei, não em ETH. Wei é usado como a menor denominação de ether._ Ufa! O nosso dinheiro falso está todo lá. -### Etapa 6: Dar início a nosso projeto {#step-6-initialize-our-project} +### Passo 6: Inicialize nosso projeto {#step-6-initialize-our-project} -Primeiro, precisamos criar uma pasta para o nosso projeto. Navegue para a sua linha de comando e entre o seguinte. +Primeiro, precisaremos criar uma pasta para o nosso projeto. Navegue para a sua linha de comando e insira o seguinte. ``` mkdir hello-world cd hello-world ``` -Agora que estamos dentro da pasta do nosso projeto, vamos usar o comando `npm init `para inicializar o projeto. +Agora que estamos dentro da pasta do nosso projeto, usaremos o `npm init` para inicializar o projeto. -> Se você não tem npm instalado ainda, siga [essas instruções para instalar o Node.js e o npm](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm). +> Se você ainda não tiver o npm instalado, siga [estas instruções para instalar o Node.js e o npm](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm). -Para finalidade deste tutorial, não importa como você responde às questões de inicialização. Aqui está como nós fizemos para referência: +Para a finalidade deste tutorial, não importa como você responde às perguntas de inicialização. Veja como fizemos isso para referência: ``` -package name: (hello-world) -version: (1.0.0) -description: hello world smart contract -entry point: (index.js) -test command: -git repository: -keywords: -author: -license: (ISC) +nome do pacote: (hello-world) +versão: (1.0.0) +descrição: contrato inteligente hello world +ponto de entrada: (index.js) +comando de teste: +repositório git: +palavras-chave: +autor: +licença: (ISC) -About to write to /Users/.../.../.../hello-world/package.json: +Prestes a escrever para /Users/.../.../.../hello-world/package.json: { "name": "hello-world", "version": "1.0.0", - "description": "hello world smart contract", + "description": "contrato inteligente hello world", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" @@ -111,23 +114,23 @@ About to write to /Users/.../.../.../hello-world/package.json: } ``` -Aprove o package.json e estaremos prontos para começar! +Aprove o package.json e estamos prontos! -### Passo 7: Baixar Hardhat {#step-7-download-hardhat} +### Passo 7: Baixe o Hardhat {#step-7-download-hardhat} Hardhat é um ambiente de desenvolvimento para compilar, implementar, testar e depurar seu software de Ethereum. Ele ajuda os desenvolvedores na criação de contratos inteligentes e dapps localmente antes de implantar na cadeia real. -Dentro de nosso projeto `hello-world` execute: +Dentro do nosso projeto `hello-world`, execute: ``` npm install --save-dev hardhat ``` -Para mais detalhes, confira esta página sobre as [instruções de instalação](https://hardhat.org/getting-started/#overview). +Confira esta página para mais detalhes sobre as [instruções de instalação](https://hardhat.org/getting-started/#overview). -### Etapa 8: Criar o projeto Hardhat {#step-8-create-hardhat-project} +### Passo 8: Crie um projeto Hardhat {#step-8-create-hardhat-project} -Dentro da pasta do nosso projeto `hello-world`, rode: +Dentro da pasta do nosso projeto `hello-world`, execute: ``` npx hardhat @@ -145,65 +148,65 @@ Você deve então ver uma mensagem de boas-vindas e a opção de selecionar o qu 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 -👷 Welcome to Hardhat v2.0.11 👷‍ +👷 Bem-vindo ao Hardhat v2.0.11 👷‍ -What do you want to do? … -Create a sample project -❯ Create an empty hardhat.config.js -Quit +O que você quer fazer? … +Crie um projeto de exemplo +❯ Crie um arquivo hardhat.config.js vazio +Sair ``` -Isto irá gerar um arquivo `hardhat.config.js` no projeto. Usaremos isso mais tarde neste tutorial para especificar a configuração do nosso projeto. +Isso gerará um arquivo `hardhat.config.js` no projeto. Usaremos isso mais tarde no tutorial para especificar a configuração do nosso projeto. -### Etapa 9: Adicionar as pastas do projeto {#step-9-add-project-folders} +### Passo 9: Adicione pastas de projeto {#step-9-add-project-folders} -Para manter a organização do nosso projeto, vamos criar duas novas pastas. No comando de linha, navegue para o diretório raiz do nosso projeto `hello-world` e digite: +Para manter o projeto organizado, vamos criar duas novas pastas. Na linha de comando, navegue para o diretório raiz do seu projeto `hello-world` e digite: ``` mkdir contracts mkdir scripts ``` -- `contracts/` é onde nós vamos manter o arquivo de código do contrato inteligente "hello world" -- `scripts/` é onde nós vamos manter scripts para implantar e interagir com nosso contrato +- `contracts/` é onde manteremos nosso arquivo de código do contrato inteligente hello world +- `scripts/` é onde manteremos os scripts para implantar e interagir com nosso contrato -### Etapa 10: Escrever nosso contrato {#step-10-write-our-contract} +### Passo 10: Escreva nosso contrato {#step-10-write-our-contract} -Você pode estar se perguntando, quando é que nós vamos escrever código? Está na hora! +Você pode estar se perguntando: quando vamos escrever código? Está na hora! -Abra o projeto hello-world no seu editor favorito. Contratos inteligentes são mais comumente escritos em Solidity, o que nós usaremos para escrever o nosso contrato inteligente. +Abra o projeto hello-world no seu editor favorito. Contratos inteligentes são mais comumente escritos em Solidity, que usaremos para escrever nosso contrato inteligente.‌ 1. Navegue para a pasta `contracts` e crie um novo arquivo chamado `HelloWorld.sol` -2. Veja abaixo uma amostra de contrato inteligente “Hello World”, que usaremos neste tutorial. Copie o conteúdo abaixo no arquivo `HelloWorld.sol`. +2. Abaixo está um exemplo de contrato inteligente "Hello World" que usaremos neste tutorial. Copie o conteúdo abaixo no arquivo `HelloWorld.sol`. -_Nota: Certifique-se de ler os comentários para entender o que o contrato faz._ +_Observação: certifique-se de ler os comentários para entender o que este contrato faz._ ``` -// Especifica a versão do Solidity usando a versão semântica. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// Especifica a versão do Solidity, usando versionamento semântico. +// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity >=0.7.3; -// Defines a contract named `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. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// Define um contrato chamado `HelloWorld`. +// Um contrato é uma coleção de funções e dados (seu estado). Depois de 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 { - //Emitted when update function is called - //Smart contract events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. + //Emitido quando a função de atualização é chamada + //Os eventos de contratos inteligentes são uma forma de o seu contrato comunicar que algo aconteceu na blockchain para o front-end do seu aplicativo, que pode estar 'ouvindo' certos eventos e agir quando eles acontecem. event UpdatedMessages(string oldStr, string newStr); - // Declares a state variable `message` of type `string`. - // Variáveis de estado são variáveis cujos valores são permanentemente armazenados no armazenamento do contrato. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. + // Declara uma variável de estado `message` do tipo `string`. + // As variáveis de estado são variáveis cujos valores são permanentemente armazenados no armazenamento do contrato. A palavra-chave `public` torna as variáveis acessíveis de fora de um contrato e cria uma função que outros contratos ou clientes podem chamar para acessar o valor. string public message; - // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation. - // Os construtores são usados para inicializar os dados do contrato. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // Semelhante a muitas linguagens orientadas a objetos baseadas em classes, um construtor é uma função especial que só é executada na 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.html#constructors constructor(string memory initMessage) { - // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable). + // Aceita um argumento de string `initMessage` e define o valor na variável de armazenamento `message` do contrato. message = initMessage; } - // A public function that accepts a string argument and updates the `message` storage variable. + // 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 { string memory oldMsg = message; message = newMessage; @@ -212,15 +215,15 @@ contract HelloWorld { } ``` -Este é um contrato inteligente básico que armazena uma mensagem quando da sua criação. Ele pode ser atualizado chamando-se a função `update`. +Este é um contrato inteligente básico que armazena uma mensagem quando da sua criação. Ele pode ser atualizado chamando a função `update`. -### Etapa 11: Vincular as contas MetaMask e Alchemy a seu projeto {#step-11-connect-metamask-alchemy-to-your-project} +### Passo 11: Conecte o MetaMask e o Alchemy ao seu projeto {#step-11-connect-metamask-alchemy-to-your-project} -Nós já criamos uma carteira Metamask, uma conta Alchemy e já escrevemos nosso contrato inteligente. Agora é hora de vincularmos os três. +Nós criamos uma carteira MetaMask, uma conta da Alchemy e escrevemos nosso contrato inteligente. Agora é hora de conectar os três. -Toda transação enviada da sua carteira requer uma assinatura, usando sua chave privada única. Para fornecer esta permissão ao nosso programa, podemos armazenar seguramente nossa chave privada em um arquivo de ambiente. Nós armazenaremos também uma chave de API da Alchemy aqui. +Toda transação enviada da sua carteira requer uma assinatura usando sua chave privada única. Para fornecer essa permissão ao nosso programa, podemos armazenar nossa chave privada com segurança em um arquivo de ambiente. Também armazenaremos uma chave de API para o Alchemy aqui. -> Para saber mais sobre o envio de transações, confira [este tutorial](https://docs.alchemyapi.io/alchemy/tutorials/sending-transactions-using-web3-and-alchemy) sobre o envio de transações usando web3. +> Para saber mais sobre o envio de transações, confira [este tutorial](https://www.alchemy.com/docs/hello-world-smart-contract#step-11-connect-metamask--alchemy-to-your-project) sobre como enviar transações usando web3. Primeiro, instale o pacote dotenv na pasta do seu projeto: @@ -228,41 +231,41 @@ Primeiro, instale o pacote dotenv na pasta do seu projeto: npm install dotenv --save ``` -Então, crie um arquivo `.env` no diretório raiz do projeto. Adicione sua chave privada MetaMask e URL da API HTTP Alchemy a ele. +Em seguida, crie um arquivo `.env` no diretório raiz do projeto. Adicione sua chave privada do MetaMask e o URL da API HTTP da Alchemy a ele. -Seu arquivo de ambiente deve ser nomeado `.env` or ele não será reconhecido como arquivo de ambiente. +Seu arquivo de ambiente deve ser nomeado `.env`, caso contrário, não será reconhecido como um arquivo de ambiente. Não o nomeie como `process.env` ou `.env-custom` ou qualquer outra coisa. - Siga [estas instruções](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) para exportar sua chave privada -- Veja abaixo como obter o URL da API HTTP Alchemy +- Veja abaixo para obter o URL da API HTTP da Alchemy ![Passo a passo animado para obter uma chave de API Alchemy](./get-alchemy-api-key.gif) -Seu arquivo `.env` ficará assim: +Seu `.env` deve ficar assim: ``` -API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" -PRIVATE_KEY = "your-metamask-private-key" +API_URL = "https://eth-goerli.alchemyapi.io/v2/sua-chave-de-api" +PRIVATE_KEY = "sua-chave-privada-metamask" ``` -Para realmente vinculá-los a nosso código, vamos fazer referência a essas variáveis em nosso arquivo `hardhat.config.js` no passo 13. +Para realmente conectar isso ao nosso código, faremos referência a essas variáveis em nosso arquivo `hardhat.config.js` na etapa 13. ### Etapa 12: Instalar o Ethers.js {#step-12-install-ethersjs} -Ethers.js é uma biblioteca que facilita a interação e o envio de solicitações ao Ethereum ao incorporar [métodos padrões JSON-RPC](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc) a outros métodos mais amigáveis ao usuário. +Ethers.js é uma biblioteca que facilita a interação e o envio de solicitações ao Ethereum ao incorporar métodos padrões JSON-RPC a outros métodos mais amigáveis ao usuário. -O Hardhat nos permite integrar [plugins](https://hardhat.org/plugins/) para ferramentas adicionais e funcionalidade estendida. Aproveitaremos o [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) para implantar o contrato. +O Hardhat nos permite integrar [plugins](https://hardhat.org/plugins/) para ferramentas adicionais e funcionalidades estendidas. Aproveitaremos o [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) para a implantação do contrato. -No diretório do projeto, digite: +No diretório do seu projeto, digite: ```bash npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0" ``` -### Etapa 13: Atualizar hardhat.config.js {#step-13-update-hardhat-configjs} +### Passo 13: Atualize o hardhat.config.js {#step-13-update-hardhat-configjs} -Até aqui, já adicionamos diversas dependências e plugins. Agora precisamos atualizar o `hardhat.config.js` para que nosso projeto reconheça todos eles. +Adicionamos várias dependências e plugins até agora. Agora precisamos atualizar o `hardhat.config.js` para que nosso projeto saiba sobre todos eles. Atualize seu `hardhat.config.js` para ficar assim: @@ -289,9 +292,9 @@ module.exports = { } ``` -### Etapa 14: Compilar nosso contrato {#step-14-compile-our-contract} +### Passo 14: Compile nosso contrato {#step-14-compile-our-contract} -Para ter certeza de que tudo está funcionando, vamos compilar nosso contrato. A tarefa `compile` é uma das tarefas integradas do Hardhat. +Para ter certeza de que tudo está funcionando, vamos compilar nosso contrato. A tarefa `compile` é uma das tarefas incorporadas do hardhat. Na linha de comando, execute: @@ -299,21 +302,21 @@ Na linha de comando, execute: npx hardhat compile ``` -Você pode receber o aviso `SPDX license identifier not provided in source file`, mas não há necessidade de se preocupar com isso. Esperemos que tudo mais esteja bem! Se não, você sempre pode enviar uma mensagem no [discord Alchemy](https://discord.gg/u72VCg3). +Você pode receber um aviso sobre `identificador de licença SPDX não fornecido no arquivo de origem`, mas não precisa se preocupar com isso — esperamos que todo o resto esteja bem! Se não, você sempre pode enviar uma mensagem no [Discord da Alchemy](https://discord.gg/u72VCg3). -### Etapa 15: Escrever nosso script de implantação {#step-15-write-our-deploy-script} +### Passo 15: Escreva nosso script de implantação {#step-15-write-our-deploy-script} Agora que nosso contrato está escrito e nosso arquivo de configuração está pronto, é hora de escrever o script de implantação do contrato. -Navegue até a pasta `scripts/` e crie um novo arquivo chamado `deploy.js`, adicionando o seguinte conteúdo: +Navegue até a pasta `scripts/` e crie um novo arquivo chamado `deploy.js`, adicionando o seguinte conteúdo a ele: ```javascript async function main() { const HelloWorld = await ethers.getContractFactory("HelloWorld") - // Start deployment, returning a promise that resolves to a contract object + // Iniciar a implantação, retornando uma promessa que resolve para um objeto de contrato const hello_world = await HelloWorld.deploy("Hello World!") - console.log("Contract deployed to address:", hello_world.address) + console.log("Contrato implantado no endereço:", hello_world.address) } main() @@ -324,23 +327,23 @@ main() }) ``` -A Hardhat fez um trabalho incrível ao explicar o que cada uma dessas linhas de código faz em seu [Tutorial sobre contratos](https://hardhat.org/tutorial/testing-contracts.html#writing-tests). Adotamos aqui as explicações deles. +A Hardhat faz um trabalho incrível explicando o que cada uma dessas linhas de código faz em seu [tutorial de Contratos](https://hardhat.org/tutorial/testing-contracts.html#writing-tests), nós adotamos as explicações deles aqui. ```javascript const HelloWorld = await ethers.getContractFactory("HelloWorld") ``` -Uma `ContractFactory` em ethers.js é uma abstração usada para implantar novos contratos inteligentes, então, aqui, `HelloWorld` representa uma [fábrica](https://en.wikipedia.org/wiki/Factory_(object-oriented_programming)) para instâncias do nosso contrato Hello World. Quando usar o plugin `hardhat-ethers` `ContractFactory` e `Contract`, as instâncias estão conectadas ao primeiro assinante (proprietário) por padrão. +Uma `ContractFactory` no ethers.js é uma abstração usada para implantar novos contratos inteligentes, então, `HelloWorld` aqui é uma [fábrica](https://en.wikipedia.org/wiki/Factory_\(object-oriented_programming\)) para instâncias do nosso contrato "olá, mundo". Ao usar o plugin `hardhat-ethers` `ContractFactory` e `Contract`, as instâncias são conectadas ao primeiro signatário (proprietário) por padrão. ```javascript const hello_world = await HelloWorld.deploy() ``` -Chamar `deploy()` em uma `ContractFactory`, irá iniciar a implantação, e retornará uma `Promise` que se resolve em um objeto `Contract`. Este é o objeto que tem um método para cada uma de nossas funções de contrato inteligente. +Chamar `deploy()` em uma `ContractFactory` iniciará a implantação e retornará uma `Promise` que resolve para um objeto `Contract`. Este é o objeto que tem um método para cada uma de nossas funções de contrato inteligente. ### Etapa 16: Implantar nosso contrato {#step-16-deploy-our-contract} -Finalmente estamos prontos para implantar o nosso contrato inteligente! Navegue até a linha de comando e digite: +Finalmente estamos prontos para implantar o nosso contrato inteligente! Navegue até a linha de comando e execute: ```bash npx hardhat run scripts/deploy.js --network goerli @@ -349,36 +352,36 @@ npx hardhat run scripts/deploy.js --network goerli Você deverá ver algo assim: ```bash -Contract deployed to address: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 +Contrato implantado no endereço: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 ``` -**Por favor, grave este endereço**. Nós o usaremos mais tarde neste tutorial. +**Por favor, salve este endereço**. Nós o usaremos mais tarde neste tutorial. -Se formos ao [etherscan da Goerli](https://goerli.etherscan.io) e procurarmos nosso endereço de contrato, devemos ser capazes de ver que ele foi implantado com sucesso. A transação ficará parecida com isto: +Se formos ao [etherscan da Goerli](https://goerli.etherscan.io) e procurarmos o endereço do nosso contrato, devemos conseguir ver que ele foi implantado com sucesso. A transação ficará parecida com isto: ![](./etherscan-contract.png) -O endereço `From` deve combinar com o endereço da sua conta MetaMask, e o endereço `To` conterá **Contract Creation**. Se clicarmos na transação, veremos o nosso endereço de contrato no campo `To`. +O endereço `From` deve corresponder ao endereço da sua conta MetaMask e o endereço `To` dirá **Criação de Contrato**. Se clicarmos na transação, veremos o nosso endereço de contrato no campo `To`. ![](./etherscan-transaction.png) Parabéns! Você acaba de implantar um contrato inteligente em uma rede de teste Ethereum. -Para entender o que está acontecendo nos bastidores, vamos navegar até a guia Explorer no [painel do Alchemy](https://dashboard.alchemyapi.io/explorer). Se você tem vários aplicativos Alchemy, certifique-se de filtrar por app e selecionar **Hello World**. +Para entender o que está acontecendo nos bastidores, vamos navegar até a guia Explorer no nosso [painel da Alchemy](https://dashboard.alchemy.com/explorer). Se você tem vários aplicativos Alchemy, certifique-se de filtrar por aplicativo e selecionar **Hello World**. ![](./hello-world-explorer.png) -Aqui você verá um punhado de métodos JSON-RPC que Hardhat/Ethers fizeram em segundo plano para nós quando chamamos a função `.deploy() `. Dois importantes métodos aqui são [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction), que é a requisição para escrever nosso contrato na cadeia Goerli, e [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash) que é uma requisição para ler informações sobre nossa transação, dado o hash. Para saber mais sobre o envio de transações, confira [este tutorial sobre o envio de transações usando web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/). +Aqui você verá alguns métodos JSON-RPC que Hardhat/Ethers fizeram nos bastidores para nós quando chamamos a função `.deploy()`. Dois métodos importantes aqui são [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction), que é a solicitação para escrever nosso contrato na cadeia Goerli, e [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash), que é uma solicitação para ler informações sobre nossa transação a partir do hash. Para saber mais sobre como enviar transações, confira [nosso tutorial sobre como enviar transações usando Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/). -## Parte 2: Interaja com o seu Contrato Inteligente {#part-2-interact-with-your-smart-contract} +## Parte 2: Interaja com seu contrato inteligente {#part-2-interact-with-your-smart-contract} -Agora que você implantou com sucesso um contrato inteligente na rede Goerli, vamos aprender como interagir com ele. +Agora que implantamos com sucesso um contrato inteligente na rede Goerli, vamos aprender como interagir com ele. ### Crie um arquivo interact.js {#create-a-interactjs-file} -Este é o arquivo onde nós iremos escrever nosso script de interação. Nós usaremos a biblioteca Ether.js que você instalou anteriormente na Parte1. +Este é o arquivo onde escreveremos nosso script de interação. Usaremos a biblioteca Ethers.js que você instalou anteriormente na Parte 1. -Dentro da pasta `scripts/` crie um novo arquivo chamado `interact.js`, adicionando o seguinte código: +Dentro da pasta `scripts/`, crie um novo arquivo chamado `interact.js` e adicione o seguinte código: ```javascript // interact.js @@ -390,65 +393,65 @@ const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS ### Atualize seu arquivo .env {#update-your-env-file} -Nós usaremos novas variáveis de ambiente, portanto nós precisamos defini-las no arquivo `.env` que [ nós criamos antes](#step-11-connect-metamask-&-alchemy-to-your-project). +Usaremos novas variáveis de ambiente, então precisamos defini-las no arquivo `.env` que [criamos anteriormente](#step-11-connect-metamask-&-alchemy-to-your-project). -Nós precisaremos adicionar uma definição para a nossa `API_KEY` Alchemy e o `CONTRACT_ADDRESS` onde o nosso contrato inteligente foi implantado. +Precisaremos adicionar uma definição para a nossa `API_KEY` da Alchemy e o `CONTRACT_ADDRESS` onde nosso contrato inteligente foi implantado. -Seu arquivo `.env` deverá se parecer com isto: +Seu arquivo `.env` deve ter a seguinte aparência: ```bash # .env -API_URL = "https://eth-goerli.alchemyapi.io/v2/" -API_KEY = "" -PRIVATE_KEY = "" -CONTRACT_ADDRESS = "0x" +API_URL = "https://eth-goerli.alchemyapi.io/v2/" +API_KEY = "" +PRIVATE_KEY = "" +CONTRACT_ADDRESS = "0x" ``` -### Pegue a ABI do seu contrato {#grab-your-contract-ABI} +### Obtenha a ABI do seu contrato {#grab-your-contract-ABI} -O [ABI (Interface binária da aplicação)](/glossary/#abi) do nosso contrato é a interface para interagir com o nosso contrato inteligente. O Hardhat automaticamente gera uma ABI e a salva no arquivo `HelloWorld.json`. Para usar a ABI, precisaremos analisar o conteúdo adicionando as seguintes linhas de código ao nosso arquivo `interact.js`: +A [ABI (Application Binary Interface)](/glossary/#abi) do nosso contrato é a interface para interagir com nosso contrato inteligente. O Hardhat gera automaticamente uma ABI e a salva em `HelloWorld.json`. Para usar a ABI, precisaremos analisar o conteúdo adicionando as seguintes linhas de código ao nosso arquivo `interact.js`: ```javascript // interact.js const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json") ``` -Se quiser ver a ABI, pode imprimi-la no console: +Se quiser ver a ABI, você pode imprimi-la no seu console: ```javascript console.log(JSON.stringify(contract.abi)) ``` -Para ver o seu ABI impresso no console, navegue até seu terminal e execute: +Para ver sua ABI impressa no console, navegue até seu terminal e execute: ```bash npx hardhat run scripts/interact.js ``` -### Criar uma instância do seu contrato {#create-an-instance-of-your-contract} +### Crie uma instância do seu contrato {#create-an-instance-of-your-contract} -Para interagir com o nosso contrato, precisamos criar uma instância dele em nosso código. Para fazer isso com Ether.js, nós precisaremos trabalhar com três conceitos: +Para interagir com nosso contrato, precisamos criar uma instância dele em nosso código. Para fazer isso com Ethers.js, precisaremos trabalhar com três conceitos: -1. Provedor — um nó fornecedor que lhe dá acesso de leitura e escrita ao blockchain -2. Signatário — representa uma conta Ethereum que pode assinar transações -3. Contrato — um objeto Ether.js representando um contrato específico implantado on-chain +1. Provedor - um provedor de nós que lhe dá acesso de leitura e escrita ao blockchain +2. Signatário - representa uma conta Ethereum que pode assinar transações +3. Contrato - um objeto Ethers.js representando um contrato específico implantado on-chain Usaremos a ABI do contrato da etapa anterior para criar nossa instância do contrato: ```javascript // interact.js -// Provider +// Provedor const alchemyProvider = new ethers.providers.AlchemyProvider( (network = "goerli"), API_KEY ) -// Signer +// Signatário const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider) -// Contract +// Contrato const helloWorldContract = new ethers.Contract( CONTRACT_ADDRESS, contract.abi, @@ -456,15 +459,15 @@ const helloWorldContract = new ethers.Contract( ) ``` -Aprenda mais sobre Provedores, Signatários e Contratos na [documentação ethers.js](https://docs.ethers.io/v5/). +Saiba mais sobre Provedores, Signatários e Contratos na [documentação do ethers.js](https://docs.ethers.io/v5/). -### Leia a mensagem init {#read-the-init-message} +### Leia a mensagem inicial {#read-the-init-message} -Lembra-se de quando implantamos nosso contrato com o `initMessage = "Hello world!"`? Nós vamos agora ler a mensagem armazenada no nosso contrato inteligente e imprimi-la no console. +Lembra-se quando implantamos nosso contrato com a `initMessage = "Hello world!"`? Agora vamos ler essa mensagem armazenada em nosso contrato inteligente e imprimi-la no console. -Em JavaScript, funções assíncronas são usadas quando interagindo com redes. Para aprender mais sobre funções assíncronas, [leia este artigo](https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff). +Em JavaScript, funções assíncronas são usadas ao interagir com redes. Para saber mais sobre funções assíncronas, [leia este artigo do Medium](https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff). -Use o código abaixo para chamar a função `message` no nosso contrato inteligente e ler a mensagem init: +Use o código abaixo para chamar a função `message` em nosso contrato inteligente e ler a mensagem inicial: ```javascript // interact.js @@ -473,24 +476,24 @@ Use o código abaixo para chamar a função `message` no nosso contrato intelige async function main() { const message = await helloWorldContract.message() - console.log("The message is: " + message) + console.log("A mensagem é: " + message) } main() ``` -Depois de rodar o arquivo usando `npx hardhat run scripts/interact.js` no terminal, nós devemos ver esta resposta: +Depois de executar o arquivo usando `npx hardhat run scripts/interact.js` no terminal, devemos ver esta resposta: ``` -The message is: Hello world! +A mensagem é: Hello world! ``` -Parabéns! Você acabou de ler com sucesso dados de contrato inteligente do blockchain Ethereum, continue assim! +Parabéns! Você leu com sucesso os dados do contrato inteligente da blockchain Ethereum, parabéns! ### Atualize a mensagem {#update-the-message} -Ao invés de só ler a mensagem, nós podemos também atualizar a mensagem salva no nosso contrato inteligente usando a função `update`! Muito bacana, não? +Em vez de apenas ler a mensagem, também podemos atualizar a mensagem salva em nosso contrato inteligente usando a função `update`! Muito legal, não é? -Para atualizar a mensagem, nós podemos chamar diretamente a função `update` no nosso objeto Contract instanciado: +Para atualizar a mensagem, podemos chamar diretamente a função `update` em nosso objeto de Contrato instanciado: ```javascript // interact.js @@ -499,22 +502,22 @@ Para atualizar a mensagem, nós podemos chamar diretamente a função `update` n async function main() { const message = await helloWorldContract.message() - console.log("The message is: " + message) + console.log("A mensagem é: " + message) - console.log("Updating the message...") - const tx = await helloWorldContract.update("This is the new message.") + console.log("Atualizando a mensagem...") + const tx = await helloWorldContract.update("Esta é a nova mensagem.") await tx.wait() } main() ``` -Note que na linha 11, nós fazemos uma chamada para `.wait()` no objeto da transação retornada. Isso garante que nosso script espere pela transação ser minerada no blockchain antes de sair da função. Se a chamada `.wait()` não estiver incluída, o script pode não ver o valor da `message` atualizada no contrato. +Note que na linha 11, fazemos uma chamada para `.wait()` no objeto da transação retornada. Isso garante que nosso script espere a transação ser minerada na blockchain antes de sair da função. Se a chamada `.wait()` não for incluída, o script pode não ver o valor da `message` atualizada no contrato. ### Leia a nova mensagem {#read-the-new-message} -Você deve ser capaz de repetir o [passo anterior](#read-the-init-message) para ler o valor atualizado da `message`. Pegue um momento e veja se você pode fazer as mudanças necessárias para imprimir o novo valor! +Você deve ser capaz de repetir o [passo anterior](#read-the-init-message) para ler o valor atualizado da `message`. Tire um momento para ver se você consegue fazer as alterações necessárias para imprimir esse novo valor! -Se você precisar de uma dica, aqui está o que o seu arquivo `interact.js` deve se parecer neste ponto: +Se precisar de uma dica, veja como seu arquivo `interact.js` deve se parecer neste ponto: ```javascript // interact.js @@ -525,16 +528,16 @@ const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json") -// provider - Alchemy +// provedor - Alchemy const alchemyProvider = new ethers.providers.AlchemyProvider( (network = "goerli"), API_KEY ) -// signer - you +// signatário - você const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider) -// contract instance +// instância do contrato const helloWorldContract = new ethers.Contract( CONTRACT_ADDRESS, contract.abi, @@ -543,72 +546,72 @@ const helloWorldContract = new ethers.Contract( async function main() { const message = await helloWorldContract.message() - console.log("The message is: " + message) + console.log("A mensagem é: " + message) - console.log("Updating the message...") - const tx = await helloWorldContract.update("this is the new message") + console.log("Atualizando a mensagem...") + const tx = await helloWorldContract.update("esta é a nova mensagem") await tx.wait() const newMessage = await helloWorldContract.message() - console.log("The new message is: " + newMessage) + console.log("A nova mensagem é: " + newMessage) } main() ``` -Agora apenas rode o script e você deve ser capaz de ver a mensagem antiga, o estado atualizado, e a nova mensagem impressa no seu terminal! +Agora, apenas execute o script e você deverá ver a mensagem antiga, o status de atualização e a nova mensagem impressa em seu terminal! `npx hardhat run scripts/interact.js --network goerli` ``` -The message is: Hello World! -Updating the message... -The new message is: This is the new message. +A mensagem é: Hello World! +Atualizando a mensagem... +A nova mensagem é: Esta é a nova mensagem. ``` -Enquanto estiver rodando este script, você pode perceber que o passo `Updating the message...` leva um tempo para carregar antes da nova mensagem carregar. Isto é por causa do processo de mineração; se você é curioso sobre rastrear transações enquanto elas estão sendo mineradas, visite o [Alchemy mempool](https://dashboard.alchemyapi.io/mempool) para ver o estado da transação. Se a transação for derrubada, também é útil checar o [Goerli Etherscan](https://goerli.etherscan.io) e procurar pelo hash da sua transação. +Ao executar esse script, você pode perceber que a etapa `Atualizando a mensagem...` leva um tempo para carregar antes que a nova mensagem seja carregada. Isso se deve ao processo de mineração; se você tiver curiosidade em rastrear transações enquanto elas estão sendo mineradas, visite o [mempool da Alchemy](https://dashboard.alchemyapi.io/mempool) para ver o status de uma transação. Se a transação for descartada, também é útil verificar o [Goerli Etherscan](https://goerli.etherscan.io) e pesquisar pelo hash da sua transação. -## Parte 3: Publique seu Contrato Inteligente no Etherscan {#part-3-publish-your-smart-contract-to-etherscan} +## Parte 3: Publique seu contrato inteligente no Etherscan {#part-3-publish-your-smart-contract-to-etherscan} -Você fez todo o trabalho duro dar vida ao seu contrato inteligente; agora é hora de compartilhá-lo com o mundo! +Você fez todo o trabalho duro de dar vida ao seu contrato inteligente; agora é hora de compartilhá-lo com o mundo! -Verificando seu contrato inteligente no Etherscan, qualquer um pode ver seu código-fonte e interagir com o seu contrato inteligente. Vamos começar! +Ao verificar seu contrato inteligente no Etherscan, qualquer pessoa pode visualizar seu código-fonte e interagir com seu contrato inteligente. Vamos começar! -### Passo 1: Gere a Chave API na sua conta Etherscan {#step-1-generate-an-api-key-on-your-etherscan-account} +### Passo 1: Gere uma chave de API na sua conta Etherscan {#step-1-generate-an-api-key-on-your-etherscan-account} -Uma Chave API Etherscan é necessária para verificar que você possui o contrato inteligente que você está tentando publicar. +Uma chave de API do Etherscan é necessária para verificar que você é o proprietário do contrato inteligente que está tentando publicar. -Se você não tem uma conta Etherscan ainda, [se inscreva para uma conta](https://etherscan.io/register). +Se você ainda não tem uma conta no Etherscan, [cadastre-se para obter uma](https://etherscan.io/register). -Uma vez conectado, encontre seu nome de usuário na barra de navegação, passe o mouse em cima dele, e selecione o botão **My profile**. +Depois de fazer o login, encontre seu nome de usuário na barra de navegação, passe o mouse sobre ele e selecione o botão **My profile**. -Na página do seu perfil, você deve ver uma barra de navegação lateral. Da barra de navegação lateral, selecione **API Keys**. Em seguida, pressione o botão "Add" para criar uma nova chave API, nomeie seu app **hello-world**e pressione o botão **Create New API Key**. +Na página do seu perfil, você deverá ver uma barra de navegação lateral. Na barra de navegação lateral, selecione **API Keys**. Em seguida, pressione o botão "Add" para criar uma nova chave de API, nomeie seu aplicativo **hello-world** e pressione o botão **Create New API Key**. -Sua nova chave API deve aparecer na tabela de chaves API. Copie a chave API na sua área de transferência. +Sua nova chave de API deve aparecer na tabela de chaves de API. Copie a chave de API para sua área de transferência. -Agora nós precisamos adicionar a chave API Etherscan no seu arquivo `.env`. +Em seguida, precisamos adicionar a chave de API do Etherscan ao nosso arquivo `.env`. -Depois de adicionar isso, seu arquivo `.env` deve se parecer com isso: +Depois de adicioná-la, seu arquivo `.env` deve ter a seguinte aparência: ```javascript -API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" -PUBLIC_KEY = "your-public-account-address" -PRIVATE_KEY = "your-private-account-address" -CONTRACT_ADDRESS = "your-contract-address" -ETHERSCAN_API_KEY = "your-etherscan-key" +API_URL = "https://eth-goerli.alchemyapi.io/v2/sua-chave-de-api" +PUBLIC_KEY = "seu-endereco-de-conta-publica" +PRIVATE_KEY = "seu-endereco-de-conta-privada" +CONTRACT_ADDRESS = "seu-endereco-de-contrato" +ETHERSCAN_API_KEY = "sua-chave-etherscan" ``` -### Contratos inteligentes implantados pelo Hardhat {#hardhat-deployed-smart-contracts} +### Contratos inteligentes implantados com Hardhat {#hardhat-deployed-smart-contracts} #### Instale o hardhat-etherscan {#install-hardhat-etherscan} -Publicar o seu contrato no Etherscan usando Hardhat é uma tarefa direta. Você primeiro precisa instalar o plugin `hardhat-etherscan` para começar. `hardhat-etherscan` verificará automaticamente o código-fonte do contrato inteligente e da ABI no Etherscan. Para adicionar isso, no diretório `hello-world` rode: +Publicar seu contrato no Etherscan usando o Hardhat é simples. Você precisará primeiro instalar o plugin `hardhat-etherscan` para começar. `hardhat-etherscan` verificará automaticamente o código-fonte do contrato inteligente e a ABI no Etherscan. Para adicionar isso, no diretório `hello-world`, execute: ```text npm install --save-dev @nomiclabs/hardhat-etherscan ``` -Uma vez instalado, inclua o seguinte comando no topo do seu `hardhat.config.js`, e adicione as opções de configuração Etherscan: +Uma vez instalado, inclua a seguinte declaração no topo do seu `hardhat.config.js` e adicione as opções de configuração do Etherscan: ```javascript // hardhat.config.js @@ -630,8 +633,8 @@ module.exports = { }, }, etherscan: { - // Your API key for Etherscan - // Obtain one at https://etherscan.io/ + // Sua chave de API para o Etherscan + // Obtenha uma em https://etherscan.io/ apiKey: ETHERSCAN_API_KEY, }, } @@ -639,91 +642,91 @@ module.exports = { #### Verifique seu contrato inteligente no Etherscan {#verify-your-smart-contract-on-etherscan} -Certifique-se que todos os arquivos foram salvos e todas as variáveis `.env` estão corretamente configuradas. +Certifique-se de que todos os arquivos estão salvos e todas as variáveis `.env` estão configuradas corretamente. -Rode a tarefa `verify`, passando o endereço do contrato, e a rede onde ele foi implantado: +Execute a tarefa `verify`, passando o endereço do contrato e a rede onde ele está implantado: ```text -npx hardhat verify --network goerli DEPLOYED_CONTRACT_ADDRESS 'Hello World!' +npx hardhat verify --network goerli ENDERECO_DO_CONTRATO_IMPLANTADO 'Hello World!' ``` -Certifique-se que `DEPLOYED_CONTRACT_ADDRESS` é o endereço do seu contrato inteligente implantado na rede de teste Goerli. Além disso, o argumento final (`'Hello World!'`) tem de ser o mesmo valor de string usado [durante o passo de implantação na parte 1](#write-our-deploy-script). +Certifique-se de que `DEPLOYED_CONTRACT_ADDRESS` é o endereço do seu contrato inteligente implantado na rede de teste Goerli. Além disso, o argumento final (`'Hello World!'`) deve ser o mesmo valor de string usado [durante a etapa de implantação na parte 1](#write-our-deploy-script). -Se tudo der certo, você verá a seguinte mensagem no seu terminal: +Se tudo correr bem, você verá a seguinte mensagem no seu terminal: ```text -Successfully submitted source code for contract -contracts/HelloWorld.sol:HelloWorld at 0xdeployed-contract-address -for verification on Etherscan. Waiting for verification result... +Código-fonte enviado com sucesso para o contrato +contracts/HelloWorld.sol:HelloWorld em 0xendereco-do-contrato-implantado +para verificação no Etherscan. Aguardando resultado da verificação... -Successfully verified contract HelloWorld on Etherscan. -https://goerli.etherscan.io/address/#contracts +Contrato HelloWorld verificado com sucesso no Etherscan. +https://goerli.etherscan.io/address/#contracts ``` Parabéns! O código do seu contrato inteligente está no Etherscan! -### Cheque seu contrato inteligente no Etherscan! {#check-out-your-smart-contract-on-etherscan} +### Confira seu contrato inteligente no Etherscan! {#check-out-your-smart-contract-on-etherscan} -Quando você navegar para o link fornecido no seu terminal, você deve ser capaz de ver o código do seu contrato inteligente e ABI publicados no Etherscan! +Ao navegar para o link fornecido no seu terminal, você poderá ver o código do seu contrato inteligente e a ABI publicados no Etherscan! -**Parabéns, você conseguiu, campeão! Agora qualquer um pode chamar ou escrever no seu contrato inteligente! Nós mal conseguimos esperar o que você vai construir em seguida!** +**Uhuuuu - você conseguiu, campeão! Agora qualquer pessoa pode chamar ou escrever em seu contrato inteligente! Mal podemos esperar para ver o que você construirá em seguida!** -## Parte 4 - Integrando seu contrato inteligente com o front-end {#part-4-integrating-your-smart-contract-with-the-frontend} +## Parte 4 - Integrando seu contrato inteligente com o frontend {#part-4-integrating-your-smart-contract-with-the-frontend} -No fim deste tutorial você saberá como: +Ao final deste tutorial, você saberá como: -- Conectar uma carteira MetaMask no seu dapp +- Conectar uma carteira MetaMask ao seu dapp - Ler dados do seu contrato inteligente usando a API [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) -- Assinar transações Ethereum usando MetaMask +- Assinar transações Ethereum usando o MetaMask -Para este dapp, estaremos usando [React](https://reactjs.org/) como nosso framework de front-end; entretanto, é importante notar que nós não gastaremos muito tempo explicando seus fundamentos, já que estaremos principalmente focados em trazer funcionalidade Web3 para o nosso projeto. +Para este dapp, usaremos o [React](https://react.dev/) como nosso framework de frontend; no entanto, é importante notar que não gastaremos muito tempo explicando seus fundamentos, pois estaremos focados principalmente em trazer funcionalidades da Web3 para o nosso projeto. -Como um pré-requisito, você deve ter um nível iniciante de entendimento de React. Caso contrário, recomendamos concluir o tutorial oficial [Introdução ao React](https://reactjs.org/tutorial/tutorial.html). +Como pré-requisito, você deve ter um nível de entendimento de iniciante em React. Caso contrário, recomendamos concluir o [tutorial oficial de Introdução ao React](https://react.dev/learn). -### Clonar os arquivos iniciais {#clone-the-starter-files} +### Clone os arquivos iniciais {#clone-the-starter-files} -Primeiro, vá até o [repositório GitHub hello-world-part-four](https://github.com/alchemyplatform/hello-world-part-four-tutorial) para obter os arquivos iniciais para esse projeto e clone o repositório no seu computador local. +Primeiro, vá para o [repositório GitHub hello-world-part-four](https://github.com/alchemyplatform/hello-world-part-four-tutorial) para obter os arquivos iniciais deste projeto e clone este repositório em sua máquina local. -Abra o repositório clonado localmente. Note que ele contém duas pastas: `starter-files` e `completed`. +Abra o repositório clonado localmente. Observe que ele contém duas pastas: `starter-files` e `completed`. -- `starter-files`- **nós trabalharemos neste diretório**, nós conectaremos a UI à nossa carteira Ethereum e o contrato inteligente que nós publicamos no Etherscan na [Parte 3](#part-3). -- `completed` contém o tutorial inteiro completado e deve ser somente usado como referência se você estiver empacado. +- `starter-files`- **trabalharemos neste diretório**, conectaremos a UI à sua carteira Ethereum e ao contrato inteligente que publicamos no Etherscan na [Parte 3](#part-3). +- `completed` contém todo o tutorial concluído e deve ser usado apenas como referência se você ficar preso. -Em seguida, abra sua cópia de `starter-files` no seu editor de código favorito, e então navegue na pasta `src`. +Em seguida, abra sua cópia de `starter-files` no seu editor de código favorito e navegue até a pasta `src`. -Todo o código que vamos escrever será exibido na pasta `src`. Nós estaremos editando o componente `HelloWorld.js` e os arquivos JavaScript `util/interact.js` para dar ao seu projeto funcionalidade Web3. +Todo o código que escrevermos ficará na pasta `src`. Editaremos o componente `HelloWorld.js` e os arquivos JavaScript `util/interact.js` para dar ao nosso projeto a funcionalidade da Web3. -### Cheque os arquivos iniciais {#check-out-the-starter-files} +### Confira os arquivos iniciais {#check-out-the-starter-files} -Antes de começar a codificar, vamos explorar o que nos é fornecido nos arquivos iniciais. +Antes de começarmos a codificar, vamos explorar o que nos é fornecido nos arquivos iniciais. -#### Tenha seu projeto React em execução {#get-your-react-project-running} +#### Coloque seu projeto react para funcionar {#get-your-react-project-running} Vamos começar executando o projeto React em nosso navegador. A beleza do React é que uma vez que nosso projeto esteja sendo executado no nosso navegador, qualquer alteração que salvarmos será atualizada ao vivo em nosso navegador. -Para fazer com que o projeto funcione, navegue até o diretório raiz da pasta `starter-files`, e execute`npm install` no seu terminal para instalar as dependências do projeto: +Para iniciar o projeto, navegue para o diretório raiz da pasta `starter-files` e execute `npm install` no seu terminal para instalar as dependências do projeto: ```bash cd starter-files npm install ``` -Uma vez terminada a instalação, execute `npm start` em seu terminal: +Assim que a instalação for concluída, execute `npm start` em seu terminal: ```bash npm start ``` -Ao fazê-lo, deve abrir [http://localhost:3000/](http://localhost:3000/) no seu navegador, onde você verá o front-end do nosso projeto. Ele deve consistir em um campo \ (um lugar para atualizar a mensagem armazenada no seu contrato inteligente\), um botão “Conectar Carteira”, e um botão “Atualizar”. +Isso deve abrir [http://localhost:3000/](http://localhost:3000/) no seu navegador, onde você verá o frontend do nosso projeto. Ele deve consistir em um campo (um local para atualizar a mensagem armazenada em seu contrato inteligente), um botão "Conectar Carteira" e um botão "Atualizar". -Se você tentar clicar em qualquer dos botões você notará que eles não funcionam — isso porque ainda precisamos programar a funcionalidade deles. +Se você tentar clicar em qualquer um dos botões, notará que eles não funcionam — isso ocorre porque ainda precisamos programar sua funcionalidade. #### O componente `HelloWorld.js` {#the-helloworld-js-component} -Vamos voltar à pasta `src` no nosso editor e abrir o arquivo `HelloWorld.js`. É muito importante que entendamos tudo neste arquivo, pois é o principal componente do React no qual vamos trabalhar. +Vamos voltar para a pasta `src` em nosso editor e abrir o arquivo `HelloWorld.js`. É muito importante que entendamos tudo neste arquivo, pois é o principal componente do React no qual vamos trabalhar. -No começo deste arquivo você irá notar que nós temos diversas declarações importantes que são necessárias para termos nosso projeto rodando, incluindo a biblioteca React, os hooks useEffect e UseState, alguns itens do `./util/interact.js` (nós os descreveremos em mais detalhes em breve!), e o logo Alchemy. +No topo deste arquivo, você notará que temos várias declarações de importação necessárias para fazer nosso projeto funcionar, incluindo a biblioteca React, os hooks useEffect e useState, alguns itens do `./util/interact.js` (descreveremos em mais detalhes em breve!) e o logotipo da Alchemy. ```javascript // HelloWorld.js @@ -741,56 +744,56 @@ import { import alchemylogo from "./alchemylogo.svg" ``` -Em seguida, temos nossas variáveis de estado que serão atualizadas após eventos específicos. +Em seguida, temos nossas variáveis de estado que atualizaremos após eventos específicos. ```javascript // HelloWorld.js -//State variables +//Variáveis de estado const [walletAddress, setWallet] = useState("") const [status, setStatus] = useState("") -const [message, setMessage] = useState("No connection to the network.") +const [message, setMessage] = useState("Sem conexão com a rede.") const [newMessage, setNewMessage] = useState("") ``` Veja aqui o que cada uma das variáveis representa: - `walletAddress` - uma string que armazena o endereço da carteira do usuário -- `status` uma string que armazena uma mensagem útil que guia o usuário em como interagir com o dapp +- `status`- uma string que armazena uma mensagem útil que guia o usuário sobre como interagir com o dapp - `message` - uma string que armazena a mensagem atual no contrato inteligente -- `newMessage` -uma string que armazena a nova mensagem que será escrita no contrato inteligente +- `newMessage` - uma string que armazena a nova mensagem que será escrita no contrato inteligente -Depois das variáveis de estado, você verá cinco funções não implementadas: `useEffect` ,`addSmartContractListener`, `addWalletListener` , `connectWalletPressed`, e `onUpdatePressed`. Nós explicaremos o que elas fazem abaixo: +Após as variáveis de estado, você verá cinco funções não implementadas: `useEffect` ,`addSmartContractListener`, `addWalletListener` , `connectWalletPressed` e `onUpdatePressed`. Explicaremos o que elas fazem abaixo: ```javascript // HelloWorld.js -//called only once +//chamado apenas uma vez useEffect(async () => { - //TODO: implement + //TODO: implementar }, []) function addSmartContractListener() { - //TODO: implement + //TODO: implementar } function addWalletListener() { - //TODO: implement + //TODO: implementar } const connectWalletPressed = async () => { - //TODO: implement + //TODO: implementar } const onUpdatePressed = async () => { - //TODO: implement + //TODO: implementar } ``` -- [`useEffect`](https://reactjs.org/docs/hooks-effect.html)- isto é um hook React hook que é chamado depois que o seu componente é renderizado. Por ele ter um array vazio `[]` prop passada por ele \(veja linha 4\), ele só será chamado na _primeira_ renderização do componente. Aqui nós vamos carregar a mensagem atual armazenada no nosso contrato inteligente, chamar nosso contrato inteligente e listeners da carteira, e atualizar nos UI para refletir se a carteira já está conectada. -- `addSmartContractListener`- esta função configura um listener que irá aguardar o evento `UpdatedMessages` do nosso contrato HelloWorld e atualizar nossa UI quando a mensagem é alterada em nosso contrato inteligente. -- `addWalletListener`- esta função configura um listener que detecta mudanças no estado da carteira MetaMask do usuário, como quando o usuário desconecta sua carteira ou muda endereços. -- `connectWalletPressed`- esta função será chamada para conectar a carteira MetaMask do usuário no nosso dapp. +- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html)- este é um hook do React que é chamado após a renderização do seu componente. Como ele tem um prop de array vazio `[]` passado para ele (veja a linha 4), ele só será chamado na _primeira_ renderização do componente. Aqui, carregaremos a mensagem atual armazenada em nosso contrato inteligente, chamaremos nossos ouvintes de contrato inteligente e de carteira e atualizaremos nossa interface do usuário para refletir se uma carteira já está conectada. +- `addSmartContractListener` - esta função configura um ouvinte que observará o evento `UpdatedMessages` do nosso contrato HelloWorld e atualizará nossa interface do usuário quando a mensagem for alterada em nosso contrato inteligente. +- `addWalletListener` - esta função configura um ouvinte que detecta alterações no estado da carteira MetaMask do usuário, como quando o usuário desconecta sua carteira ou troca de endereços. +- `connectWalletPressed`- esta função será chamada para conectar a carteira MetaMask do usuário ao nosso dapp. - `onUpdatePressed` - essa função será chamada quando o usuário quiser atualizar a mensagem armazenada no contrato inteligente. Perto do final desse arquivo, temos a interface de usuário do nosso componente. @@ -798,64 +801,65 @@ Perto do final desse arquivo, temos a interface de usuário do nosso componente. ```javascript // HelloWorld.js -//the UI of our component +//a UI do nosso componente return (
-

Current Message:

+

Mensagem Atual:

{message}

-

New Message:

+

Nova Mensagem:

setNewMessage(e.target.value)} value={newMessage} />

{status}

-
-
+ + + ) ``` -Se você procurar com cuidado no código, você notará quando nós usamos nossas várias variáveis de estado na nossa UI: +Se você examinar este código com atenção, notará onde usamos nossas várias variáveis de estado em nossa interface do usuário: -- Nas linhas 6 a 12, se a carteira do usuário estiver conectada \(ou seja. `walletAddress.length > 0`\), mostraremos uma versão truncada da `walletAddress` do usuário no botão com a ID "walletButton;", caso contrário, ele simplesmente dirá "Connect Wallet." -- Na linha 17, nós mostramos a mensagem atual armazenada no contrato inteligente, que é capturada na string `message`. -- Nas linhas 23-26, nós usamos um [componente controlado](https://reactjs.org/docs/forms.html#controlled-components) para atualizar nossa variável de estado `newMessage` quando a entrada no campo texto muda. +- Nas linhas 6-12, se a carteira do usuário estiver conectada (ou seja, `walletAddress.length > 0`), exibimos uma versão truncada do `walletAddress` do usuário no botão com o ID "walletButton;" caso contrário, ele simplesmente diz "Conectar Carteira". +- Na linha 17, exibimos a mensagem atual armazenada no contrato inteligente, que é capturada na string `message`. +- Nas linhas 23-26, usamos um [componente controlado](https://legacy.reactjs.org/docs/forms.html#controlled-components) para atualizar nossa variável de estado `newMessage` quando a entrada no campo de texto muda. -Em adição às nossas variáveis de estado, você também verá que as funções `connectWalletPressed` e `onUpdatePressed` são chamadas quando os botões com IDs `publishButton` e `walletButton` são respectivamente clicados. +Além de nossas variáveis de estado, você também verá que as funções `connectWalletPressed` e `onUpdatePressed` são chamadas quando os botões com os IDs `publishButton` e `walletButton` são clicados, respectivamente. -Finalmente, vamos endereçar onde esse componente `HelloWorld.js` será adicionado. +Finalmente, vamos abordar onde este componente `HelloWorld.js` é adicionado. -Se você for ao arquivo `App.js`, que é o componente principal do React, que atua como um contêiner para todos os outros componentes, você verá que o nosso componente `HelloWorld.js` é injetado na linha 7. +Se você for ao arquivo `App.js`, que é o componente principal do React que atua como um contêiner para todos os outros componentes, você verá que nosso componente `HelloWorld.js` é injetado na linha 7. -Finalmente, mas não menos importante, vamos checar mais um arquivo fornecido para você, o arquivo `interact.js`. +Por último, mas não menos importante, vamos conferir mais um arquivo fornecido a você, o arquivo `interact.js`. #### O arquivo `interact.js` {#the-interact-js-file} -Como queremos respeitar o paradigma [M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), queremos um arquivo separado que contém todas as nossas funções para gerenciar a lógica, dados e regras do nosso dapp, para então conseguirmos exportar essas funções para o nosso front-end \(nosso componente `HelloWorld.js` component\). +Como queremos seguir o paradigma [M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), queremos um arquivo separado que contenha todas as nossas funções para gerenciar a lógica, os dados e as regras do nosso dapp e, em seguida, exportar essas funções para o nosso frontend (nosso componente `HelloWorld.js`). -👆🏽Esta é a exata finalidade do nosso arquivo `interact.js`! +👆🏽Este é o propósito exato do nosso arquivo `interact.js`! -Navegue para a pasta `util` no seu diretório `src`, e você notará que nós incluimos um arquivo chamado `interact.js` que irá conter todas as nossas interações com o contrato inteligente, funções de carteira, e variáveis. +Navegue até a pasta `util` em seu diretório `src` e você notará que incluímos um arquivo chamado `interact.js` que conterá todas as nossas funções e variáveis de interação com o contrato inteligente e a carteira. ```javascript // interact.js @@ -871,55 +875,55 @@ const getCurrentWalletConnected = async () => {} export const updateMessage = async (message) => {} ``` -Você pode notar no topo do arquivo que nós transformamos o objeto `helloWorldContract` em um comentário. Mais tarde neste tutorial nós vamos descomentar este objeto e instanciar nosso contrato inteligente nesta variável, que irá então exportar no nosso componente `HelloWorld.js`. +Você notará no topo do arquivo que comentamos o objeto `helloWorldContract`. Mais tarde neste tutorial, descomentaremos este objeto e instanciaremos nosso contrato inteligente nesta variável, que então exportaremos para nosso componente `HelloWorld.js`. -As quatro funções não implementadas depois do nosso objeto `helloWorldContract` fazem o seguinte: +As quatro funções não implementadas após nosso objeto `helloWorldContract` fazem o seguinte: -- `loadCurrentMessage`: esta função manipula a lógica de carregamento da mensagem atual armazenada no contrato inteligente. Ela fará uma chamada _read_ para o contrato inteligente Olá, Mundo usando a [API Web3 da Alchemy](https://github.com/alchemyplatform/alchemy-web3). -- `connectWallet`: essa função conectará a MetaMask do usuário ao nosso dapp. -- `getCurrentWalletConnected` - essa função irá checar se uma conta Ethereum já está conectada no nosso dapp no carregamento da página e atualização da nossa UI devidamente. -- `updateMessage` - esta função atualizará a mensagem armazenada no contrato inteligente. Ela fará uma chamada _write_ para o contrato inteligente Hello World, para que a carteira do usuário MetaMask tenha que assinar uma transação Ethereum para atualizar a mensagem. +- `loadCurrentMessage` - esta função lida com a lógica de carregar a mensagem atual armazenada no contrato inteligente. Ela fará uma chamada de _leitura_ para o contrato inteligente Hello World usando a [API Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3). +- `connectWallet` - esta função conectará a MetaMask do usuário ao nosso dapp. +- `getCurrentWalletConnected` - esta função verificará se uma conta Ethereum já está conectada ao nosso dapp ao carregar a página e atualizará nossa interface do usuário de acordo. +- `updateMessage` - esta função atualizará a mensagem armazenada no contrato inteligente. Ela fará uma chamada de _escrita_ para o contrato inteligente Hello World, então a carteira MetaMask do usuário terá que assinar uma transação Ethereum para atualizar a mensagem. -Agora que você entende no que estamos trabalhando, vamos entender como ler do nosso contrato inteligente! +Agora que entendemos com o que estamos trabalhando, vamos descobrir como ler do nosso contrato inteligente! -### Passo 3: Leia do seu Contrato Inteligente {#step-3-read-from-your-smart-contract} +### Passo 3: Leia do seu contrato inteligente {#step-3-read-from-your-smart-contract} -Para ler do seu contrato inteligente, você irá precisar configurar com sucesso: +Para ler do seu contrato inteligente, você precisará configurar com sucesso: -- Uma conexão API com a cadeia Ethereum -- Uma instância carregada para o seu contrato inteligente -- Uma função para chamar para a sua função de contrato inteligente -- Um ouvinte para observar as atualizações quando os dados de contrato inteligente que você está lendo mudem +- Uma conexão de API com a cadeia Ethereum +- Uma instância carregada do seu contrato inteligente +- Uma função para chamar a função do seu contrato inteligente +- Um ouvinte para observar as atualizações quando os dados que você está lendo do contrato inteligente mudarem -Isto pode parecer que são muitos passos, mas não se preocupe! Nós vamos acompanhá-lo como fazer cada um deles passo a passo! :\) +Isso pode parecer muitos passos, mas não se preocupe! Vamos guiá-lo passo a passo sobre como fazer cada um deles! :\) -#### Estabeleça uma conexão API com a cadeia Ethereum {#establish-an-api-connection-to-the-ethereum-chain} +#### Estabeleça uma conexão de API com a cadeia Ethereum {#establish-an-api-connection-to-the-ethereum-chain} -Você se lembra como na Parte 2 deste tutorial usamos a nossa chave [Alchemy Web3 para ler do nosso contrato inteligente](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)? Você também irá precisar de uma chave Alchemy Web3 em seu dapp para ler da cadeia. +Então, lembra como na Parte 2 deste tutorial, usamos nossa [chave Web3 da Alchemy para ler do nosso contrato inteligente](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)? Você também precisará de uma chave Web3 da Alchemy em seu dapp para ler da cadeia. -Se você ainda não tem, primeiro instale [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navegando até o diretório raiz do seu `starter-files` e executando o seguinte em seu terminal: +Se você ainda não tiver, primeiro instale o [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navegando até o diretório raiz dos seus `starter-files` e executando o seguinte no seu terminal: ```text -yarn add @alch/alchemy-web3 +npm install @alch/alchemy-web3 ``` -[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) é um invólucro em torno do [Web3.js](https://docs.web3js.org/), fornecendo métodos aprimorados da API e outros benefícios cruciais para tornar a sua vida de desenvolvedor da Web3 mais fácil. Ele foi projetado para exigir uma configuração mínima, para que você possa começar a usá-la no seu aplicativo imediatamente! +O [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) é um wrapper em torno do [Web3.js](https://docs.web3js.org/), fornecendo métodos de API aprimorados e outros benefícios cruciais para facilitar sua vida como desenvolvedor web3. Ele foi projetado para exigir uma configuração mínima, para que você possa começar a usá-la no seu aplicativo imediatamente! -Então, instale o pacote [dotenv](https://www.npmjs.com/package/dotenv) no seu diretório do projeto, para termos um lugar seguro para armazenar nossa chave API depois de pegarmos ela. +Em seguida, instale o pacote [dotenv](https://www.npmjs.com/package/dotenv) no diretório do seu projeto, para termos um local seguro para armazenar nossa chave de API depois de buscá-la. ```text npm install dotenv --save ``` -Para o nosso dapp, **nós usaremos nossa chave API Websockets** ao invés de nossa chave API HTTP, já que nos garante configurar um listener que detecta quando a mensagem, armazenada no contrato inteligente, muda. +Para nosso dapp, **usaremos nossa chave de API Websockets** em vez da nossa chave de API HTTP, pois ela nos permitirá configurar um ouvinte que detecta quando a mensagem armazenada no contrato inteligente muda. -Uma vez que você tem a chave API, crie um arquivo `.env` no seu diretório raiz e adicione sua url Alchemy Websockets a ele. Depois disso, seu arquivo `.env` deve se parecer com isso: +Depois de ter sua chave de API, crie um arquivo `.env` no seu diretório raiz e adicione sua URL de Websockets da Alchemy a ele. Depois disso, seu arquivo `.env` deve ter a seguinte aparência: ```javascript -REACT_APP_ALCHEMY_KEY = wss://eth-goerli.ws.alchemyapi.io/v2/ +REACT_APP_ALCHEMY_KEY = wss://eth-goerli.ws.alchemyapi.io/v2/ ``` -Agora estamos prontos para configurar nosso ponto de extremidade Web3 da Alchemy no nosso dapp! Vamos voltar para o nosso `interact.js`, que é aninhado dentro da nossa pasta `util` e adicionar o seguinte código no topo do arquivo: +Agora, estamos prontos para configurar nosso ponto de extremidade Alchemy Web3 em nosso dapp! Vamos voltar ao nosso `interact.js`, que está aninhado dentro da nossa pasta `util`, e adicionar o seguinte código no topo do arquivo: ```javascript // interact.js @@ -932,23 +936,23 @@ const web3 = createAlchemyWeb3(alchemyKey) //export const helloWorldContract; ``` -Acima, nós primeiro importamos a chave Alchemy do nosso arquivo `.env` e então passamos nosso `alchemyKey` para `createAlchemyWeb3` estabelecer nosso endpoint Alchemy Web3. +Acima, primeiro importamos a chave da Alchemy do nosso arquivo `.env` e depois passamos nossa `alchemyKey` para `createAlchemyWeb3` para estabelecer nosso ponto de extremidade Alchemy Web3. -Com este endpoint pronto, é hora de carregar nosso contrato inteligente! +Com este ponto de extremidade pronto, é hora de carregar nosso contrato inteligente! -#### Carregando o seu contrato inteligente Hello World {#loading-your-hello-world-smart-contract} +#### Carregando seu contrato inteligente Hello World {#loading-your-hello-world-smart-contract} -Para carregar o seu contrato inteligente Hello World, você precisará do seu endereço de contrato e ABI, ambos os quais podem ser encontrados no Etherscan se você completou a [Parte 3 deste tutorial.](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan) +Para carregar seu contrato inteligente Hello World, você precisará do endereço do contrato e da ABI, ambos podem ser encontrados no Etherscan se você concluiu a [Parte 3 deste tutorial.](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan) #### Como obter a ABI do seu contrato no Etherscan {#how-to-get-your-contract-abi-from-etherscan} -Se você pulou a Parte 3 deste tutorial, você pode usar o contrato Olá, Mundo com o endereço [0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code). Sua ABI pode ser encontrada [aqui](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code). +Se você pulou a Parte 3 deste tutorial, pode usar o contrato HelloWorld com o endereço [0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code). Sua ABI pode ser encontrada [aqui](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code). -A ABI de um contrato é necessária para especificar qual função um contrato irá invocar, assim como garantir que a função irá retornar dados no formato que você está esperando. Uma vez que nós copiamos nosso contrato ABI, vamos salvá-lo como um arquivo JSON chamado `contract-abi.json` no seu diretório `src`. +A ABI de um contrato é necessária para especificar qual função um contrato invocará, bem como para garantir que a função retorne dados no formato que você espera. Depois de copiar a ABI do nosso contrato, vamos salvá-la como um arquivo JSON chamado `contract-abi.json` em seu diretório `src`. -O seu contract-abi.json deve ser armazenado na sua pasta src. +Seu contract-abi.json deve ser armazenado na sua pasta src. -Armados com nosso endereço de contrato, ABI, e endpoint Alchemy Web3, nós podemos usar o [método do contrato](https://docs.web3js.org/api/web3-eth-contract/class/Contract) para carregar uma instância do nosso contrato inteligente. Importe a ABI do seu contrato no arquivo `interact.js` e adicione o seu endereço de contrato. +Armados com o endereço do nosso contrato, ABI e o ponto de extremidade da Alchemy Web3, podemos usar o [método de contrato](https://docs.web3js.org/api/web3-eth-contract/class/Contract) para carregar uma instância do nosso contrato inteligente. Importe a ABI do seu contrato no arquivo `interact.js` e adicione o endereço do seu contrato. ```javascript // interact.js @@ -957,7 +961,7 @@ const contractABI = require("../contract-abi.json") const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A" ``` -Nós podemos agora finalmente descomentar nossa variável `helloWorldContract`, e carregar o contrato inteligente usando nosso endpoint AlchemyWeb3: +Agora podemos finalmente descomentar nossa variável `helloWorldContract` e carregar o contrato inteligente usando nosso ponto de extremidade AlchemyWeb3: ```javascript // interact.js @@ -967,7 +971,7 @@ export const helloWorldContract = new web3.eth.Contract( ) ``` -Para recapitular, as primeiras 12 linhas do seu `interact.js` deve agora se parecer com isso: +Para recapitular, as primeiras 12 linhas do seu `interact.js` devem ter a seguinte aparência: ```javascript // interact.js @@ -986,11 +990,11 @@ export const helloWorldContract = new web3.eth.Contract( ) ``` -Agora que nós temos nosso contrato carregado, nós podemos implementar nossa função `loadCurrentMessage`! +Agora que nosso contrato está carregado, podemos implementar nossa função `loadCurrentMessage`! -#### Implementando `loadCurrentMessage` no nosso arquivo `interact.js` {#implementing-loadCurrentMessage-in-your-interact-js-file} +#### Implementando `loadCurrentMessage` no seu arquivo `interact.js` {#implementing-loadCurrentMessage-in-your-interact-js-file} -Esta função é super simples. Nós vamos fazer uma simples chamada async web3 para ler do nosso contrato. Nossa função irá retornar a mensagem armazenada no contrato inteligente: +Esta função é super simples. Faremos uma chamada assíncrona simples da web3 para ler do nosso contrato. Nossa função retornará a mensagem armazenada no contrato inteligente: Atualize o `loadCurrentMessage` no seu arquivo `interact.js` para o seguinte: @@ -1003,60 +1007,60 @@ export const loadCurrentMessage = async () => { } ``` -Já que nós queremos exibir este contrato inteligente na nossa UI, vamos atualizar a função `useEffect` no nosso componente `HelloWorld.js` com o seguinte: +Como queremos exibir este contrato inteligente em nossa interface do usuário, vamos atualizar a função `useEffect` em nosso componente `HelloWorld.js` para o seguinte: ```javascript // HelloWorld.js -//called only once +//chamado apenas uma vez useEffect(async () => { const message = await loadCurrentMessage() setMessage(message) }, []) ``` -Note que nós somente queremos nosso `loadCurrentMessage` ser chamado uma vez durante a primeira renderização do componente. Logo implementaremos `addSmartContractListener` para atualizar automaticamente a interface do usuário depois que a mensagem no contrato inteligente mudar. +Observe que só queremos que nosso `loadCurrentMessage` seja chamado uma vez durante a primeira renderização do componente. Em breve, implementaremos o `addSmartContractListener` para atualizar automaticamente a interface do usuário após a alteração da mensagem no contrato inteligente. -Antes que nós mergulhemos no nosso listener, vamos checar o que nós temos até aqui! Salve seus arquivos `HelloWorld.js` e `interact.js`, e então vá para [http://localhost:3000/](http://localhost:3000/) +Antes de mergulharmos em nosso ouvinte, vamos conferir o que temos até agora! Salve seus arquivos `HelloWorld.js` e `interact.js` e vá para [http://localhost:3000/](http://localhost:3000/) -Você notará que a mensagem atual não diz mais "No connection to the network." Ao invés disso, ela reflete a mensagem armazenada no contrato inteligente. Ótimo! +Você notará que a mensagem atual não diz mais "Sem conexão com a rede". Em vez disso, ela reflete a mensagem armazenada no contrato inteligente. Incrível! -#### Sua UI poderia agora refletir a mensagem armazenada no contrato inteligente {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract} +#### Sua interface do usuário agora deve refletir a mensagem armazenada no contrato inteligente {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract} -Agora falando daquele listener... +Agora, falando daquele ouvinte... -#### Implementar `addSmartContractListener` {#implement-addsmartcontractlistener} +#### Implemente `addSmartContractListener` {#implement-addsmartcontractlistener} -Se você voltar para pensar no arquivo `HelloWorld.sol` que escrevemos na [Parte 1 desta série de tutoriais](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract), você se lembrará que há um evento de contrato inteligente chamado `UpdatedMessages` que é emitido depois da função `update` do nosso contrato inteligente ser invocada \(ver linhas 9 e 27\): +Se você se lembrar do arquivo `HelloWorld.sol` que escrevemos na [Parte 1 desta série de tutoriais](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract), lembrará que há um evento de contrato inteligente chamado `UpdatedMessages` que é emitido após a invocação da função `update` do nosso contrato inteligente (veja as linhas 9 e 27): ```javascript // HelloWorld.sol -// Specifies the version of Solidity, using semantic versioning. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// Especifica a versão do Solidity, usando versionamento semântico. +// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity ^0.7.3; -// Defines a contract named `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. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// Define um contrato chamado `HelloWorld`. +// Um contrato é uma coleção de funções e dados (seu estado). Depois de 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 { - //Emitted when update function is called - //Smart contract events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. + //Emitido quando a função de atualização é chamada + //Os eventos de contratos inteligentes são uma forma de o seu contrato comunicar que algo aconteceu na blockchain para o front-end do seu aplicativo, que pode estar 'ouvindo' certos eventos e agir quando eles acontecem. event UpdatedMessages(string oldStr, string newStr); - // Declares a state variable `message` of type `string`. - // Variáveis de estado são variáveis cujos valores são permanentemente armazenados no armazenamento do contrato. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. + // Declara uma variável de estado `message` do tipo `string`. + // As variáveis de estado são variáveis cujos valores são permanentemente armazenados no armazenamento do contrato. A palavra-chave `public` torna as variáveis acessíveis de fora de um contrato e cria uma função que outros contratos ou clientes podem chamar para acessar o valor. string public message; - // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation. - // Os construtores são usados para inicializar os dados do contrato. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // Semelhante a muitas linguagens orientadas a objetos baseadas em classes, um construtor é uma função especial que só é executada na 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.html#constructors constructor(string memory initMessage) { - // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable). + // Aceita um argumento de string `initMessage` e define o valor na variável de armazenamento `message` do contrato. message = initMessage; } - // A public function that accepts a string argument and updates the `message` storage variable. + // 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 { string memory oldMsg = message; message = newMessage; @@ -1065,11 +1069,11 @@ contract HelloWorld { } ``` -Eventos de contratos inteligentes são uma maneira do seu contrato comunicar que alguma coisa aconteceu \(ou seja, houve um _event_\) na blockchain no seu aplicativo de front-end, que pode “escutar” eventos específicos e tomar uma ação quando eles acontecem. +Eventos de contratos inteligentes são uma forma de o seu contrato comunicar que algo aconteceu (ou seja, houve um _evento_) na blockchain para seu aplicativo de front-end, que pode estar 'ouvindo' eventos específicos e tomar uma ação quando eles acontecem. -A função `addSmartContractListener` escutará especificamente o evento `UpdatedMessages` do nosso contrato inteligente Olá, Mundo e atualizar nossa interface do usuário para mostrar a nova mensagem. +A função `addSmartContractListener` irá ouvir especificamente o evento `UpdatedMessages` do nosso contrato inteligente Hello World e atualizará nossa interface do usuário para exibir a nova mensagem. -Modifique `addSmartContractListener` da seguinte maneira: +Modifique `addSmartContractListener` para o seguinte: ```javascript // HelloWorld.js @@ -1081,18 +1085,18 @@ function addSmartContractListener() { } else { setMessage(data.returnValues[1]) setNewMessage("") - setStatus("🎉 Your message has been updated!") + setStatus("🎉 Sua mensagem foi atualizada!") } }) } ``` -Vamos quebrar em partes o que acontece quando o listener detecta um evento: +Vamos detalhar o que acontece quando o ouvinte detecta um evento: -- Se um erro ocorre quando o evento é emitido, ele será refletido na UI via nossa variável de estado `status`. -- Caso contrário, nós usaremos o objeto `data` retornado. O `data.returnValues` é uma array indexada no zero onde o primeiro elemento da array armazena a mensagem anterior e o segundo elemento armazena o atualizado. Ao todo, em um evento bem-sucedido, iremos configurar nossa cadeia de caracteres `message` com a mensagem atualizada, limpar a cadeia de caracteres `newMessage` e atualizar nossa variável de estado `status` para refletir que uma nova mensagem foi publicada no nosso contrato inteligente. +- Se ocorrer um erro quando o evento for emitido, ele será refletido na interface do usuário por meio de nossa variável de estado `status`. +- Caso contrário, usaremos o objeto `data` retornado. O `data.returnValues` é um array indexado em zero onde o primeiro elemento no array armazena a mensagem anterior e o segundo elemento armazena a atualizada. No total, em um evento bem-sucedido, definiremos nossa string `message` para a mensagem atualizada, limparemos a string `newMessage` e atualizaremos nossa variável de estado `status` para refletir que uma nova mensagem foi publicada em nosso contrato inteligente. -Finalmente, vamos chamar nosso listener em nossa função `useEffect` para que seja inicializada na primeira renderização do componente `HelloWorld.js`. Tudo junto, sua função `useEffect` deve se parecer com: +Finalmente, vamos chamar nosso ouvinte em nossa função `useEffect` para que ele seja inicializado na primeira renderização do componente `HelloWorld.js`. No total, sua função `useEffect` deve ter a seguinte aparência: ```javascript // HelloWorld.js @@ -1104,43 +1108,43 @@ useEffect(async () => { }, []) ``` -Agora que nós somos capazes de ler do nosso contrato inteligente, seria ótimo descobrir como escrever nele também! Entretanto, para escrever no nosso dapp, nós precisamos primeiro uma carteira Ethereum conectada nele. +Agora que podemos ler do nosso contrato inteligente, seria ótimo descobrir como escrever nele também! No entanto, para escrever em nosso dapp, primeiro devemos ter uma carteira Ethereum conectada a ele. -Então, em seguida vamos configurar nossa carteira Ethereum \(MetaMask\) e então conectá-la ao nosso dapp! +Então, a seguir, abordaremos a configuração de nossa carteira Ethereum (MetaMask) e, em seguida, a conexão dela ao nosso dapp! -### Passo 4: Configurar sua carteira Ethereum {#step-4-set-up-your-ethereum-wallet} +### Passo 4: Configure sua carteira Ethereum {#step-4-set-up-your-ethereum-wallet} -Para escrever qualquer coisa na cadeia Ethereum, usuários devem assinar transações usando as chaves privadas das suas carteiras virtuais. Para este tutorial, usaremos o [MetaMask](https://metamask.io/), uma carteira virtual no navegador usada para gerenciar o seu endereço de conta do Ethereum, pois ele torna esta assinatura de transação superfácil para o usuário final. +Para escrever qualquer coisa na cadeia Ethereum, os usuários devem assinar transações usando as chaves privadas de suas carteiras virtuais. Para este tutorial, usaremos o [MetaMask](https://metamask.io/), uma carteira virtual no navegador usada para gerenciar o endereço da sua conta Ethereum, pois torna a assinatura de transações superfácil para o usuário final. -Se você quiser entender mais sobre como as transações no Ethereum funcionam, confira [esta página](/developers/docs/transactions/) na Fundação Ethereum. +Se quiser entender mais sobre como as transações na Ethereum funcionam, confira [esta página](/developers/docs/transactions/) da Ethereum Foundation. -#### Baixar MetaMask {#download-metamask} +#### Baixe o MetaMask {#download-metamask} -Você pode baixar e criar uma conta MetaMask gratuitamente [neste link](https://metamask.io/download). Ao criar uma conta, ou mesmo se você já tiver uma conta, certifique-se de mudar para "Goerli Test Network” na parte superior direita \(para não lidarmos com dinheiro real\). +Você pode baixar e criar uma conta MetaMask gratuitamente [aqui](https://metamask.io/download). Ao criar uma conta, ou se você já tiver uma, certifique-se de mudar para a “Rede de Teste Goerli” no canto superior direito (para não lidarmos com dinheiro real). -#### Etapa: Adicionar Faucet ether {#add-ether-from-a-faucet} +#### Adicione ether de uma Faucet {#add-ether-from-a-faucet} -Para assinar a transação no blockchain Ethereum, nós precisamos de alguns Eth falsos. Para obter Eth você pode ir em[FaucETH](https://fauceth.komputing.org) e entrar seu endereço de conta Goerli, clicar em “Request funds”, e então selecionar “Ethereum Testnet Goerli” no menu, e finalmente clicar no botão "Request funds" novamente. Em seguida, você deve ver Eth em sua conta Metamask! +Para assinar uma transação na blockchain Ethereum, precisaremos de um pouco de Eth falso. Para obter Eth, você pode ir para a [FaucETH](https://fauceth.komputing.org) e inserir o endereço da sua conta Goerli, clicar em “Solicitar fundos”, selecionar “Rede de Teste Ethereum Goerli” no menu suspenso e, finalmente, clicar no botão “Solicitar fundos” novamente. Em seguida, você deve ver Eth em sua conta MetaMask! -#### Cheque seu Saldo {#check-your-balance} +#### Verifique seu saldo {#check-your-balance} -Para verificar novamente que tem saldo, vamos fazer uma solicitação através da ferramenta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) fornecida pelo [compositor da Alchemy](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ela mostrará a quantidade de Eth na sua carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: +Para verificar novamente se nosso saldo está lá, vamos fazer uma solicitação [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando a [ferramenta de composição da Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ela mostrará a quantidade de Eth na sua carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: ```text {"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} ``` -**NOTA:** Este resultado está em wei, não em ETH. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para eth é: 1 eth = 10¹⁸ wei. Então, se convertemos 0xde0b6b3a7640000 para decimal, temos 1\*10¹⁸ wei, que é igual a 1 eth. +**OBSERVAÇÃO:** Este resultado está em wei, não em eth. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para eth é: 1 eth = 10¹⁸ wei. Então, se convertemos 0xde0b6b3a7640000 para decimal, temos 1\*10¹⁸ wei, que é igual a 1 eth. Ufa! Nosso dinheiro falso está todo lá! 🤑 -### Passo 5: Conecte o MetaMask na sua UI {#step-5-connect-metamask-to-your-UI} +### Passo 5: Conecte o MetaMask à sua interface do usuário {#step-5-connect-metamask-to-your-UI} Agora que nossa carteira MetaMask está configurada, vamos conectar nosso dapp a ela! -#### Função `connectWallet` {#the-connectWallet-function} +#### A função `connectWallet` {#the-connectWallet-function} -No nosso arquivo `interact.js`, vamos implementar a função `connectWallet`, a qual podemos então chamar no nosso componente `HelloWorld.js`. +Em nosso arquivo `interact.js`, vamos implementar a função `connectWallet`, que podemos chamar em nosso componente `HelloWorld.js`. Vamos modificar `connectWallet` para o seguinte: @@ -1154,7 +1158,7 @@ export const connectWallet = async () => { method: "eth_requestAccounts", }) const obj = { - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 Escreva uma mensagem no campo de texto acima.", address: addressArray[0], } return obj @@ -1172,8 +1176,7 @@ export const connectWallet = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + Você deve instalar o MetaMask, uma carteira virtual Ethereum, no seu navegador.

@@ -1185,24 +1188,24 @@ export const connectWallet = async () => { Então, o que esse bloco gigante de código faz exatamente? -Bem, primeiro, ele checar se a `window.ethereum` está habilitada no seu navegador. +Bem, primeiro, ele verifica se o `window.ethereum` está habilitado no seu navegador. -`window.ethereum` é uma API global injetada pela MetaMask e outros provedores de carteira que permitem que sites solicitem contas Ethereum dos usuários. Se aprovado, ele pode ler dados dos blockchains que o usuário está conectado, e sugerir que o usuário assine mensagens e transações. Confira a [documentação da MetaMask](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) para obter mais informações! +`window.ethereum` é uma API global injetada pelo MetaMask e outros provedores de carteira que permite que sites solicitem as contas Ethereum dos usuários. Se aprovado, ele pode ler dados das blockchains às quais o usuário está conectado e sugerir que o usuário assine mensagens e transações. Confira a [documentação do MetaMask](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) para mais informações! -Se `window.ethereum` _não está_ presente, então isso significa que o MetaMask não está instalado. Isso resulta em um objeto JSON sendo retornado, onde o `endereço` retornado é uma string vazia, e o `status` do objeto JSX repassa que o usuário deve instalar o MetaMask. +Se o `window.ethereum` _não estiver_ presente, isso significa que o MetaMask não está instalado. Isso resulta no retorno de um objeto JSON, onde o `address` retornado é uma string vazia, e o objeto JSX `status` informa que o usuário deve instalar o MetaMask. -Agora se `window.ethereum` _estiver_ presente, e é aí que as coisas ficam interessantes. +Agora, se o `window.ethereum` _estiver_ presente, é aí que as coisas ficam interessantes. -Usando um laço try/catch, nós vamos tentar conectar ao MetaMask chamando[`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts). Chamando esta função o MetaMask irá abrir no navegador, onde o usuário será solicitado a conectar sua carteira ao seu dapp. +Usando um loop try/catch, tentaremos nos conectar ao MetaMask chamando [`window.ethereum.request({ method: \"eth_requestAccounts\" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts). Chamando esta função o MetaMask irá abrir no navegador, onde o usuário será solicitado a conectar sua carteira ao seu dapp. -- Se o usuário escolher conectar, `method: "eth_requestAccounts"` irá retornar uma array que contém todos os endereços de contas de usuário que conectaram ao dapp. No total, nossa função `connectWallet` retornará um objeto JSON que contém o _primeiro_ `address` desta matriz \(ver linha 9\) e uma mensagem `status` que pede que o usuário escreva uma mensagem para o contrato inteligente. -- Se o usuário rejeitar a conexão, então o objeto JSON vai conter uma string vazia para o `address` retornado e uma mensagem de `status` que reflete que o usuário rejeitou a conexão. +- Se o usuário optar por conectar, `method: "eth_requestAccounts"` retornará um array que contém todos os endereços de conta do usuário conectados ao dapp. No total, nossa função `connectWallet` retornará um objeto JSON que contém o _primeiro_ `address` neste array (veja a linha 9) e uma mensagem de `status` que solicita ao usuário que escreva uma mensagem para o contrato inteligente. +- Se o usuário rejeitar a conexão, o objeto JSON conterá uma string vazia para o `address` retornado e uma mensagem de `status` que reflete que o usuário rejeitou a conexão. -Agora que nós escrevemos esta função `connectWallet`, o próximo passo é chamar ele para o nosso componente `HelloWorld.js`. +Agora que escrevemos esta função `connectWallet`, o próximo passo é chamá-la em nosso componente `HelloWorld.js`. #### Adicione a função `connectWallet` ao seu componente de interface do usuário `HelloWorld.js` {#add-the-connectWallet-function-to-your-HelloWorld-js-ui-component} -Navegue para a função `connectWalletPressed` em `HelloWorld.js`, e atualize-o para o seguinte: +Navegue para a função `connectWalletPressed` em `HelloWorld.js` e atualize-a para o seguinte: ```javascript // HelloWorld.js @@ -1214,25 +1217,25 @@ const connectWalletPressed = async () => { } ``` -Observe como a maior parte das nossas funcionalidades está abstraída do nosso componente `HelloWorld.js` do arquivo `interact.js`? É assim que respeitamos o paradigma M-V-C! +Observe como a maior parte de nossa funcionalidade está abstraída de nosso componente `HelloWorld.js` do arquivo `interact.js`? É assim que respeitamos o paradigma M-V-C! -Em `connectWalletPressed`, simplesmente fazemos uma chamada de espera (await) para a função `connectWallet`, importada, e usando sua resposta, nós atualizaremos nossas variáveis `status` e `walletAddress` através de seus state hooks. +Em `connectWalletPressed`, nós simplesmente fazemos uma chamada `await` para a nossa função `connectWallet` importada e, usando sua resposta, atualizamos nossas variáveis `status` e `walletAddress` através de seus hooks de estado. -Agora, vamos salvar os dois arquivos `HelloWorld.js` e `interact.js` e testar nossa UI até agora. +Agora, vamos salvar ambos os arquivos (`HelloWorld.js` e `interact.js`) e testar nossa interface do usuário até agora. -Abra seu navegador na página [http://localhost:3000/](http://localhost:3000/) e clique no botão “Connect Wallet” na parte superior direita da página. +Abra seu navegador na página [http://localhost:3000/](http://localhost:3000/) e pressione o botão "Conectar Carteira" no canto superior direito da página. Se você tiver o MetaMask instalado, você será solicitado a conectar sua carteira ao seu dapp. Aceite o convite para se conectar. -Observe que o botão de carteira agora mostra que o seu endereço está conectado! Ótimo!!🔥 +Você deve ver que o botão da carteira agora reflete que seu endereço está conectado! Demais! 🔥 -Em seguida, tente atualizar a página... isso é estranho. Nosso botão de carteira está nos pedindo para conectar o MetaMask, mesmo que já esteja conectado... +Em seguida, tente atualizar a página... que estranho. Nosso botão de carteira está nos pedindo para conectar o MetaMask, mesmo que já esteja conectado... -Entretanto, não tenha medo! Nós podemos endereçar (entendeu?) facilmente isso implementando `getCurrentWalletConnected`, o qual irá checar se um endereço já está conectado no nosso dapp e atualizar nossa UI de acordo! +No entanto, não tema! Podemos facilmente resolver isso (entendeu?) implementando `getCurrentWalletConnected`, que verificará se um endereço já está conectado ao nosso dapp e atualizará nossa interface do usuário de acordo! #### A função `getCurrentWalletConnected` {#the-getcurrentwalletconnected-function} -Atualize a sua função `getCurrentWalletConnected` no arquivo `interact.js` como mostrado abaixo: +Atualize sua função `getCurrentWalletConnected` no arquivo `interact.js` para o seguinte: ```javascript // interact.js @@ -1246,12 +1249,12 @@ export const getCurrentWalletConnected = async () => { if (addressArray.length > 0) { return { address: addressArray[0], - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 Escreva uma mensagem no campo de texto acima.", } } else { return { address: "", - status: "🦊 Connect to MetaMask using the top right button.", + status: "🦊 Conecte-se ao MetaMask usando o botão superior direito.", } } } catch (err) { @@ -1268,8 +1271,7 @@ export const getCurrentWalletConnected = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + Você deve instalar o MetaMask, uma carteira virtual Ethereum, no seu navegador.

@@ -1279,11 +1281,11 @@ export const getCurrentWalletConnected = async () => { } ``` -Este código é _muito_ similar à função `connectWallet` que nós acabamos de escrever no passo anterior. +Este código é _muito_ semelhante à função `connectWallet` que acabamos de escrever na etapa anterior. -A diferença principal é que, em vez de chamar o método `eth_requestAccounts`, que abre o MetaMask para o usuário conectar sua carteira, aqui chamamos o método `eth_accounts`, que simplesmente retorna uma matriz que contém os endereços MetaMask atualmente conectados ao nosso dapp. +A principal diferença é que, em vez de chamar o método `eth_requestAccounts`, que abre o MetaMask para o usuário conectar sua carteira, aqui chamamos o método `eth_accounts`, que simplesmente retorna uma matriz contendo os endereços do MetaMask atualmente conectados ao nosso dapp. -Para ver esta função em ação, vamos chamar nossa função `useEffect` do nosso componente `HelloWorld.js`: +Para ver esta função em ação, vamos chamá-la em nossa função `useEffect` do nosso componente `HelloWorld.js`: ```javascript // HelloWorld.js @@ -1299,17 +1301,17 @@ useEffect(async () => { }, []) ``` -Note que nós usamos a resposta da nossa chamada a `getCurrentWalletConnected` para atualizar nossa `walletAddress` e nossa variável de estado `status`. +Observe que usamos a resposta da nossa chamada para `getCurrentWalletConnected` para atualizar nossas variáveis de estado `walletAddress` e `status`. -Agora que você adicionou este código, tente atualizar a janela do navegador. +Agora que você adicionou este código, vamos tentar atualizar a janela do nosso navegador. -Ótimo!!!! O botão deve dizer que você está conectado e mostrar uma visualização do endereço de sua carteira conectada - mesmo depois de atualizar! +Ótimoooo! O botão deve dizer que você está conectado e mostrar uma visualização do endereço de sua carteira conectada - mesmo depois de atualizar! #### Implemente `addWalletListener` {#implement-addwalletlistener} O passo final na configuração da nossa carteira dapp é implementar o ouvinte de carteira, para que nossa interface atualize quando o estado mudar, como quando o usuário desconecta ou troca de contas. -No seu arquivo `HelloWorld.js`, modifique a sua função `addWalletListener` para o seguinte: +No seu arquivo `HelloWorld.js`, modifique sua função `addWalletListener` para o seguinte: ```javascript // HelloWorld.js @@ -1319,10 +1321,10 @@ function addWalletListener() { window.ethereum.on("accountsChanged", (accounts) => { if (accounts.length > 0) { setWallet(accounts[0]) - setStatus("👆🏽 Write a message in the text-field above.") + setStatus("👆🏽 Escreva uma mensagem no campo de texto acima.") } else { setWallet("") - setStatus("🦊 Connect to MetaMask using the top right button.") + setStatus("🦊 Conecte-se ao MetaMask usando o botão superior direito.") } }) } else { @@ -1330,7 +1332,7 @@ function addWalletListener() {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your browser. + Você deve instalar o MetaMask, uma carteira virtual Ethereum, no seu navegador.

) @@ -1338,13 +1340,13 @@ function addWalletListener() { } ``` -Eu aposto que você nem mesmo precisou da nossa ajuda para entender o que está acontecendo aqui neste ponto, mas por finalidade de clareza, vamos quebrá-lo em partes: +Aposto que você nem precisa da nossa ajuda para entender o que está acontecendo aqui neste ponto, mas, para fins de completude, vamos detalhar rapidamente: -- Primeiro, nossa função verifica se o `window.ethereum` está habilitado no seu navegador \(ex. MetaMask instalado\). - - Caso contrário, nós simplesmente configuramos a variável de estado `status` para uma JSX string que solicita o usuário instalar a MetaMask. - - Se estiver habilitado, configuramos o ouvinte `window.ethereum.on("accountsChanged")` na linha 3 que houve mudança de estado na carteira MetaMask, inclusive quando o usuário conecta uma conta adicional ao dapp, troca de conta ou desconecta uma conta. Se houver pelo menos uma conta conectada, a variável de estado `walletAddress` é atualizada como a primeira conta no array `accounts` retornada pelo ouvinte. Caso contrário, `walletAddress` é definida como uma string vazia. +- Primeiro, nossa função verifica se o `window.ethereum` está ativado (ou seja, se o MetaMask está instalado). + - Se não estiver, simplesmente definimos nossa variável de estado `status` como uma string JSX que solicita ao usuário que instale o MetaMask. + - Se estiver habilitado, configuramos o listener `window.ethereum.on("accountsChanged")` na linha 3 que escuta por mudanças de estado na carteira MetaMask, que incluem quando o usuário conecta uma conta adicional ao dapp, troca de contas ou desconecta uma conta. Se houver pelo menos uma conta conectada, a variável de estado `walletAddress` é atualizada como a primeira conta no array `accounts` retornado pelo listener. Caso contrário, o `walletAddress` é definido como uma string vazia. -Por último, mas não menos importante, nós devemos chamá-la em nossa função `useEffect`: +Por último, mas não menos importante, devemos chamá-la em nossa função `useEffect`: ```javascript // HelloWorld.js @@ -1362,23 +1364,23 @@ useEffect(async () => { }, []) ``` -E é isso! Concluímos com sucesso a programação de toda a nossa carteira! Agora, a nossa última tarefa: atualizar a mensagem armazenada no nosso contrato inteligente! +E é isso! Concluímos com sucesso a programação de toda a funcionalidade da nossa carteira! Agora para nossa última tarefa: atualizar a mensagem armazenada em nosso contrato inteligente! ### Passo 6: Implemente a função `updateMessage` {#step-6-implement-the-updateMessage-function} -Tudo bem, nós chegamos ao trecho caseiro! No `updateMessage` do seu arquivo `interact.js`, façamos o seguinte: +Tudo bem, pessoal, chegamos à reta final! Na `updateMessage` do seu arquivo `interact.js`, faremos o seguinte: -1. Certifique-se que a mensagem que nós queremos publicar no nosso contrato inteligente é válida -2. Assine nossa transação usando MetaMask -3. Chame esta função do nosso componente de frontend `HelloWorld.js` +1. Certificar-se de que a mensagem que desejamos publicar em nosso contrato inteligente é válida +2. Assinar nossa transação usando o MetaMask +3. Chamar esta função do nosso componente de frontend `HelloWorld.js` -Isso não vai demorar muito; vamos terminar este dapp! +Isso não levará muito tempo; vamos terminar este dapp! -#### Manipulação de erros de script {#input-error-handling} +#### Tratamento de erros de entrada {#input-error-handling} -Naturalmente, faz sentido ter alguns tipos de gerencialmente de erros de entrada no início da função. +Naturalmente, faz sentido ter algum tipo de tratamento de erro de entrada no início da função. -Queremos que nossa função retorne rapidamente. Se não houver uma extensão MetaMask instalada, não haverá carteiras conectadas \(ou seja, o `address` transmitido é uma cadeira de caracteres vazia\) ou a `message` será uma cadeira de caracteres vazia. Vamos adicionar o seguinte gerencialmente de erro em `updateMessage`: +Queremos que nossa função retorne mais cedo se não houver extensão MetaMask instalada, se não houver carteira conectada (ou seja, o `address` passado é uma string vazia) ou se a `message` for uma string vazia. Vamos adicionar o seguinte tratamento de erro a `updateMessage`: ```javascript // interact.js @@ -1387,35 +1389,35 @@ export const updateMessage = async (address, message) => { if (!window.ethereum || address === null) { return { status: - "💡 Connect your MetaMask wallet to update the message on the blockchain.", + "💡 Conecte sua carteira MetaMask para atualizar a mensagem na blockchain.", } } if (message.trim() === "") { return { - status: "❌ Your message cannot be an empty string.", + status: "❌ Sua mensagem não pode ser uma string vazia.", } } } ``` -Agora que ele tem o devido gerenciamento de erro de entrada, é hora de assinar a transação via MetaMask! +Agora que temos o tratamento de erro de entrada adequado, é hora de assinar a transação via MetaMask! -#### Assinando a nossa transação {#signing-our-transaction} +#### Assinando nossa transação {#signing-our-transaction} -Se você já está confortável com as transações tradicionais Web3 do Ethereum, o código que vamos escrever em seguida será bastante familiar. Abaixo, nosso código de manipulação de erro de entrada, adicione o seguinte a `updateMessage`: +Se você já está confortável com transações Ethereum da web3 tradicional, o código que escreveremos a seguir será muito familiar. Abaixo do seu código de tratamento de erro de entrada, adicione o seguinte a `updateMessage`: ```javascript // interact.js -//set up transaction parameters +//configurar parâmetros da transação const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: address, // must match user's active address. + to: contractAddress, // Obrigatório, exceto durante publicações de contrato. + from: address, // deve corresponder ao endereço ativo do usuário. data: helloWorldContract.methods.update(message).encodeABI(), } -//sign the transaction +//assinar a transação try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -1426,11 +1428,10 @@ try { ✅{" "} - View the status of your transaction on Etherscan! + Veja o status da sua transação no Etherscan!
- ℹ️ Once the transaction is verified by the network, the message will be - updated automatically. + ℹ️ Assim que a transação for verificada pela rede, a mensagem será atualizada automaticamente. ), } @@ -1441,47 +1442,47 @@ try { } ``` -Vamos quebrar em partes o que está acontecendo. Primeiro, configuramos nossos parâmetros de transações, em que: +Vamos detalhar o que está acontecendo. Primeiro, configuramos nossos parâmetros de transações, onde: -- `to` especificar o endereço do destinatário \(nosso contrato inteligente\) -- `from` especifica o signatário da transação, a variável `address` que transmitimos para a nossa função -- `data` contém a chamada para o método `update` do nosso contrato inteligente Olá, Mundo, recebendo nossa variável de cadeia de caracteres `message` como entrada +- `to` especifica o endereço do destinatário (nosso contrato inteligente) +- `from` especifica o signatário da transação, a variável `address` que passamos para nossa função +- `data` contém a chamada para o método `update` do nosso contrato inteligente Hello World, recebendo nossa variável de string `message` como entrada -Então, nós fazemos uma chamada await, `window.ethereum.request`, onde nós pedimos ao MetaMask para assinar a transação. Observe que nas linhas 11 e 12, estamos especificando nosso método eth `eth_sendTransaction` e passando os nossos `transactionParameters`. +Então, fazemos uma chamada de espera, `window.ethereum.request`, onde pedimos ao MetaMask para assinar a transação. Observe que, nas linhas 11 e 12, estamos especificando nosso método eth, `eth_sendTransaction`, e passando nossos `transactionParameters`. Neste ponto, a MetaMask irá abrir no navegador e pedirá que o usuário assine ou rejeite a transação. -- Se a transação tiver sucesso, a função retornará um objeto JSON no qual a cadeia de caracteres JSX `status` pede ao usuário para verificar o Etherscan para mais informações sobre suas transações. -- Se a transação falha, a função irá retornar um objeto JSON onde a string `status` retransmite a mensagem de erro. +- Se a transação for bem-sucedida, a função retornará um objeto JSON onde a string JSX `status` solicita ao usuário que verifique o Etherscan para mais informações sobre sua transação. +- Se a transação falhar, a função retornará um objeto JSON onde a string `status` transmite a mensagem de erro. -Tudo junto, nossa função `updateMessage` deve se parecer com isso: +No total, nossa função `updateMessage` deve ter a seguinte aparência: ```javascript // interact.js export const updateMessage = async (address, message) => { - //input error handling + //tratamento de erro de entrada if (!window.ethereum || address === null) { return { status: - "💡 Connect your MetaMask wallet to update the message on the blockchain.", + "💡 Conecte sua carteira MetaMask para atualizar a mensagem na blockchain.", } } if (message.trim() === "") { return { - status: "❌ Your message cannot be an empty string.", + status: "❌ Sua mensagem não pode ser uma string vazia.", } } - //set up transaction parameters + //configurar parâmetros da transação const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: address, // must match user's active address. + to: contractAddress, // Obrigatório, exceto durante publicações de contrato. + from: address, // deve corresponder ao endereço ativo do usuário. data: helloWorldContract.methods.update(message).encodeABI(), } - //sign the transaction + //assinar a transação try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -1492,11 +1493,10 @@ export const updateMessage = async (address, message) => { ✅{" "} - View the status of your transaction on Etherscan! + Veja o status da sua transação no Etherscan!
- ℹ️ Once the transaction is verified by the network, the message will - be updated automatically. + ℹ️ Assim que a transação for verificada pela rede, a mensagem será atualizada automaticamente. ), } @@ -1508,11 +1508,11 @@ export const updateMessage = async (address, message) => { } ``` -Por último, mas não menos importante, nós precisamos conectar nossa função `updateMessage` ao componente `HelloWorld.js`. +Por último, mas não menos importante, precisamos conectar nossa função `updateMessage` ao nosso componente `HelloWorld.js`. -#### Conecte `updateMessage` ao front-end `HelloWorld.js` {#connect-updatemessage-to-the-helloworld-js-frontend} +#### Conecte `updateMessage` ao frontend `HelloWorld.js` {#connect-updatemessage-to-the-helloworld-js-frontend} -Nossa função `onUpdatePressed` deve fazer uma chamada await para a função `updateMessage` importada e modificar a variável de estado `status` para refletir se a nossa transação teve sucesso ou falhou: +Nossa função `onUpdatePressed` deve fazer uma chamada de espera para a função `updateMessage` importada e modificar a variável de estado `status` para refletir se nossa transação foi bem-sucedida ou falhou: ```javascript // HelloWorld.js @@ -1523,18 +1523,18 @@ const onUpdatePressed = async () => { } ``` -É super limpo e simples. E advinhe... SEU DAPP ESTÁ COMPLETO!!! +É super limpo e simples. E adivinhe só... SEU DAPP ESTÁ COMPLETO!!! -Vá em frente e teste com o botão **Update**! +Vá em frente e teste o botão **Atualizar**! -### Faça o seu próprio dapp customizado {#make-your-own-custom-dapp} +### Crie seu próprio dapp personalizado {#make-your-own-custom-dapp} -Ebaaaaa, você chegou até o fim deste tutorial! Para recapitular, você aprendeu como: +Uhuuu, você chegou ao final do tutorial! Para recapitular, você aprendeu como: -- Conectar a carteira MetaMask no seu projeto dapp +- Conectar uma carteira MetaMask ao seu projeto de dapp - Ler dados do seu contrato inteligente usando a API [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) -- Assinar transações Ethereum usando MetaMask +- Assinar transações Ethereum usando o MetaMask -Agora você está totalmente equipado para aplicar suas habilidades deste tutorial para construir seu próprio projeto dapp customizado! Como sempre, se você tiver questões, não hesite em nos contatar para pedir ajuda no[Discord da Alchemy](https://discord.gg/gWuC7zB). 🧙‍♂️ +Agora você está totalmente equipado para aplicar as habilidades deste tutorial para construir seu próprio projeto de dapp personalizado! Como sempre, se tiver alguma dúvida, não hesite em nos contatar para obter ajuda no [Discord da Alchemy](https://discord.gg/gWuC7zB). 🧙‍♂️ -Uma vez que você terminou este tutorial, nos diga como foi sua experiência ou se você tem alguma opinião, nos marcando no Twitter [@alchemyplatform](https://twitter.com/AlchemyPlatform)! +Depois de concluir este tutorial, conte-nos como foi sua experiência ou se você tem algum feedback, marcando-nos no Twitter [@alchemyplatform](https://twitter.com/AlchemyPlatform)! diff --git a/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract/index.md b/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract/index.md index 540ba1314d8..2621a803c53 100644 --- a/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract/index.md +++ b/public/content/translations/pt-br/developers/tutorials/hello-world-smart-contract/index.md @@ -1,90 +1,86 @@ --- title: Contrato inteligente "Hello World" para iniciantes -description: Tutorial introdutório sobre como escrever e implementar um contrato inteligente simples no Ethereum. +description: "Tutorial introdutório sobre como escrever e implantar um contrato inteligente simples no Ethereum." author: "elanh" tags: - - "solidity" - - "hardhat" - - "alchemy" - - "contratos inteligentes" - - "implementação" + [ + "Solidity", + "Hardhat", + "Alchemy", + "smart contracts", + "implantação" + ] skill: beginner lang: pt-br published: 2021-03-31 --- -Se você é novo no desenvolvimento de blockchain e não sabe por onde começar, ou se apenas deseja entender como implementar ou interagir com contratos inteligentes, este guia é para você. Vamos criar e implantar um contrato inteligente simples na rede de teste Goerli usando uma carteira virtual [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/) e [Alchemy](https://alchemyapi.io/eth) (não se preocupe se você ainda não entendeu o que isso significa, nós explicaremos). +Se você é novo no desenvolvimento de blockchain e não sabe por onde começar, ou se apenas deseja entender como implantar ou interagir com contratos inteligentes, este guia é para você. Vamos criar e implantar um contrato inteligente simples na rede de teste Sepolia usando uma carteira virtual [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/) e [Alchemy](https://www.alchemy.com/eth) (não se preocupe se você ainda não entendeu o que isso significa, nós explicaremos). -> **Atenção** -> -> Aviso de descontinuidade -> -> Para este guia inteiro, a rede de teste Goerli está sendo usada para criação e implantação de contratos inteligentes. Entretanto, por favor note que a Ethereum Foundation anunciou que a [Goerli será descontinuada em breve](https://www.alchemy.com/blog/goerli-faucet-deprecation). -> -> Nós recomendamos você usar a [Sepolia](https://www.alchemy.com/overviews/sepolia-testnet) e [faucets Sepolia](https://sepoliafaucet.com/) para este tutorial. +Na [parte 2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract) deste tutorial, vamos ver como podemos interagir com nosso contrato inteligente depois de implantado aqui, e na [parte 3](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) vamos cobrir como publicá-lo no Etherscan. -Na [parte 2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract) deste tutorial, veremos como podemos interagir com nosso contrato inteligente, assim que for implantado aqui, e na [parte 3](https://docs.alchemy.com/docs/submitting-your-smart-contract-to-etherscan), abordaremos como publicá-lo no Etherscan. +Se você tiver alguma dúvida, sinta-se à vontade para entrar em contato no [Discord da Alchemy](https://discord.gg/gWuC7zB)! -Caso surjam perguntas em qualquer momento, sinta-se à vontade para falar no Discord da [Alchemy](https://discord.gg/gWuC7zB)! +## Etapa 1: Conectar-se à rede Ethereum {#step-1} -## Passo 1: Conecte-se à rede de Ethereum {#step-1} +Existem muitas maneiras de fazer solicitações para a cadeia Ethereum. Para simplificar, usaremos uma conta gratuita no Alchemy, uma plataforma de desenvolvimento de blockchain e API que nos permite comunicar com a cadeia Ethereum sem ter que executar nossos próprios nós. A plataforma também possui ferramentas de desenvolvedor para monitoramento e análise das quais tiraremos proveito neste tutorial para entender o que está acontecendo nos bastidores na implantação do nosso contrato inteligente. Se você ainda não tem uma conta da Alchemy, [pode se inscrever gratuitamente aqui](https://dashboard.alchemy.com/signup). -Existem muitas maneiras de fazer solicitações à cadeia de Ethereum. Por simplicidade, usaremos uma conta gratuita na Alchemy, uma API e plataforma de desenvolvedores de blockchain, a qual permite nos comunicar com a cadeia de Ethereum sem ter que executar nossos próprios nós. A plataforma também possui ferramentas de desenvolvedor para monitorar e analisar; ferramentas das quais vamos tirar proveito neste tutorial, para entender o que está acontecendo nos bastidores da implantação de nosso contrato inteligente. Se ainda não tiver uma conta na Alchemy, você pode se cadastrar gratuitamente [neste link](https://dashboard.alchemyapi.io/signup). +## Etapa 2: Criar seu aplicativo (e chave de API) {#step-2} -## Passo 2: Crie seu aplicativo (e chave de API) {#step-2} +Assim que criar uma conta na Alchemy, você pode gerar uma chave de API criando um "app". Isso nos permitirá fazer solicitações à rede de teste Sepolia. Se você não está familiarizado com redes de teste, confira [esta página](/developers/docs/networks/). -Assim que você criar uma conta na Alchemy, você pode gerar uma chave de API criando um app. Isso nos permitirá fazer solicitações na rede de teste Goerli. Se não estiver familiarizado com as redes de teste, confira [esta página](/developers/docs/networks/). +1. Navegue até a página "Create new app" em seu Painel de Controle da Alchemy, selecionando "Select an app" na barra de navegação e clicando em "Create new app" -1. Navegue até a pagina "Create App" na sua "Dashboard da Alchemy", indo na aba de "Apps" na barra de navegação e clicando em “Create App” +![Hello world criar aplicativo](./hello-world-create-app.png) -![Criar um aplicativo Hello World](./hello-world-create-app.png) +2. Dê um nome ao seu aplicativo, como “Hello World”, ofereça uma breve descrição e escolha um caso de uso, por exemplo, "Infra & Tooling." Em seguida, pesquise por "Ethereum" e selecione a rede. -2. Nomeie seu aplicativo “Hello World”, ofereça uma breve descrição, selecione “Staging” para o ambiente (usado para seu aplicativo de contabilidade) e escolha “Goerli” para sua rede. +![visualização de criação de aplicativo hello world](./create-app-view-hello-world.png) -![criar uma visualização do app hello world](./create-app-view-hello-world.png) +3. Clique em "Next" para prosseguir, depois em “Create app” e pronto! Seu aplicativo deve aparecer no menu suspenso da barra de navegação, com uma chave de API disponível para cópia. -3. Clique em "Criar app" e pronto! Seu app deve aparecer na tabela abaixo. +## Etapa 3: Criar uma conta Ethereum (endereço) {#step-3} -## Passo 3: Crie uma conta (endereço) de Ethereum {#step-3} +Precisamos de uma conta Ethereum para enviar e receber transações. Para este tutorial, usaremos uma carteira virtual no navegador, a MetaMask, para gerenciar o endereço da sua conta Ethereum. Mais sobre [transações](/developers/docs/transactions/). -Precisamos de uma conta de Ethereum para enviar e receber transações. Para este tutorial, usaremos uma carteira virtual no navegador, a MetaMask, para gerenciar o endereço da sua conta Ethereum. Mais sobre [transações](/developers/docs/transactions/). +Você pode baixar o MetaMask e criar uma conta Ethereum gratuitamente [aqui](https://metamask.io/download). Ao criar uma conta, ou se você já tiver uma, certifique-se de mudar para a rede de teste "Sepolia" usando o menu suspenso de rede (para que não estejamos lidando com dinheiro de verdade). -Você pode baixar e criar uma conta MetaMask gratuitamente [neste link](https://metamask.io/download). Quando você estiver criando uma conta, ou se já tiver uma conta, certifique-se de mudar para a “Rede de teste Goerli”, no canto superior direito (para que não estejamos lidando com dinheiro real). +Se você não vir a Sepolia listada, vá ao menu, depois em Advanced e role para baixo para ativar a opção "Show test networks". No menu de seleção de rede, escolha a aba "Custom" para encontrar uma lista de redes de teste e selecione "Sepolia." -![exemplo metamask ropsten](./metamask-ropsten-example.png) +![exemplo metamask sepolia](./metamask-sepolia-example.png) -## Passo 4: Adicione ether de um faucet {#step-4} +## Etapa 4: Adicionar ether de um faucet {#step-4} -Para implantar nosso contrato inteligente na rede de teste, precisaremos de algum Eth falso. Para obter Eth, você pode acessar a [torneira Goerli](https://goerlifaucet.com/), fazer login na sua conta Alchemy, inserir o endereço da carteira e clicar em "Send Me Eth." Pode levar algum tempo para receber seu Eth falso devido ao tráfego de rede. (Enquanto escrevia isto, levou cerca de 30 minutos) Você deve ver Eth em sua conta Metamask logo depois! +Para implantar nosso contrato inteligente na rede de teste, precisaremos de um pouco de ETH falso. Para obter Sepolia ETH, você pode ir para os [detalhes da rede Sepolia](/developers/docs/networks/#sepolia) para ver uma lista de vários faucets. Se um não funcionar, tente outro, pois eles podem, às vezes, ficar sem fundos. Pode levar algum tempo para receber seu ETH falso devido ao tráfego da rede. Você deverá ver o ETH em sua conta MetaMask logo em seguida! -## Passo 5: Verifique seu saldo {#step-5} +## Etapa 5: Verificar seu saldo {#step-5} -Para verificar novamente que temos saldo, vamos fazer uma solicitação através da ferramenta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) fornecida pelo [compositor da Alchemy](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ele mostrará a quantidade de ETH em nossa carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: +Para verificar se nosso saldo está lá, vamos fazer uma solicitação [eth_getBalance](/developers/docs/apis/json-rpc/#eth_getbalance) usando a [ferramenta composer da Alchemy](https://sandbox.alchemy.com/?network=ETH_SEPOLIA&method=eth_getBalance&body.id=1&body.jsonrpc=2.0&body.method=eth_getBalance&body.params%5B0%5D=&body.params%5B1%5D=latest). Ele mostrará a quantidade de ETH em nossa carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: ```json { "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" } ``` -> **OBSERVAÇÃO:** este resultado é em wei não em ETH. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para ETH é 1 ETH = 1018 wei. Desta maneira, se convertermos 0x2B5E3AF16B1880000 em decimal obteremos 5\*10¹⁸, o que equivale a 5 ETH. +> **OBSERVAÇÃO:** Este resultado está em wei, não em ETH. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para ETH é: 1 eth = 1018 wei. Então, se convertermos 0x2B5E3AF16B1880000 para decimal, teremos 5\*10¹⁸, o que equivale a 5 ETH. > -> Ufa! Nosso dinheiro de imitação está todo aí . +> Ufa! Nosso dinheiro falso está todo lá . -## Passo 6: Inicialize nosso projeto {#step-6} +## Etapa 6: Inicializar nosso projeto {#step-6} -Primeiramente, precisaremos criar uma pasta para o nosso projeto. Navegue até sua linha de comando e digite: +Primeiro, precisamos criar uma pasta para o nosso projeto. Navegue até sua linha de comando e digite: ``` mkdir hello-world cd hello-world ``` -Agora que estamos dentro da pasta do nosso projeto, vamos usar o comando `npm init `para inicializar o projeto. Se você ainda não tiver o npm instalado, siga [estas instruções](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm). Também vamos precisar do node.js, então baixe-o também! +Agora que estamos dentro da pasta do nosso projeto, usaremos o `npm init` para inicializar o projeto. Se você ainda não tiver o npm instalado, siga [estas instruções](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) (também precisaremos do Node.js, então baixe-o também!). ``` npm init ``` -Não importa muito como você responde às questões sobre a instalação. A modo de referência, aqui está o que nós fizemos: +Não importa muito como você responde às perguntas da instalação, aqui está como fizemos para referência: ``` package name: (hello-world) @@ -104,30 +100,30 @@ About to write to /Users/.../.../.../hello-world/package.json: "description": "hello world smart contract", "main": "index.js", "scripts": { - "test": "echo \\"Error: no test specified\\" && exit 1" + "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC" } ``` -Aprove o package.json e estaremos prontos para começar! +Aprove o package.json e estamos prontos! -## Etapa 7: Faça o download do [Hardhat](https://hardhat.org/getting-started/#overview) {#step-7} +## Etapa 7: Baixar o [Hardhat](https://hardhat.org/getting-started/#overview) {#step-7} Hardhat é um ambiente de desenvolvimento para compilar, implementar, testar e depurar seu software de Ethereum. Ele ajuda os desenvolvedores na criação de contratos inteligentes e dapps localmente antes de implantar na cadeia real. -Dentro de nosso projeto `hello-world` execute: +Dentro do nosso projeto `hello-world`, execute: ``` npm install --save-dev hardhat ``` -Para mais detalhes, confira esta página sobre as [instruções de instalação](https://hardhat.org/getting-started/#overview). +Confira esta página para mais detalhes sobre as [instruções de instalação](https://hardhat.org/getting-started/#overview). -## Passo 8: Crie um projeto Hardhat {#step-8} +## Etapa 8: Criar projeto Hardhat {#step-8} -Dentro da nossa pasta do projeto, execute: +Dentro da nossa pasta de projeto, execute: ``` npx hardhat @@ -147,70 +143,70 @@ Você deve então ver uma mensagem de boas-vindas e a opção de selecionar o qu 👷 Welcome to Hardhat v2.0.11 👷‍? -O que você deseja fazer? … +What do you want to do? … Create a sample project ❯ Create an empty hardhat.config.js Quit ``` -Isso vai gerar um arquivo `hardhat.config.js` onde especificaremos todas as configurações para o nosso projeto (no passo 13). +Isso gerará um arquivo `hardhat.config.js` para nós, que é onde especificaremos toda a configuração do nosso projeto (na etapa 13). -## Passo 9: Adicione pastas do projeto {#step-9} +## Etapa 9: Adicionar pastas do projeto {#step-9} -Para manter nosso projeto organizado vamos criar duas pastas novas. Navegue até o diretório raiz do seu projeto na sua linha de comando e digite: +Para manter nosso projeto organizado, criaremos duas novas pastas. Navegue até o diretório raiz do seu projeto na sua linha de comando e digite: ``` mkdir contracts mkdir scripts ``` -- `contracts/` é onde nós vamos manter o arquivo de código do contrato inteligente "hello world" -- `scripts/` é onde nós vamos manter scripts para implantar e interagir com nosso contrato +- `contracts/` é onde manteremos nosso arquivo de código do contrato inteligente hello world +- `scripts/` é onde manteremos os scripts para implantar e interagir com nosso contrato -## Passo 10: Escreva nosso contrato {#step-10} +## Etapa 10: Escrever nosso contrato {#step-10} -Você pode estar se perguntando, quando é que nós vamos escrever códigos? Bem, aqui estamos, no passo 10. +Você pode estar se perguntando, quando diabos vamos escrever código?? Bem, aqui estamos, na etapa 10. -Abra o projeto hello-world em seu editor favorito (nós preferimos o [VSCode](https://code.visualstudio.com/)). Os contratos inteligentes são escritos em uma linguagem chamada Solidity, que usaremos para escrever nosso contrato inteligente HelloWorld.sol +Abra o projeto hello-world em seu editor favorito (nós gostamos do [VSCode](https://code.visualstudio.com/)). Os contratos inteligentes são escritos em uma linguagem chamada Solidity, que é o que usaremos para escrever nosso contrato inteligente HelloWorld.sol.‌ -1. Navegue até a pasta "contracts" e crie um novo arquivo chamado HelloWorld.sol -2. Veja abaixo uma amostra de contrato inteligente "Hello World" da Ethereum Foundation, que usaremos neste tutorial. Copie e cole os itens abaixo em seu arquivo HelloWorld.sol e não se esqueça de ler os comentários para entender o que este contrato faz: +1. Navegue até a pasta “contracts” e crie um novo arquivo chamado HelloWorld.sol +2. Abaixo está um exemplo de contrato inteligente Hello World da Ethereum Foundation que usaremos neste tutorial. Copie e cole o conteúdo abaixo em seu arquivo HelloWorld.sol e certifique-se de ler os comentários para entender o que este contrato faz: ```solidity -// Especifica a versão do Solidity usando a versão semântica. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// Especifica a versão do Solidity, usando o versionamento semântico. +// Saiba mais: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity ^0.7.0; -// Defines a contract named `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. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// 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 { - // Declares a state variable `message` of type `string`. - // Variáveis de estado são variáveis cujos valores são permanentemente armazenados no armazenamento do contrato. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. + // Declara uma variável de estado `message` do tipo `string`. + // As variáveis de estado são variáveis cujos valores são armazenados permanentemente no armazenamento do contrato. A palavra-chave `public` torna as variáveis acessíveis de fora de um contrato e cria uma função que outros contratos ou clientes podem chamar para acessar o valor. string public message; - // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation. - // Os construtores são usados para inicializar os dados do contrato. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // Semelhante a muitas linguagens orientadas a objetos baseadas em classes, um construtor é uma função especial que só é executada na 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.html#constructors constructor(string memory initMessage) { - // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable). + // Aceita um argumento de string `initMessage` e define o valor na variável de armazenamento `message` do contrato). message = initMessage; } - // A public function that accepts a string argument and updates the `message` storage variable. + // 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; } } ``` -Este é um contrato inteligente muito simples, que armazena uma mensagem ao ser criado e pode ser atualizado através da função `update`. +Este é um contrato inteligente super simples que armazena uma mensagem na criação e pode ser atualizado chamando a função `update`. -## Passo 11: Vincule Metamask e Alchemy a seu projeto {#step-11} +## Etapa 11: Conectar o MetaMask e o Alchemy ao seu projeto {#step-11} -Nós já criamos uma carteira Metamask, uma conta Alchemy e já escrevemos nosso contrato inteligente. Agora é hora de vincularmos os três. +Nós criamos uma carteira MetaMask, uma conta da Alchemy e escrevemos nosso contrato inteligente. Agora é hora de conectar os três. -Toda transação enviada da sua carteira virtual requer uma assinatura, usando sua chave privada única. Para fornecer essa permissão ao nosso programa, nós podemos armazenar com segurança nossa chave privada (e a chave Alchemy API) em um arquivo de ambiente. +Toda transação enviada da sua carteira virtual requer uma assinatura, usando sua chave privada única. Para fornecer esta permissão a nosso programa, podemos armazenar nossa chave privada (e a chave Alchemy API) em um arquivo de ambiente. > Para saber mais sobre o envio de transações, confira [este tutorial](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) sobre o envio de transações usando web3. @@ -220,49 +216,49 @@ Primeiro, instale o pacote dotenv na pasta do seu projeto: npm install dotenv --save ``` -Depois, crie um arquivo `.env` no diretório raiz do seu projeto e adicione sua chave Metamask privada e o URL da API HTTP Alchemy nele. +Em seguida, crie um arquivo `.env` no diretório raiz do nosso projeto e adicione sua chave privada do MetaMask e o URL da API HTTP da Alchemy a ele. -- Siga [estas instruções](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) para exportar sua chave privada -- Veja abaixo como obter o URL da API HTTP Alchemy +- Siga [estas instruções](https://support.metamask.io/configure/accounts/how-to-export-an-accounts-private-key/) para exportar sua chave privada +- Veja abaixo para obter o URL da API HTTP da Alchemy -![obter chave da alchemy api](./get-alchemy-api-key.gif) +![obter chave de api da alchemy](./get-alchemy-api-key.png) -Copiar o URL da Alchemy API +Copiar URL da API da Alchemy -Seu arquivo `.env` ficará assim: +Seu `.env` deve ficar assim: ``` -API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" -PRIVATE_KEY = "your-metamask-private-key" +API_URL = "https://eth-sepolia.g.alchemy.com/v2/sua-chave-de-api" +PRIVATE_KEY = "sua-chave-privada-metamask" ``` -Para realmente vinculá-los a nosso código, vamos fazer referência a essas variáveis em nosso arquivo `hardhat.config.js` no passo 13. +Para realmente conectar isso ao nosso código, faremos referência a essas variáveis em nosso arquivo `hardhat.config.js` na etapa 13. -No faça commit do .env! Por favor, tenha certeza de nunca compartilhar ou expor seu arquivo .env com ninguém, pois estará comprometendo suas partes secretas ao fazê-lo. Se estiver usando um controle de versão, adicione seu .env ao arquivo gitignore +Não faça commit do .env! Por favor, certifique-se de nunca compartilhar ou expor seu arquivo .env com ninguém, pois você está comprometendo seus segredos ao fazer isso. Se você estiver usando controle de versão, adicione seu .env a um arquivo gitignore. -## Passo 12: Instale o Ethers.js {#step-12-install-ethersjs} +## Etapa 12: Instalar o Ethers.js {#step-12-install-ethersjs} -Ethers.js é uma biblioteca que facilita a interação e o envio de solicitações ao Ethereum ao incorporar [métodos padrões JSON-RPC](/developers/docs/apis/json-rpc/) a outros métodos mais amigáveis ao usuário. +Ethers.js é uma biblioteca que facilita a interação e a realização de solicitações à Ethereum, envolvendo os [métodos JSON-RPC padrão](/developers/docs/apis/json-rpc/) com métodos mais amigáveis ao usuário. -Hardhat torna muito fácil a integração de [plugins](https://hardhat.org/plugins/), para ferramentas adicionais e funcionalidades extendidas. Aproveitaremos o [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) para implantação de contratos. ([Ethers.js](https://github.com/ethers-io/ethers.js/) tem alguns métodos de implantação de contratos bastante claros). +O Hardhat torna muito fácil a integração de [Plugins](https://hardhat.org/plugins/) para ferramentas adicionais e funcionalidades estendidas. Aproveitaremos o [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) para a implantação de contratos ([Ethers.js](https://github.com/ethers-io/ethers.js/) has some super clean contract deployment methods). -No diretório do projeto, digite: +No diretório do seu projeto, digite: ``` npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0" ``` -Também vamos precisar de ethers em nosso `hardhat.config.js` no próximo passo. +Também vamos precisar do ethers em nosso `hardhat.config.js` na próxima etapa. -## Passo 13: Atualize o hardhat.config.js {#step-13-update-hardhatconfigjs} +## Etapa 13: Atualizar o hardhat.config.js {#step-13-update-hardhatconfigjs} -Até aqui, já adicionamos diversas dependências e plugins. Agora precisamos atualizar o `hardhat.config.js` para que nosso projeto reconheça todos eles. +Adicionamos várias dependências e plugins até agora. Agora precisamos atualizar o `hardhat.config.js` para que nosso projeto saiba sobre todos eles. Atualize seu `hardhat.config.js` para ficar assim: @@ -277,10 +273,10 @@ const { API_URL, PRIVATE_KEY } = process.env; */ module.exports = { solidity: "0.7.3", - defaultNetwork: "goerli", + defaultNetwork: "sepolia", networks: { hardhat: {}, - goerli: { + sepolia: { url: API_URL, accounts: [`0x${PRIVATE_KEY}`] } @@ -288,9 +284,9 @@ module.exports = { } ``` -## Passo 14: Compile nosso contrato {#step-14-compile-our-contracts} +## Etapa 14: Compilar nosso contrato {#step-14-compile-our-contracts} -Para ter certeza de que tudo está funcionando, vamos compilar nosso contrato. A tarefa `compile` é uma das tarefas integradas do Hardhat. +Para ter certeza de que tudo está funcionando, vamos compilar nosso contrato. A tarefa `compile` é uma das tarefas incorporadas do hardhat. Na linha de comando, execute: @@ -298,21 +294,21 @@ Na linha de comando, execute: npx hardhat compile ``` -Você pode receber o aviso `SPDX license identifier not provided in source file`, mas não há necessidade de se preocupar com isso. Esperemos que tudo mais esteja bem! Se não, você sempre pode enviar uma mensagem no [discord Alchemy](https://discord.gg/u72VCg3). +Você pode receber um aviso sobre `SPDX license identifier not provided in source file`, mas não precisa se preocupar com isso — esperamos que todo o resto pareça bom! Se não, você sempre pode enviar uma mensagem no [Discord da Alchemy](https://discord.gg/u72VCg3). -## Passo 15: Escreva nosso script de implantação {#step-15-write-our-deploy-scripts} +## Etapa 15: Escrever nosso script de implantação {#step-15-write-our-deploy-scripts} Agora que nosso contrato está escrito e nosso arquivo de configuração está pronto, é hora de escrever o script de implantação do contrato. -Navegue até a pasta `scripts/` e crie um novo arquivo chamado `deploy.js`, adicionando o seguinte conteúdo: +Navegue até a pasta `scripts/` e crie um novo arquivo chamado `deploy.js`, adicionando o seguinte conteúdo a ele: ``` async function main() { const HelloWorld = await ethers.getContractFactory("HelloWorld"); - // Start deployment, returning a promise that resolves to a contract object + // Inicia a implantação, retornando uma promessa que resolve para um objeto de contrato const hello_world = await HelloWorld.deploy("Hello World!"); - console.log("Contract deployed to address:", hello_world.address);} + console.log("Contrato implantado no endereço:", hello_world.address);} main() .then(() => process.exit(0)) @@ -322,48 +318,50 @@ main() }); ``` -A Hardhat fez um trabalho incrível ao explicar o que cada uma dessas linhas de código faz em seu [Tutorial sobre contratos](https://hardhat.org/tutorial/testing-contracts.html#writing-tests). Adotamos aqui as explicações deles. +A Hardhat faz um trabalho incrível explicando o que cada uma dessas linhas de código faz em seu [tutorial de Contratos](https://hardhat.org/tutorial/testing-contracts.html#writing-tests), nós adotamos as explicações deles aqui. ``` const HelloWorld = await ethers.getContractFactory("HelloWorld"); ``` -Uma `ContractFactory` em ethers.js é uma abstração usada para implantar novos contratos inteligentes, então, aqui, `HelloWorld` representa uma fábrica para instâncias do nosso contrato Hello World. Ao usar o plug-in `hardhat-ethers`, as instâncias `ContractFactory` e `Contract` são conectadas ao primeiro signatário por padrão. +Uma `ContractFactory` em ethers.js é uma abstração usada para implantar novos contratos inteligentes. Portanto, `HelloWorld` aqui é uma fábrica para instâncias do nosso contrato hello world. Ao usar o plugin `hardhat-ethers`, as instâncias `ContractFactory` e `Contract` são conectadas ao primeiro signatário por padrão. ``` const hello_world = await HelloWorld.deploy(); ``` -Ao chamar `deploy()` em uma `ContractFactory`, a implantação se iniciará e retornará uma `Promise` que se resolve em um `Contract`. Este é o objeto que tem um método para cada uma de nossas funções de contrato inteligente. +Chamar `deploy()` em uma `ContractFactory` iniciará a implantação e retornará uma `Promise` que resolve para um `Contrato`. Este é o objeto que tem um método para cada uma de nossas funções de contrato inteligente. -## Passo 16: Implante nosso contrato {#step-16-deploy-our-contract} +## Etapa 16: Implantar nosso contrato {#step-16-deploy-our-contract} -Finalmente estamos prontos para implantar o nosso contrato inteligente! Navegue até a linha de comando e digite: +Finalmente estamos prontos para implantar o nosso contrato inteligente! Navegue até a linha de comando e execute: ``` -npx hardhat run scripts/deploy.js --network goerli +npx hardhat run scripts/deploy.js --network sepolia ``` Você deverá ver algo assim: ``` -Contract deployed to address: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 +Contrato implantado no endereço: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 ``` -Se formos ao [etherscan da Goerli](https://goerli.etherscan.io/) e procurarmos nosso endereço de contrato, devemos ser capazes de ver que ele foi implantado com sucesso. A transação ficará parecida com isto: +Se formos ao [Etherscan da Sepolia](https://sepolia.etherscan.io/) e pesquisarmos o endereço do nosso contrato, poderemos ver que ele foi implantado com sucesso. A transação ficará parecida com isto: -![contrato etherscan](./etherscan-contract.png) +![contrato no etherscan](./etherscan-contract.png) -O endereço `From` deve corresponder ao endereço da sua conta Metamask, e o endereço "Para" vai dizer "Criação de contrato", mas se clicarmos na transação veremos o endereço do nosso contrato no campo `To`: +O endereço `From` deve corresponder ao endereço da sua conta MetaMask e o endereço To dirá “Contract Creation”, mas se clicarmos na transação, veremos o endereço do nosso contrato no campo `To`: -![transação etherscan](./etherscan-transaction.png) +![transação no etherscan](./etherscan-transaction.png) -Parabéns! Você acaba de implantar um contrato inteligente para a cadeia Ethereum 🎉 +Parabéns! Você acabou de implantar um contrato inteligente na cadeia Ethereum 🎉 -Para entender o que está acontecendo nos bastidores, vamos navegar até a guia Explorer no [painel do Alchemy](https://dashboard.alchemyapi.io/explorer). Se você tem vários aplicativos Alchemy, certifique-se de filtrar por app e selecionar “Hello World”. ![explorador hello world](./hello-world-explorer.png) +Para entender o que está acontecendo nos bastidores, vamos navegar para a guia Explorer em nosso [painel da Alchemy](https://dashboard.alchemyapi.io/explorer). Se você tiver vários aplicativos Alchemy, certifique-se de filtrar por aplicativo e selecionar “Hello World”. +![explorador hello world](./hello-world-explorer.png) -Aqui você verá um punhado de chamadas JSON-RPC que Hardhat/Ethers fizeram em segundo plano para nós quando chamamos a função `.deploy() `. Duas importantes chamadas aqui são [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction), que é o pedido para escrever de fato nosso contrato na cadeia Goerli, e [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash) que é um pedido para ler informações sobre nossa transação dado o hash (um padrão típico em transações). Para saber mais sobre o envio de transações, confira este tutorial em [ sobre como enviar transações usando a Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) +Aqui você verá uma série de chamadas JSON-RPC que o Hardhat/Ethers fizeram nos bastidores para nós quando chamamos a função `.deploy()`. Duas chamadas importantes a serem destacadas aqui são [`eth_sendRawTransaction`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-send-raw-transaction), que é a solicitação para realmente escrever nosso contrato na cadeia Sepolia, e [`eth_getTransactionByHash`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-get-transaction-by-hash), que é uma solicitação para ler informações sobre nossa transação, dado o hash (um padrão típico ao lidar com +transações). Para saber mais sobre o envio de transações, confira este tutorial sobre [o envio de transações usando Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) -Isso é tudo para a parte 1 deste tutorial. Na parte 2, [interagiremos com nosso contrato inteligente](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#part-2-interact-with-your-smart-contract) atualizando nossa mensagem inicial e, na parte 3, [publicaremos nosso contrato inteligente no Etherscan](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#optional-part-3-publish-your-smart-contract-to-etherscan) para que todos aprendam como interagir com ele. +Isso é tudo para a parte 1 deste tutorial. Na parte 2, vamos [interagir com nosso contrato inteligente](https://www.alchemy.com/docs/interacting-with-a-smart-contract) atualizando nossa mensagem inicial e, na parte 3, vamos [publicar nosso contrato inteligente no Etherscan](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) para que todos saibam como interagir com ele. -**Quer aprender mais sobre Alchemy? Confira nosso [site](https://alchemyapi.io/eth). Não quer perder nenhuma atualização? Assine o nosso boletim informativo [aqui](https://www.alchemyapi.io/newsletter)! Não se esqueça também de nos seguir no [Twitter](https://twitter.com/alchemyplatform) e participar do nosso [Discord](https://discord.com/invite/u72VCg3)**. +**Quer saber mais sobre o Alchemy? Confira nosso [site](https://www.alchemy.com/eth). Não quer perder nenhuma atualização? Assine nossa newsletter [aqui](https://www.alchemy.com/newsletter)! Não se esqueça de entrar também no nosso [Discord](https://discord.gg/u72VCg3).**. diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-implement-an-erc721-market/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-implement-an-erc721-market/index.md index dc2b696978c..39272d5c6f9 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-implement-an-erc721-market/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-implement-an-erc721-market/index.md @@ -2,11 +2,7 @@ title: Como implementar um mercado ERC-721 description: Como colocar itens tokenizados para venda em um mercado descentralizado author: "Alberto Cuesta Cañada" -tags: - - "contratos inteligentes" - - "erc-721" - - "solidez" - - "tokens" +tags: [ "smart contracts", "erc-721", "Solidity", "tokens" ] skill: intermediate lang: pt-br published: 2020-03-19 @@ -26,13 +22,13 @@ Com a blockchain, esses mercados estão definidos para mudar mais uma vez, deixe O modelo de negócio de um conselho de classificações públicas da blockchain precisará ser diferente do da Ebay e da empresa. -Primeiro, há [o ângulo de descentralização](/developers/docs/web2-vs-web3/). Plataformas existentes precisam manter seus próprios servidores. Uma plataforma descentralizada é mantida por seus usuários, então o custo de executar a plataforma principal cai para zero para o proprietário da plataforma. +Primeiro, há [a perspectiva da descentralização](/developers/docs/web2-vs-web3/). Plataformas existentes precisam manter seus próprios servidores. Uma plataforma descentralizada é mantida por seus usuários, então o custo de executar a plataforma principal cai para zero para o proprietário da plataforma. -Em seguida, há o front-end, o site ou a interface que dá acesso à plataforma. Aqui há muitas opções. Os proprietários da plataforma podem restringir o acesso e forçar todos a usar a interface, carregando uma taxa. Os proprietários da plataforma também podem decidir abrir o acesso (Poder para as Pessoas!) e deixar qualquer pessoa construir interfaces na plataforma. Ou os proprietários poderiam decidir qualquer abordagem no meio desses extremos. +Em seguida, há o front-end, o site ou a interface que dá acesso à plataforma. Aqui há muitas opções. Os proprietários da plataforma podem restringir o acesso e forçar todos a usar a interface, carregando uma taxa. Os proprietários da plataforma também podem decidir abrir o acesso (Poder para o povo!) e permitir que qualquer pessoa crie interfaces para a plataforma. Ou os proprietários poderiam decidir qualquer abordagem no meio desses extremos. _Os líderes empresariais com mais visão do que eu saberão bem como monetizar isso. Tudo o que entendo é que isto é diferente do status quo e é, provavelmente, lucrativo._ -Além disso, há o ponto relativo à automação e aos pagamentos. Algumas coisas podem ser [efetivamente tokenizadas](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) e negociadas em um quadro de classificações. Ativos tokenizados são facilmente transferidos em uma blockchain. Métodos de pagamento altamente complexos podem ser facilmente implementados em uma blockchain. +Além disso, há o ponto relativo à automação e aos pagamentos. Algumas coisas podem ser [tokenizadas de forma muito eficaz](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) e negociadas em um quadro de classificados. Ativos tokenizados são facilmente transferidos em uma blockchain. Métodos de pagamento altamente complexos podem ser facilmente implementados em uma blockchain. Sinto uma oportunidade de negócios aqui. Um quadro de classificados sem custos correntes pode ser facilmente implementado, com caminhos de pagamento complexos incluídos em cada transação. Tenho certeza de que alguém vai ter uma ideia sobre em que usar isso. @@ -40,9 +36,9 @@ Estou feliz construindo. Vamos dar uma olhada no código. ## Implementação {#implementation} -Há algum tempo iniciamos um [repositório de código aberto](https://github.com/HQ20/contracts?ref=hackernoon.com) com implementações de exemplos de casos de negócios e outros brindes, dê uma olhada. +Há algum tempo, iniciamos um [repositório de código aberto](https://github.com/HQ20/contracts?ref=hackernoon.com) com exemplos de implementação de casos de negócio e outras coisinhas, por favor, dê uma olhada. -O código para este [Ethereum Classifieds Board](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) está lá, por favor, use e abuse dele. Apenas esteja ciente de que o código não foi auditado e de que você precisa fazer a sua própria diligência antes de deixar o dinheiro entrar. +O código para este [Quadro de Classificados do Ethereum](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) está lá, por favor, use e abuse dele. Apenas esteja ciente de que o código não foi auditado e de que você precisa fazer a sua própria diligência antes de deixar o dinheiro entrar. Os fundamentos do conselho não são complexos. Todos os anúncios no board serão apenas uma construção com alguns campos: @@ -67,9 +63,9 @@ Usando um mapeamento significa apenas que temos que criar um id para cada anúnc Em seguida, a questão de quais são os itens com que lidamos, e qual é esta moeda que é usada para pagar a transação. -Para os itens, vamos apenas pedir que eles implementem a interface [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com), que realmente é apenas uma maneira de representar itens do mundo real em uma blockchain, embora [funcione melhor com os recursos digitais](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com). Vamos especificar o nosso próprio contrato ERC721 no construtor, significa que todos os ativos do nosso quadro de classificados precisam ter sido tokenizados previamente. +Para os itens, vamos apenas pedir que eles implementem a interface [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com), que na verdade é apenas uma forma de representar itens do mundo real em uma blockchain, embora [funcione melhor com ativos digitais](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com). Vamos especificar o nosso próprio contrato ERC721 no construtor, significa que todos os ativos do nosso quadro de classificados precisam ter sido tokenizados previamente. -Quanto aos pagamentos, vamos fazer algo semelhante. A maioria dos projetos blockchain definem suas próprias criptomoedas [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com). Outros preferem usar um mainstream como a DAI. Neste quadro de classificações, você só precisa decidir em construção qual será a sua moeda. Fácil. +Quanto aos pagamentos, vamos fazer algo semelhante. A maioria dos projetos de blockchain define sua própria criptomoeda [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com). Outros preferem usar um mainstream como a DAI. Neste quadro de classificações, você só precisa decidir em construção qual será a sua moeda. Fácil. ```solidity constructor ( @@ -127,16 +123,16 @@ function cancelTrade(uint256 _trade) Trade memory trade = trades[_trade]; require( msg.sender == trade.poster, - "Trade can be cancelled only by poster." + "A negociação só pode ser cancelada pelo anunciante." ); - require(trade.status == "Open", "Trade is not Open."); + require(trade.status == "Open", "A negociação não está aberta."); itemToken.transferFrom(address(this), trade.poster, trade.item); trades[_trade].status = "Cancelled"; emit TradeStatusChange(_trade, "Cancelled"); } ``` -É isso. Você chegou ao fim da implementação. É bastante surpreendente como alguns conceitos de negócios se tornam compactos quando são expressados em código, e este é um desses casos. Verifique o contrato completo [no nosso repositório](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol). +É isso. Você chegou ao fim da implementação. É bastante surpreendente como alguns conceitos de negócios se tornam compactos quando são expressados em código, e este é um desses casos. Confira o contrato completo [em nosso repositório](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol). ## Conclusão {#conclusion} @@ -146,4 +142,4 @@ Também acontece de as seções de classificados serem uma ferramenta fácil de Neste artigo, tentei fazer uma ponte entre a realidade comercial de um conselho de administração clássico com a implementação tecnológica. Este conhecimento deve ajudá-lo a criar uma visão e um roteiro para a implementação, se você tiver as habilidades certas. -Como sempre, se você for construir algo divertido e gostaria de alguns conselhos, por favor [envie-me uma mensagem](https://albertocuesta.es/)! Fico sempre feliz em ajudar. +Como sempre, se você pretende construir algo divertido e gostaria de algum conselho, por favor [me envie uma mensagem](https://albertocuesta.es/)! Fico sempre feliz em ajudar. diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-mint-an-nft/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-mint-an-nft/index.md index 94593c6e630..a26f6ef7125 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-mint-an-nft/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-mint-an-nft/index.md @@ -1,33 +1,31 @@ --- -title: Como criar um NFT (Segunda parte da série de tutoriais sobre NFT) -description: Este tutorial descreve como criar um NFT na blockchain Ethereum usando nosso contrato inteligente e Web3. +title: "Como Cunhar um NFT (Parte 2/3 da Série de Tutoriais sobre NFT)" +description: Este tutorial descreve como cunhar um NFT na blockchain Ethereum usando nosso contrato inteligente e Web3. author: "Sumi Mudgil" -tags: - - "ERC-721" - - "alchemy" - - "solidity" - - "contratos inteligentes" +tags: [ "ERC-721", "Alchemy", "Solidity", "smart contracts" ] skill: beginner lang: pt-br published: 2021-04-22 --- -[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): 69 milhões de doláres [3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): 11 milhões de doláres [Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): 6 milhões de doláres +[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): $69 Milhões +[3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): $11 Milhões +[Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): $6 Milhões -All of them minted their NFTs using Alchemy’s powerful API. Neste tutorial, vamos te ensinar a fazer o mesmo em < 10 minutos. +Todos eles cunharam seus NFTs usando a poderosa API da Alchemy. Neste tutorial, vamos te ensinar a fazer o mesmo em \<10 minutos. -"Cunhar um NFT" é o ato de publicar uma instância única do seu token ERC-721 na blockchain. Usando nosso contrato inteligente da [Parte 1 desta série de tutoriais NFT](/developers/tutorials/how-to-write-and-deploy-an-nft/), vamos usar nossas habilidades Web3 e criar um NFT. No final deste tutorial, você será capaz de cunhar tantos NFTs quanto seu coração (e sua carteira) desejar! +“Cunhar um NFT” é o ato de publicar uma instância única de seu token ERC-721 na blockchain. Usando nosso contrato inteligente da [Parte 1 desta série de tutoriais sobre NFT](/developers/tutorials/how-to-write-and-deploy-an-nft/), vamos usar nossas habilidades de Web3 e cunhar um NFT. No final deste tutorial, você será capaz de cunhar tantos NFTs quanto seu coração (e sua carteira) desejar! Vamos começar! -## Etapa 1: Instalar a Web3 {#install-web3} +## Etapa 1: Instalar o Web3 {#install-web3} -Se você seguiu o primeiro tutorial sobre a criação do seu contrato inteligente NFT, você já tem experiência usando a Ethers.js. Web3 é semelhante a Ethers, uma vez que é uma biblioteca usada para facilitar a criação de solicitações para a blockchain Ethereum. Neste tutorial, usaremos a [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), que é uma biblioteca Web3 aprimorada que oferece novas tentativas automáticas e um suporte WebSocket sólido. +Se você seguiu o primeiro tutorial sobre a criação do seu contrato inteligente NFT, você já tem experiência usando a Ethers.js. Web3 é semelhante ao Ethers, pois é uma biblioteca usada para facilitar a criação de solicitações para a blockchain Ethereum. Neste tutorial, usaremos o [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), que é uma biblioteca Web3 aprimorada que oferece novas tentativas automáticas e suporte robusto a WebSocket. -No diretório inicial do seu projeto execute: +No diretório inicial do seu projeto, execute: ``` -yarn add @alch/alchemy-web3 +npm install @alch/alchemy-web3 ``` ## Etapa 2: Criar um arquivo `mint-nft.js` {#create-mintnftjs} @@ -41,83 +39,83 @@ const { createAlchemyWeb3 } = require("@alch/alchemy-web3") const web3 = createAlchemyWeb3(API_URL) ``` -## Etapa 3: Conseguir sua ABI de contrato {#contract-abi} +## Etapa 3: Obter a ABI do seu contrato {#contract-abi} -Nossa ABI (Interface binária de aplicativo) de contrato é a interface para interagir com nosso contrato inteligente. Você pode aprender mais sobre ABIs de contratos [aqui](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is). O Hardhat automaticamente gera uma ABI para nós e a salva no arquivo `MyNFT.json`. Para usar isso, precisaremos distribuir o conteúdo adicionando as seguintes linhas de código ao nosso arquivo `mint-nft.js`: +A ABI (Application Binary Interface) do nosso contrato é a interface para interagir com o nosso contrato inteligente. Você pode saber mais sobre ABIs de Contrato [aqui](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is). O Hardhat gera automaticamente uma ABI para nós e a salva no arquivo `MyNFT.json`. Para usar isso, precisaremos analisar o conteúdo, adicionando as seguintes linhas de código ao nosso arquivo `mint-nft.js`: ```js const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json") ``` -Se quiser ver a ABI, pode imprimi-la no console: +Se quiser ver a ABI, você pode imprimi-la no seu console: ```js console.log(JSON.stringify(contract.abi)) ``` -Para executar o `mint-nft.js` e ver seu ABI impresso no console, navegue até seu terminal e execute: +Para executar o `mint-nft.js` e ver sua ABI impressa no console, navegue até seu terminal e execute: ```js node scripts/mint-nft.js ``` -## Etapa 4: Configurar os metadados para seu NFT usando IPFS {#config-meta} +## Etapa 4: Configurar os metadados do seu NFT usando o IPFS {#config-meta} -Se você se lembra do nosso tutorial na Parte 1, nossa função do contrato inteligente `mintNFT` assume um parâmetro tokenURI que deve resolver em um documento JSON, descrevendo os metadados do NFT, o que realmente dá vida ao NFT, permitindo que ele tenha propriedades configuráveis, tais como: nome, descrição, imagem e outros atributos. +Se você se lembra do nosso tutorial da Parte 1, nossa função de contrato inteligente `mintNFT` recebe um parâmetro tokenURI que deve ser resolvido em um documento JSON que descreve os metadados do NFT — que é o que realmente dá vida ao NFT, permitindo que ele tenha propriedades configuráveis, como nome, descrição, imagem e outros atributos. -> _Interplanetary File System (IPFS) é um protocolo descentralizado e uma rede peer-to-peer para armazenar e compartilhar dados em um sistema de arquivos distribuído._ +> _O Interplanetary File System (IPFS) é um protocolo descentralizado e uma rede ponto a ponto para armazenar e compartilhar dados em um sistema de arquivos distribuído._ -Usaremos o Pinata, uma API IPFS e um kit de ferramentas práticos, para armazenar nossos ativos e metadados NFT para garantir que nosso NFT seja realmente descentralizado. Se você não tem uma conta em Pinata, cadastre-se [aqui](https://app.pinata.cloud) gratuitamente e conclua as etapas de confirmação de seu e-mail. +Usaremos o Pinata, uma API e um kit de ferramentas IPFS convenientes, para armazenar o ativo e os metadados do nosso NFT para garantir que nosso NFT seja verdadeiramente descentralizado. Se você não tiver uma conta no Pinata, crie uma conta gratuita [aqui](https://app.pinata.cloud) e siga as etapas para verificar seu e-mail. -Assim que você tiver criado sua conta: +Assim que tiver criado uma conta: -- Navegue até a página "Files" e clique no botão azul "Upload" no canto superior esquerdo da página. +- Navegue até a página “Arquivos” e clique no botão azul "Fazer Upload" no canto superior esquerdo da página. -- Faça o upload de uma imagem no Pinata — este será o recurso de imagem para o seu NFT. Sinta-se à vontade para nomear o ativo da forma que quiser +- Faça o upload de uma imagem para o Pinata — esta será a imagem do seu NFT. Sinta-se à vontade para nomear o ativo como quiser -- Após o upload, você verá as informações do arquivo na tabela da página "Arquivos". Você também verá a coluna CID. Você pode copiar o CID clicando no botão de cópia ao lado dele. Você pode ver seu ‘upload’ em: `https://gateway.pinata.cloud/ipfs/`. Você pode encontrar a imagem que usamos no IPFS [aqui](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5), por exemplo. +- Após o upload, você verá as informações do arquivo na tabela na página "Arquivos". Você também verá uma coluna CID. Você pode copiar o CID clicando no botão de cópia ao lado dele. Você pode visualizar seu upload em: `https://gateway.pinata.cloud/ipfs/`. Por exemplo, você pode encontrar a imagem que usamos no IPFS [aqui](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5). -Para os que aprendem de maneira mais visual, os passos acima são resumidos aqui: +Para aqueles que aprendem melhor visualmente, as etapas acima estão resumidas aqui: -![Como fazer o upload de sua imagem para Pinata](./instructionsPinata.gif) +![Como fazer o upload da sua imagem para o Pinata](./instructionsPinata.gif) -Agora, nós queremos enviar mais um documento para o Pinata. Mas antes, precisamos criá-lo! +Agora, vamos querer fazer o upload de mais um documento para o Pinata. Mas antes disso, precisamos criá-lo! -Em seu diretório raiz, faça um novo arquivo chamado `nft-metadata.json` e adicione o seguinte código json: +No seu diretório raiz, crie um novo arquivo chamado `nft-metadata.json` e adicione o seguinte código json: ```json { "attributes": [ { - "trait_type": "Breed", + "trait_type": "Raça", "value": "Maltipoo" }, { - "trait_type": "Eye color", + "trait_type": "Cor dos olhos", "value": "Mocha" } ], - "description": "The world's most adorable and sensitive pup.", + "description": "O cachorrinho mais adorável e sensível do mundo.", "image": "ipfs://QmWmvTJmJU3pozR9ZHFmQC2DNDwi2XJtf3QGyYiiagFSWb", "name": "Ramses" } ``` -Sinta-se à vontade para mudar os dados no json. Você pode remover ou adicionar na seção de atributos. O mais importante é se certificar de que o campo de imagem aponta para a localização da sua imagem IPFS — caso contrário, seu NFT incluirá uma foto de um cachorro (bem bonito, por sinal). +Sinta-se à vontade para alterar os dados no json. Você pode remover ou adicionar itens à seção de atributos. O mais importante é se certificar de que o campo da imagem aponte para a localização da sua imagem IPFS — caso contrário, seu NFT incluirá a foto de um (muito fofo!) cachorro. -Uma vez terminada a edição do arquivo JSON, salve-o e faça o upload para o Pinata, seguindo os mesmos passos que fizemos para o upload da imagem. +Quando terminar de editar o arquivo JSON, salve-o e faça o upload para o Pinata, seguindo os mesmos passos que fizemos para o upload da imagem. -![Como fazer o upload de seu nft-metadata.json para Pinata](./uploadPinata.gif) +![Como fazer o upload do seu nft-metadata.json para o Pinata](./uploadPinata.gif) -## Etapa 5: Criar uma instância de seu contrato {#instance-contract} +## Etapa 5: Criar uma instância do seu contrato {#instance-contract} -Agora, para interagir com o nosso contrato, precisamos criar uma instância dele em nosso código. Para fazer isso, precisaremos do nosso endereço de contrato, obtido na implantação ou no [Etherscan](https://sepolia.etherscan.io/), procurando o endereço que você usou para implantar o contrato. +Agora, para interagir com o nosso contrato, precisamos criar uma instância dele em nosso código. Para fazer isso, precisaremos do endereço do nosso contrato, que podemos obter na implantação ou no [Blockscout](https://eth-sepolia.blockscout.com/), pesquisando o endereço que você usou para implantar o contrato. -![Veja o seu endereço de contrato no Etherscan](./view-contract-etherscan.png) +![Veja o endereço do seu contrato no Etherscan](./view-contract-etherscan.png) -No exemplo acima, o endereço do contrato é 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778. +No exemplo acima, o endereço do nosso contrato é 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778. -Em seguida, usaremos o [método do contrato](https://docs.web3js.org/api/web3-eth-contract/class/Contract) Web3 para criar nosso contrato usando a ABI e o endereço. Em seu arquivo `mint-nft.js`, adicione o seguinte: +A seguir, usaremos o [método de contrato](https://docs.web3js.org/api/web3-eth-contract/class/Contract) do Web3 para criar nosso contrato usando a ABI e o endereço. No seu arquivo `mint-nft.js`, adicione o seguinte: ```js const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" @@ -125,11 +123,11 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" const nftContract = new web3.eth.Contract(contract.abi, contractAddress) ``` -## Etapa 6: Atualize o arquivo `.env` {#update-env} +## Etapa 6: Atualizar o arquivo `.env` {#update-env} -Agora, para criar e enviar transações para a cadeia Ethereum, usaremos seu endereço de conta Ethereum para obter o nonce da conta (explicaremos abaixo). +Agora, para criar e enviar transações para a rede Ethereum, usaremos o endereço da sua conta pública do Ethereum para obter o nonce da conta (explicaremos abaixo). -Adicione sua chave pública ao seu arquivo `.env` — se você concluiu a parte 1 do tutorial, nosso arquivo `.env` deve ficar assim: +Adicione sua chave pública ao seu arquivo `.env` — se você concluiu a parte 1 do tutorial, nosso arquivo `.env` deve estar assim agora: ```js API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key" @@ -139,25 +137,25 @@ PUBLIC_KEY = "your-public-account-address" ## Etapa 7: Criar sua transação {#create-txn} -Primeiro, vamos definir a função nomeada `mintNFT(tokenData)` e criar nossa transação através do seguinte: +Primeiro, vamos definir uma função chamada `mintNFT(tokenData)` e criar nossa transação fazendo o seguinte: -1. Pegue a _PRIVATE_KEY_ e a _PUBLIC_KEY_ do arquivo `.env`. +1. Obtenha suas _PRIVATE_KEY_ e _PUBLIC_KEY_ do arquivo `.env`. -1. Em seguida, precisaremos descobrir qual é o nonce da conta. A especificação nonce é usada para acompanhar o número de transações enviadas a partir do seu endereço — que precisamos para fins de segurança e evitar [ataques de replay](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). Para obter o número de transações enviadas a partir do seu endereço, usamos [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount). +2. Em seguida, precisaremos descobrir qual é o nonce da conta. A especificação nonce é usada para acompanhar o número de transações enviadas a partir do seu endereço — o que precisamos para fins de segurança e para prevenir [ataques de replay](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). Para obter o número de transações enviadas a partir do seu endereço, usamos o [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount). -1. Finalmente, vamos configurar nossa transação com as seguintes informações: +3. Finalmente, vamos configurar nossa transação com as seguintes informações: -- `'from': PUBLIC_KEY`: a origem da nossa transação é nosso endereço público +- `'from': PUBLIC_KEY` — A origem da nossa transação é o nosso endereço público -- `'to': contractAddress`: o contrato com o qual queremos interagir e ao qual enviar a transação +- `'to': contractAddress` — O contrato com o qual desejamos interagir e para o qual enviar a transação - `'nonce': nonce` — O nonce da conta com o número de transações enviadas do nosso endereço -- `'gas': estimatedGas`: o gás estimado necessário para completar a transação +- `'gas': estimatedGas` — O gás estimado necessário para concluir a transação -- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()`: o cálculo que queremos realizar nesta transação que, neste caso, é cunhar um NFT +- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — A computação que desejamos realizar nesta transação, que neste caso é cunhar um NFT -Seu arquivo `mint-nft.js` deverá ficar assim: +Seu arquivo `mint-nft.js` deve estar assim agora: ```js require('dotenv').config(); @@ -173,9 +171,9 @@ Seu arquivo `mint-nft.js` deverá ficar assim: const nftContract = new web3.eth.Contract(contract.abi, contractAddress); async function mintNFT(tokenURI) { - const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); //get latest nonce + const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); //obter o nonce mais recente - //the transaction + //a transação const tx = { 'from': PUBLIC_KEY, 'to': contractAddress, @@ -190,7 +188,7 @@ Seu arquivo `mint-nft.js` deverá ficar assim: Agora que criamos a nossa transação, precisamos assiná-la para poder enviá-la. É aqui que usaremos nossa chave privada. -`web3.eth.sendSignedTransaction` nos dará o hash da transação, que podemos usar para ter certeza de que nossa transação foi minerada e não foi descartada pela rede. Você vai notar na seção de assinatura de transações que adicionamos alguma verificação de erro para saber se nossa transação foi processada com sucesso. +`web3.eth.sendSignedTransaction` nos dará o hash da transação, que podemos usar para garantir que nossa transação foi minerada e não foi descartada pela rede. Você notará que, na seção de assinatura da transação, adicionamos uma verificação de erros para que saibamos se a nossa transação foi concluída com sucesso. ```js require("dotenv").config() @@ -206,9 +204,9 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" const nftContract = new web3.eth.Contract(contract.abi, contractAddress) async function mintNFT(tokenURI) { - const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //get latest nonce + const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //obter o nonce mais recente - //the transaction + //a transação const tx = { from: PUBLIC_KEY, to: contractAddress, @@ -225,13 +223,13 @@ async function mintNFT(tokenURI) { function (err, hash) { if (!err) { console.log( - "The hash of your transaction is: ", + "O hash de sua transação é: ", hash, - "\nCheck Alchemy's Mempool to view the status of your transaction!" + "\nVerifique o Mempool da Alchemy para ver o status da sua transação!" ) } else { console.log( - "Something went wrong when submitting your transaction:", + "Algo deu errado ao enviar sua transação:", err ) } @@ -239,24 +237,24 @@ async function mintNFT(tokenURI) { ) }) .catch((err) => { - console.log(" Promise failed:", err) + console.log(" Falha na promessa:", err) }) } ``` -## Etapa 9: Chame `mintNFT` e execute o nó `mint-nft.js` {#call-mintnft-fn} +## Etapa 9: Chamar `mintNFT` e executar node `mint-nft.js` {#call-mintnft-fn} -Lembra do `metadata.json` que você carregou no Pinata? Obtenha o seu hashcode no Pinata e transmita o seguinte como parâmetro para a função `mintNFT` `https://gateway.pinata.cloud/ipfs/` +Lembra do arquivo `metadata.json` que você enviou para o Pinata? Obtenha seu hashcode do Pinata e passe o seguinte como parâmetro para a função `mintNFT`: `https://gateway.pinata.cloud/ipfs/` Veja como obter o hashcode: -![Como obter seu hashcode de metadados do nft no Pinata](./metadataPinata.gif)_Como obter seu hashcode de metadados do nft no Pinata_ +![Como obter o hashcode dos metadados do seu nft no Pinata](./metadataPinata.gif)_Como obter o hashcode dos metadados do seu nft no Pinata_ -> Verifique se o hashcode que você copiou se vincula ao **metadata.json** ao carregar `https://gateway.pinata.cloud/ipfs/` em uma janela separada. A página deve parecer semelhante à imagem abaixo: +> Verifique se o hashcode que você copiou leva ao seu **metadata.json** carregando `https://gateway.pinata.cloud/ipfs/` em uma janela separada. A página deve ser parecida com a captura de tela abaixo: ![Sua página deve exibir os metadados json](./metadataJSON.png)_Sua página deve exibir os metadados json_ -O código deve parecer com isso: +No total, seu código deve se parecer com isto: ```js require("dotenv").config() @@ -272,9 +270,9 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" const nftContract = new web3.eth.Contract(contract.abi, contractAddress) async function mintNFT(tokenURI) { - const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //get latest nonce + const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //obter o nonce mais recente - //the transaction + //a transação const tx = { from: PUBLIC_KEY, to: contractAddress, @@ -291,13 +289,13 @@ async function mintNFT(tokenURI) { function (err, hash) { if (!err) { console.log( - "The hash of your transaction is: ", + "O hash de sua transação é: ", hash, - "\nCheck Alchemy's Mempool to view the status of your transaction!" + "\nVerifique o Mempool da Alchemy para ver o status da sua transação!" ) } else { console.log( - "Something went wrong when submitting your transaction:", + "Algo deu errado ao enviar sua transação:", err ) } @@ -305,7 +303,7 @@ async function mintNFT(tokenURI) { ) }) .catch((err) => { - console.log("Promise failed:", err) + console.log("Falha na promessa:", err) }) } @@ -314,16 +312,18 @@ mintNFT("ipfs://QmYueiuRNmL4MiA2GwtVMm6ZagknXnSpQnB3z2gWbz36hP") Agora, execute `node scripts/mint-nft.js` para implantar seu NFT. Depois de alguns segundos, você deverá ver uma resposta como essa no seu terminal: - O hash de sua transação é: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8 + ``` + O hash da sua transação é: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8 - Verifique o Mempool da Alquemy para ver o estado da sua transação! + Verifique o Mempool da Alchemy para ver o status da sua transação! + ``` -Em seguida, acesse a [mempool (área de espera) da Alchemy](https://dashboard.alchemyapi.io/mempool) para ver o estado da sua transação (se pendente, minerada ou recusada pela rede). Se a sua transação se perdeu, também é útil verificar no [Sepolia Etherscan](https://sepolia.etherscan.io/) e procurar o hash da transação. +Em seguida, visite o [mempool da Alchemy](https://dashboard.alchemyapi.io/mempool) para ver o status da sua transação (se está pendente, minerada ou foi descartada pela rede). Se sua transação for descartada, também é útil verificar o [Blockscout](https://eth-sepolia.blockscout.com/) e pesquisar pelo hash da sua transação. -![Veja seu hash de transação NFT no Etherscan](./view-nft-etherscan.png)_Veja seu hash de transação NFT no Etherscan_ +![Veja o hash da transação do seu NFT no Etherscan](./view-nft-etherscan.png)_Veja o hash da transação do seu NFT no Etherscan_ -E pronto! Você agora implantou E cunhou um NFT na blockchain Ethereum +E é isso! Você implantou E cunhou um NFT na blockchain Ethereum -Using the `mint-nft.js` you can mint as many NFTs as your heart (and wallet) desires! Apenas certifique-se de transmitir um novo tokenURI descrevendo os metadados do NFT (caso contrário, você acaba criando um monte de identificações idênticas, com IDs diferentes). +Usando o `mint-nft.js`, você pode cunhar quantos NFTs seu coração (e sua carteira) desejar! Apenas certifique-se de passar um novo tokenURI descrevendo os metadados do NFT (caso contrário, você acabará criando um monte de NFTs idênticos com IDs diferentes). -Provavelmente você gostaria de poder exibir seu NFT na sua carteira — então certifique-se de conferir [Parte 3: Como ver seu NFT na sua carteira](/developers/tutorials/how-to-view-nft-in-metamask/)! +Provavelmente, você gostaria de poder exibir seu NFT em sua carteira — então não deixe de conferir a [Parte 3: Como visualizar seu NFT em sua carteira](/developers/tutorials/how-to-view-nft-in-metamask/)! diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md index 02f4bea1fb4..75db3d8bbfa 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md @@ -1,30 +1,26 @@ --- title: Como simular contratos inteligentes em Solidity para teste -description: Por que você deve aproveitar os seus contratos ao testar +description: "Por que você deve aproveitar os seus contratos ao testar" author: Markus Waas lang: pt-br -tags: - - "solidez" - - "contratos inteligentes" - - "testando" - - "simulando" +tags: [ "Solidity", "smart contracts", "testando", "simulando" ] skill: intermediate published: 2020-05-02 source: soliditydeveloper.com sourceUrl: https://soliditydeveloper.com/mocking-contracts --- -[Mock de objetos ](https://wikipedia.org/wiki/Mock_object) são um padrão de design comum na programação orientada a objetos. Vindo da velha palavra francesa "mocquer" com o significado de "diversão de", evoluiu para a "imitação de algo real", que é na realidade, o que estamos fazendo na programação. Por favor, só se divirta de seus contratos inteligentes se você quiser, mas faça o mock deles sempre que puder. Isso torna sua vida mais fácil. +[Objetos mock](https://wikipedia.org/wiki/Mock_object) são um padrão de design comum na programação orientada a objetos. Vindo da velha palavra francesa "mocquer" com o significado de "diversão de", evoluiu para a "imitação de algo real", que é na realidade, o que estamos fazendo na programação. Por favor, só se divirta de seus contratos inteligentes se você quiser, mas faça o mock deles sempre que puder. Isso torna sua vida mais fácil. -## Testes de unidade de contratos com simulações {#unit-testing-contracts-with-mocks} +## Teste de unidade de contratos com mocks {#unit-testing-contracts-with-mocks} -Simular um contrato (mocking) significa essencialmente criar uma segunda versão desse contrato que se comporta de maneira muito semelhante ao original, mas de uma maneira que pode ser facilmente controlada pelo desenvolvedor. Muitas vezes, você acaba com contratos complexos nos quais você só quer [fazer testes de unidade de pequenas partes do contrato](/developers/docs/smart-contracts/testing/). O problema é: e se o teste desta pequena parte exigir um estado de contrato muito específico que seja difícil de alcançar? +Simular um contrato (mocking) significa essencialmente criar uma segunda versão desse contrato que se comporta de maneira muito semelhante ao original, mas de uma maneira que pode ser facilmente controlada pelo desenvolvedor. Muitas vezes, você acaba com contratos complexos nos quais só quer [fazer o teste de unidade de pequenas partes do contrato](/developers/docs/smart-contracts/testing/). O problema é: e se o teste desta pequena parte exigir um estado de contrato muito específico que seja difícil de alcançar? Você poderia escrever uma lógica de configuração de testes complexa toda vez que apresentasse o contrato no estado necessário ou você escreveria uma simulação (mock, em inglês). Simular um contrato é fácil com herança. Basta criar um segundo contrato mock que herda do original. Agora você pode substituir funções de seu mock. Vejamos com um exemplo. -## Exemplo: ERC20 Privado {#example-private-erc20} +## Exemplo: Private ERC20 {#example-private-erc20} -Usamos um exemplo de contrato ERC-20 que tem um tempo privado inicial. O proprietário pode gerenciar usuários privados e apenas esses terão permissão para receber tokens no início. Uma vez que um certo tempo tenha passado, todos poderão utilizar os tokens. Se você estiver curioso, estamos usando o hook (código modificado) [`_beforeTokenTransfer`](https://docs.openzeppelin.com/contracts/5.x/extending-contracts#using-hooks) dos novos contratos OpenZeppelin v3. +Usamos um exemplo de contrato ERC-20 que tem um tempo privado inicial. O proprietário pode gerenciar usuários privados e apenas esses terão permissão para receber tokens no início. Uma vez que um certo tempo tenha passado, todos poderão utilizar os tokens. Se tiver curiosidade, estamos usando o hook [`_beforeTokenTransfer`](https://docs.openzeppelin.com/contracts/5.x/extending-contracts#using-hooks) dos novos contratos v3 da OpenZeppelin. ```solidity pragma solidity ^0.6.0; @@ -51,7 +47,7 @@ contract PrivateERC20 is ERC20, Ownable { function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override { super._beforeTokenTransfer(from, to, amount); - require(_validRecipient(to), "PrivateERC20: invalid recipient"); + require(_validRecipient(to), "PrivateERC20: destinatário inválido"); } function _validRecipient(address to) private view returns (bool) { @@ -90,17 +86,17 @@ Você receberá uma das seguintes mensagens de erro: - `PrivateERC20Mock.sol: TypeError: Overriding function is missing "override" specifier.` - `PrivateERC20.sol: TypeError: Trying to override non-virtual function. Did you forget to add "virtual"?.` -Como estamos usando a nova versão 0.6 do Solidity, temos que adicionar a palavra-chave `virtual` para funções que podem ser sobrescritas e substituídas pela função substituta. Então vamos adicioná-los para ambas as funções `isPublic`. +Como estamos usando a nova versão 0.6 do Solidity, temos que adicionar a palavra-chave `virtual` para funções que podem ser sobrescritas e `override` para a função de sobrescrita. Então, vamos adicioná-los a ambas as funções `isPublic`. -Agora você pode usar `PrivateERC20Mock` nos seus testes de unidade. Quando você quiser testar o comportamento durante o tempo de uso privado, use `setIsPublic(false)` e, da mesma forma, `setIsPublic(true)` para testar o tempo de uso público. É claro que em nosso exemplo, poderíamos usar simplesmente [auxiliares de tempo](https://docs.openzeppelin.com/test-helpers/0.5/api#increase) para alterar os tempos de acordo também. Mas a ideia de mocking deve estar clara agora e você pode imaginar cenários em que não é tão fácil quanto simplesmente avançar no tempo. +Agora, em seus testes de unidade, você pode usar o `PrivateERC20Mock`. Quando você quiser testar o comportamento durante o tempo de uso privado, use `setIsPublic(false)` e, da mesma forma, `setIsPublic(true)` para testar o tempo de uso público. Claro que, em nosso exemplo, também poderíamos usar [auxiliares de tempo](https://docs.openzeppelin.com/test-helpers/0.5/api#increase) para alterar os horários de acordo. Mas a ideia de mocking deve estar clara agora e você pode imaginar cenários em que não é tão fácil quanto simplesmente avançar no tempo. -## Mocking em muitos contratos {#mocking-many-contracts} +## Fazendo mock de muitos contratos {#mocking-many-contracts} -Pode ficar confuso se você tiver que criar outro contrato para cada mock. Se isso incomoda você, dê uma olhada na biblioteca [MockContract](https://github.com/gnosis/mock-contract). Ele permite que você sobrescreva e modifique comportamentos de contratos em tempo real. No entanto, ele só funciona para chamadas mocking para outro contrato, portanto, não funcionaria para o nosso exemplo. +Pode ficar confuso se você tiver que criar outro contrato para cada mock. Se isso o incomoda, você pode dar uma olhada na biblioteca [MockContract](https://github.com/gnosis/mock-contract). Ele permite que você sobrescreva e modifique comportamentos de contratos em tempo real. No entanto, ele só funciona para chamadas mocking para outro contrato, portanto, não funcionaria para o nosso exemplo. -## Mocking podem ser ainda mais poderosas {#mocking-can-be-even-more-powerful} +## O mocking pode ser ainda mais poderoso {#mocking-can-be-even-more-powerful} Os poderes de mocking não terminam aí. -- Adicionando funções: sobrescrever uma função específica é útil, mas apenas acrescentar funções adicionais também poderá ser. Um bom exemplo para tokens é ter apenas uma função adicional `mint` para permitir que qualquer usuário obtenha novos tokens gratuitamente. +- Adicionando funções: sobrescrever uma função específica é útil, mas apenas acrescentar funções adicionais também poderá ser. Um bom exemplo para tokens é simplesmente ter uma função `mint` adicional para permitir que qualquer usuário obtenha novos tokens gratuitamente. - Uso em testnets: ao implantar e testar seus contratos em testnets juntamente com seu Dapp, considere usar uma versão mock. Evite sobrescrever funções, a menos que você realmente precise. Afinal, você quer testar a lógica real. Mas adicionar, por exemplo, uma função de redefinição pode ser útil que simplesmente redefine o estado do contrato para o início, sem necessidade de nova implantação. Obviamente, você não gostaria de ter isso em um contrato na mainnet (rede principal). diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md index 3cb13dcff28..8c54fb967c0 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md @@ -4,31 +4,33 @@ description: Como usar o Echidna para testar automaticamente contratos inteligen author: "Trailofbits" lang: pt-br tags: - - "solidez" - - "smart contracts" - - "segurança" - - "testando" - - "fuzzing" + [ + "Solidity", + "smart contracts", + "segurança", + "testando", + "fuzzing" + ] skill: advanced published: 2020-04-10 -source: Construindo contratos seguros +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna --- ## Instalação {#installation} -Echidna pode ser instalado através do docker ou usando o binário pré-compilado. +O Echidna pode ser instalado através do docker ou usando o binário pré-compilado. -### Echidna com docker {#echidna-through-docker} +### Echidna através do docker {#echidna-through-docker} ```bash docker pull trailofbits/eth-security-toolbox docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox ``` -_O último comando roda a eth-security-toolbox em um docker que tem acesso ao seu diretório atual. Você pode alterar os arquivos do seu host e executar as ferramentas nos arquivos através do docker_ +_O último comando executa o eth-security-toolbox em um docker que tem acesso ao seu diretório atual. Você pode alterar os arquivos do seu host e executar as ferramentas nos arquivos do docker_ -Dentro do docker, execute : +Dentro do docker, execute: ```bash solc-select 0.5.11 @@ -39,33 +41,33 @@ cd /home/training [https://github.com/crytic/echidna/releases/tag/v1.4.0.0](https://github.com/crytic/echidna/releases/tag/v1.4.0.0) -## Introdução a fuzzing baseado em propriedade {#introduction-to-property-based-fuzzing} +## Introdução ao fuzzing baseado em propriedade {#introduction-to-property-based-fuzzing} -Echidna é um fuzzer baseado em propriedades, descrevemos em nossos posts anteriores ([1](https://blog.trailofbits.com/2018/03/09/echidna-a-smart-fuzzer-for-ethereum/), [2](https://blog.trailofbits.com/2018/05/03/state-machine-testing-with-echidna/), [3](https://blog.trailofbits.com/2020/03/30/an-echidna-for-all-seasons/)). +O Echidna é um fuzzer baseado em propriedade, que descrevemos em nossas postagens de blog anteriores ([1](https://blog.trailofbits.com/2018/03/09/echidna-a-smart-fuzzer-for-ethereum/), [2](https://blog.trailofbits.com/2018/05/03/state-machine-testing-with-echidna/), [3](https://blog.trailofbits.com/2020/03/30/an-echidna-for-all-seasons/)). ### Fuzzing {#fuzzing} -[Fuzzing](https://wikipedia.org/wiki/Fuzzing) é uma técnica bem conhecida na comunidade de segurança. It consists of generating inputs that are more or less random to find bugs in the program. Fuzzers por software tradicional (como [AFL](http://lcamtuf.coredump.cx/afl/) ou [LibFuzzer](https://llvm.org/docs/LibFuzzer.html)) são conhecidos por serem ferramentas eficientes para encontrar bugs. +[Fuzzing](https://wikipedia.org/wiki/Fuzzing) é uma técnica bem conhecida na comunidade de segurança. Consiste em gerar entradas que são mais ou menos aleatórias para encontrar bugs no programa. Fuzzers para software tradicional (como [AFL](http://lcamtuf.coredump.cx/afl/) ou [LibFuzzer](https://llvm.org/docs/LibFuzzer.html)) são conhecidos por serem ferramentas eficientes para encontrar bugs. -Além da geração aleatória de entradas, há muitas técnicas e estratégias para gerar bons inputs, incluindo: +Além da geração puramente aleatória de entradas, existem muitas técnicas e estratégias para gerar boas entradas, incluindo: -- Obtenha feedback de cada execução e geração de guias usando-o. Por exemplo, se uma entrada recém-gerada leva à descoberta de um novo caminho, ele pode fazer sentido para gerar novas entradas fechadas a ele. -- Geração da entrada respeitando uma restrição estrutural. Por exemplo, se a sua entrada contiver um cabeçalho com uma soma de verificação, fará sentido deixar o difusor gerar uma entrada validando a soma de verificação. -- Usando entradas conhecidas para gerar novas entradas: se você tem acesso a um grande conjunto de dados de entrada válida, seu difusor pode gerar novas entradas a partir deles, ao invés de começar sua geração do zero. Eles geralmente são chamados de _seeds_. +- Obter feedback de cada execução e usá-lo para guiar a geração. Por exemplo, se uma entrada recém-gerada levar à descoberta de um novo caminho, pode fazer sentido gerar novas entradas próximas a ela. +- Gerar a entrada respeitando uma restrição estrutural. Por exemplo, se sua entrada contiver um cabeçalho com um checksum, fará sentido deixar que o fuzzer gere uma entrada que valide o checksum. +- Usar entradas conhecidas para gerar novas entradas: se você tiver acesso a um grande conjunto de dados de entrada válida, seu fuzzer pode gerar novas entradas a partir deles, em vez de iniciar sua geração do zero. Normalmente, são chamadas de _seeds_. ### Fuzzing baseado em propriedade {#property-based-fuzzing} -Echidna pertence a uma família específica de fuzzer: fuzzing baseada em propriedades fortemente inspirada pelo [QuickCheck](https://wikipedia.org/wiki/QuickCheck). Em contraste com o fuzzing clássico que tentará encontrar falhas, Echidna tentará quebrar invariantes definidos pelo usuário. +O Echidna pertence a uma família específica de fuzzer: fuzzing baseado em propriedade, fortemente inspirado pelo [QuickCheck](https://wikipedia.org/wiki/QuickCheck). Em contraste com o fuzzer clássico, que tentará encontrar falhas, o Echidna tentará quebrar invariantes definidos pelo usuário. -Nos contratos inteligentes, invariantes são funções Solidity, que podem representar qualquer estado incorreto ou inválido que o contrato possa alcançar, incluindo: +Em contratos inteligentes, as invariantes são funções do Solidity que podem representar qualquer estado incorreto ou inválido que o contrato possa alcançar, incluindo: -- Controle de acesso incorreto: quem ataca tornou-se o proprietário do contrato. -- Máquina de estado incorreta: os tokens podem ser transferidos enquanto o contrato é pausado. -- Aritmética incorreta: o usuário pode passar abaixo do saldo e obter tokens gratuitos ilimitados. +- Controle de acesso incorreto: o invasor tornou-se o proprietário do contrato. +- Máquina de estado incorreta: os tokens podem ser transferidos enquanto o contrato está pausado. +- Aritmética incorreta: o usuário pode causar um underflow em seu saldo e obter tokens gratuitos ilimitados. -### Testando uma propriedade com Echidna {#testing-a-property-with-echidna} +### Testando uma propriedade com o Echidna {#testing-a-property-with-echidna} -Veremos como testar um contrato inteligente com o Echidna. O alvo é o seguinte contrato inteligente [`exemplo.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol): +Veremos como testar um contrato inteligente com o Echidna. O alvo é o seguinte contrato inteligente [`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol): ```solidity contract Token{ @@ -83,26 +85,26 @@ contract Token{ } ``` -Assumiremos que esse token deve ter as seguintes propriedades: +Vamos supor que este token deva ter as seguintes propriedades: -- Qualquer um pode ter no máximo 1000 tokens +- Qualquer pessoa pode ter no máximo 1.000 tokens - O token não pode ser transferido (não é um token ERC20) -### Escrever uma propriedade {#write-a-property} +### Escreva uma propriedade {#write-a-property} -Propriedades do Echidna são funções de Solidity. Uma propriedade deve: +As propriedades do Echidna são funções do Solidity. Uma propriedade deve: -- Ter nenhum argumento -- Retornar `verdadeiro` se for bem sucedido -- Tenha seu nome começando com `echidna` +- Não ter argumentos +- Retornar `true` se for bem-sucedida +- Ter seu nome começando com `echidna` -Echidna irá: +O Echidna irá: -- Gera automaticamente transações arbitrárias para testar a propriedade. -- Relata quaisquer transações que levem uma propriedade para retornar `` falso ou lançar um erro. -- Descartar efeito lateral ao chamar uma propriedade (ou seja, se a propriedade altera uma variável de estado, ela é descartada após o teste) +- Gerar automaticamente transações arbitrárias para testar a propriedade. +- Relatar quaisquer transações que levem uma propriedade a retornar `false` ou a lançar um erro. +- Descartar o efeito colateral ao chamar uma propriedade (ou seja, se a propriedade alterar uma variável de estado, ela será descartada após o teste) -A propriedade a seguir verifica que o "caller" não possui mais do que 1000 tokens: +A propriedade a seguir verifica se o chamador não tem mais de 1.000 tokens: ```solidity function echidna_balance_under_1000() public view returns(bool){ @@ -120,36 +122,36 @@ contract TestToken is Token{ } ``` -[`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol) implementa a propriedade e herda do token. +O [`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol) implementa a propriedade e herda do token. ### Iniciar um contrato {#initiate-a-contract} -Echidna precisa de um [constructor](/developers/docs/smart-contracts/anatomy/#constructor-functions) sem argumento. Se seu contrato precisa de uma inicialização específica, você precisa fazê-lo no construtor. +O Echidna precisa de um [construtor](/developers/docs/smart-contracts/anatomy/#constructor-functions) sem argumentos. Se seu contrato precisar de uma inicialização específica, você precisará fazê-la no construtor. -Há alguns endereços específicos no Echidna: +Existem alguns endereços específicos no Echidna: -- `0x00a329c0648769A73afAc7F9381E08FB43dBEA72` que chama o constructor. -- `0x10000`, `0x20000`, e `0x00a329C0648769a73afAC7F9381e08fb43DBEA70` que aleatoriamente chama as outras funções. +- `0x00a329c0648769A73afAc7F9381E08FB43dBEA72`, que chama o construtor. +- `0x10000`, `0x20000` e `0x00a329C0648769a73afAC7F9381e08fb43DBEA70`, que chamam aleatoriamente as outras funções. -Nós não precisamos de nenhuma inicialização específica em nosso exemplo atual, como resultado, nosso construtor está vazio. +Não precisamos de nenhuma inicialização específica em nosso exemplo atual, como resultado, nosso construtor está vazio. -### Executando Echidna {#run-echidna} +### Executar o Echidna {#run-echidna} -Echidna foi lançado com: +O Echidna é iniciado com: ```bash echidna-test contract.sol ``` -Se o contract.sol contém múltiplos contratos, você pode especificar o alvo: +Se contract.sol contiver vários contratos, você pode especificar o alvo: ```bash echidna-test contract.sol --contract MyContract ``` -### Resumo: Testando uma propriedade {#summary-testing-a-property} +### Resumo: testando uma propriedade {#summary-testing-a-property} -O seguinte resumo é a execução de Echidna no nosso exemplo: +O texto a seguir resume a execução do Echidna em nosso exemplo: ```solidity contract TestToken is Token{ @@ -164,19 +166,20 @@ contract TestToken is Token{ echidna-test testtoken.sol --contract TestToken ... -echidna_balance_under_1000: failed!💥 - Call sequence, shrinking (1205/5000): +echidna_balance_under_1000: falhou!💥 + Sequência de chamadas, encolhendo (1205/5000): airdrop() backdoor() ... ``` -Echidna descobriu que a propriedade é violada se `backdoor` é chamada. +O Echidna descobriu que a propriedade é violada se `backdoor` for chamado. ## Filtrando funções para chamar durante uma campanha de fuzzing {#filtering-functions-to-call-during-a-fuzzing-campaign} -Veremos como filtrar as funções a serem "fuzzed". O alvo é o seguinte contrato inteligente: +Veremos como filtrar as funções que sofrerão fuzzing. +O alvo é o seguinte contrato inteligente: ```solidity contract C { @@ -227,56 +230,60 @@ contract C { } ``` -Este pequeno exemplo força Echidna a encontrar uma determinada sequência de transações para alterar uma variável de estado. Isso é difícil para um fuzzer (é recomendado usar uma ferramenta de execução simbólica como [Manticore](https://github.com/trailofbits/manticore)). Podemos executar o Echidna para verificar isto: +Este pequeno exemplo força o Echidna a encontrar uma determinada sequência de transações para alterar uma variável de estado. +Isso é difícil para um fuzzer (recomenda-se usar uma ferramenta de execução simbólica como o [Manticore](https://github.com/trailofbits/manticore)). +Podemos executar o Echidna para verificar isso: ```bash echidna-test multi.sol ... -echidna_state4: passed! 🎉 +echidna_state4: passou! 🎉 Seed: -3684648582249875403 ``` -### Filtrando funções {#filtering-functions} +### Funções de filtragem {#filtering-functions} -Echidna tem problemas para encontrar a sequência correta para testar esse contrato, porque as duas funções de redefinição (`reset1` e `reset2`) definirão todas as variáveis de estado como `false`. No entanto, podemos usar um recurso especial Echidna para ou para a lista negra redefinir a função ou apenas para a lista branca `f`, `g`, `h` e `i` funções. +O Echidna tem dificuldade em encontrar a sequência correta para testar este contrato porque as duas funções de redefinição (`reset1` e `reset2`) definirão todas as variáveis de estado como `false`. +No entanto, podemos usar um recurso especial do Echidna para adicionar as funções de redefinição à lista de bloqueio ou para adicionar apenas as funções `f`, `g`, +`h` e `i` à lista de permissões. -Para funções da lista negra, podemos usar esse arquivo de configuração: +Para adicionar funções à lista de bloqueio, podemos usar este arquivo de configuração: ```yaml filterBlacklist: true filterFunctions: ["reset1", "reset2"] ``` -Outra abordagem para as funções de filtro é listar as funções na lista branca. Para fazer isso, podemos usar este arquivo de configuração: +Outra abordagem para filtrar funções é listar as funções permitidas. Para fazer isso, podemos usar este arquivo de configuração: ```yaml filterBlacklist: false filterFunctions: ["f", "g", "h", "i"] ``` -- `filterBlacklist` é `verdadeiro` por padrão. -- A filtragem será executada apenas por nome (sem parâmetros). Se você tiver `f()` e `f(uint256)`, o filtro `"f"` corresponderá a ambas as funções. +- `filterBlacklist` é `true` por padrão. +- A filtragem será realizada apenas por nome (sem parâmetros). Se você tiver `f()` e `f(uint256)`, o filtro `"f"` corresponderá a ambas as funções. -### Executar Echidna {#run-echidna-1} +### Executar o Echidna {#run-echidna-1} -Para executar Echidna com um arquivo de configuração `blacklist.yaml`: +Para executar o Echidna com um arquivo de configuração `blacklist.yaml`: ```bash echidna-test multi.sol --config blacklist.yaml ... -echidna_state4: failed!💥 - Call sequence: +echidna_state4: falhou!💥 + Sequência de chamadas: f(12) g(8) h(42) i() ``` -Echidna vai encontrar a sequência de transações para falsificar a propriedade quase de forma mesquinha. +O Echidna encontrará a sequência de transações para falsear a propriedade quase imediatamente. -### Resumo: Filtrando funções {#summary-filtering-functions} +### Resumo: funções de filtragem {#summary-filtering-functions} -Echidna pode ser chamada na lista negra ou na lista branca durante uma campanha de fuzzing: +O Echidna pode adicionar funções a uma lista de bloqueio ou a uma lista de permissões para chamar durante uma campanha de fuzzing usando: ```yaml filterBlacklist: true @@ -288,11 +295,11 @@ echidna-test contract.sol --config config.yaml ... ``` -Echidna inicia uma campanha de fuzzing em qualquer blacklist `f1`, `f2` e `f3` ou apenas chamando a eles, de acordo com o valor do booleano `filterBlacklist`. +O Echidna inicia uma campanha de fuzzing adicionando `f1`, `f2` e `f3` à lista de bloqueio ou chamando apenas essas funções, de acordo com o valor do booleano `filterBlacklist`. -## Como testar a asserção de Solidity com Echidna {#how-to-test-soliditys-assert-with-echidna} +## Como testar a asserção do Solidity com o Echidna {#how-to-test-soliditys-assert-with-echidna} -Neste breve tutorial, vamos mostrar como usar o Echidna para testar a verificação de asserção em contratos. Vamos supor que tenhamos um contrato como este: +Neste breve tutorial, vamos mostrar como usar o Echidna para testar a verificação de asserções em contratos. Vamos supor que tenhamos um contrato como este: ```solidity contract Incrementor { @@ -307,9 +314,10 @@ contract Incrementor { } ``` -### Escreva uma asserção {#write-an-assertion} +### Escrever uma asserção {#write-an-assertion} -Queremos ter certeza de que `tmp` é menor ou igual a `contador` depois de retornar a sua diferença. Nós poderíamos escrever uma propriedade de Echidna, mas precisaremos armazenar o valor de `tmp` em algum lugar. Em vez disso, poderíamos usar uma asserção como esta: +Queremos ter certeza de que `tmp` é menor ou igual a `counter` depois de retornar sua diferença. Poderíamos escrever uma +propriedade do Echidna, mas precisaríamos armazenar o valor `tmp` em algum lugar. Em vez disso, poderíamos usar uma asserção como esta: ```solidity contract Incrementor { @@ -324,15 +332,15 @@ contract Incrementor { } ``` -### Executando Echidna {#run-echidna-2} +### Executar o Echidna {#run-echidna-2} -Para habilitar o teste de falha de asserção, crie um arquivo de configuração [Echidna](https://github.com/crytic/echidna/wiki/Config) `config.yaml`: +Para habilitar o teste de falha de asserção, crie um [arquivo de configuração do Echidna](https://github.com/crytic/echidna/wiki/Config) `config.yaml`: ```yaml checkAsserts: true ``` -Quando executamos este contrato em Echidna, obtemos os resultados esperados: +Quando executamos este contrato no Echidna, obtemos os resultados esperados: ```bash echidna-test assert.sol --config config.yaml @@ -346,11 +354,11 @@ assertion in inc: failed!💥 Seed: 1806480648350826486 ``` -Como você pode ver, Echidna relata algumas falhas de afirmação na função `inc`. Adicionar mais de uma asserção por função é possível, mas Echidna não pode dizer qual afirmação falhou. +Como você pode ver, o Echidna relata alguma falha de asserção na função `inc`. Adicionar mais de uma asserção por função é possível, mas o Echidna não consegue dizer qual asserção falhou. ### Quando e como usar asserções {#when-and-how-use-assertions} -As asserções podem ser usadas como alternativas às propriedades explícitas, se as condições a serem verificadas estão diretamente relacionadas com o uso correto de alguma operação `f`. Adicionar asserções após algum código forçará que a verificação ocorra imediatamente após sua execução: +As asserções podem ser usadas como alternativas a propriedades explícitas, especialmente se as condições a serem verificadas estiverem diretamente relacionadas ao uso correto de alguma operação `f`. Adicionar asserções após algum código garantirá que a verificação ocorra imediatamente após sua execução: ```solidity function f(..) public { @@ -362,7 +370,7 @@ function f(..) public { ``` -Pelo contrário, usando uma propriedade Echidna explícita irá executar transações aleatoriamente e não há maneira fácil de aplicar exatamente quando elas serão verificadas. Ainda é possível fazer esta solução alternativa: +Pelo contrário, o uso de uma propriedade explícita do Echidna executará transações aleatoriamente e não há uma maneira fácil de forçar exatamente quando ela será verificada. Ainda é possível fazer esta solução alternativa: ```solidity function echidna_assert_after_f() public returns (bool) { @@ -371,22 +379,22 @@ function echidna_assert_after_f() public returns (bool) { } ``` -Entretanto, existem alguns problemas: %\{issues}: +No entanto, há alguns problemas: -- Ele falha se `f` é declarado como `interno` ou `externo`. +- Falha se `f` for declarada como `internal` ou `external`. - Não está claro quais argumentos devem ser usados para chamar `f`. -- Se `f` reverter, a propriedade irá falhar. +- Se `f` reverter, a propriedade falhará. -Em geral, recomendamos seguir a recomendação de [John Regehr](https://blog.regehr.org/archives/1091) sobre como usar asserções: +Em geral, recomendamos seguir a [recomendação de John Regehr](https://blog.regehr.org/archives/1091) sobre como usar asserções: -- Não force qualquer efeito colateral durante a verificação de asserção. Por exemplo: `assert(ChangeStateAndReturn() == 1)` +- Não force nenhum efeito colateral durante a verificação de asserção. Por exemplo: `assert(ChangeStateAndReturn() == 1)` - Não faça asserções óbvias. Por exemplo, `assert(var >= 0)` onde `var` é declarado como `uint`. -Finalmente, **não use** `require` em vez de `assert`, já que Echidna não será capaz de detectá-lo (mas o contrato será revertido mesmo assim). +Finalmente, **não use** `require` em vez de `assert`, pois o Echidna não será capaz de detectá-lo (mas o contrato será revertido de qualquer maneira). -### Resumo: checando a asserção {#summary-assertion-checking} +### Resumo: verificação de asserção {#summary-assertion-checking} -O seguinte resumo é a execução de Echidna no nosso exemplo: +O texto a seguir resume a execução do Echidna em nosso exemplo: ```solidity contract Incrementor { @@ -413,11 +421,11 @@ assertion in inc: failed!💥 Seed: 1806480648350826486 ``` -Echidna percebeu que a asserção em `inc` pode falhar se essa função é chamada várias vezes com argumentos grandes. +O Echidna descobriu que a asserção em `inc` pode falhar se essa função for chamada várias vezes com argumentos grandes. -## Coletando e modificando um corpus Echidna {#collecting-and-modifying-an-echidna-corpus} +## Coletando e modificando um corpus do Echidna {#collecting-and-modifying-an-echidna-corpus} -Veremos como coletar e usar um corpus de transações com Echidna. O alvo é o seguinte contrato inteligente [`exemplo.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/magic.sol): +Veremos como coletar e usar um corpus de transações com o Echidna. O alvo é o seguinte contrato inteligente [`magic.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/magic.sol): ```solidity contract C { @@ -437,41 +445,44 @@ contract C { } ``` -Este pequeno exemplo força Echidna a encontrar uma determinada sequência de transações para alterar uma variável de estado. Isso é difícil para um fuzzer (é recomendado usar uma ferramenta de execução simbólica como [Manticore](https://github.com/trailofbits/manticore)). Podemos executar o Echidna para verificar isto: +Este pequeno exemplo força o Echidna a encontrar determinados valores para alterar uma variável de estado. Isso é difícil para um fuzzer +(recomenda-se usar uma ferramenta de execução simbólica como o [Manticore](https://github.com/trailofbits/manticore)). +Podemos executar o Echidna para verificar isso: ```bash echidna-test magic.sol ... -echidna_magic_values: passed! 🎉 +echidna_magic_values: passou! 🎉 Seed: 2221503356319272685 ``` -No entanto, ainda podemos usar o Echidna para coletar corpus na condução desta campanha de fuzzing. +No entanto, ainda podemos usar o Echidna para coletar o corpus ao executar esta campanha de fuzzing. ### Coletando um corpus {#collecting-a-corpus} -Para habilitar a coleção de corpus, crie um diretório corpus: +Para habilitar a coleta de corpus, crie um diretório de corpus: ```bash mkdir corpus-magic ``` -E um [arquivo de configuração Echidna](https://github.com/crytic/echidna/wiki/Config) `config.yaml`: +E um [arquivo de configuração do Echidna](https://github.com/crytic/echidna/wiki/Config) `config.yaml`: ```yaml coverage: true corpusDir: "corpus-magic" ``` -Agora podemos rodar nossa ferramenta e checar o corpus coletado: +Agora podemos executar nossa ferramenta e verificar o corpus coletado: ```bash echidna-test magic.sol --config config.yaml ``` -Echidna ainda não conseguiu encontrar os valores mágicos corretos, mas podemos olhar para o corpus que ele coletou. Por exemplo, um desses arquivos foi: +O Echidna ainda não consegue encontrar os valores mágicos corretos, mas podemos dar uma olhada no corpus que ele coletou. +Por exemplo, um desses arquivos era: ```json [ @@ -516,17 +527,18 @@ Echidna ainda não conseguiu encontrar os valores mágicos corretos, mas podemos ] ``` -Claramente, esse input não causará falha em nossa propriedade. No entanto, no próximo passo, veremos como modificá-lo nesse sentido. +Claramente, essa entrada não acionará a falha em nossa propriedade. No entanto, na próxima etapa, veremos como modificá-lo para isso. ### Semeando um corpus {#seeding-a-corpus} -Echidna precisa de ajuda para lidar com a função `mágica`. Vamos copiar e modificar a entrada para usar os parâmetros adequados para ele: +O Echidna precisa de ajuda para lidar com a função `magic`. Vamos copiar e modificar a entrada para usar parâmetros +adequados para ela: ```bash cp corpus/2712688662897926208.txt corpus/new.txt ``` -Nós iremos modificar `new.txt` para chamar `mágica(42,129,333,0)`. Agora, podemos reexecutar o Echidna: +Modificaremos o `new.txt` para chamar `magic(42,129,333,0)`. Agora, podemos executar novamente o Echidna: ```bash echidna-test magic.sol --config config.yaml @@ -542,11 +554,11 @@ Seed: -7293830866560616537 ``` -Desta vez, constatou que a propriedade é violada imediatamente. +Desta vez, descobriu que a propriedade é violada imediatamente. -## Localizando transações com alto consumo de gas {#finding-transactions-with-high-gas-consumption} +## Encontrando transações com alto consumo de gás {#finding-transactions-with-high-gas-consumption} -Veremos como encontrar as transações com alto consumo de gas com o Echidna. O alvo é o seguinte contrato inteligente: +Veremos como encontrar as transações com alto consumo de gás com o Echidna. O alvo é o seguinte contrato inteligente: ```solidity contract C { @@ -571,21 +583,22 @@ contract C { } ``` -Aqui `caro` pode ter um grande consumo de gas. +Aqui, `expensive` pode ter um grande consumo de gás. -Atualmente, Echidna sempre precisa de uma propriedade para testar: aqui `echidna_test` sempre retorna `true`. Podemos executar o Echidna para verificar isto: +Atualmente, o Echidna sempre precisa de uma propriedade para testar: aqui, `echidna_test` sempre retorna `true`. +Podemos executar o Echidna para verificar isso: ``` echidna-test gas.sol ... -echidna_test: passed! 🎉 +echidna_test: passou! 🎉 Seed: 2320549945714142710 ``` -### Medição do consumo de gas {#measuring-gas-consumption} +### Medindo o consumo de gás {#measuring-gas-consumption} -Para habilitar o consumo de gas com Echidna, crie um arquivo de configuração `config.yaml`: +Para habilitar o consumo de gás com o Echidna, crie um arquivo de configuração `config.yaml`: ```yaml estimateGas: true @@ -598,9 +611,9 @@ seqLen: 2 estimateGas: true ``` -### Executando Echidna {#run-echidna-3} +### Executar o Echidna {#run-echidna-3} -Assim que tivermos o arquivo de configuração criado, poderemos executar o Echidna assim: +Depois que o arquivo de configuração for criado, podemos executar o Echidna desta forma: ```bash echidna-test gas.sol --config config.yaml @@ -617,12 +630,14 @@ Seed: -325611019680165325 ``` -- O gas mostrado é um cálculo fornecido por [HEVM](https://github.com/dapphub/dapptools/tree/master/src/hevm#hevm-). +- O gás mostrado é uma estimativa fornecida pelo [HEVM](https://github.com/dapphub/dapptools/tree/master/src/hevm#hevm-). -### Filtrando Chamadas com Redução de Gas {#filtering-out-gas-reducing-calls} +### Filtrando chamadas que reduzem o gás {#filtering-out-gas-reducing-calls} -O tutorial sobre **funções de filtragem para chamar durante uma campanha de difusão** acima mostra como remover algumas funções de seu teste. -Isso pode ser fundamental para obter uma estimativa de gas precisa. Considere o seguinte exemplo: +O tutorial sobre **como filtrar funções a serem chamadas durante uma campanha de fuzzing**, acima, mostra como +remover algumas funções do seu teste. +Isso pode ser crítico para obter uma estimativa de gás precisa. +Considere o seguinte exemplo: ```solidity contract C { @@ -648,7 +663,7 @@ contract C { } ``` -Se Echidna pode chamar todas as funções, ele não encontrará facilmente transações com alto custo de gas: +Se o Echidna puder chamar todas as funções, ele não encontrará facilmente transações com alto custo de gás: ``` echidna-test pushpop.sol --config config.yaml @@ -662,7 +677,8 @@ clear used a maximum of 35916 gas push used a maximum of 40839 gas ``` -Isso porque o custo depende do tamanho dos `addrs` e chamadas aleatórias tendem a deixar o array quase vazio. Lista negra `pop` e `limpa`, no entanto, nos dá resultados muito melhores: +Isso porque o custo depende do tamanho de `addrs` e chamadas aleatórias tendem a deixar o array quase vazio. +Isso ocorre porque o custo depende do tamanho de `addrs` e as chamadas aleatórias tendem a deixar o array quase vazio. Adicionar `pop` e `clear` à lista de bloqueio, no entanto, nos dá resultados muito melhores: ```yaml filterBlacklist: true @@ -677,9 +693,9 @@ push used a maximum of 40839 gas check used a maximum of 1484472 gas ``` -### Localizando transações com alto consumo de gás {#summary-finding-transactions-with-high-gas-consumption} +### Resumo: encontrando transações com alto consumo de gás {#summary-finding-transactions-with-high-gas-consumption} -Echidna pode encontrar transações com alto consumo de gás usando a opção de configuração `estimateGas`: +O Echidna pode encontrar transações com alto consumo de gás usando a opção de configuração `estimateGas`: ```yaml estimateGas: true @@ -690,4 +706,4 @@ echidna-test contract.sol --config config.yaml ... ``` -Echidna irá relatar uma sequência com o consumo máximo de gas para cada função, uma vez terminada a campanha de fuzzing. +O Echidna relatará uma sequência com o consumo máximo de gás para cada função, uma vez que a campanha de fuzzing tenha terminado. diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md index 3382b47b034..c24bd70e257 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md @@ -1,17 +1,19 @@ --- title: Como usar o Manticore para encontrar bugs em contratos inteligentes -description: Como usar o Manticore para encontrar bugs automaticamente em contratos inteligentes +description: Como usar o Manticore para encontrar bugs em contratos inteligentes automaticamente author: Trailofbits lang: pt-br tags: - - "solidez" - - "smart contracts" - - "segurança" - - "testando" - - "verificação formal" + [ + "Solidity", + "smart contracts", + "segurança", + "testando", + "verificação formal" + ] skill: advanced published: 2020-01-13 -source: Construindo contratos seguros +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore --- @@ -19,16 +21,16 @@ O objetivo deste tutorial é mostrar como usar o Manticore para encontrar bugs e ## Instalação {#installation} -Manticore requer >= python 3.6. Pode ser instalado pelo pip ou usando o docker. +Manticore requer >= python 3.6. Pode ser instalado via pip ou usando o docker. -### Manticore através do Docker {#manticore-through-docker} +### Manticore via docker {#manticore-through-docker} ```bash docker pull trailofbits/eth-security-toolbox docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox ``` -_O último comando roda a eth-security-toolbox em um docker que tem acesso ao seu diretório atual. Você pode alterar os arquivos do seu host e executar as ferramentas nos arquivos através do docker_ +_O último comando executa o eth-security-toolbox em um docker que tem acesso ao seu diretório atual. Você pode alterar os arquivos do seu host e executar as ferramentas nos arquivos do docker_ Dentro do docker, execute: @@ -37,7 +39,7 @@ solc-select 0.5.11 cd /home/trufflecon/ ``` -### Manticore através do pip {#manticore-through-pip} +### Manticore via pip {#manticore-through-pip} ```bash pip3 install --user manticore @@ -55,18 +57,18 @@ python3 script.py ## Introdução à execução simbólica dinâmica {#introduction-to-dynamic-symbolic-execution} -### Execução Simbólica Dinâmica em uma Nutshell {#dynamic-symbolic-execution-in-a-nutshell} +### Execução Simbólica Dinâmica em poucas palavras {#dynamic-symbolic-execution-in-a-nutshell} -A execução simbólica dinâmica (DSE) é uma técnica de análise de programa que explora um espaço de estado com um alto grau de consciência semântica. Esta técnica baseia-se na descoberta de "caminhos do programa", representados como fórmulas matemáticas chamadas de `predicados de caminho`. Conceitualmente, esta técnica opera em predicados de caminho em dois passos: +A execução simbólica dinâmica (DSE) é uma técnica de análise de programa que explora um espaço de estado com um alto grau de consciência semântica. Esta técnica é baseada na descoberta de "caminhos de programa", representados como fórmulas matemáticas chamadas de `predicados de caminho`. Conceitualmente, esta técnica opera em predicados de caminho em duas etapas: -1. Eles são construídos usando restrições na entrada de dados do programa. -2. Eles são usados para gerar entradas no programa que farão com que os caminhos associados sejam executados. +1. Eles são construídos usando restrições na entrada do programa. +2. Eles são usados para gerar entradas de programa que farão com que os caminhos associados sejam executados. -Esta abordagem não produz falsos positivos no sentido de que todos os estados identificados do programa podem ser acionados durante a execução concreta. Por exemplo, se a análise encontrar um integer overflow, é certo que será reproduzível. +Esta abordagem não produz falsos positivos, no sentido de que todos os estados de programa identificados podem ser acionados durante a execução concreta. Por exemplo, se a análise encontrar um integer overflow, é garantido que será reproduzível. -### Exemplo de Predicado do Caminho {#path-predicate-example} +### Exemplo de Predicado de Caminho {#path-predicate-example} -Para se ter uma idéia de como o DSE funciona, considere o seguinte exemplo: +Para ter uma ideia de como o DSE funciona, considere o seguinte exemplo: ```solidity function f(uint a){ @@ -78,37 +80,37 @@ function f(uint a){ } ``` -Como `f()` contém dois caminhos, uma DSE construirá dois caminhos diferentes atribuídos: +Como `f()` contém dois caminhos, um DSE construirá dois predicados de caminho diferentes: - Caminho 1: `a == 65` - Caminho 2: `Not (a == 65)` -Cada caminho atribuido é uma fórmula matemática que pode ser dada a uma chamada [SMT solver](https://wikipedia.org/wiki/Satisfiability_modulo_theories), que tentará resolver a equação. Para o `Caminho 1`, o solver dirá que o caminho pode ser explorado com `a = 65`. Para o `Caminho 2`, o solver pode dar para `a` qualquer valor diferente de 65, por exemplo, `a = 0`. +Cada predicado de caminho é uma fórmula matemática que pode ser fornecida a um chamado [solucionador SMT](https://wikipedia.org/wiki/Satisfiability_modulo_theories), que tentará resolver a equação. Para o `Caminho 1`, o solucionador dirá que o caminho pode ser explorado com `a = 65`. Para o `Caminho 2`, o solucionador pode atribuir a `a` qualquer valor diferente de 65, por exemplo `a = 0`. ### Verificando propriedades {#verifying-properties} -A Manticore permite um controle total sobre toda a execução de cada caminho. Como resultado, permite que você adicione restrições arbitrárias a quase qualquer coisa. Este controle permite a criação de propriedades no contrato. +O Manticore permite controle total sobre toda a execução de cada caminho. Como resultado, ele permite que você adicione restrições arbitrárias a quase tudo. Este controle permite a criação de propriedades no contrato. Considere o seguinte exemplo: ```solidity function unsafe_add(uint a, uint b) returns(uint c){ - c = a + b; // no overflow protection + c = a + b; // sem proteção contra overflow return c; } ``` -Aqui há apenas um caminho para explorar na função: +Aqui, há apenas um caminho a ser explorado na função: - Caminho 1: `c = a + b` -Usando o Manticore, você pode verificar se há overflow, e adicionar restrições à previsão do caminho: +Usando o Manticore, você pode verificar se há overflow e adicionar restrições ao predicado de caminho: - `c = a + b AND (c < a OR c < b)` -Se é possível encontrar uma avaliação de `um` e `b` para a qual o caminho predicado acima é viável, significa que encontrou um transbordamento ("overflow"). Por exemplo, o solver pode gerar a entrada `a = 10 , b = MAXUINT256`. +Se for possível encontrar uma valoração de `a` e `b` para a qual o predicado de caminho acima seja viável, significa que você encontrou um overflow. Por exemplo, o solucionador pode gerar a entrada `a = 10, b = MAXUINT256`. -Se você considerar uma versão fixa: +Se você considerar uma versão corrigida: ```solidity function safe_add(uint a, uint b) returns(uint c){ @@ -119,17 +121,17 @@ function safe_add(uint a, uint b) returns(uint c){ } ``` -A fórmula associada com verificação de overflow seria: +A fórmula associada com a verificação de overflow seria: - `c = a + b AND (c >= a) AND (c=>b) AND (c < a OR c < b)` -Esta fórmula não pode ser resolvida; em outras palavras, esta é uma **prova** que em `safe_add`, `c` irá sempre aumentar. +Esta fórmula não pode ser resolvida; em outras palavras, esta é uma **prova** de que em `safe_add`, `c` sempre aumentará. -DSE é assim uma ferramenta poderosa, que pode verificar restrições arbitrárias no seu código. +O DSE é, portanto, uma ferramenta poderosa que pode verificar restrições arbitrárias em seu código. -## Executando sob Manticore {#running-under-manticore} +## Executando no Manticore {#running-under-manticore} -Veremos como explorar um contrato inteligente com a API Manticore. O alvo é o seguinte contrato inteligente [`exemplo.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol): +Veremos como explorar um contrato inteligente com a API do Manticore. O alvo é o seguinte contrato inteligente [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol): ```solidity pragma solidity >=0.4.24 <0.6.0; @@ -143,15 +145,15 @@ contract Simple { } ``` -### Executar uma exploração independente {#run-a-standalone-exploration} +### Execute uma exploração autônoma {#run-a-standalone-exploration} -Você pode executar a Manticore diretamente no contrato inteligente pelo seguinte comando (`projeto` pode ser um Arquivo Solidity, ou um diretório de projeto): +Você pode executar o Manticore diretamente no contrato inteligente com o seguinte comando (`project` pode ser um arquivo Solidity ou um diretório de projeto): ```bash $ manticore project ``` -Você obterá a saída de casos de teste como este (a ordem pode mudar): +Você receberá a saída de casos de teste como este (a ordem pode mudar): ``` ... @@ -166,51 +168,54 @@ Você obterá a saída de casos de teste como este (a ordem pode mudar): ... ``` -Sem informações adicionais, Manticore explorará o contrato com novas transações simbólicas até que não explore novos caminhos do contrato. Manticore não executa novas transações após uma falha (por exemplo: após um reversão). +Sem informações adicionais, o Manticore explorará o contrato com novas transações +simbólicas até que não explore novos caminhos no contrato. O Manticore não executa novas transações após uma que falhou (ex: após uma reversão). -Manticore irá gerar as informações em um diretório `mcore_*`. Entre outros, você encontrará nesse diretório: +O Manticore produzirá a informação em um diretório `mcore_*`. Entre outras coisas, você encontrará neste diretório: - `global.summary`: cobertura e avisos do compilador -- `test_XXXXX.summary`: cobertura, última instrução, saldos de conta por caso de teste +- `test_XXXXX.summary`: cobertura, última instrução, saldos da conta por caso de teste - `test_XXXXX.tx`: lista detalhada de transações por caso de teste -Aqui, Manticore encontrou 7 casos de teste, que correspondem à (a ordem do nome do arquivo pode mudar): +Aqui o Manticore encontra 7 casos de teste, que correspondem a (a ordem do nome do arquivo pode mudar): -| | Transação 0 | Transação 1 | Transação 2 | Resultado | -|:--------------------:|:-------------------:|:----------------------:| ---------------------- |:---------:| -| **test_00000000.tx** | Criação de contrato | f(!=65) | f(!=65) | STOP | -| **test_00000001.tx** | Criação de contrato | função de contingência | | REVERT | -| **test_00000002.tx** | Criação de contrato | | | RETURN | -| **test_00000003.tx** | Criação de contrato | f(65) | | REVERT | -| **test_00000004.tx** | Criação de contrato | f(!=65) | | STOP | -| **test_00000005.tx** | Criação de contrato | f(!=65) | f(65) | REVERT | -| **test_00000006.tx** | Criação de contrato | f(!=65) | função de contingência | REVERT | +| | Transação 0 | Transação 1 | Transação 2 | Resultado | +| :-------------------------------------------------------: | :-----------------: | :------------------------: | -------------------------- | :-------: | +| **test_00000000.tx** | Criação de contrato | f(!=65) | f(!=65) | STOP | +| **test_00000001.tx** | Criação de contrato | função de fallback | | REVERT | +| **test_00000002.tx** | Criação de contrato | | | RETURN | +| **test_00000003.tx** | Criação de contrato | f(65) | | REVERT | +| **test_00000004.tx** | Criação de contrato | f(!=65) | | STOP | +| **test_00000005.tx** | Criação de contrato | f(!=65) | f(65) | REVERT | +| **test_00000006.tx** | Criação de contrato | f(!=65) | função de fallback | REVERT | _Resumo da exploração f(!=65) denota f chamado com qualquer valor diferente de 65._ -Como você pode perceber, Manticore gera um caso de teste único para cada transação bem sucedida ou revertida. +Como você pode perceber, o Manticore gera um caso de teste único para cada transação bem-sucedida ou revertida. -Use a flag `--quick-mode` se você quiser uma exploração rápida de código (ele desativa detectores de bugs, cálculo de gas, ...) +Use a flag `--quick-mode` se você quiser uma exploração rápida de código (ela desativa detectores de bugs, computação de gás, ...) -### Manipule um contrato inteligente através da API {#manipulate-a-smart-contract-through-the-api} +### Manipular um contrato inteligente através da API {#manipulate-a-smart-contract-through-the-api} -Esta seção descreve detalhes sobre como manipular um contrato inteligente através da API Manticore Python. Você pode criar um novo arquivo com a extensão python `*. y` e escreva o código necessário adicionando os comandos da API (básicos dos quais serão descritos abaixo) neste arquivo e então execute-o com o comando `$ python3 *. a`. Também você pode executar os comandos abaixo diretamente no console python, para executar o console use o comando `$ python3`. +Esta seção descreve em detalhes como manipular um contrato inteligente através da API Python do Manticore. Você pode criar um novo arquivo com a extensão python `*.py` e escrever o código necessário adicionando os comandos da API (cujos fundamentos serão descritos abaixo) neste arquivo e, em seguida, executá-lo com o comando `$ python3 *.py`. Você também pode executar os comandos abaixo diretamente no console do python; para executar o console, use o comando `$ python3`. ### Criando Contas {#creating-accounts} -A primeira coisa que você deve fazer é iniciar uma nova blockchain com os seguintes comandos: +A primeira coisa que você deve fazer é iniciar uma nova cadeia de blocos com os seguintes comandos: ```python from manticore.ethereum import ManticoreEVM + +m = ManticoreEVM() ``` -Uma conta de não-contrato é criada usando [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account): +Uma conta que não seja de contrato é criada usando [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account): ```python user_account = m.create_account(balance=1000) ``` -Um contrato de Solidity pode ser implantado usando [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract): +Um contrato Solidity pode ser implantado usando [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract): ```solidity source_code = ''' @@ -229,11 +234,11 @@ contract_account = m.solidity_create_contract(source_code, owner=user_account) #### Resumo {#summary} -- Você pode criar contas de usuário e contratos com [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) and [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract). +- Você pode criar contas de usuário e de contrato com [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) e [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract). ### Executando transações {#executing-transactions} -Manticore suporta dois tipos de transação: +O Manticore suporta dois tipos de transação: - Transação bruta: todas as funções são exploradas - Transação nomeada: apenas uma função é explorada @@ -249,10 +254,10 @@ m.transaction(caller=user_account, value=value) ``` -O chamador, o endereço, os dados ou o valor da transação pode ser concreto ou simbólico: +O chamador, o endereço, os dados ou o valor da transação podem ser concretos ou simbólicos: -- [m.make_symbollic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_value#manticore.ethereum.ManticoreEVM.make_symbolic_value) cria um valor simbólico. -- [m.make_symbollic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_buffer#manticore.ethereum.ManticoreEVM.make_symbolic_buffer) cria um valor simbólico "byte array". +- [m.make_symbolic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_value#manticore.ethereum.ManticoreEVM.make_symbolic_value) cria um valor simbólico. +- [m.make_symbolic_buffer(size)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_buffer#manticore.ethereum.ManticoreEVM.make_symbolic_buffer) cria uma matriz de bytes simbólica. Por exemplo: @@ -262,43 +267,44 @@ symbolic_data = m.make_symbolic_buffer(320) m.transaction(caller=user_account, address=contract_address, data=symbolic_data, - value=symbolic_value + value=symbolic_value) ``` -Se os dados forem simbólicos, Manticore irá explorar todas as funções do contrato durante a execução da transação. Será útil ver a explicação de Função de Fallback nas [Mãos do CTF Ethernaut](https://blog.trailofbits.com/2017/11/06/hands-on-the-ethernaut-ctf/), artigo para entender como a seleção de função funciona. +Se os dados forem simbólicos, o Manticore explorará todas as funções do contrato durante a execução da transação. Será útil ver a explicação da Função de Fallback no artigo [Hands on the Ethernaut CTF](https://blog.trailofbits.com/2017/11/06/hands-on-the-ethernaut-ctf/) para entender como a seleção de funções funciona. #### Transação nomeada {#named-transaction} -Funções podem ser executadas através de seu nome. Para executar `f(uint var)` com um valor simbólico, do user_account, e com 0 ether, use: +As funções podem ser executadas pelo nome. +Para executar `f(uint var)` com um valor simbólico, de user_account, e com 0 ether, use: ```python symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var, caller=user_account, value=0) ``` -Se `valor` da transação não for especificado, ela é 0 por padrão. +Se o `value` da transação não for especificado, ele será 0 por padrão. #### Resumo {#summary-1} -- Os argumentos de uma transação podem ser concretos ou simbólicos -- Uma transação bruta irá explorar todas as funções -- A função pode ser chamada pelo nome +- Argumentos de uma transação podem ser concretos ou simbólicos +- Uma transação bruta explorará todas as funções +- A função pode ser chamada pelo seu nome ### Espaço de trabalho {#workspace} `m.workspace` é o diretório usado como diretório de saída para todos os arquivos gerados: ```python -print("Results are in {}".format(m.workspace)) +print("Os resultados estão em {}".format(m.workspace)) ``` -### Terminar a Exploração {#terminate-the-exploration} +### Encerrar a exploração {#terminate-the-exploration} -Para parar a exploração, use [m.finalize()](https://manticore.readthedocs.io/en/latest/evm.html?highlight=finalize#manticore.ethereum.ManticoreEVM.finalize). Nenhuma transação adicional deve ser enviada quando este método for chamado e a Manticore gerar casos de teste para cada caminho explorado. +Para parar a exploração, use [m.finalize()](https://manticore.readthedocs.io/en/latest/evm.html?highlight=finalize#manticore.ethereum.ManticoreEVM.finalize). Nenhuma transação adicional deve ser enviada depois que este método for chamado e o Manticore gerará casos de teste para cada caminho explorado. -### Resumo: Executando sob Manticore {#summary-running-under-manticore} +### Resumo: Executando no Manticore {#summary-running-under-manticore} -Juntando todos os passos anteriores, obtemos: +Juntando todas as etapas anteriores, obtemos: ```python from manticore.ethereum import ManticoreEVM @@ -314,15 +320,15 @@ contract_account = m.solidity_create_contract(source_code, owner=user_account) symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var) -print("Results are in {}".format(m.workspace)) -m.finalize() # stop the exploration +print("Os resultados estão em {}".format(m.workspace)) +m.finalize() # para a exploração ``` -Todo o código acima você pode encontrar no [`exemple_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) +Todo o código acima pode ser encontrado em [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) -## Obtendo caminhos {#getting-throwing-paths} +## Obtendo caminhos que lançam exceções {#getting-throwing-paths} -Agora vamos gerar entradas específicas para os caminhos levantando uma exceção em `f()`. O alvo é ainda o seguinte contrato inteligente [`exemplo.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol): +Agora, vamos gerar entradas específicas para os caminhos que levantam uma exceção em `f()`. O alvo ainda é o seguinte contrato inteligente [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol): ```solidity pragma solidity >=0.4.24 <0.6.0; @@ -335,38 +341,38 @@ contract Simple { } ``` -### Usando informações do estado {#using-state-information} +### Usando informações de estado {#using-state-information} -Cada caminho executado tem seu estado de blockchain. Um estado ou está pronto ou é morto, o que significa que atinge um caminho de THROW ou REVERT: +Cada caminho executado tem seu estado da cadeia de blocos. Um estado está pronto ou é encerrado, o que significa que ele atinge uma instrução THROW ou REVERT: - [m.ready_states](https://manticore.readthedocs.io/en/latest/states.html#accessing): a lista de estados que estão prontos (não executaram um REVERT/INVALID) -- [m.killed_states](https://manticore.readthedocs.io/en/latest/states.html#accessings): a lista de estados que estão mortos -- [m.all_states](https://manticore.readthedocs.io/en/latest/states.html#accessings): todos os estados +- [m.killed_states](https://manticore.readthedocs.io/en/latest/states.html#accessing): a lista de estados que são encerrados +- [m.all_states](https://manticore.readthedocs.io/en/latest/states.html#accessing): todos os estados ```python -for state in m.all_statees: - # faz algo com estado +for state in m.all_states: + # faça algo com o estado ``` -Você pode acessar informações de estado. Por exemplo: +Você pode acessar as informações de estado. Por exemplo: - `state.platform.get_balance(account.address)`: o saldo da conta - `state.platform.transactions`: a lista de transações - `state.platform.transactions[-1].return_data`: os dados retornados pela última transação -Os dados retornados pela última transação são um array, que pode ser convertido para um valor com ABI.deserialize, por exemplo: +Os dados retornados pela última transação são uma matriz, que pode ser convertida em um valor com ABI.deserialize, por exemplo: ```python data = state.platform.transactions[0].return_data data = ABI.deserialize("uint", data) ``` -### Como gerar caixa de teste {#how-to-generate-testcase} +### Como gerar um caso de teste {#how-to-generate-testcase} -Use [m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=generate_testcase#manticore.ethereum.ManticoreEVM.generate_testcase) para gerar a caixa de teste: +Use [m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=generate_testcase#manticore.ethereum.ManticoreEVM.generate_testcase) para gerar um caso de teste: ```python -m.generate_testcase(estado, 'BugFound') +m.generate_testcase(state, 'BugFound') ``` ### Resumo {#summary-2} @@ -374,10 +380,10 @@ m.generate_testcase(estado, 'BugFound') - Você pode iterar sobre o estado com m.all_states - `state.platform.get_balance(account.address)` retorna o saldo da conta - `state.platform.transactions` retorna a lista de transações -- `Transtion.return_data` são os dados retornados +- `transaction.return_data` são os dados retornados - `m.generate_testcase(state, name)` gera entradas para o estado -### Resumo: Obtendo o caminho de lançamento {#summary-getting-throwing-path} +### Resumo: Obtendo caminhos que lançam exceções {#summary-getting-throwing-path} ```python from manticore.ethereum import ManticoreEVM @@ -393,21 +399,23 @@ contract_account = m.solidity_create_contract(source_code, owner=user_account) symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var) -## Verificando se a execução termina com um REVERT ou INVALID +## Verifique se uma execução termina com um REVERT ou INVALID + for state in m.terminated_states: last_tx = state.platform.transactions[-1] if last_tx.result in ['REVERT', 'INVALID']: - print('Throw found {}'.format(m.workspace)) + print('Exceção encontrada {}'.format(m.workspace)) m.generate_testcase(state, 'ThrowFound') ``` -Todo o código acima você pode encontrar no [`exemple_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) +Todo o código acima pode ser encontrado em [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) -_Note que poderíamos ter gerado um script muito mais simples, como todos os estados retornados por terminated_state REVERT ou INVALID no seu resultado: este exemplo foi destinado apenas para demonstrar como manipular a API._ +_Observe que poderíamos ter gerado um script muito mais simples, pois todos os estados retornados por terminated_state têm REVERT ou INVALID em seu resultado: este exemplo teve como objetivo apenas demonstrar como manipular a API._ -## Adicionar Restrições {#adding-constraints} +## Adicionando restrições {#adding-constraints} -Veremos como restringir a exploração. Vamos fazer a suposição de que a documentação de `f()` que afirma que a função nunca é chamada com `a == 65`, então qualquer erro com `a == 65` não é um bug de verdade. O alvo é o seguinte contrato inteligente [`exemplo.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol): +Veremos como restringir a exploração. Vamos assumir que a +documentação de `f()` afirma que a função nunca é chamada com `a == 65`, então qualquer bug com `a == 65` não é um bug real. O alvo ainda é o seguinte contrato inteligente [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol): ```solidity pragma solidity >=0.4.24 <0.6.0; @@ -422,22 +430,22 @@ contract Simple { ### Operadores {#operators} -O módulo [Operadores](https://github.com/trailofbits/manticore/blob/master/manticore/core/smtlib/operators.py) facilita a manipulação de restrições, entre outras que fornece: +O módulo [Operators](https://github.com/trailofbits/manticore/blob/master/manticore/core/smtlib/operators.py) facilita a manipulação de restrições, entre outras coisas, ele fornece: -- Operadores.AND, -- Operadores.OR, -- Operators.UGT (não assinado maior que), -- Operators.UGE (não assinado maior ou igual a), -- Operators.UGT (não assinado menor que), -- Operators.ULE (menor que ou igual a). +- Operators.AND, +- Operators.OR, +- Operators.UGT (maior que sem sinal), +- Operators.UGE (maior ou igual que sem sinal), +- Operators.ULT (menor que sem sinal), +- Operators.ULE (menor ou igual que sem sinal). -Para importar o módulo use o seguinte: +Para importar o módulo, use o seguinte: ```python from manticore.core.smtlib import Operators ``` -`Operators.CONCAT` é usado para concatenar uma matriz a um valor. Por exemplo, o return_data de uma transação precisa ser alterado para um valor a ser verificado contra outro valor: +`Operators.CONCAT` é usado para concatenar uma matriz a um valor. Por exemplo, o return_data de uma transação precisa ser alterado para um valor para ser verificado em relação a outro valor: ```python last_return = Operators.CONCAT(256, *last_return) @@ -449,7 +457,8 @@ Você pode usar restrições globalmente ou para um estado específico. #### Restrição global {#state-constraint} -Use `m.constrain(constraint)` para adicionar um constraint ("restrição") global. Por exemplo, você pode chamar um contrato de um endereço simbólico e restringir este endereço para serem valores específicos: +Use `m.constrain(constraint)` para adicionar uma restrição global. +Por exemplo, você pode chamar um contrato a partir de um endereço simbólico e restringir esse endereço a valores específicos: ```python symbolic_address = m.make_symbolic_value() @@ -462,21 +471,23 @@ m.transaction(caller=user_account, #### Restrição de estado {#state-constraint} -Use o estado de [. onstrain(restrição)](https://manticore.readthedocs.io/en/latest/states.html?highlight=StateBase#manticore.core.state.StateBase.constrain) para adicionar uma restrição a um estado específico. Ele pode ser usado para restringir o estado após sua exploração para verificar alguma propriedade nele. +Use [state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/states.html?highlight=StateBase#manticore.core.state.StateBase.constrain) para adicionar uma restrição a um estado específico. +Pode ser usado para restringir o estado após sua exploração para verificar alguma propriedade nele. -### Verificando a constraint ("restrição") {#checking-constraint} +### Verificando a restrição {#checking-constraint} -Use `solver.check(state.constraints)` para saber se uma restrição ainda é viável. Por exemplo, o seguinte irá restringir o simbolic_valor para ser diferente do 65 e verificar se o estado ainda é viável: +Use `solver.check(state.constraints)` para saber se uma restrição ainda é viável. +Por exemplo, o seguinte irá restringir o symbolic_value a ser diferente de 65 e verificar se o estado ainda é viável: ```python state.constrain(symbolic_var != 65) if solver.check(state.constraints): - # estado é viável + # o estado é viável ``` -### Resumo: Adicionando constraints ("restrições") {#summary-adding-constraints} +### Resumo: Adicionando restrições {#summary-adding-constraints} -Adicionando constraints ("restrições") ao código anterior, obtemos: +Adicionando restrição ao código anterior, obtemos: ```python from manticore.ethereum import ManticoreEVM @@ -497,18 +508,19 @@ contract_account.f(symbolic_var) no_bug_found = True -## Verificar se a execução termina com um REVERT ou INVALID +## Verifique se uma execução termina com um REVERT ou INVALID + for state in m.terminated_states: last_tx = state.platform.transactions[-1] if last_tx.result in ['REVERT', 'INVALID']: - # we do not consider the path were a == 65 + # não consideramos o caminho onde a == 65 condition = symbolic_var != 65 if m.generate_testcase(state, name="BugFound", only_if=condition): - print(f'Bug found, results are in {m.workspace}') + print(f'Bug encontrado, os resultados estão em {m.workspace}') no_bug_found = False if no_bug_found: - print(f'No bug found') + print(f'Nenhum bug encontrado') ``` -Todo o código acima você pode encontrar no [`exemple_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) +Todo o código acima pode ser encontrado em [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md index b9ac9dc2118..80af4439b10 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md @@ -1,17 +1,12 @@ --- -title: Como utilizar o Slither para encontrar bugs nos contratos inteligentes +title: Como usar o Slither para encontrar bugs em contratos inteligentes description: Como usar o Slither para encontrar automaticamente bugs em contratos inteligentes author: Trailofbits lang: pt-br -tags: - - "solidity" - - "smart contracts" - - "segurança" - - "testando" - - "análise estática" +tags: [ "Solidity", "smart contracts", "segurança", "testando" ] skill: advanced published: 2020-06-09 -source: Construindo contratos seguros +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither --- @@ -26,7 +21,7 @@ O objetivo deste tutorial é mostrar como usar o Slither para localizar automati ## Instalação {#installation} -O Slither requer a versão 3.6 do Python ou superior. Pode ser instalado pelo pip ou usando o docker. +O Slither requer a versão 3.6 do Python ou superior. Pode ser instalado via pip ou usando o docker. Slither via pip: @@ -34,14 +29,14 @@ Slither via pip: pip3 install --user slither-analyzer ``` -Slither através de docker: +Slither via docker: ```bash docker pull trailofbits/eth-security-toolbox docker run -it -v "$PWD":/home/trufflecon trailofbits/eth-security-toolbox ``` -_O último comando roda a eth-security-toolbox em um docker que tem acesso ao seu diretório atual. Você pode alterar os arquivos do seu host e executar as ferramentas nos arquivos através do docker_ +_O último comando executa o eth-security-toolbox em um docker que tem acesso ao seu diretório atual. Você pode alterar os arquivos do seu host e executar as ferramentas nos arquivos do docker_ Dentro do docker, execute: @@ -60,23 +55,23 @@ python3 script.py ### Linha de comando {#command-line} -**Linha de comando versus scripts definidos pelo usuário.** O Slither vem com um conjunto de detectores predefinidos que encontram muitos bugs comuns. Chamar o Slither na linha de comando irá executar todos os detectores. Nenhum conhecimento detalhado da análise estática é necessária: +**Linha de comando versus scripts definidos pelo usuário.** O Slither vem com um conjunto de detectores predefinidos que encontram muitos bugs comuns. Chamar o Slither pela linha de comando executará todos os detectores, não é necessário conhecimento detalhado de análise estática: ```bash slither project_paths ``` -Além de detectadores, o Slither possui recursos de revisão de código através de suas [printers](https://github.com/crytic/slither#printers) e [ferramentas](https://github.com/crytic/slither#tools). +Além dos detectores, o Slither tem recursos de revisão de código por meio de seus [printers](https://github.com/crytic/slither#printers) e [ferramentas](https://github.com/crytic/slither#tools). -Use [crytic.io](https://github.com/crytic) para obter acesso a detectadores privados e integração GitHub. +Use o [crytic.io](https://github.com/crytic) para obter acesso a detectores privados e integração com o GitHub. ## Análise estática {#static-analysis} -Os recursos e design do framework estático de análise do Slither foram descritos nos posts de blog ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/)), [2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) e em um [documento acadêmico](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf). +As capacidades e o design da estrutura de análise estática Slither foram descritos em posts de blog ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/), [2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) e em um [artigo acadêmico](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf). -A análise estática existe em diferentes "flavors". Você provavelmente percebe que compiladores como [clang](https://clang-analyzer.llvm.org/) e [gcc](https://lwn.net/Articles/806099/) dependem destas técnicas de pesquisa, mas também sustenta ([Infer](https://fbinfer.com/), [CodeClimate](https://codeclimate.com/), [FindBugs](http://findbugs.sourceforge.net/) e ferramentas baseadas em métodos formais como [Frama-C](https://frama-c.com/) e [Polyspace](https://www.mathworks.com/products/polyspace.html). +A análise estática existe em diferentes "sabores". Você provavelmente percebe que compiladores como [clang](https://clang-analyzer.llvm.org/) e [gcc](https://lwn.net/Articles/806099/) dependem dessas técnicas de pesquisa, mas elas também são a base para ([Infer](https://fbinfer.com/), [CodeClimate](https://codeclimate.com/), [FindBugs](http://findbugs.sourceforge.net/)) e ferramentas baseadas em métodos formais como [Frama-C](https://frama-c.com/) e [Polyspace](https://www.mathworks.com/products/polyspace.html). -Nós não analisaremos exaustivamente técnicas de análise estática e pesquisador aqui. Em vez disso, vamos focar no que é necessário para entender como o Slither funciona para que você possa usá-lo de forma mais eficiente para encontrar bugs e entender códigos. +Não faremos uma revisão exaustiva das técnicas de análise estática e dos pesquisadores aqui. Em vez disso, vamos nos concentrar no que é necessário para entender como o Slither funciona para que você possa usá-lo com mais eficácia para encontrar bugs e entender o código. - [Representação de código](#code-representation) - [Análise de código](#analysis) @@ -84,13 +79,13 @@ Nós não analisaremos exaustivamente técnicas de análise estática e pesquisa ### Representação de código {#code-representation} -Em contraste com uma análise dinâmica, que justifica um único caminho de execução, razões de análise estática sobre todos os caminhos ao mesmo tempo. Para isso, ele depende de uma representação diferente do código. As duas mais comuns são a árvore de sintaxe abstrata (AST) e o gráfico de fluxo de controle (CFG). +Em contraste com uma análise dinâmica, que analisa um único caminho de execução, a análise estática analisa todos os caminhos de uma só vez. Para isso, ela se baseia em uma representação de código diferente. As duas mais comuns são a árvore de sintaxe abstrata (AST) e o grafo de fluxo de controle (CFG). -### Árvores de sintaxe abstratas (AST) {#abstract-syntax-trees-ast} +### Árvores de Sintaxe Abstrata (AST) {#abstract-syntax-trees-ast} -AST é usado toda vez que o compilador analisa o código. É provavelmente a estrutura mais básica sobre a qual se pode efetuar a análise estática. +As ASTs são usadas sempre que o compilador analisa o código. É provavelmente a estrutura mais básica sobre a qual a análise estática pode ser realizada. -Em poucas palavras, a AST é uma árvore estruturada onde, normalmente, cada folha contém uma variável ou uma constante e os nós internos são operações ou operações de fluxo de controle. Considere o seguinte código: +Em resumo, uma AST é uma árvore estruturada onde, geralmente, cada folha contém uma variável ou uma constante, e os nós internos são operandos ou operações de fluxo de controle. Considere o seguinte código: ```solidity function safeAdd(uint a, uint b) pure internal returns(uint){ @@ -101,15 +96,15 @@ function safeAdd(uint a, uint b) pure internal returns(uint){ } ``` -O AST correspondente é mostrado em: +A AST correspondente é mostrada em: ![AST](./ast.png) -O Slither usa o AST exportado pelo solc. +O Slither usa a AST exportada pelo solc. -Enquanto for simples construir, o AST é uma estrutura aninhada. Por vezes, esta não é a mais simples de analisar. Por exemplo, para identificar as operações usadas pela expressão `a + b <= a`,, primeiro você deve analisar `<=` e, em seguida, `+`. Uma abordagem comum é usar o chamado padrão de visitantes, que navega pela árvore recursivamente. O Slither contém um visitante genérico em [`ExpressionVisitor`](https://github.com/crytic/slither/blob/master/slither/visitors/expression/expression.py). +Embora seja simples de construir, a AST é uma estrutura aninhada. Às vezes, essa não é a forma mais direta de analisar. Por exemplo, para identificar as operações usadas pela expressão `a + b <= a`, você deve primeiro analisar `<=` e depois `+`. Uma abordagem comum é usar o chamado padrão de visitante, que navega pela árvore recursivamente. O Slither contém um visitante genérico em [`ExpressionVisitor`](https://github.com/crytic/slither/blob/master/slither/visitors/expression/expression.py). -O código a seguir usa `ExpressionVisitor` para detectar se a expressão contém uma adição: +O código a seguir usa o `ExpressionVisitor` para detectar se a expressão contém uma adição: ```python from slither.visitors.expression.expression import ExpressionVisitor @@ -128,39 +123,39 @@ visitor = HasAddition(expression) # expression is the expression to be tested print(f'The expression {expression} has a addition: {visitor.result()}') ``` -### Controlar Gráfico de Fluxos (CFG) {#control-flow-graph-cfg} +### Grafo de Fluxo de Controle (CFG) {#control-flow-graph-cfg} -A segunda representação de código mais comum é o gráfico de fluxo de controle (CFG). Como seu nome sugere, é uma representação baseada em gráficos que expõe todos os caminhos de execução. Cada nó contém uma ou várias instruções. Bordas no gráfico representam as operações de fluxo de controle (se/então/outra vez, loop, etc). O nosso exemplo anterior é o do CFG: +A segunda representação de código mais comum é o grafo de fluxo de controle (CFG). Como o nome sugere, é uma representação baseada em grafo que expõe todos os caminhos de execução. Cada nó contém uma ou várias instruções. As arestas no grafo representam as operações de fluxo de controle (if/then/else, loop, etc). O CFG do nosso exemplo anterior é: ![CFG](./cfg.png) -O CFG é a representação que está por cima da qual se constrói a maioria das análises. +O CFG é a representação sobre a qual a maioria das análises é construída. -Existem muitas outras representações de código. Cada representação tem vantagens e desvantagens de acordo com a análise que você deseja realizar. +Existem muitas outras representações de código. Cada representação tem vantagens e desvantagens, dependendo da análise que você deseja realizar. ### Análise {#analysis} -O tipo mais simples de análises que você pode realizar com o Slither são análises sintáticas. +O tipo mais simples de análise que você pode realizar com o Slither é a análise sintática. -### Análises de sintaxe {#syntax-analysis} +### Análise de sintaxe {#syntax-analysis} -O Slither pode navegar através dos diferentes componentes do código e sua representação para encontrar inconsistências e falhas usando uma abordagem semelhante a padrões de correspondência. +O Slither pode navegar pelos diferentes componentes do código e sua representação para encontrar inconsistências e falhas usando uma abordagem do tipo correspondência de padrões. Por exemplo, os seguintes detectores procuram por problemas relacionados à sintaxe: -- [State variable shadowing](https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing): itera sobre todas as variáveis de estado e verifica se tem alguma variável "shadow" de um contrato herdado ([state.py#L51-L62](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/shadowing/state.py#L51-L62)) +- [Sombreamento de variável de estado](https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing): itera sobre todas as variáveis de estado e verifica se alguma sombreia uma variável de um contrato herdado ([state.py#L51-L62](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/shadowing/state.py#L51-L62)) -- [Interface ERC20 incorreta](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-erc20-interface): procurar por assinaturas de função ERC20 incorretas ([incorrect_erc20_interface.py#L34-L55](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/erc/incorrect_erc20_interface.py#L34-L55)) +- [Interface ERC20 incorreta](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-erc20-interface): procura por assinaturas de função ERC20 incorretas ([incorrect_erc20_interface.py#L34-L55](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/erc/incorrect_erc20_interface.py#L34-L55)) ### Análise semântica {#semantic-analysis} -Em contraste com a análise de sintaxe, uma análise semântica vai aprofundar e analisar o "significado" do código. Esta família inclui vários tipos de análises. Conduzem a resultados mais poderosos e úteis, mas são também mais complexos de escrever. +Em contraste com a análise de sintaxe, uma análise semântica irá mais a fundo e analisará o "significado" do código. Esta família inclui alguns tipos abrangentes de análises. Elas levam a resultados mais poderosos e úteis, mas também são mais complexas de escrever. -Análises semânticas são usadas para detecções de vulnerabilidades mais avançadas. +As análises semânticas são usadas para as detecções de vulnerabilidades mais avançadas. #### Análise de dependência de dados {#fixed-point-computation} -Uma variável `variable_a` diz ser dependente de dados `variable_b` se houver um caminho para o qual o valor de `variable_a` seja influenciado pela `variable_b`. +Diz-se que uma variável `variable_a` tem dependência de dados de `variable_b` se houver um caminho no qual o valor de `variable_a` é influenciado por `variable_b`. No código a seguir, `variable_a` depende de `variable_b`: @@ -169,13 +164,13 @@ No código a seguir, `variable_a` depende de `variable_b`: variable_a = variable_b + 1; ``` -O Slither vem com capacidades embutidas de [dependência de dados,](https://github.com/crytic/slither/wiki/data-dependency) graças à sua representação intermediária (discutida em uma seção posterior). +O Slither vem com recursos integrados de [dependência de dados](https://github.com/crytic/slither/wiki/data-dependency), graças à sua representação intermediária (discutida em uma seção posterior). -Um exemplo de uso de dependência de dados pode ser encontrado em ["dangerous strict equality detector"](https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities). Aqui o Slither procurará por uma comparação rigorosa de igualdade com um valor perigoso ([incorrect_strict_equality. y#L86-L87](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L86-L87)), e informará o usuário que deve usar `>=` ou `<=` ao invés de `==`para evitar um invasor para prender o contrato. Entre outros, o detector considerará como perigoso o valor de retorno de uma chamada para o `balanceOf(endereço)` ([incorrect_strict_equality. y#L63-L64](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L63-L64)), e usará o mecanismo de dependência de dados para rastrear seu uso. +Um exemplo de uso de dependência de dados pode ser encontrado no [detector de igualdades estritas perigosas](https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities). Aqui, o Slither procurará por uma comparação de igualdade estrita com um valor perigoso ([incorrect_strict_equality.py#L86-L87](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L86-L87)), e informará ao usuário que deve usar `>=` ou `<=` em vez de `==`, para evitar que um invasor prenda o contrato em uma armadilha. Entre outras coisas, o detector considerará perigoso o valor de retorno de uma chamada para `balanceOf(address)` ([incorrect_strict_equality.py#L63-L64](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L63-L64)) e usará o mecanismo de dependência de dados para rastrear seu uso. -#### Cálculo de ponto fixo {#fixed-point-computation} +#### Computação de ponto fixo {#fixed-point-computation} -Se a sua análise navegar através do CFG e seguir as bordas, é provável que você veja os nós já visitados. Por exemplo, se um loop é apresentado como mostrado abaixo: +Se sua análise navegar pelo CFG e seguir as arestas, você provavelmente verá nós já visitados. Por exemplo, se um loop for apresentado como mostrado abaixo: ```solidity for(uint i; i < range; ++){ @@ -183,23 +178,23 @@ for(uint i; i < range; ++){ } ``` -A sua análise terá de saber quando parar. Existem duas estratégias principais aqui: (1) iterar em cada nó um número finito de vezes, (2) calcular um chamado _fixpoint_. Um ponto de acesso basicamente significa que a análise deste nó não fornece nenhuma informação significativa. +Sua análise precisará saber quando parar. Existem duas estratégias principais aqui: (1) iterar em cada nó um número finito de vezes, (2) computar um chamado _ponto fixo_. Um ponto fixo basicamente significa que analisar este nó não fornece nenhuma informação significativa. -Um exemplo de fixpoint usado pode ser encontrado nos detectadores de reentrância: Slither explora os nós, e procurar por chamadas externas, escrever e ler para armazenar. Uma vez que chegou a um ponto de correção ("fixpoint") ([reentrancy.py#L125-L131](https://github.com/crytic/slither/blob/master/slither/detectors/reentrancy/reentrancy.py#L125-L131)), interrompe a exploração e analisa os resultados para ver se uma reentrância está presente, através de diferentes padrões de reentrada ([reentrancy_benign. y](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_benign.py), [reentrancy_read_before_write.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_read_before_write.py), [reentrancy_eth.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_eth.py)). +Um exemplo de uso de ponto fixo pode ser encontrado nos detectores de reentrância: o Slither explora os nós e procura por chamadas externas, escrita e leitura no armazenamento. Depois de atingir um ponto fixo ([reentrancy.py#L125-L131](https://github.com/crytic/slither/blob/master/slither/detectors/reentrancy/reentrancy.py#L125-L131)), ele interrompe a exploração e analisa os resultados para ver se há uma reentrância, por meio de diferentes padrões de reentrância ([reentrancy_benign.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_benign.py), [reentrancy_read_before_write.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_read_before_write.py), [reentrancy_eth.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_eth.py)). -Escrever análises usando um cálculo de ponto fixo eficiente requer um bom entendimento de como a análise propaga sua informação. +Escrever análises usando computação de ponto fixo eficiente requer uma boa compreensão de como a análise propaga suas informações. ### Representação intermediária {#intermediate-representation} -Uma representação intermediária (IR) é uma linguagem que deve ser mais acessível à análise estática do que a original. Slither traduz Solidity para seu próprio IR: [SlithIR](https://github.com/crytic/slither/wiki/SlithIR). +Uma representação intermediária (RI) é uma linguagem destinada a ser mais adequada à análise estática do que a original. O Slither traduz Solidity para sua própria RI: [SlithIR](https://github.com/crytic/slither/wiki/SlithIR). -Compreender o SlithIR não é necessário se você quiser apenas escrever verificações básicas. No entanto, será útil se você planejar escrever análises semânticas avançadas. As [SlithIR](https://github.com/crytic/slither/wiki/Printer-documentation#slithir) e [SSA](https://github.com/crytic/slither/wiki/Printer-documentation#slithir-ssa)printers irão ajudá-lo a entender como o código é traduzido. +Entender o SlithIR não é necessário se você quiser apenas escrever verificações básicas. No entanto, será útil se você planeja escrever análises semânticas avançadas. Os printers [SlithIR](https://github.com/crytic/slither/wiki/Printer-documentation#slithir) e [SSA](https://github.com/crytic/slither/wiki/Printer-documentation#slithir-ssa) ajudarão você a entender como o código é traduzido. -## API Básica {#api-basics} +## Conceitos básicos da API {#api-basics} -Slither tem uma API que permite explorar os atributos básicos do contrato e suas funções. +O Slither tem uma API que permite explorar atributos básicos do contrato e suas funções. -Carregando um codebase: +Para carregar uma base de código: ```python from slither import Slither @@ -209,30 +204,30 @@ slither = Slither('/path/to/project') ### Explorando contratos e funções {#exploring-contracts-and-functions} -Um objeto `Slither` contém: +Um objeto `Slither` tem: -- contracts`contracts (list(Contract)`: lista de contratos +- `contracts (list(Contract)`: lista de contratos - `contracts_derived (list(Contract)`: lista de contratos que não são herdados por outro contrato (subconjunto de contratos) -- `get_contract_from_name (str)`: Retorna um contrato a partir de seu nome +- `get_contract_from_name (str)`: retorna um contrato a partir do seu nome -Um objeto `Slither` contém: +Um objeto `Contract` tem: -- `name (str)`: Nome do contrato -- `functions (list(Function))`: Lista de funções -- `modifiers (list(Modifier))`: Lista de funções -- `all_functions_called (list(Função/Modificador))`: Lista de todas as funções internas acessíveis pelo contrato -- `herança (lista(contrato))`: Lista de contratos herdados -- `get_function_from_signature (str)`: Retorna uma função a partir de sua assinatura -- `get_function_from_signature (str)`: Retorna uma função a partir de sua assinatura -- `get_contract_from_name (str)`: Retorna um contrato a partir de seu nome +- `name (str)`: nome do contrato +- `functions (list(Function))`: lista de funções +- `modifiers (list(Modifier))`: lista de modificadores +- `all_functions_called (list(Function/Modifier))`: lista de todas as funções internas alcançáveis pelo contrato +- `inheritance (list(Contract))`: lista de contratos herdados +- `get_function_from_signature (str)`: retorna uma função a partir de sua assinatura +- `get_modifier_from_signature (str)`: retorna um modificador a partir de sua assinatura +- `get_state_variable_from_name (str)`: retorna uma StateVariable a partir do seu nome -Um objeto `Function` ou `Modifier` têm: +Um objeto `Function` ou `Modifier` tem: -- `name (str)`: Nome da função +- `name (str)`: nome da função - `contract (contract)`: o contrato onde a função é declarada -- `nodes (list(Node))`: Lista dos nós que compõem o CFG da função/modificador -- `entry_point (Node)`: Ponto de entrada do CFG -- `variables_read (list(variável))`: Lista de variáveis lidas -- `variables_written (list(variável))`: Lista de variáveis escritas -- `state_variables_read (list(StateVariable))`: Lista de variáveis de estado lidas (subconjunto de variáveis lidas) -- `state_variables_written (list(StateVariable))`: Lista de variáveis de estado escritas (subconjunto de variáveis escritas) +- `nodes (list(Node))`: lista dos nós que compõem o CFG da função/modificador +- `entry_point (Node)`: ponto de entrada do CFG +- `variables_read (list(Variable))`: lista de variáveis lidas +- `variables_written (list(Variable))`: lista de variáveis escritas +- `state_variables_read (list(StateVariable))`: lista de variáveis de estado lidas (subconjunto de `variables_read`) +- `state_variables_written (list(StateVariable))`: lista de variáveis de estado escritas (subconjunto de `variables_written`) diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md index 2dae6657637..05931fb052a 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -1,53 +1,50 @@ --- -title: Como configurar Tellor como seu Oráculo -description: Um guia para começar a integrar o oráculo Tellor ao seu protocolo +title: "Como configurar o Tellor como seu Oráculo" +description: "Um guia para começar a integrar o oráculo Tellor ao seu protocolo" author: "Tellor" lang: pt-br -tags: - - "solidity" - - "contratos inteligentes" - - "oráculos" -skill: intermediate +tags: [ "Solidity", "smart contracts", "oráculos" ] +skill: beginner published: 2021-06-29 -source: Documentação Tellor +source: Tellor Docs sourceUrl: https://docs.tellor.io/tellor/ --- -Pop Quiz: Seu protocolo está quase pronto, mas precisa de um oráculo para obter acesso aos dados off-chain... O que você faz? +Pop Quiz: seu protocolo está quase pronto, mas precisa de um oráculo para ter acesso a dados fora da cadeia... O que você faz? -## (Soft) Pré-requisitos {#soft-prerequisites} +## (Pré-requisitos básicos) {#soft-prerequisites} -Esse texto tem como objetivo tornar o acesso a um conjunto de dados através do uso de um oráculo o mais simples e direto possível. Dito isso, estamos assumindo o seguinte sobre seu nível de habilidade de codificação para focar no aspecto do oráculo. +Esta publicação visa tornar o acesso a uma fonte de dados de oráculo o mais simples e direto possível. Dito isso, estamos assumindo o seguinte sobre o seu nível de habilidade de programação para focar no aspecto do oráculo. Suposições: -- você pode navegar em um terminal +- você consegue navegar em um terminal - você tem o npm instalado - você sabe como usar o npm para gerenciar dependências -Tellor é um oráculo vivo e de código aberto pronto para implementação. Este guia para iniciantes está aqui para mostrar a facilidade com que se pode começar a trabalhar com Tellor, fornecendo ao seu projeto um oráculo totalmente descentralizado e resistente à censura. +Tellor é um oráculo ativo e de código aberto pronto para implementação. Este guia para iniciantes está aqui para mostrar a facilidade com que se pode começar a trabalhar com o Tellor, fornecendo ao seu projeto um oráculo totalmente descentralizado e resistente à censura. ## Visão geral {#overview} -Tellor é um sistema de oráculo onde as partes podem solicitar o valor de um ponto de dados off-chain (por exemplo, BTC/USD) e os repórteres (nós ou participantes) competem para adicionar esse valor a um banco de dados on-chain, acessível por todos os contratos inteligentes do Ethereum. As entradas para este banco de dados são asseguradas por uma rede de repórteres participantes. Tellor utiliza mecanismos de incentivo cripto-econômico, recompensando envios de dados honestos por repórteres e punindo maus atores por meio da emissão do token Tellor, Tributos (TRB) e um mecanismo de disputa. +Tellor é um sistema de oráculo onde as partes podem solicitar o valor de um ponto de dados fora da cadeia (p. ex., BTC/USD) e os relatores competem para adicionar esse valor a um banco de dados em cadeia, acessível a todos os contratos inteligentes da Ethereum. As entradas para este banco de dados são protegidas por uma rede de relatores em staking. O Tellor utiliza mecanismos de incentivo criptoeconômicos, recompensando os envios de dados honestos por relatores e punindo os agentes mal-intencionados através da emissão do token do Tellor, Tributes (TRB), e de um mecanismo de disputa. -Neste tutorial, nós iremos ver: +Neste tutorial, abordaremos: -- Configurar o kit de ferramentas inicial, que você precisará para começar a trabalhar. -- Percorra por um exemplo simples. -- Listar os endereços de teste das redes as quais você pode testar o Tellor atualmente. +- Configurar o kit de ferramentas inicial que você precisará para começar a usar. +- Analisar um exemplo simples. +- Listar os endereços de redes de teste nas quais você pode testar o Tellor atualmente. ## UsingTellor {#usingtellor} -A primeira coisa que você vai querer fazer é instalar as ferramentas básicas necessárias para usar o Tellor como seu oráculo. Use [este pacote](https://github.com/tellor-io/usingtellor) para instalar os contratos de usuário do Tellor: +A primeira coisa que você vai querer fazer é instalar as ferramentas básicas necessárias para usar o Tellor como seu oráculo. Use [este pacote](https://github.com/tellor-io/usingtellor) para instalar os Contratos de Usuário do Tellor: `npm install usingtellor` Uma vez instalado, isso permitirá que seus contratos herdem as funções do contrato 'UsingTellor'. -Excelente! Agora que você tem as ferramentas prontas, vamos passar por um simples exercício onde recuperamos o preço do bitcoin: +Ótimo! Agora que você tem as ferramentas prontas, vamos fazer um exercício simples em que recuperamos o preço do bitcoin: -### Exemplo BTC/USD {#btcusd-example} +### Exemplo de BTC/USD {#btcusd-example} Herde o contrato UsingTellor, passando o endereço do Tellor como um argumento do construtor: @@ -59,7 +56,7 @@ import "usingtellor/contracts/UsingTellor.sol"; contract PriceContract is UsingTellor { uint256 public btcPrice; - //This Contract now has access to all functions in UsingTellor + //Este contrato agora tem acesso a todas as funções em UsingTellor constructor(address payable _tellorAddress) UsingTellor(_tellorAddress) public {} @@ -77,8 +74,8 @@ function setBtcPrice() public { } ``` -Para uma lista completa de endereços de contrato, consulte [aqui](https://docs.tellor.io/tellor/the-basics/contracts-reference). +Para obter uma lista completa de endereços de contrato, consulte [aqui](https://docs.tellor.io/tellor/the-basics/contracts-reference). -Para facilidade de uso, o repositório UsingTellor vem com uma versão do contrato [Tellor Playground](https://github.com/tellor-io/TellorPlayground) para facilitar a integração. Consulte [aqui](https://github.com/tellor-io/sampleUsingTellor#tellor-playground) para obter uma lista de funções úteis. +Para facilitar o uso, o repositório UsingTellor vem com uma versão do contrato [Tellor Playground](https://github.com/tellor-io/TellorPlayground) para uma integração mais fácil. Veja [aqui](https://github.com/tellor-io/sampleUsingTellor#tellor-playground) uma lista de funções úteis. -Para uma implementação mais robusta do oráculo Tellor, confira a lista completa de funções, disponíveis [aqui](https://github.com/tellor-io/usingtellor/blob/master/README.md). +Para uma implementação mais robusta do oráculo Tellor, confira a lista completa de funções disponíveis [aqui](https://github.com/tellor-io/usingtellor/blob/master/README.md). diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-view-nft-in-metamask/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-view-nft-in-metamask/index.md index 3171780741b..b24bdeed295 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-view-nft-in-metamask/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-view-nft-in-metamask/index.md @@ -1,36 +1,33 @@ --- -title: Como ver seu NFT na sua carteira (Parte 3/3 da série de tutorial sobre NFT) -description: This tutorial describes how to view an existing NFT on MetaMask! +title: "Como visualizar seu NFT na sua carteira (Parte 3/3 da série de tutoriais de NFT)" +description: Este tutorial descreve como visualizar um NFT existente no MetaMask! author: "Sumi Mudgil" -tags: - - "ERC-721" - - "Alchemy" - - "Solidity" -skill: intermediate +tags: [ "ERC-721", "Alchemy", "Solidity" ] +skill: beginner lang: pt-br published: 2021-04-22 --- -Este tutorial é a Parte 3/3 das séries de Tutorial de NFT, onde vemos nosso NFT recentemente cunhado. No entanto, você pode usar o tutorial geral para qualquer token ERC-721 usando MetaMask, inclusive na rede principal ou em qualquer rede de teste. Se você quiser aprender como cunhar seu próprio NFT no Ethereum, confira a [Parte 1 sobre Como Escrever implantar um contrato inteligente de NFT](/developers/tutorials/how-to-write-and-deploy-an-nft)! +Este tutorial é a Parte 3/3 da série de tutoriais sobre NFT, onde visualizamos nosso NFT recém-mintado. No entanto, você pode usar o tutorial geral para qualquer token ERC-721 usando o MetaMask, inclusive na Mainnet ou em qualquer rede de teste. Se quiser aprender a mintar seu próprio NFT na Ethereum, confira a [Parte 1 sobre Como Escrever e Implantar um Contrato Inteligente de NFT](/developers/tutorials/how-to-write-and-deploy-an-nft)! -Parabéns! Você chegou à parte mais curta e simples da nossa série de tutoriais de NFT: como visualizar seu NFT recém-cunhado em uma carteira virtual. Assim como nas duas partes anteriores, também usaremos o MetaMask aqui. +Parabéns! Você chegou à parte mais curta e simples da nossa série de tutoriais de NFT: como visualizar seu NFT recém-mintado em uma carteira virtual. Usaremos o MetaMask para este exemplo, pois foi o que usamos nas duas partes anteriores. -Como pré-requisito, você já deve ter MetaMask instalado no celular e deve incluir a conta para a qual você cunhou seu NFT. Você pode obter o aplicativo gratuitamente no [iOS](https://apps.apple.com/us/app/metamask-blockchain-wallet/id1438144202) ou [Android](https://play.google.com/store/apps/details?id=io.metamask&hl=en_US&gl=US). +Como pré-requisito, você já deve ter o MetaMask instalado no celular, e ele deve incluir a conta na qual você mintou seu NFT — você pode obter o aplicativo gratuitamente para [iOS](https://apps.apple.com/us/app/metamask-blockchain-wallet/id1438144202) ou [Android](https://play.google.com/store/apps/details?id=io.metamask&hl=en_US&gl=US). ## Passo 1: Defina sua rede para Sepolia {#set-network-to-sepolia} -No topo do aplicativo, pressione o botão "Wallet". Em seguida, você será solicitado a selecionar uma rede. Como nosso NFT foi cunhado na rede Sepolia, você deverá selecionar Sepolia como sua rede. +Na parte superior do aplicativo, pressione o botão “Carteira”, após o qual você será solicitado a selecionar uma rede. Como nosso NFT foi mintado na rede Sepolia, você deverá selecionar Sepolia como sua rede. -![Como definir Sepolia como sua rede no MetaMask Mobile](./goerliMetamask.gif) +![Como definir a Sepolia como sua rede no MetaMask Mobile](./goerliMetamask.gif) -## Passo 2: Adicionar o seu colecionável ao MetaMask {#add-nft-to-metamask} +## Passo 2: Adicionar seu colecionável ao MetaMask {#add-nft-to-metamask} -Quando estiver na rede Sepolia, selecione a guia “Colecionáveis” à direita e adicione o endereço do contrato inteligente NFT e o ID do token ERC-721 do seu NFT - o qual você poderá encontrar no Etherscan com base no hash da transação do seu NFT implantado na Parte II do nosso tutorial. +Assim que estiver na rede Sepolia, selecione a aba “Colecionáveis” à direita e adicione o endereço do contrato inteligente e o ID do token ERC-721 do seu NFT — que você deve conseguir encontrar no Etherscan com base no hash da transação do seu NFT implantado na Parte II do nosso tutorial. -![Como encontrar seu hash de transação e o ID do token ERC-721](./findNFTEtherscan.png) +![Como encontrar o hash da sua transação e o ID do token ERC-721](./findNFTEtherscan.png) -Talvez você precise atualizar algumas vezes para visualizar seu NFT — mas ele estará lá ! +Talvez seja preciso atualizar algumas vezes para visualizar seu NFT — mas ele estará lá ! -![Como enviar seu NFT para a MetaMask](./findNFTMetamask.gif) +![Como fazer o upload do seu NFT para o MetaMask](./findNFTMetamask.gif) -Parabéns! Você cunhou um NFT com sucesso e agora pode visualizá-lo! Mal podemos esperar para ver como você vai conquistar o mundo NFT! +Parabéns! Você mintou um NFT com sucesso e agora pode visualizá-lo! Mal podemos esperar para ver como você vai conquistar o mundo dos NFTs! diff --git a/public/content/translations/pt-br/developers/tutorials/how-to-write-and-deploy-an-nft/index.md b/public/content/translations/pt-br/developers/tutorials/how-to-write-and-deploy-an-nft/index.md index 2d6d8c017c4..3112d45b539 100644 --- a/public/content/translations/pt-br/developers/tutorials/how-to-write-and-deploy-an-nft/index.md +++ b/public/content/translations/pt-br/developers/tutorials/how-to-write-and-deploy-an-nft/index.md @@ -1,36 +1,32 @@ --- -title: Como escrever e implantar um NFT (Primeira parte da série de tutoriais sobre NFT) -description: Este tutorial é a parte 1 de uma série sobre NFTs que o guiará passo a passo sobre como escrever e implantar um contrato inteligente não fungível (token ERC-721) usando Ethereum e o sistema de arquivos do Inter Planetary (IPFS). +title: "Como Escrever e Implantar um NFT (Parte 1/3 da Série de Tutoriais sobre NFT)" +description: "Este tutorial é a parte 1 de uma série sobre NFTs que o guiará passo a passo sobre como escrever e implantar um contrato inteligente não fungível (token ERC-721) usando Ethereum e o sistema de arquivos do Inter Planetary (IPFS)." author: "Sumi Mudgil" -tags: - - "ERC-721" - - "Alchemy" - - "Solidity" - - "contratos inteligentes" -skill: intermediate +tags: [ "ERC-721", "Alchemy", "Solidity", "smart contracts" ] +skill: beginner lang: pt-br published: 2021-04-22 --- Com os NFTs trazendo a blockchain aos olhos do público, agora é uma excelente oportunidade para entender a tendência publicando seu próprio contrato NFT (ERC-721 Token) na blockchain Ethereum! -A Alchemy tem muito orgulho por estar no espaço NFT com os maiores nomes incluindo Makersplace (recentemente atingiu a marca de 69 milhões de doláres em vendas de artes digitais), Dapper Labs (criadores do NBA Top Shot e Crypto Kitties), OpenSea (o maior mercado de NFT do mundo), Zora, Super Rare, NFTfi, Foundation, Enjin, Origin Protocol, Immutable e muito mais. +A Alchemy se orgulha imensamente de impulsionar os maiores nomes no espaço de NFT, incluindo a Makersplace (que recentemente estabeleceu um recorde de venda de arte digital na Christie's por 69 milhões de dólares), Dapper Labs (criadores do NBA Top Shot & Crypto Kitties), OpenSea (o maior marketplace de NFT do mundo), Zora, Super Rare, NFTfi, Foundation, Enjin, Origin Protocol, Immutable e muito mais. -Neste tutorial, nós vamos criar e implantar um contrato inteligente ERC-721 na rede de teste Sepolia usando [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/), [Pinata](https://pinata.cloud/) e [Alquimia](https://alchemy.com/signup/eth) (não se preocupe caso não entender o que tudo isso significa — explicaremos tudo!). +Neste tutorial, vamos percorrer a criação e implantação de um contrato inteligente ERC-721 na rede de teste Sepolia usando [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/), [Pinata](https://pinata.cloud/) e [Alchemy](https://alchemy.com/signup/eth) (não se preocupe se você ainda não entende o que tudo isso significa — nós explicaremos!). Na parte 2 deste tutorial, veremos como podemos usar nosso contrato inteligente para gerar NFT, e na Parte 3, explicaremos como ver seu NFT no MetaMask. -E claro, se você tiver dúvidas a qualquer momento, acesso o [Alchemy Discord](https://discord.gg/gWuC7zB) ou visite a página de [Documentação sobre a API NFT da Alchemy](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)! +E, claro, se você tiver dúvidas a qualquer momento, não hesite em nos contatar no [Discord da Alchemy](https://discord.gg/gWuC7zB) ou visite a [documentação da API de NFT da Alchemy](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)! -## Etapa 1: Se conectar à rede Ethereum {#connect-to-ethereum} +## Etapa 1: Conecte-se à rede Ethereum {#connect-to-ethereum} -Existem várias maneiras de fazer solicitações para a blockchain Ethereum, mas para facilitar as coisas, usaremos uma conta gratuita na [Alchemy](https://alchemy.com/signup/eth), uma plataforma e API de desenvolvedores de blockchain que nos permite nos comunicar com a cadeia Ethereum sem ter que executar os nossos próprios nós. +Há várias maneiras de fazer solicitações para a blockchain Ethereum, mas, para facilitar, usaremos uma conta gratuita na [Alchemy](https://alchemy.com/signup/eth), uma plataforma de desenvolvimento de blockchain e API que nos permite comunicar com a blockchain Ethereum sem ter que executar nossos próprios nós. -Neste tutorial, também aproveitaremos as ferramentas de desenvolvedor da Alchemy para fins de monitoramento e análise, para entender o que está acontecendo nos bastidores da nossa implantação de contrato inteligente. Se você ainda não tiver uma conta da Alchemy, inscreva-se gratuitamente [aqui](https://alchemy.com/signup/eth). +Neste tutorial, também aproveitaremos as ferramentas de desenvolvedor da Alchemy para fins de monitoramento e análise, para entender o que está acontecendo nos bastidores da nossa implantação de contrato inteligente. Se você ainda não tem uma conta na Alchemy, pode se inscrever gratuitamente [aqui](https://alchemy.com/signup/eth). -## Etapa 2: Criar seu aplicativo (e chave de API) {#make-api-key} +## Etapa 2: Crie seu aplicativo (e chave de API) {#make-api-key} -Assim que criar uma conta na Alchemy, você pode gerar uma chave de API criando um "app". Isso nos permitirá fazer solicitações à rede de teste Sepolia. Confira [este guia](https://docs.alchemyapi.io/guides/choosing-a-network) se você está curioso para aprender mais sobre as redes de teste. +Assim que criar uma conta na Alchemy, você pode gerar uma chave de API criando um "app". Isso nos permitirá fazer solicitações à rede de teste Sepolia. Confira [este guia](https://docs.alchemyapi.io/guides/choosing-a-network) se tiver curiosidade em aprender mais sobre redes de teste. 1. Vá até a página "Create App" no painel da Alchemy, passe o mouse sobre a palavra "Apps" na barra de navegação e clique em "Create App" @@ -42,84 +38,97 @@ Assim que criar uma conta na Alchemy, você pode gerar uma chave de API criando 3. Clique em "Create App", e é isso e tudo! Seu app deveria aparecer na tabela abaixo. -## Etapa 3: Criar uma conta Ethereum (endereço) {#create-eth-address} +## Etapa 3: Crie uma conta Ethereum (endereço) {#create-eth-address} -Precisamos de uma conta Ethereum para enviar e receber transações. Para este tutorial, usaremos uma carteira virtual no navegador, a MetaMask, para gerenciar o endereço da sua conta Ethereum. Se você quiser entender mais sobre como as transações no Ethereum funcionam, confira [esta página](/developers/docs/transactions/) na Fundação Ethereum. +Precisamos de uma conta Ethereum para enviar e receber transações. Para este tutorial, usaremos uma carteira virtual no navegador, a MetaMask, para gerenciar o endereço da sua conta Ethereum. Se quiser entender mais sobre como as transações na Ethereum funcionam, confira [esta página](/developers/docs/transactions/) da Ethereum Foundation. -Você pode baixar e criar uma conta MetaMask gratuitamente [neste link](https://metamask.io/download). Quando você estiver criando uma conta, ou se você já tiver uma, certifique-se de mudar para a “Sepolia Test Network” no canto superior direito (para que não lidemos com dinheiro real). +Você pode baixar e criar uma conta MetaMask gratuitamente [aqui](https://metamask.io/download). Quando você estiver criando uma conta, ou se você já tiver uma, certifique-se de mudar para a “Sepolia Test Network” no canto superior direito (para que não lidemos com dinheiro real). ![Defina Sepolia como sua rede](./metamask-goerli.png) -## Etapa 4: Adicionar ether de um faucet {#step-4-add-ether-from-a-faucet} +## Etapa 4: Adicione ether de um Faucet {#step-4-add-ether-from-a-faucet} -Para implementar nosso contrato inteligente na rede de teste, precisaremos de alguns ETHs de imitação. Para obter ETH, você pode acessar a [Torneira da Sepolia](https://sepoliafaucet.com/) hospedada pela Alchemy, fazer login, inserir o endereço da sua conta e clicar em "Enviar-me ETH". Você deveria ver o ETH na sua conta MetaMask logo depois! +Para implementar nosso contrato inteligente na rede de teste, precisaremos de alguns ETHs de imitação. Para obter ETH, você pode ir para o [Sepolia Faucet](https://sepoliafaucet.com/) hospedado pela Alchemy, fazer login, inserir o endereço da sua conta e clicar em “Envie-me ETH”. Você deveria ver o ETH na sua conta MetaMask logo depois! -## Etapa 5: Verificar seu saldo {#check-balance} +## Etapa 5: Verifique seu saldo {#check-balance} -Para verificar novamente que temos saldo, vamos fazer uma solicitação através da ferramenta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) fornecida pelo [compositor da Alchemy](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ele mostrará a quantidade de ETH em nossa carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: +Para conferir nosso saldo, vamos fazer uma solicitação [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando a [ferramenta de composição da Alchemy](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ele mostrará a quantidade de ETH em nossa carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: + ``` `{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}` + ``` -> **Nota** Este resultado está em wei, não em ETH. Lembre-se de que o wei é a menor unidade do ether. A conversão de wei para ETH é 1 eth = 1018 wei. Então, se convertemos 0xde0b6b3a7640000 para decimal, temos 1\*1018 wei, que é igual a 1 ETH. +> **Observação**: este resultado está em wei, não em ETH. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para ETH é 1 eth = 1018 wei. Então, se convertemos 0xde0b6b3a7640000 para decimal, temos 1\*1018 wei, que é igual a 1 ETH. Ufa! O nosso dinheiro falso está todo lá. -## Etapa 6: Dar início a nosso projeto {#initialize-project} +## Etapa 6: Inicialize nosso projeto {#initialize-project} Primeiro, precisamos criar uma pasta para o nosso projeto. Navegue até sua linha de comando e digite: + ``` mkdir my-nft cd my-nft + ``` -Agora que estamos dentro da pasta do nosso projeto, vamos usar npm init para inicializá-lo. Se você ainda não tiver o npm instalado, siga [estas instruções](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) (nós também vamos precisar do [Node.js](https://nodejs.org/en/download/), então baixe isso também!). +Agora que estamos dentro da pasta do nosso projeto, vamos usar npm init para inicializá-lo. Se você ainda não tem o npm instalado, siga [estas instruções](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) (também vamos precisar do [Node.js](https://nodejs.org/en/download/), então baixe-o também!). + ``` npm init + ``` Não importa realmente como você responde às questões de instalação; aqui está o que utilizamos de referência: + ```json - package name: (my-nft) - version: (1.0.0) - description: My first NFT! - entry point: (index.js) - test command: - git repository: - keywords: - author: - license: (ISC) - About to write to /Users/thesuperb1/Desktop/my-nft/package.json: + nome do pacote: (my-nft) + versão: (1.0.0) + descrição: Meu primeiro NFT! + ponto de entrada: (index.js) + comando de teste: + repositório git: + palavras-chave: + autor: + licença: (ISC) + Prestes a escrever em /Users/thesuperb1/Desktop/my-nft/package.json: { "name": "my-nft", "version": "1.0.0", - "description": "My first NFT!", + "description": "Meu primeiro NFT!", "main": "index.js", "scripts": { - "test": "echo \"Error: no test specified\" && exit 1" + "test": "echo \"Erro: nenhum teste especificado\" && exit 1" }, "author": "", "license": "ISC" } ``` + Aprove o package.json e estamos prontos para começar! -## Etapa 7: Instalar o [Hardhat](https://hardhat.org/getting-started/#overview) {#install-hardhat} +## Etapa 7: Instale o [Hardhat](https://hardhat.org/getting-started/#overview) {#install-hardhat} Hardhat é um ambiente de desenvolvimento para compilar, implementar, testar e depurar seu software de Ethereum. Ele ajuda os desenvolvedores na criação de contratos inteligentes e dapps localmente antes de implantar na cadeia real. Dentro do nosso projeto my-nft execute: + ``` npm install --save-dev hardhat + ``` -Para mais detalhes, confira esta página sobre as [instruções de instalação](https://hardhat.org/getting-started/#overview). +Confira esta página para mais detalhes sobre as [instruções de instalação](https://hardhat.org/getting-started/#overview). -## Etapa 8: Criar o projeto Hardhat {#create-hardhat-project} +## Etapa 8: Crie um projeto Hardhat {#create-hardhat-project} Dentro da nossa pasta de projeto, execute: + ``` npx hardhat + ``` Você deve então ver uma mensagem de boas-vindas e a opção de selecionar o que quer fazer. Selecione "criar uma hardhat.config.js vazia": + ``` 888 888 888 888 888 888 888 888 888 888 888 888 888 888 888 @@ -128,37 +137,40 @@ Você deve então ver uma mensagem de boas-vindas e a opção de selecionar o qu 888 888 .d888888 888 888 888 888 888 .d888888 888 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 - 👷 Welcome to Hardhat v2.0.11 👷‍ - ? O que você deseja fazer? … - Create a sample project - ❯ Create an empty hardhat.config.js - Quit + 👷 Bem-vindo ao Hardhat v2.0.11 👷‍ + ? O que você quer fazer? … + Criar um projeto de exemplo + ❯ Criar um hardhat.config.js vazio + Sair + ``` Isso vai gerar um arquivo hardhat.config.js, no qual especificaremos todas as configurações para o nosso projeto (no passo 13). -## Etapa 9: Adicionar as pastas do projeto {#add-project-folders} +## Etapa 9: Adicione pastas ao projeto {#add-project-folders} Para manter a organização do nosso projeto, vamos criar duas novas pastas. Navegue até o diretório raiz do seu projeto na sua linha de comando e digite: + ``` mkdir contracts mkdir scripts + ``` - contracts/ é onde manteremos o nosso código de contrato inteligente para o NFT - scripts/ é onde manteremos scripts para implantar e interagir com nosso contrato inteligente -## Etapa 10: Escrever nosso contrato {#write-contract} +## Etapa 10: Escreva nosso contrato {#write-contract} -Agora que nosso ambiente de trabalho está configurado, iremos para a parte mais emocionante: _escrever nosso contrato de código inteligente!_ +Agora que nosso ambiente está configurado, vamos para a parte mais empolgante: _escrever o código do nosso contrato inteligente!_ -Abra o projeto my-nft no seu editor favorito (nós gostamos do [VSCode](https://code.visualstudio.com/)). Os contratos inteligentes são escritos em uma linguagem chamada Solidity, que usaremos para escrever nosso contrato inteligente MyNFT.sol. +Abra o projeto my-nft em seu editor favorito (gostamos do [VSCode](https://code.visualstudio.com/)). Os contratos inteligentes são escritos em uma linguagem chamada Solidity, que usaremos para escrever nosso contrato inteligente MyNFT.sol. -1. Navegue até a pasta de `contracts` e crie um novo arquivo chamado MyNFT.sol +1. Navegue para a pasta `contracts` e crie um novo arquivo chamado MyNFT.sol -2. Abaixo está o nosso código de contrato inteligente NFT, nossa base para a implementação do ERC-721 da biblioteca [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc721). Copie e cole o conteúdo abaixo no seu arquivo MyNFT.sol. +2. Abaixo está nosso código de contrato inteligente NFT, que baseamos na implementação ERC-721 da biblioteca [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc721). Copie e cole o conteúdo abaixo no seu arquivo MyNFT.sol. ```solidity - //Contract based on [https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721) + //Contrato baseado em [https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721) // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; @@ -188,31 +200,31 @@ Abra o projeto my-nft no seu editor favorito (nós gostamos do [VSCode](https:// } ``` -3. Como estamos herdando classes da biblioteca de contratos OpenZeppelin, na linha de comando execute `npm install @openzeppelin/contracts` para instalar a biblioteca em nossa pasta. +3. Como estamos herdando classes da biblioteca de contratos OpenZeppelin, na sua linha de comando execute `npm install @openzeppelin/contracts^4.0.0` para instalar a biblioteca em nossa pasta. -Então, o que esse código _faz_ exatamente? Vamos por partes, linha por linha. +Então, o que este código _faz_ exatamente? Vamos por partes, linha por linha. -No topo do nosso contrato inteligente, importamos três [classes de contrato inteligente OpenZeppelin](https://openzeppelin.com/): +No topo do nosso contrato inteligente, importamos três classes de contrato inteligente [OpenZeppelin](https://openzeppelin.com/): -- @openzeppelin/contracts/token/ERC721/ERC721.sol contém a implementação do padrão ERC-721, que nosso contrato inteligente NFT herdará. (Para ser um NFT válido, seu contrato inteligente deve implementar todos os métodos do padrão ERC-721.) Para saber mais sobre as funções herdadas do ERC-721, confira a definição da interface [aqui](https://eips.ethereum.org/EIPS/eip-721). +- @openzeppelin/contracts/token/ERC721/ERC721.sol contém a implementação do padrão ERC-721, que nosso contrato inteligente NFT herdará. (Para ser um NFT válido, seu contrato inteligente deve implementar todos os métodos do padrão ERC-721.) Para saber mais sobre as funções ERC-721 herdadas, confira a definição da interface [aqui](https://eips.ethereum.org/EIPS/eip-721). - @openzeppelin/contracts/utils/Counters.sol fornece contadores que só podem ser incrementados ou diminuídos por um. Nosso contrato inteligente usa um contador para acompanhar o número total de NFTs impressos e definir o ID exclusivo em nosso novo NFT. (Cada NFT cunhado usando um contrato inteligente deve ter um ID único – aqui nosso ID exclusivo é determinado pelo número total de NFTs existentes. Por exemplo, o primeiro NFT que cunhamos com o nosso contrato inteligente tem um ID igual a "1," nosso segundo NFT tem um ID igual a "2," etc.) -- @openzeppelin/contratos/access/Ownable.sol configura [controle de acesso](https://docs.openzeppelin.com/contracts/3.x/access-control) em nosso contrato inteligente, então apenas o proprietário do contrato inteligente (você) pode 'cunhar' NFTs. (Observação, incluir controle de acesso é inteiramente uma preferência. Se você quer que qualquer pessoa consiga gerar um NFT usando seu contrato inteligente, remove a palavra "Ownable" na linha 10 e "onlyOwner" na linha 17.) +- @openzeppelin/contracts/access/Ownable.sol configura o [controle de acesso](https://docs.openzeppelin.com/contracts/3.x/access-control) em nosso contrato inteligente, de modo que apenas o proprietário do contrato inteligente (você) pode cunhar NFTs. (Observação, incluir controle de acesso é inteiramente uma preferência. Se você quer que qualquer pessoa consiga gerar um NFT usando seu contrato inteligente, remove a palavra "Ownable" na linha 10 e "onlyOwner" na linha 17.) -Depois de seguir nossas instruções de importação, temos o nosso contrato inteligente de NFT, que é surpreendentemente curto – contém apenas um contador, um construtor e uma única função! Isso se deve aos nossos contratos OpenZeppelin herdados, que implementam a maioria dos métodos de que precisamos para criar um NFT, tal como `ownerOf`, que retorna o proprietário do NFT, e `transferFrom`, que transfere a propriedade do NFT de uma conta para outra. +Depois de seguir nossas instruções de importação, temos o nosso contrato inteligente de NFT, que é surpreendentemente curto – contém apenas um contador, um construtor e uma única função! Isso é graças aos nossos contratos OpenZeppelin herdados, que implementam a maioria dos métodos que precisamos para criar um NFT, como `ownerOf`, que retorna o proprietário do NFT, e `transferFrom`, que transfere a propriedade do NFT de uma conta para outra. No nosso construtor ERC-721, você notará que transmitimos duas cadeias de caracteres: "MyNFT" e "NFT" A primeira variável é o nome do contrato inteligente e a segunda é símbolo dele. Você pode nomear cada uma dessas variáveis como quiser! -Finalmente, temos nossa função `mintNFT(destinatário de endereço, string memory tokenURI)`, que nos permite cunhar um NFT! Você vai notar que essa função recebe duas variáveis: +Finalmente, temos nossa função `mintNFT(address recipient, string memory tokenURI)` que nos permite cunhar um NFT! Você vai notar que essa função recebe duas variáveis: -- `address recipient` especifica o endereço que receberá o seu NFT recém-cunhado +- `address recipient` especifica o endereço que receberá seu NFT recém-cunhado -- `string memory tokenURI` é uma string que deve ser resolvida em um documento JSON que descreve os metadados do NFT. Os metadados de um NFT são o que realmente o torna realidade, permitindo que tenha propriedades configuráveis, como um nome, descrição, imagem e outros atributos. Na parte 2 deste tutorial, descreveremos como configurar este metadado. +- `string memory tokenURI` é uma string que deve ser resolvida para um documento JSON que descreve os metadados do NFT. Os metadados de um NFT são o que realmente o torna realidade, permitindo que tenha propriedades configuráveis, como um nome, descrição, imagem e outros atributos. Na parte 2 deste tutorial, descreveremos como configurar este metadado. -`mintNFT` chama alguns métodos da biblioteca ERC-721 herdada, e retorna um número que representa a ID do NFT recém-cunhado. +`mintNFT` chama alguns métodos da biblioteca ERC-721 herdada e, por fim, retorna um número que representa o ID do NFT recém-cunhado. -## Etapa 11: Vincular as contas MetaMask e Alchemy a seu projeto {#connect-metamask-and-alchemy} +## Etapa 11: Conecte o MetaMask e a Alchemy ao seu projeto {#connect-metamask-and-alchemy} Agora que criamos uma carteira MetaMask, uma conta Alchemy, e escrevemos o nosso contrato inteligente, é hora de vincular os três. @@ -222,38 +234,44 @@ Para saber mais sobre o envio de transações, confira [este tutorial](/develope Primeiro, instale o pacote dotenv na pasta do seu projeto: + ``` npm install dotenv --save + ``` -Então crie um arquivo `.env` no diretório raiz do nosso projeto e adicione sua chave privada do MetaMask e sua URL HTTP da API Alchemy a ele. +Em seguida, crie um arquivo `.env` no diretório raiz do nosso projeto e adicione sua chave privada do MetaMask e o URL da API HTTP da Alchemy a ele. - Siga [estas instruções](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) para exportar sua chave privada do MetaMask - Veja abaixo como obter o URL da API HTTP Alchemy e copiá-la para a área de transferência -![Copie o URL da API Alchemy](./copy-alchemy-api-url.gif) +![Copie a URL da sua API da Alchemy](./copy-alchemy-api-url.gif) -Seu arquivo `.env` ficará assim: +Seu `.env` deve agora se parecer com isto: - API_URL="https://eth-sepolia.g.alchemy.com/v2/your-api-key" - PRIVATE_KEY="your-metamask-private-key" + ``` + API_URL="https://eth-sepolia.g.alchemy.com/v2/sua-chave-de-api" + PRIVATE_KEY="sua-chave-privada-metamask" + ``` Para realmente conectá-las ao nosso código, referenciaremos essas variáveis em nosso arquivo hardhat.config.js na etapa 13. -## Etapa 12: Instalar o Ethers.js {#install-ethers} +## Etapa 12: Instale o Ethers.js {#install-ethers} -Ethers.js é uma biblioteca que facilita a interação e o envio de solicitações ao Ethereum ao incorporar [métodos padrões JSON-RPC](/developers/docs/apis/json-rpc/) a outros métodos mais amigáveis ao usuário. +Ethers.js é uma biblioteca que facilita a interação e a realização de solicitações à Ethereum, envolvendo os [métodos JSON-RPC padrão](/developers/docs/apis/json-rpc/) com métodos mais amigáveis ao usuário. -Hardhat torna muito fácil a integração de [plugins](https://hardhat.org/plugins/), para ferramentas adicionais e funcionalidades extendidas. Aproveitaremos o [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) para implantação de contratos. ([Ethers.js](https://github.com/ethers-io/ethers.js/) tem alguns métodos de implantação de contratos bastante claros). +O Hardhat torna muito fácil a integração de [Plugins](https://hardhat.org/plugins/) para ferramentas adicionais e funcionalidades estendidas. Aproveitaremos o [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) para a implantação de contratos ([Ethers.js](https://github.com/ethers-io/ethers.js/) has some super clean contract deployment methods). -No diretório do projeto, digite: +No diretório do seu projeto, digite: + ``` npm install --save-dev @nomiclabs/hardhat-ethers ethers@^5.0.0 + ``` Também precisaremos de ethers em nosso hardhat.config.js na próxima etapa. -## Etapa 13: Atualizar hardhat.config.js {#update-hardhat-config} +## Etapa 13: Atualize o hardhat.config.js {#update-hardhat-config} Até aqui, já adicionamos diversas dependências e plugins. Agora precisamos atualizar o hardhat.config.js para que nosso projeto reconheça todos eles. @@ -279,30 +297,32 @@ Atualize seu hardhat.config.js para ficar assim: } ``` -## Etapa 14: Compilar nosso contrato {#compile-contract} +## Etapa 14: Compile nosso contrato {#compile-contract} Para ter certeza de que tudo está funcionando, vamos compilar nosso contrato. A tarefa de compilação é uma das tarefas integradas do Hardhat. Na linha de comando, execute: + ``` npx hardhat compile + ``` -Você pode receber o aviso do identificador de licença SPDX não fornecido no arquivo fonte, mas não há necessidade de se preocupar com isso. Esperemos que tudo mais esteja bem! Se não, você sempre pode enviar uma mensagem no [discord Alchemy](https://discord.gg/u72VCg3). +Você pode receber o aviso do identificador de licença SPDX não fornecido no arquivo fonte, mas não há necessidade de se preocupar com isso. Esperemos que tudo mais esteja bem! Se não, você sempre pode enviar uma mensagem no [Discord da Alchemy](https://discord.gg/u72VCg3). -## Etapa 15: Escrever nosso script de implantação {#write-deploy} +## Etapa 15: Escreva nosso script de implantação {#write-deploy} Agora que nosso contrato está escrito e nosso arquivo de configuração está pronto, é hora de escrever o script de implantação do contrato. -Navegue até a pasta `scripts/` e crie um novo arquivo chamado `deploy.js`, adicionando o seguinte conteúdo: +Navegue até a pasta `scripts/` e crie um novo arquivo chamado `deploy.js`, adicionando o seguinte conteúdo a ele: ```js async function main() { const MyNFT = await ethers.getContractFactory("MyNFT") - // Start deployment, returning a promise that resolves to a contract object + // Inicia a implantação, retornando uma promessa que se resolve em um objeto de contrato const myNFT = await MyNFT.deploy() await myNFT.deployed() - console.log("Contract deployed to address:", myNFT.address) + console.log("Contrato implantado para o endereço:", myNFT.address) } main() @@ -313,40 +333,48 @@ main() }) ``` -A Hardhat fez um trabalho incrível ao explicar o que cada uma dessas linhas de código faz em seu [Tutorial sobre contratos](https://hardhat.org/tutorial/testing-contracts.html#writing-tests). Adotamos aqui as explicações deles. +A Hardhat faz um trabalho incrível explicando o que cada uma dessas linhas de código faz em seu [tutorial de Contratos](https://hardhat.org/tutorial/testing-contracts.html#writing-tests), nós adotamos as explicações deles aqui. + ``` const MyNFT = await ethers.getContractFactory("MyNFT"); + ``` Uma ContractFactory em ethers.js é uma abstração usada para implantar novos contratos inteligentes, então a MyNFT aqui representa uma fábrica para instâncias do nosso contrato NFT. Ao usar o plug-in hardhat-ethers, as instâncias ContractFactory e Contract são conectadas ao primeiro signatário por padrão. + ``` const myNFT = await MyNFT.deploy(); + ``` Ao chamar deploy() em uma ContractFactory, a implantação se iniciará e retornará uma Promise que se resolve em um Contract. Este é o objeto que tem um método para cada uma de nossas funções de contrato inteligente. -## Etapa 16: Implantar nosso contrato {#deploy-contract} +## Etapa 16: Implante nosso contrato {#deploy-contract} Finalmente estamos prontos para implantar o nosso contrato inteligente! Navegue de volta para a raiz do diretório do seu projeto e, na linha de comando, execute: + ``` npx hardhat --network sepo lia run scripts/deploy.js + ``` Você deverá ver algo assim: + ``` Contrato implantado no endereço: 0x4C5266cCc4b3F426965d2f51b6D910325a0E7650 + ``` -Se nós formos ao [Sepolia etherscan](https://sepolia.etherscan.io/) e procurarmos o endereço do nosso contrato, poderemos ver que ele foi implantado com sucesso. Se você não puder ver o endereço imediatamente, por favor, aguarde um momento, pois pode levar algum tempo. A transação ficará parecida com isto: +Se formos ao [Etherscan da Sepolia](https://sepolia.etherscan.io/) e pesquisarmos o endereço do nosso contrato, poderemos ver que ele foi implantado com sucesso. Se você não puder ver o endereço imediatamente, por favor, aguarde um momento, pois pode levar algum tempo. A transação ficará parecida com isto: -![Veja o seu endereço de transação no Etherscan](./etherscan-sepoila-contract-creation.png) +![Veja o endereço da sua transação no Etherscan](./etherscan-sepoila-contract-creation.png) -O endereço do remetente (From) deve corresponder ao seu endereço da conta MetaMask e o endereço do destinatário (To) deve dizer "Contract Creation". Se clicarmos na transação, veremos o nosso endereço de contrato no campo "To": +O endereço do remetente (From) deve corresponder ao endereço da sua conta MetaMask e o endereço do destinatário (To) indicará “Criação de Contrato”. Se clicarmos na transação, veremos o nosso endereço de contrato no campo "To": -![Veja o seu endereço de contrato no Etherscan](./etherscan-sepolia-tx-details.png) +![Veja o endereço do seu contrato no Etherscan](./etherscan-sepolia-tx-details.png) Sim! Você acabou de implantar seu contrato inteligente NFT na cadeia Ethereum (testnet)! -Para entender o que está acontecendo nos bastidores, vamos navegar até a guia Explorer no [painel do Alchemy](https://dashboard.alchemyapi.io/explorer). Se você tem vários aplicativos Alchemy certifique-se de filtrar por app e selecionar "MyNFT". +Para entender o que está acontecendo nos bastidores, vamos navegar para a guia Explorer em nosso [painel da Alchemy](https://dashboard.alchemyapi.io/explorer). Se você tem vários aplicativos Alchemy, certifique-se de filtrar por app e selecionar "MyNFT". -![Exibir chamadas feitas "em segundo plano" com o Explorer Dashboard do Alquimia](./alchemy-explorer-goerli.png) +![Veja as chamadas feitas “nos bastidores” com o painel do Explorer da Alchemy](./alchemy-explorer-goerli.png) -Aqui você verá um punhado de chamadas JSON-RPC que Hardhat/Ethers fizeram em segundo plano para nós quando chamamos a função .deploy() . Dois importantes pontos a destacar aqui são [eth_sendRawTransaction](/developers/docs/apis/json-rpc/#eth_sendrawtransaction), que é a solicitação para realmente escrever nosso contrato inteligente na cadeia Sepolia, e [eth_getTransactionByHash](/developers/docs/apis/json-rpc/#eth_gettransactionbyhash), que é uma solicitação para ler informações sobre nossa transação dado o hash (um padrão típico ao enviar transações). Para saber mais sobre o envio de transações, confira [este tutorial](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) sobre como enviar transações usando a web3. +Aqui você verá um punhado de chamadas JSON-RPC que Hardhat/Ethers fizeram em segundo plano para nós quando chamamos a função .deploy() . Dois pontos importantes a serem mencionados aqui são [eth_sendRawTransaction](/developers/docs/apis/json-rpc/#eth_sendrawtransaction), que é a solicitação para realmente escrever nosso contrato inteligente na blockchain Sepolia, e [eth_getTransactionByHash](/developers/docs/apis/json-rpc/#eth_gettransactionbyhash), que é uma solicitação para ler informações sobre nossa transação, dado o hash (um padrão típico ao enviar transações). Para saber mais sobre o envio de transações, confira este tutorial sobre o [envio de transações usando Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/). -Isso é tudo para a Parte 1 deste tutorial. Na [Parte 2, interagiremos com o nosso contrato inteligente cunhando um NFT](/developers/tutorials/how-to-mint-an-nft/), e na [Parte 3, mostraremos como ver o seu NFT na sua carteira Ethereum](/developers/tutorials/how-to-view-nft-in-metamask/)! +Isso é tudo para a Parte 1 deste tutorial. Na [Parte 2, vamos interagir de fato com nosso contrato inteligente cunhando um NFT](/developers/tutorials/how-to-mint-an-nft/), e na [Parte 3, mostraremos como visualizar seu NFT em sua carteira Ethereum](/developers/tutorials/how-to-view-nft-in-metamask/)! diff --git a/public/content/translations/pt-br/developers/tutorials/interact-with-other-contracts-from-solidity/index.md b/public/content/translations/pt-br/developers/tutorials/interact-with-other-contracts-from-solidity/index.md index 53c8a1a6b79..bc125e0b684 100644 --- a/public/content/translations/pt-br/developers/tutorials/interact-with-other-contracts-from-solidity/index.md +++ b/public/content/translations/pt-br/developers/tutorials/interact-with-other-contracts-from-solidity/index.md @@ -3,11 +3,13 @@ title: Interaja com outros contratos de Solidity description: Como implantar um contrato inteligente a partir de um contrato existente e interagir com ele author: "jdourlens" tags: - - "contratos Inteligentes" - - "solidity" - - "remix" - - "implementação" - - "componibilidade" + [ + "smart contracts", + "Solidity", + "Remix", + "implantação", + "componibilidade" + ] skill: advanced lang: pt-br published: 2020-04-05 @@ -16,9 +18,9 @@ sourceUrl: https://ethereumdev.io/interact-with-other-contracts-from-solidity/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -Nos tutoriais anteriores, aprendemos muito [como publicar seu primeiro contrato inteligente](/developers/tutorials/deploying-your-first-smart-contract/) e adicionar alguns recursos a ele, como [controlar o acesso com modificadores](https://ethereumdev.io/organize-your-code-and-control-access-to-your-smart-contract-with-modifiers/) ou [manipulação de erros no Solidity](https://ethereumdev.io/handle-errors-in-solidity-with-require-and-revert/). Neste tutorial, aprenderemos como implantar um contrato inteligente a partir de um contrato existente e interagir com ele. +Nos tutoriais anteriores, aprendemos muito sobre [como implantar seu primeiro contrato inteligente](/developers/tutorials/deploying-your-first-smart-contract/) e adicionar alguns recursos a ele, como [controle de acesso com modificadores](https://ethereumdev.io/organize-your-code-and-control-access-to-your-smart-contract-with-modifiers/) ou [tratamento de erros no Solidity](https://ethereumdev.io/handle-errors-in-solidity-with-require-and-revert/). Neste tutorial, aprenderemos como implantar um contrato inteligente a partir de um contrato existente e interagir com ele. -Faremos um contrato que permite a qualquer pessoa ter seu próprio contrato inteligente`Counter`, criando uma fábrica para ele. Seu nome será `CounterFactory`. De início, aqui está o código do nosso primeiro contrato inteligente `Counter`: +Faremos um contrato que permite a qualquer pessoa ter seu próprio contrato inteligente `Counter`, criando uma fábrica para ele. Seu nome será `CounterFactory`. Primeiro, aqui está o código do nosso contrato inteligente `Counter` inicial: ```solidity pragma solidity 0.5.17; @@ -31,12 +33,12 @@ contract Counter { modifier onlyOwner(address caller) { - require(caller == _owner, "You're not the owner of the contract"); + require(caller == _owner, "Você não é o proprietário do contrato"); _; } modifier onlyFactory() { - require(msg.sender == _factory, "You need to use the factory"); + require(msg.sender == _factory, "Você precisa usar a fábrica"); _; } @@ -56,19 +58,19 @@ contract Counter { } ``` -Note que modificamos ligeiramente o código do contrato para manter um controle do endereço da fábrica e do endereço do proprietário. Quando você chamar um código de contrato de outro contrato, o msg.sender irá consultar o endereço da nossa fábrica de contratos. Este é **um ponto muito importante para entender** como usar um contrato para interagir com outros contratos é uma prática comum. Você deve, portanto, cuidar de quem é o remetente em casos complexos. +Observe que modificamos ligeiramente o código do contrato para manter um registro do endereço da fábrica e do endereço do proprietário do contrato. Quando você chama o código de um contrato a partir de outro, o `msg.sender` se referirá ao endereço da nossa fábrica de contratos. Este é **um ponto muito importante a ser entendido**, pois usar um contrato para interagir com outros é uma prática comum. Portanto, você deve ter cuidado com quem é o remetente em casos complexos. -Para isso também adicionamos um modificador de `onlyFactory` que certifica-se de que a função de mudança de estado só pode ser chamada pela fábrica que passará o chamador original como um parâmetro. +Para isso, também adicionamos um modificador `onlyFactory` que garante que a função que altera o estado só possa ser chamada pela fábrica, que passará o chamador original como um parâmetro. -Dentro de nossa nova `CounterFactory` que gerenciará todos os outros Counters, adicionaremos um mapeamento que associará o proprietário ao endereço de seu contrato: +Dentro de nossa nova `CounterFactory`, que gerenciará todos os outros `Counters`, adicionaremos um mapeamento que associará um proprietário ao endereço de seu contrato `Counter`: ```solidity mapping(address => Counter) _counters; ``` -Na Ethereum, o mapeamento é equivalente a objetos em Javascript. Eles permitem mapear uma chave do tipo A para um valor do tipo B. Neste caso, mapeamos o endereço de um proprietário com a instância de seu Counter. +No Ethereum, mapeamentos são o equivalente a objetos em JavaScript; eles permitem mapear uma chave do tipo A para um valor do tipo B. Nesse caso, mapeamos o endereço de um proprietário com a instância de seu `Counter`. -Instanciar um novo Counter para alguém ficará assim: +Instanciar um novo `Counter` para alguém ficará assim: ```solidity function createCounter() public { @@ -77,9 +79,9 @@ Instanciar um novo Counter para alguém ficará assim: } ``` -Primeiro, verificamos se a pessoa já possui um Counter. Se ele não tem um Counter, instanciamos um novo Counter, passando seu endereço para o construtor `Counter` e atribuímos a instância recém-criada para o mapeamento. +Primeiro, verificamos se a pessoa já possui um `Counter`. Se a pessoa não possuir um `Counter`, nós instanciamos um novo, passando o endereço dela para o construtor `Counter`, e atribuímos a instância recém-criada ao mapeamento. -Para obter a contagem de um Counter específico, fica assim: +Para obter a contagem de um `Counter` específico, o código será assim: ```solidity function getCount(address account) public view returns (uint256) { @@ -92,9 +94,9 @@ function getMyCount() public view returns (uint256) { } ``` -A primeira função verifica se o contrato do Counter existe para um determinado endereço e, em seguida, chama o método `getCount` a partir da instância. A segunda função: `getMyCount` é apenas um breve fim para passar a função msg.sender diretamente para a função `getCount`. +A primeira função verifica se o contrato `Counter` existe para um determinado endereço e, em seguida, chama o método `getCount` da instância. A segunda função, `getMyCount`, é apenas um atalho para passar o `msg.sender` diretamente para a função `getCount`. -A função `increment` é bastante parecida, mas passa o remetente da transação original para o contrato `Counter`: +A função `increment` é bem parecida, mas passa o remetente da transação original para o contrato `Counter`: ```solidity function increment() public { @@ -103,9 +105,9 @@ function increment() public { } ``` -Observe que, se for chamado várias vezes, nosso contador poderá ser vítima de um transbordamento ("overflow"). Você deve usar a [biblioteca SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/) tanto quanto possível para se proteger deste possível caso. +Observe que, se chamada muitas vezes, nosso contador poderia ser vítima de um estouro (overflow). Você deve usar a [biblioteca SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/) o máximo possível para se proteger desse possível caso. -Para implantar nosso contrato, você precisará fornecer tanto o código da `CounterFactory` quanto o `Counter`. Ao implantar, por exemplo, em Remix, você precisará selecionar a CounterFactory. +Para implantar nosso contrato, você precisará fornecer tanto o código da `CounterFactory` quanto o do `Counter`. Ao implantar, por exemplo, no Remix, você precisará selecionar `CounterFactory`. Aqui está o código completo: @@ -120,12 +122,12 @@ contract Counter { modifier onlyOwner(address caller) { - require(caller == _owner, "You're not the owner of the contract"); + require(caller == _owner, "Você não é o proprietário do contrato"); _; } modifier onlyFactory() { - require(msg.sender == _factory, "You need to use the factory"); + require(msg.sender == _factory, "Você precisa usar a fábrica"); _; } @@ -170,8 +172,8 @@ contract CounterFactory { } ``` -Depois de compilar, na seção de implante de Remix, você selecionará a fábrica a ser implantada: +Após a compilação, na seção de implantação do Remix, você selecionará a fábrica a ser implantada: ![Selecionando a fábrica a ser implantada no Remix](./counterfactory-deploy.png) -Então você pode brincar com sua fábrica de contrato e verificar a mudança de valor. Se você prefere chamar o contrato inteligente a partir de um endereço diferente, altere o endereço na Conta selecionada do Remix. +Então você pode experimentar sua fábrica de contratos e verificar a alteração de valor. Se você quiser chamar o contrato inteligente de um endereço diferente, precisará alterar o endereço no seletor de Contas do Remix. diff --git a/public/content/translations/pt-br/developers/tutorials/ipfs-decentralized-ui/index.md b/public/content/translations/pt-br/developers/tutorials/ipfs-decentralized-ui/index.md new file mode 100644 index 00000000000..8e08c7c603a --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/ipfs-decentralized-ui/index.md @@ -0,0 +1,73 @@ +--- +title: "IPFS para interfaces de usuário descentralizadas" +description: "Este tutorial ensina o leitor a usar o IPFS para armazenar a interface do usuário para um dapp. Embora os dados e a lógica de negócios do aplicativo sejam descentralizados, sem uma interface de usuário resistente à censura, os usuários podem perder o acesso a ele de qualquer maneira." +author: Ori Pomerantz +tags: [ "ipfs" ] +skill: beginner +lang: pt-br +published: 2024-06-29 +--- + +Você escreveu um novo dapp incrível. Você até escreveu uma [interface de usuário](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) para ele. Mas agora você tem medo de que alguém tente censurá-lo, derrubando sua interface de usuário, que é apenas um servidor na nuvem. Neste tutorial, você aprende a evitar a censura colocando sua interface de usuário no **[sistema de arquivos interplanetário (IPFS)](https://ipfs.tech/developers/)** para que qualquer pessoa interessada possa fixá-lo em um servidor para acesso futuro. + +Você pode usar um serviço de terceiros, como o [Fleek](https://resources.fleek.xyz/docs/), para fazer todo o trabalho. Este tutorial é para pessoas que querem fazer o suficiente para entender o que estão fazendo, mesmo que dê mais trabalho. + +## Começando localmente {#getting-started-locally} + +Existem vários [provedores IPFS de terceiros](https://docs.ipfs.tech/how-to/work-with-pinning-services/#use-a-third-party-pinning-service), mas é melhor começar executando o IPFS localmente para testes. + +1. Instale a [interface de usuário do IPFS](https://docs.ipfs.tech/install/ipfs-desktop/#install-instructions). + +2. Crie um diretório com seu site. Se você estiver usando o [Vite](https://vite.dev/), use este comando: + + ```sh + pnpm vite build + ``` + +3. No IPFS Desktop, clique em **Importar > Pasta** e selecione o diretório que você criou na etapa anterior. + +4. Selecione a pasta que você acabou de carregar e clique em **Renomear**. Dê a ele um nome mais significativo. + +5. Selecione-o novamente e clique em **Compartilhar link**. Copie a URL para a área de transferência. O link será semelhante a `https://ipfs.io/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`. + +6. Clique em **Status**. Expanda a guia **Avançado** para ver o endereço do gateway. Por exemplo, no meu sistema, o endereço é `http://127.0.0.1:8080`. + +7. Combine o caminho da etapa do link com o endereço do gateway para encontrar seu endereço. Por exemplo, para o exemplo acima, a URL é `http://127.0.0.1:8080/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`. Abra essa URL em um navegador para ver seu site. + +## Fazendo upload {#uploading} + +Então agora você pode usar o IPFS para servir arquivos localmente, o que não é muito emocionante. O próximo passo é torná-los disponíveis para o mundo quando você estiver offline. + +Existem vários [serviços de fixação](https://docs.ipfs.tech/concepts/persistence/#pinning-services) bem conhecidos. Escolha um deles. Qualquer que seja o serviço que você usar, você precisa criar uma conta e fornecer a ela o **identificador de conteúdo (CID)** no seu IPFS desktop. + +Pessoalmente, achei o [4EVERLAND](https://docs.4everland.org/storage/4ever-pin/guides) o mais fácil de usar. Aqui estão as instruções para isso: + +1. Navegue até [o painel](https://dashboard.4everland.org/overview) e faça login com sua carteira. + +2. Na barra lateral esquerda, clique em **Armazenamento > 4EVER Pin**. + +3. Clique em **Carregar > CID Selecionado**. Dê um nome ao seu conteúdo e forneça o CID do IPFS desktop. Atualmente, um CID é uma string que começa com `Qm` seguida por 44 letras e dígitos que representam um hash [codificado em base-58](https://medium.com/bootdotdev/base64-vs-base58-encoding-c25553ff4524), como `QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`, mas [isso provavelmente mudará](https://docs.ipfs.tech/concepts/content-addressing/#version-1-v1). + +4. O status inicial é **Na fila**. Recarregue até que mude para **Fixado**. + +5. Clique no seu CID para obter o link. Você pode ver meu aplicativo [aqui](https://bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im.ipfs.dweb.link/). + +6. Você pode precisar ativar sua conta para mantê-lo fixado por mais de um mês. A ativação da conta custa cerca de US$ 1. Se você fechou, saia e faça login novamente para ser solicitado a ativar novamente. + +## Usando do IPFS {#using-from-ipfs} + +Neste ponto, você tem um link para um gateway centralizado que serve seu conteúdo IPFS. Em resumo, sua interface de usuário pode ser um pouco mais segura, mas ainda não é resistente à censura. Para uma real resistência à censura, os usuários precisam usar o IPFS [diretamente de um navegador](https://docs.ipfs.tech/install/ipfs-companion/#prerequisites). + +Depois de instalá-lo (e com o IPFS desktop funcionando), você pode ir para [/ipfs/``](https://any.site/ipfs/bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im) em qualquer site e obterá esse conteúdo, servido de maneira descentralizada. + +## Desvantagens {#drawbacks} + +Você não pode excluir arquivos IPFS de forma confiável, então, enquanto estiver modificando sua interface de usuário, provavelmente é melhor deixá-la centralizada ou usar o [sistema de nomes interplanetário (IPNS)](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs), um sistema que fornece mutabilidade sobre o IPFS. Claro, qualquer coisa que seja mutável pode ser censurada, no caso do IPNS, pressionando a pessoa com a chave privada à qual corresponde. + +Além disso, alguns pacotes têm problemas com o IPFS, então se o seu site for muito complicado, essa pode não ser uma boa solução. E, claro, qualquer coisa que dependa da integração do servidor não pode ser descentralizada apenas por ter o lado do cliente no IPFS. + +## Conclusão {#conclusion} + +Assim como o Ethereum permite que você descentralize o banco de dados e os aspectos da lógica de negócios do seu dapp, o IPFS permite que você descentralize a interface do usuário. Isso permite que você elimine mais um vetor de ataque contra o seu dapp. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md new file mode 100644 index 00000000000..f3c3769e3f8 --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md @@ -0,0 +1,111 @@ +--- +title: "Dê o pontapé inicial no desenvolvimento do frontend do seu dapp com o create-eth-app" +description: "Uma visão geral de como usar o create-eth-app e seus recursos" +author: "Markus Waas" +tags: + [ + "front-end", + "JavaScript", + "ethers.js", + "the graph", + "defi" + ] +skill: beginner +lang: pt-br +published: 2020-04-27 +source: soliditydeveloper.com +sourceUrl: https://soliditydeveloper.com/create-eth-app +--- + +Na última vez, vimos [o panorama geral do Solidity](https://soliditydeveloper.com/solidity-overview-2020) e já mencionamos o [create-eth-app](https://github.com/PaulRBerg/create-eth-app). Agora você descobrirá como usá-lo, quais recursos estão integrados e ideias adicionais sobre como expandi-lo. Iniciado por Paul Razvan Berg, o fundador do [Sablier](http://sablier.com/), este aplicativo dará o pontapé inicial no seu desenvolvimento de frontend e vem com várias integrações opcionais para você escolher. + +## Instalação {#installation} + +A instalação requer o Yarn 0.25 ou superior (`npm install yarn --global`). É tão simples quanto executar: + +```bash +yarn create eth-app my-eth-app +cd my-eth-app +yarn react-app:start +``` + +Ele usa o [create-react-app](https://github.com/facebook/create-react-app) por baixo dos panos. Para ver seu app, abra `http://localhost:3000/`. Quando estiver pronto para implantar em produção, crie um pacote minificado com `yarn build`. Uma maneira fácil de hospedar isso seria o [Netlify](https://www.netlify.com/). Você pode criar um repositório no GitHub, adicioná-lo ao Netlify, configurar o comando de build e pronto! Seu app será hospedado e poderá ser usado por todos. E tudo isso gratuitamente. + +## Recursos {#features} + +### React e create-react-app {#react--create-react-app} + +Primeiramente, o coração do app: o React e todos os recursos adicionais que vêm com o _create-react-app_. Usar apenas isso é uma ótima opção se você não quiser integrar o Ethereum. O próprio [React](https://react.dev/) torna a criação de UIs interativas muito fácil. Pode não ser tão amigável para iniciantes quanto o [Vue](https://vuejs.org/), mas ainda é o mais utilizado, tem mais recursos e, o mais importante, milhares de bibliotecas adicionais para escolher. O _create-react-app_ também torna muito fácil começar a usá-lo e inclui: + +- Suporte às sintaxes React, JSX, ES6, TypeScript e Flow. +- Recursos de linguagem além do ES6, como o operador de propagação de objeto. +- CSS com prefixo automático, para que você não precise de `-webkit-` ou outros prefixos. +- Um executor de testes unitários rápido e interativo com suporte integrado para relatórios de cobertura. +- Um servidor de desenvolvimento em tempo real que avisa sobre erros comuns. +- Um script de build para empacotar JS, CSS e imagens para produção, com hashes e sourcemaps. + +O _create-eth-app_ em particular faz uso dos novos [efeitos de hooks](https://legacy.reactjs.org/docs/hooks-effect.html). Um método para escrever os chamados componentes funcionais, que são poderosos, mas muito pequenos. Veja a seção abaixo sobre o Apollo para saber como eles são usados no _create-eth-app_. + +### Yarn Workspaces {#yarn-workspaces} + +Os [Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) permitem que você tenha vários pacotes, mas com a capacidade de gerenciá-los todos a partir da pasta raiz e instalar as dependências de todos de uma vez usando `yarn install`. Isso faz sentido especialmente para pacotes adicionais menores, como o gerenciamento de endereços/ABIs de contratos inteligentes (as informações sobre onde você implantou quais contratos inteligentes e como se comunicar com eles) ou a integração do graph, ambos parte do `create-eth-app`. + +### ethers.js {#ethersjs} + +Embora o [Web3](https://docs.web3js.org/) ainda seja o mais usado, o [ethers.js](https://docs.ethers.io/) tem ganhado muito mais força como alternativa no último ano e é o que está integrado no _create-eth-app_. Você pode trabalhar com ele, alterá-lo para Web3 ou considerar a atualização para o [ethers.js v5](https://docs.ethers.org/v5/), que está quase saindo da versão beta. + +### The Graph {#the-graph} + +[GraphQL](https://graphql.org/) é uma forma alternativa de lidar com dados em comparação com uma [API Restful](https://restfulapi.net/). Eles têm várias vantagens sobre as APIs Restful, especialmente para dados descentralizados da cadeia de blocos. Se você estiver interessado no raciocínio por trás disso, dê uma olhada em [GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a). + +Normalmente, você buscaria dados diretamente do seu contrato inteligente. Quer ler o horário da última negociação? Basta chamar `MyContract.methods.latestTradeTime().call()`, que busca os dados de um nó do Ethereum para o seu dapp. Mas e se você precisar de centenas de pontos de dados diferentes? Isso resultaria em centenas de buscas de dados no nó, cada uma exigindo um [RTT](https://wikipedia.org/wiki/Round-trip_delay_time), tornando seu dapp lento e ineficiente. Uma solução alternativa pode ser uma função de chamada de busca dentro do seu contrato que retorna múltiplos dados de uma vez. No entanto, isso nem sempre é o ideal. + +E você também pode se interessar por dados históricos. Você quer saber não apenas o horário da última negociação, mas os horários de todas as negociações que você mesmo já fez. Use o pacote subgraph do _create-eth-app_, leia a [documentação](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph) e adapte-o aos seus próprios contratos. Se você estiver procurando por contratos inteligentes populares, pode ser que já exista um subgraph. Confira o [explorador de subgraphs](https://thegraph.com/explorer/). + +Depois de ter um subgraph, ele permite que você escreva uma consulta simples em seu dapp que recupera todos os dados importantes da cadeia de blocos, incluindo os históricos que você precisa, com apenas uma busca necessária. + +### Apollo {#apollo} + +Graças à integração do [Apollo Boost](https://www.apollographql.com/docs/react/get-started/), você pode integrar facilmente o graph em seu dapp React. Especialmente ao usar [React hooks e Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks), buscar dados é tão simples quanto escrever uma única consulta GraphQL em seu componente: + +```js +const { loading, error, data } = useQuery(myGraphQlQuery) + +React.useEffect(() => { + if (!loading && !error && data) { + console.log({ data }) + } +}, [loading, error, data]) +``` + +## Modelos {#templates} + +Além disso, você pode escolher entre vários modelos diferentes. Até agora, você pode usar uma integração com Aave, Compound, UniSwap ou sablier. Todos eles adicionam endereços de contratos inteligentes de serviços importantes, juntamente com integrações de subgraphs pré-fabricadas. Basta adicionar o modelo ao comando de criação, como `yarn create eth-app my-eth-app --with-template aave`. + +### Aave {#aave} + +O [Aave](https://aave.com/) é um mercado descentralizado de empréstimo de dinheiro. Os depositantes fornecem liquidez ao mercado para obter uma renda passiva, enquanto os mutuários podem pegar emprestado usando garantias. Uma característica única do Aave são os [empréstimos-relâmpago (flash loans)](https://aave.com/docs/developers/flash-loans), que permitem que você pegue dinheiro emprestado sem qualquer garantia, desde que devolva o empréstimo em uma única transação. Isso pode ser útil, por exemplo, para lhe dar um dinheiro extra em negociações de arbitragem. + +Os tokens negociados que rendem juros são chamados de _aTokens_. + +Ao optar por integrar o Aave com o _create-eth-app_, você obterá uma [integração de subgraph](https://docs.aave.com/developers/getting-started/using-graphql). O Aave usa o The Graph e já fornece vários subgraphs prontos para uso na [Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten) e na [Rede Principal (Mainnet)](https://thegraph.com/explorer/subgraph/aave/protocol) em formato [bruto (raw)](https://thegraph.com/explorer/subgraph/aave/protocol-raw) ou [formatado (formatted)](https://thegraph.com/explorer/subgraph/aave/protocol). + +![Meme de Empréstimo-Relâmpago (Flash Loan) da Aave – \"Éééé, se eu pudesse manter meu empréstimo-relâmpago por mais de 1 transação, seria ótimo\"](./flashloan-meme.png) + +### Compound {#compound} + +O [Compound](https://compound.finance/) é semelhante ao Aave. A integração já inclui o novo [Compound v2 Subgraph](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195). Os tokens que rendem juros aqui são, surpreendentemente, chamados de _cTokens_. + +### Uniswap {#uniswap} + +A [Uniswap](https://uniswap.exchange/) é uma corretora descentralizada (DEX). Os provedores de liquidez podem ganhar taxas fornecendo os tokens ou ether necessários para ambos os lados de uma negociação. É amplamente utilizada e, portanto, tem uma das maiores liquidez para uma gama muito ampla de tokens. Você pode integrá-la facilmente em seu dapp para, por exemplo, permitir que os usuários façam o swap de seus ETH por DAI. + +Infelizmente, no momento em que este artigo foi escrito, a integração é apenas para a Uniswap v1 e não para a [versão v2 recém-lançada](https://uniswap.org/blog/uniswap-v2/). + +### Sablier {#sablier} + +O [Sablier](https://sablier.com/) permite que os usuários façam pagamentos de dinheiro por streaming. Em vez de um único dia de pagamento, você recebe seu dinheiro constantemente, sem necessidade de administração adicional após a configuração inicial. A integração inclui seu [próprio subgraph](https://thegraph.com/explorer/subgraph/sablierhq/sablier). + +## O que vem a seguir? {#whats-next} + +Se você tiver dúvidas sobre o _create-eth-app_, acesse o [servidor da comunidade Sablier](https://discord.gg/bsS8T47), onde você pode entrar em contato com os autores do _create-eth-app_. Como próximos passos, você pode querer integrar um framework de UI como o [Material UI](https://mui.com/material-ui/), escrever consultas GraphQL para os dados que você realmente precisa e configurar a implantação. diff --git a/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md b/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md index d697c1f2039..aad9f84f3f3 100644 --- a/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md +++ b/public/content/translations/pt-br/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md @@ -1,6 +1,6 @@ --- title: Comece a desenvolver o front-end do seu dapp usando create-eth-app -description: Uma visão geral de como criar um aplicativo eth-app e seus recursos +description: "Uma visão geral de como criar um aplicativo eth-app e seus recursos" author: "Markus Waas" tags: - "create-eth-app" diff --git a/public/content/translations/pt-br/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md b/public/content/translations/pt-br/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md index fbfad7e5fa5..848360459d4 100644 --- a/public/content/translations/pt-br/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md +++ b/public/content/translations/pt-br/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md @@ -1,39 +1,36 @@ --- -title: Aprenda Tópicos fundamentais de Ethereum com SQL -description: Este tutorial ajuda os leitores a entender os conceitos fundamentais de Ethereum, incluindo transações, blocos e gas, consultando dados on-chain com linguagem de consulta estruturada (SQL). +title: "Aprenda Tópicos Fundamentais do Ethereum com SQL" +description: "Este tutorial ajuda os leitores a entenderem os conceitos fundamentais do Ethereum, incluindo transações, blocos e gás, consultando dados em cadeia com a Linguagem de Consulta Estruturada (SQL)." author: "Paul Apivat" -tags: - - "SQL" - - "Querying" - - "Transações" -skill: intermediate +tags: [ "SQL", "Consulta", "Transações" ] +skill: beginner lang: pt-br published: 2021-05-11 source: paulapivat.com sourceUrl: https://paulapivat.com/post/query_ethereum/ --- -Muitos tutorias da Ethereum são direcionadas para desenvolvedores, mas há uma falta de recursos educacionais para analistas de dados ou pessoas que desejam ver dados on-chain sem executar um cliente ou um nó. +Muitos tutoriais do Ethereum são direcionados a desenvolvedores, mas há uma falta de recursos educacionais para analistas de dados ou para pessoas que desejam ver dados em cadeia sem executar um cliente ou um nó. -Esse tutorial ajuda os leitores a entenderem os conceitos fundamentais da Ethereum, incluindo transações, blocos e gás, consultando dados on-chain com a linguagem SQL por meio de uma interface fornecida por [Dune Analytics](https://dune.xyz/home). +Este tutorial ajuda os leitores a entenderem os conceitos fundamentais do Ethereum, incluindo transações, blocos e gás, consultando dados em cadeia com a linguagem de consulta estruturada (SQL) por meio de uma interface fornecida pela [Dune Analytics](https://dune.com/). -Dados on-chain podem nos ajudar a compreender a rede Ethereum como uma economia para capacidade computacional, e deve servir como base para entender os desafios enfrentados pela Ethereum hoje (por exemplo, o aumento dos preços do gas) e, o mais importante, discussões sobre soluções de escalabilidade. +Dados em cadeia podem nos ajudar a compreender o Ethereum, a rede, e como uma economia para poder computacional. Eles devem servir como base para entender os desafios que o Ethereum enfrenta hoje (ou seja, o aumento dos preços do gás) e, mais importante, as discussões sobre soluções de escalabilidade. ### Transações {#transactions} -A jornada do usuário no Ethereum começa com a inicialização de uma conta controlada ou uma entidade com saldo ETH. Há duas categorias de contas: controlada pelo usuário ou um contrato inteligente (veja em: [ethereum.org](/developers/docs/accounts/)). +A jornada de um usuário no Ethereum começa com a inicialização de uma conta controlada pelo usuário ou uma entidade com saldo de ETH. Existem dois tipos de conta: controlada pelo usuário ou um contrato inteligente (consulte [ethereum.org](/developers/docs/accounts/)). -Qualquer conta pode ser visualizada em um explorador de bloco como a [Etherscan](https://etherscan.io/). Exploradores de bloco são um portal para os dados da Ethereum. Eles exibem, em tempo real, dados em blocos, transações, mineiradores, contas, e outras atividades on-chain (veja [aqui](/developers/docs/data-and-analytics/block-explorers/)). +Qualquer conta pode ser visualizada em um explorador de blocos como o [Etherscan](https://etherscan.io/) ou o [Blockscout](https://eth.blockscout.com/). Os exploradores de blocos são um portal para os dados do Ethereum. Eles exibem, em tempo real, dados sobre blocos, transações, mineradores, contas e outras atividades em cadeia (veja [aqui](/developers/docs/data-and-analytics/block-explorers/)). -No entanto, um usuário pode desejar consultar um dado diretamente para reconciliar as informações fornecidas por exploradores de bloco externos. O [Dune Analytics](https://duneanalytics.com/) fornece esse recurso para qualquer pessoa com algum conhecimento em SQL. +No entanto, um usuário pode querer consultar os dados diretamente para reconciliar as informações fornecidas por exploradores de blocos externos. O [Dune Analytics](https://dune.com/) oferece essa capacidade a qualquer pessoa com algum conhecimento de SQL. -Como referência, a conta de contrato inteligente da Fundação Ethereum (EF) pode ser visualizada na [Etherscan](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae). +Para referência, a conta de contrato inteligente da Ethereum Foundation (EF) pode ser visualizada no [Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe). -Uma coisa a ser observada é que todas as contas, incluindo as EF's, têm um endereço público que pode ser utilizado para enviar e receber transações. +Uma coisa a se notar é que todas as contas, incluindo a da EF, têm um endereço público que pode ser usado para enviar e receber transações. -O saldo da conta na Etherscan inclui transações regulare e transações internas. As transações internas, apesar do nome, não são _realmente_ transações que alteram o estado da cadeia. Elas são transferências de valores iniciadas pela execução de um contrato ([fonte](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions)). Visto que as transações internas não têm assinatura, elas **não** são incluídas na blockchain e não podem ser consultadas com o Dune Analytics. +O saldo da conta no Etherscan compreende transações regulares e transações internas. Transações internas, apesar do nome, não são transações _reais_ que mudam o estado da cadeia. São transferências de valor iniciadas pela execução de um contrato ([fonte](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions)). Como as transações internas não têm assinatura, elas **não** são incluídas na blockchain e não podem ser consultadas com o Dune Analytics. -Portanto, este tutorial irá focar em transações regulares. Isso pode ser consultado como: +Portanto, este tutorial se concentrará em transações regulares. Isso pode ser consultado da seguinte forma: ```sql WITH temp_table AS ( @@ -61,33 +58,33 @@ SELECT FROM temp_table ``` -Isso irá gerar as mesmas informações fornecidas na página de transações do Etherscan. Para você comparar, aqui estão duas fontes: +Isso resultará na mesma informação fornecida na página de transações do Etherscan. Para comparação, aqui estão as duas fontes: #### Etherscan {#etherscan} ![Captura de tela da visualização do explorador de transações Etherscan](./etherscan_view.png) -[Visualizar página de contratos de EF's no Etherscan.](https://etherscan.io/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) +[Página do contrato da EF no Blockscout.](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) #### Dune Analytics {#dune-analytics} ![Captura de tela de um painel de consulta do Dune Analytics](./dune_view.png) -Você pode encontrar o painel [aqui](https://duneanalytics.com/paulapivat/Learn-Ethereum). Clique na tabela para visualizar a consulta (veja também acima). +Você pode encontrar o painel [aqui](https://dune.com/paulapivat/Learn-Ethereum). Clique na tabela para ver a consulta (veja também acima). -### Decompondo Transações {#breaking_down_transactions} +### Analisando as Transações {#breaking_down_transactions} Uma transação enviada inclui várias informações, incluindo ([fonte](/developers/docs/transactions/)): -- **Destinatário**: O endereço de recebimento (chamado como "para") -- **Assinatura**: Enquanto as chaves privadas de um remetente assinam uma transação, o que podemos consultar com o SQL é o endereço público de um remetente ("de"). -- **Valor**: Esta é a quantidade de ETH transferido (veja a coluna `ether`). -- **Dados**: Estes são dados arbitrários misturados (veja a coluna `dados`). -- **gasLimit**: a quantidade máxima de gas que pode ser consumida pela transação. As unidades de gas representam etapas computacionais -- **maxPriorityFeePerGas**: a quantidade máxima de gas a ser incluída como dica para o minerador -- **maxFeePerGas** - a quantidade máxima de gas disposta a ser paga pela transação (incluindo baseFeePerGas e maxPriorityFeePerGas) +- **Destinatário**: O endereço de recebimento (consultado como "to") +- **Assinatura**: Embora as chaves privadas de um remetente assinem uma transação, o que podemos consultar com SQL é o endereço público de um remetente ("from"). +- **Valor**: Esta é a quantidade de ETH transferida (veja a coluna `ether`). +- **Dados**: São dados arbitrários que sofreram hash (consulte a coluna `data`) +- **gasLimit** – a quantidade máxima de unidades de gás que podem ser consumidas pela transação. As unidades de gás representam etapas computacionais +- **maxPriorityFeePerGas** - a quantidade máxima de gás a ser incluída como gorjeta para o minerador +- **maxFeePerGas** - a quantidade máxima de gás que se está disposto a pagar pela transação (incluindo baseFeePerGas e maxPriorityFeePerGas) -Podemos consultar essas informações específicas sobre transações no endereço público da Fundação Ethereum: +Podemos consultar estas informações específicas para transações para o endereço público da Ethereum Foundation: ```sql SELECT @@ -106,15 +103,15 @@ ORDER BY block_time DESC ### Blocos {#blocks} -Cada transação irá alterar o estado da máquina virtual da Ethereum ([EVM](/developers/docs/evm/)) ([fonte](/developers/docs/transactions/)). As transações são transmitidas à rede para serem verificadas e incluídas em um bloco. Cada transação está associada a um número de bloco. Para ver os dados, nós podemos consultar um número de bloco específico: 12396854 (o bloco mais recente entre as transações da Fundação Ethereum a partir desta escrita, 11/05/21). +Cada transação mudará o estado da máquina virtual ethereum ([EVM](/developers/docs/evm/)) ([fonte](/developers/docs/transactions/)). As transações são transmitidas para a rede para serem verificadas e incluídas em um bloco. Cada transação está associada a um número de bloco. Para ver os dados, podemos consultar um número de bloco específico: 12396854 (o bloco mais recente entre as transações da Ethereum Foundation no momento da redação deste artigo, em 11/05/21). -Além disso, quando consultarmos os próximos dois blocos, podemos observar que cada bloco contém o hash do bloco anterior (i.., hash pai), ilustrando como a blockchain é formada. +Além disso, quando consultamos os dois blocos seguintes, podemos ver que cada bloco contém o hash do bloco anterior (ou seja, o hash pai), ilustrando como a blockchain é formada. -Cada bloco contém uma referência ao bloco pai. Isso é mostrado abaixo entre as colunas `hash` e `parent_hash` (fonte[](/developers/docs/blocks/)): +Cada bloco contém uma referência ao seu bloco pai. Isso é mostrado abaixo entre as colunas `hash` e `parent_hash` ([fonte](/developers/docs/blocks/)): ![parent_hash](./parent_hash.png) -Aqui está a [consulta](https://duneanalytics.com/queries/44856/88292) no Dune Analytics: +Aqui está a [consulta](https://dune.com/queries/44856/88292) no Dune Analytics: ```sql SELECT @@ -128,18 +125,18 @@ WHERE "number" = 12396854 OR "number" = 12396855 OR "number" = 12396856 LIMIT 10 ``` -Podemos examinar um bloco consultando o horário, o número de bloco, a dificuldade (quantidade de computação necessária), o hash, o hash pai e a nonce. +Podemos examinar um bloco consultando o tempo, o número do bloco, a dificuldade, o hash, o hash pai e o nonce. -A única coisa que esta consulta não cobre é a _lista de transações_ que requer uma consulta separada abaixo e _raiz do estado_. Um nó completo ou de arquivamento irá armazenar todas as transações e transições de estado, permitindo que os clientes consultem o estado da cadeia a qualquer momento. Como isso requer um grande espaço de armazenamento, nós podemos separar os dados em cadeia dos dados de estado: +A única coisa que esta consulta não cobre é a _lista de transações_, que requer uma consulta separada abaixo, e a _raiz do estado_. Um nó completo ou de arquivamento armazenará todas as transações e transições de estado, permitindo que os clientes consultem o estado da cadeia a qualquer momento. Como isso exige um grande espaço de armazenamento, podemos separar os dados da cadeia dos dados de estado: -- Dados em cadeia (lista de blocos, transações) +- Dados da cadeia (lista de blocos, transações) - Dados de estado (resultado da transição de estado de cada transação) -A raiz de estado cai na última e são _ dados implícitos_ (não armazenados na cadeia), enquanto os dados em cadeia são explícitos e armazenados na própria cadeia ([fonte](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored)). +A raiz do estado se enquadra no último e são dados _implícitos_ (não armazenados em cadeia), enquanto os dados da cadeia são explícitos e armazenados na própria cadeia ([fonte](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored)). -Para este tutorial, estaremos focando em dados on-chain que _podem_ ser consultados com SQL via Dune Analytics. +Neste tutorial, vamos nos concentrar nos dados em cadeia que _podem_ ser consultados com SQL via Dune Analytics. -Como mencionado acima, cada bloco contém uma lista de transações, podemos consultar isso filtrando por um bloco específico. Vamos tentar o bloco mais recente, 12396854: +Conforme indicado acima, cada bloco contém uma lista de transações. Podemos consultar isso filtrando por um bloco específico. Vamos tentar o bloco mais recente, 12396854: ```sql SELECT * FROM ethereum."transactions" @@ -147,13 +144,13 @@ WHERE block_number = 12396854 ORDER BY block_time DESC` ``` -Segue o SQL output no Dune: +Aqui está a saída SQL no Dune: ![](./list_of_txn.png) -Este único bloco sendo adicionado à cadeia altera o estado da máquina virtual Ethereum ([EVM](/developers/docs/evm/)). Dezenas, às vezes centenas, de transações são verificadas de uma só vez. Neste caso específico, foram incluídas 222 transações. +Este único bloco adicionado à cadeia altera o estado da máquina virtual ethereum ([EVM](/developers/docs/evm/)). Dezenas, às vezes centenas, de transações são verificadas de uma só vez. Neste caso específico, 222 transações foram incluídas. -Para ver quantas foram realmente bem-sucedidas, nós adicionaríamos outro filtro para contar transações bem-sucedidas: +Para ver quantas foram realmente bem-sucedidas, adicionaríamos outro filtro para contar as transações bem-sucedidas: ```sql WITH temp_table AS ( @@ -166,26 +163,26 @@ SELECT FROM temp_table ``` -Para o bloco 12396854, do total de 222 transações, 204 foram verificadas com sucesso: +Para o bloco 12396854, de um total de 222 transações, 204 foram verificadas com sucesso: ![](./successful_txn.png) -As solicitações de transações ocorrem dezenas de vezes por segundo, mas os blocos são confirmados aproximadamente uma vez a cada 15 segundos ([source](/developers/docs/blocks/)). +As solicitações de transação ocorrem dezenas de vezes por segundo, mas os blocos são consolidados aproximadamente uma vez a cada 15 segundos ([fonte](/developers/docs/blocks/)). -Para ver que há um bloco produzido aproximadamente a cada 15 segundos, poderíamos pegar o número de segundos em um dia (86400) por 15, para obter um número médio estimado de blocos por dia (~ 5760). +Para ver que um bloco é produzido aproximadamente a cada 15 segundos, poderíamos pegar o número de segundos em um dia (86400) e dividi-lo por 15 para obter um número médio estimado de blocos por dia (~ 5760). -O gráfico de blocos Ethereum produzidos por dia (2016 - presente) é: +O gráfico de blocos do Ethereum produzidos por dia (2016 - presente) é: ![](./daily_blocks.png) -O número médio de blocos produzidos diariamente durante esse período de tempo é de aproximadamente ~5.874: +O número médio de blocos produzidos diariamente durante este período é de aproximadamente 5.874: ![](./avg_daily_blocks.png) As consultas são: ```sql -# query to visualize number of blocks produced daily since 2016 +# consulta para visualizar o número de blocos produzidos diariamente desde 2016 SELECT DATE_TRUNC('day', time) AS dt, @@ -194,7 +191,7 @@ FROM ethereum."blocks" GROUP BY dt OFFSET 1 -# average number of blocks produced per day +# número médio de blocos produzidos por dia WITH temp_table AS ( SELECT @@ -209,13 +206,13 @@ SELECT FROM temp_table ``` -O número médio de blocos produzidos por dia desde 2016 está um pouco acima desse número em 5.874. Alternativamente, dividindo 86400 segundos por 5874 blocos médios resultam em 14,7 segundos ou aproximadamente um bloco a cada 15 segundos. +O número médio de blocos produzidos por dia desde 2016 é ligeiramente superior a esse número, em 5.874. Alternativamente, dividir 86400 segundos por uma média de 5874 blocos resulta em 14,7 segundos ou aproximadamente um bloco a cada 15 segundos. ### Gás {#gas} -Blocos são limitados em tamanho. O tamanho máximo do bloco é dinâmico e varia de acordo com a demanda de rede entre 12.500.000 e 25.000.000 unidades. Limites são necessários para evitar que, blocos de tamanho arbitrariamente grandes coloquem tensão em nós completos, em termos de espaço em disco e requisitos de velocidade ([source](/developers/docs/blocks/)). +Os blocos têm um tamanho limitado. O tamanho máximo do bloco é dinâmico e varia de acordo com a demanda da rede entre 12.500.000 e 25.000.000 unidades. São necessários limites para evitar que blocos de tamanho arbitrariamente grande sobrecarreguem os nós completos em termos de espaço em disco e requisitos de velocidade ([fonte](/developers/docs/blocks/)). -Uma maneira de conceitualizar o limite de gas do bloco é pensar nele como o **suprimento** de espaço de bloco disponível para as transações em lote. O limite de gas do bloco pode ser consultado e visualizado a partir de 2016 até o presente dia: +Uma forma de conceituar o limite de gás do bloco é pensar nele como a **oferta** de espaço de bloco disponível para transações em lote. O limite de gás do bloco pode ser consultado e visualizado de 2016 até os dias atuais: ![](./avg_gas_limit.png) @@ -228,7 +225,7 @@ GROUP BY dt OFFSET 1 ``` -Depois, há o gas real usado diariamente para pagar pela computação realizada na cadeia Ethereum (ou seja, enviar transações, chamar um contrato inteligente, cunhar um NFT). Esta é a **demanda** por espaço de bloco disponível no Ethereum: +Depois, há o gás real usado diariamente para pagar pela computação feita na cadeia Ethereum (ou seja, enviar transações, chamar um contrato inteligente, mintar um NFT). Esta é a **demanda** por espaço de bloco disponível no Ethereum: ![](./daily_gas_used.png) @@ -241,17 +238,17 @@ GROUP BY dt OFFSET 1 ``` -Também podemos justapor esses dois gráficos para ver como a **demanda e oferta** se alinham: +Também podemos justapor estes dois gráficos para ver como a **demanda e a oferta** se alinham: ![gas_demand_supply](./gas_demand_supply.png) -Portanto, podemos entender os preços do gas em função da demanda por espaço no bloco Ethereum, dada a oferta disponível. +Portanto, podemos entender os preços do gás como uma função da demanda por espaço de bloco do Ethereum, dada a oferta disponível. -Finalmente, podemos querer consultar os preços médios diários do gas para a cadeia Ethereum, no entanto, fazê-lo resultará em um tempo de consulta especialmente longo, então, filtraremos a nossa consulta pela quantidade média de gas paga por transação pela Fundação Ethereum. +Finalmente, podemos querer consultar os preços médios diários do gás para a cadeia Ethereum. No entanto, isso resultará em um tempo de consulta especialmente longo, por isso filtraremos nossa consulta para a quantidade média de gás paga por transação pela Ethereum Foundation. ![](./ef_daily_gas.png) -Podemos ver os preços do gas pagos por todas as transações feitas para o endereço da Ethereum Foundation ao longo dos anos. Aqui está a consulta: +Podemos ver os preços do gás pagos por todas as transações feitas para o endereço da Ethereum Foundation ao longo dos anos. Aqui está a consulta: ```sql SELECT @@ -265,8 +262,8 @@ ORDER BY block_time DESC ### Resumo {#summary} -Com este tutorial, entendemos os conceitos fundamentais do Ethereum e como a blockchain do Ethereum funciona consultando e obtendo uma ideia dos dados on-chain. +Com este tutorial, entendemos os conceitos fundamentais do Ethereum e como a blockchain do Ethereum funciona, consultando e tendo uma noção dos dados em cadeia. -O painel que contém todo o código usado neste tutorial pode ser encontrado [aqui](https://duneanalytics.com/paulapivat/Learn-Ethereum). +O painel que contém todo o código usado neste tutorial pode ser encontrado [aqui](https://dune.com/paulapivat/Learn-Ethereum). -Para mais uso de dados para explorar a web3 [siga-me no Twitter](https://twitter.com/paulapivat). +Para mais usos de dados para explorar a web3, [encontre-me no Twitter](https://twitter.com/paulapivat). diff --git a/public/content/translations/pt-br/developers/tutorials/logging-events-smart-contracts/index.md b/public/content/translations/pt-br/developers/tutorials/logging-events-smart-contracts/index.md index d74031cc9e8..1286acb2a7f 100644 --- a/public/content/translations/pt-br/developers/tutorials/logging-events-smart-contracts/index.md +++ b/public/content/translations/pt-br/developers/tutorials/logging-events-smart-contracts/index.md @@ -1,12 +1,8 @@ --- title: Registrando dados de contratos inteligentes com eventos -description: Uma introdução aos eventos de contrato inteligentes e como você pode usá-los para registrar os dados +description: "Uma introdução aos eventos de contrato inteligente e como você pode usá-los para registrar dados" author: "jdourlens" -tags: - - "contratos inteligentes" - - "remix" - - "solidity" - - "eventos" +tags: [ "smart contracts", "Remix", "Solidity", "eventos" ] skill: intermediate lang: pt-br published: 2020-04-03 @@ -15,19 +11,19 @@ sourceUrl: https://ethereumdev.io/logging-data-with-events/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -No Solidity, [eventos](/developers/docs/smart-contracts/anatomy/#events-and-logs) são sinais enviados que os contratos inteligentes podem disparar. Dapps, ou qualquer coisa conectada à API Ethereum JSON-RPC, podem reconhecer esses eventos e agir em conformidade. Um evento também pode ser indexado para que o histórico de eventos seja pesquisável posteriormente. +Em Solidity, [eventos](/developers/docs/smart-contracts/anatomy/#events-and-logs) são sinais despachados que os contratos inteligentes podem disparar. Dapps, ou qualquer coisa conectada à API JSON-RPC do Ethereum, podem escutar esses eventos e agir de acordo. Um evento também pode ser indexado para que o histórico de eventos seja pesquisável posteriormente. ## Eventos {#events} -O evento mais comum na blockchain Ethereum no momento da redação deste artigo é o evento Transfer, que é emitido por tokens ERC20 quando alguém transfere tokens. +O evento mais comum na blockchain Ethereum, no momento em que este artigo foi escrito, é o evento Transfer, emitido por tokens ERC20 quando alguém transfere tokens. ```solidity event Transfer(address indexed from, address indexed to, uint256 value); ``` -A assinatura do evento é declarada dentro do código do contrato e pode ser emitida com a palavra-chave de emissão. Por exemplo, os registros de eventos de transferência que enviaram a transferência (_from_), para quem foram transferidos (_to_) e quantos tokens foram transferidos (_value_). +A assinatura do evento é declarada dentro do código do contrato e pode ser emitida com a palavra-chave emit. Por exemplo, o evento de transferência registra quem enviou a transferência (_from_), para quem (_to_) e quantos tokens foram transferidos (_value_). -Se voltarmos ao nosso contrato inteligente Contador e decidirmos registrar toda vez que o valor for alterado. Como este contrato não é para ser usado, mas serve como uma base para a construção de outro contrato, estendendo-o: é chamado de contrato abstrato. No caso de nosso exemplo de contador, ele ficaria assim: +Se voltarmos ao nosso contrato inteligente Counter e decidirmos registrar toda vez que o valor é alterado. Como este contrato não se destina a ser implantado, mas a servir como base para a construção de outro contrato estendendo-o: ele é chamado de contrato abstrato. No caso do nosso exemplo de contador, ficaria assim: ```solidity pragma solidity 0.5.17; @@ -36,16 +32,16 @@ contract Counter { event ValueChanged(uint oldValue, uint256 newValue); - // Private variable of type unsigned int to keep the number of counts + // Variável privada do tipo inteiro não assinado para manter o número de contagens uint256 private count = 0; - // Function that increments our counter + // Função que incrementa nosso contador function increment() public { count += 1; emit ValueChanged(count - 1, count); } - // Getter to get the count value + // Getter para obter o valor da contagem function getCount() public view returns (uint256) { return count; } @@ -55,12 +51,12 @@ contract Counter { Observe que: -- **Linha 5**: declaramos nosso evento e o que ele contém, o valor antigo e o novo valor. +- **Linha 5**: declaramos nosso evento e o que ele contém: o valor antigo e o novo valor. - **Linha 13**: Quando incrementamos nossa variável de contagem, emitimos o evento. -Se implementarmos o contrato e chamarmos a função de incremento, veremos que o Remix será exibido automaticamente se você clicar na nova transação dentro de um array de logs nomeados. +Se implantarmos o contrato agora e chamarmos a função de incremento, veremos que o Remix o exibirá automaticamente se você clicar na nova transação dentro de um array chamado logs. -![Captura de tela Remix](./remix-screenshot.png) +![Captura de tela do Remix](./remix-screenshot.png) -Os logs são muito úteis para depurar seus contratos inteligentes, mas também são importantes se você criar aplicativos usados por diferentes pessoas e tornar mais fácil fazer análises para rastrear e entender como seu contrato inteligente é usado. Os registros gerados pelas transações são exibidos em exploradores de blocos populares e você também pode, por exemplo, usá-los para criar 'scripts' fora da cadeia para ver eventos específicos e agir quando eles ocorrerem. +Os logs são muito úteis para depurar seus contratos inteligentes, mas também são importantes se você constrói aplicações usadas por pessoas diferentes, o que facilita a análise para rastrear e entender como seu contrato inteligente é usado. Os logs gerados pelas transações são exibidos nos exploradores de bloco populares e você também pode, por exemplo, usá-los para criar scripts fora da cadeia para escutar eventos específicos e agir quando eles ocorrerem. diff --git a/public/content/translations/pt-br/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/pt-br/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md index 791dfeb56ef..2829bc1edc4 100644 --- a/public/content/translations/pt-br/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md +++ b/public/content/translations/pt-br/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md @@ -1,9 +1,8 @@ --- title: Provas de Merkle para integridade de dados offline -description: Assegurar a integridade dos dados na cadeia para os dados armazenados, sobretudo, fora da cadeia +description: "Garantindo a integridade dos dados na cadeia para dados que são armazenados, em sua maioria, fora da cadeia" author: Ori Pomerantz -tags: - - "armazenamento" +tags: [ "armazenamento" ] skill: advanced lang: pt-br published: 2021-12-30 @@ -11,21 +10,23 @@ published: 2021-12-30 ## Introdução {#introduction} -Idealmente, gostaríamos de guardar tudo no armazenamento do Ethereum, que é armazenado em milhares de computadores e conta com uma disponibilidade extremamente alta (os dados não podem ser censurados) e integridade (os dados não podem ser modificados de forma não autorizada), sabendo que armazenar uma palavra de 32 bytes normalmente custa 20.000 gás. No momento em que estou escrevendo isto, o custo é equivalente a $6,60. A 21 centavos por byte, isso é bastante caro para muitas utilizações. +Idealmente, gostaríamos de guardar tudo no armazenamento do Ethereum, que é armazenado em milhares de computadores e conta com uma disponibilidade extremamente alta (os dados não podem ser censurados) e integridade (os dados não podem ser modificados de forma não autorizada), sabendo que armazenar uma palavra de 32 bytes normalmente custa 20.000 gás. No momento em que estou escrevendo isto, o custo +é equivalente a $6,60. A 21 centavos por byte, isso é bastante caro para muitas utilizações. -Para resolver esse problema, o ecossistema do Ethereum desenvolveu [muitas formas alternativas de armazenar dados de forma descentralizada](/developers/docs/storage/). Geralmente, elas envolvem um equilíbrio entre a disponibilidade e o preço. No entanto, a integridade é geralmente assegurada. +Para resolver esse problema, o ecossistema da Ethereum desenvolveu [muitas maneiras alternativas de armazenar dados de forma descentralizada](/developers/docs/storage/). Geralmente, elas envolvem um equilíbrio entre a disponibilidade e o preço. No entanto, a integridade é geralmente assegurada. -Neste artigo, você aprenderá **como** garantir a integridade dos dados sem armazenar os dados na blockchain, usando [ provas de Merkle](https://computersciencewiki.org/index.php/Merkle_proof). +Neste artigo, você aprenderá **como** garantir a integridade dos dados sem armazenar os dados na blockchain, usando +[provas de Merkle](https://computersciencewiki.org/index.php/Merkle_proof). ## Como isso funciona? {#how-does-it-work} -Em teoria, poderíamos apenas armazenar o hash dos dados na cadeia e enviar todos os dados em transações que precisam deles. No entanto, isso ainda é demasiado caro. Um byte de dados para uma transação custa cerca de 16 gás, atualmente cerca de meio centavo ou cerca de $5 por kilobyte. A $5.000 por megabyte, isso ainda é muito caro para várias utilizações, mesmo sem o custo adicional de hashing de dados. +Em teoria, poderíamos apenas armazenar o hash dos dados na cadeia e enviar todos os dados em transações que o exigem. No entanto, isso ainda é demasiado caro. Um byte de dados para uma transação custa cerca de 16 gás, atualmente cerca de meio centavo ou cerca de $5 por kilobyte. A $5.000 por megabyte, isso ainda é muito caro para várias utilizações, mesmo sem o custo adicional de hashing de dados. A solução é fazer hash repetidamente de diferentes subconjuntos dos dados. Para os dados que você não precisa enviar, você pode apenas enviar um hash. Você pode fazer isso usando uma árvore de Merkle, uma estrutura de dados de árvore em que cada nó é um hash dos nós abaixo: -![Árvores de Merkle](tree.png) +![Árvore de Merkle](tree.png) -O hash raiz é a única parte que precisa ser armazenada na cadeia. Para comprovar um determinado valor, forneça todos os hashes que precisam ser combinados com ele para obter a raiz. Por exemplo, para provar `C` você fornece `D`, `(H-B)`, e `H(E-H)`. +O hash raiz é a única parte que precisa ser armazenada na cadeia. Para comprovar um determinado valor, forneça todos os hashes que precisam ser combinados com ele para obter a raiz. Por exemplo, para provar `C`, você fornece `D`, `H(A-B)` e `H(E-H)`. ![Prova do valor de C](proof-c.png) @@ -33,11 +34,11 @@ O hash raiz é a única parte que precisa ser armazenada na cadeia. Para comprov [O código de exemplo é fornecido aqui](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity). -### Código fora da cadeia {#off-chain-code} +### Código fora da cadeia {#offchain-code} -Neste artigo, usamos JavaScript para os cálculos fora da cadeia. A maioria dos aplicativos descentralizados tem seu componente off-chain em JavaScript. +Neste artigo, usamos JavaScript para os cálculos fora da cadeia. A maioria dos aplicativos descentralizados tem seu componente fora da cadeia em JavaScript. -#### Criando a raiz Merkle {#creating-the-merkle-root} +#### Criando a raiz de Merkle {#creating-the-merkle-root} Primeiro, precisamos fornecer a raiz Merkle à cadeia. @@ -45,61 +46,64 @@ Primeiro, precisamos fornecer a raiz Merkle à cadeia. const ethers = require("ethers") ``` -[Usamos a função hash do pacote ethers](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256). +[Usamos a função de hash do pacote ethers](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256). ```javascript -// The raw data whose integrity we have to verify. The first two bytes a -// are a user identifier, and the last two bytes the amount of tokens the -// user owns at present. +// Os dados brutos cuja integridade temos que verificar. Os primeiros dois bytes a +// são um identificador de usuário, e os dois últimos bytes a quantidade de tokens que o +// usuário possui no momento. const dataArray = [ 0x0bad0010, 0x60a70020, 0xbeef0030, 0xdead0040, 0xca110050, 0x0e660060, 0xface0070, 0xbad00080, 0x060d0091, ] ``` -Codificar cada entrada em um único inteiro de 256 bits resulta em um código menos legível que o JSON, por exemplo. No entanto, isso significa um processamento significativamente menor para recuperar os dados contidos no contrato, portanto, custos de gás muito menores. [Você pode ler o JSON na cadeia](https://github.com/chrisdotn/jsmnSol), porém, isso é uma má ideia e evite fazer isso se puder. +Codificar cada entrada em um único inteiro de 256 bits resulta em um código menos legível que o JSON, por exemplo. No entanto, isso significa um processamento significativamente menor para recuperar os dados contidos no contrato, portanto, custos de gás muito menores. [Você pode ler JSON na cadeia](https://github.com/chrisdotn/jsmnSol), mas é uma má ideia se for evitável. ```javascript -// The array of hash values, as BigInts +// A matriz de valores de hash, como BigInts const hashArray = dataArray ``` Nesse caso, para começar, nossos dados têm um valor 256 bits. Portanto, não é necessário qualquer tipo de processamento. Se usarmos uma estrutura de dados mais complicada, como cadeias de caracteres, precisamos ter certeza de que fazemos primeiro o hash dos dados para obter uma matriz de hashes. Observe que isso também é devido ao fato de não nos importarmos se usuários conhecem as informações de outros usuários. Caso contrário, teríamos tido que fazer um hash, para que o usuário 1 não saiba o valor para o usuário 0, ao usuário 2 que não saberá o valor para o usuário 3, etc. ```javascript -// Convert between the string the hash function expects and the -// BigInt we use everywhere else. +// Converte entre a string que a função de hash espera e o +// BigInt que usamos em todos os outros lugares. const hash = (x) => BigInt(ethers.utils.keccak256("0x" + x.toString(16).padStart(64, 0))) ``` -A função hash de ethers espera obter uma cadeia de caracteres em JavaScript com um número hexadecimal, como `0x60A7`, e responde com outra cadeia de caracteres com a mesma estrutura. No entanto, para o resto do código, é mais fácil usar `BigInt`, então convertemos em uma cadeia de caracteres hexadecimal e de volta novamente. +A função de hash ethers espera obter uma string JavaScript com um número hexadecimal, como `0x60A7`, e responde com outra string com a mesma estrutura. No entanto, para o resto do código, é mais fácil usar `BigInt`, então convertemos para uma string hexadecimal e de volta novamente. ```javascript -// Symmetrical hash of a pair so we won't care if the order is reversed. +// Hash simétrico de um par para que não nos importemos se a ordem for invertida. const pairHash = (a, b) => hash(hash(a) ^ hash(b)) ``` -Essa função é simétrica (hash de um [xor](https://en.wikipedia.org/wiki/Exclusive_or) b). Isto significa que quando verificamos a prova de Merkle, não precisamos nos preocupar se devemos colocar o valor da prova antes ou depois do valor calculado. A verificação da prova de Merkle é feita na cadeia, portanto, quanto menos precisarmos fazer lá, melhor. +Esta função é simétrica (hash de um [xor](https://en.wikipedia.org/wiki/Exclusive_or) b). Isto significa que quando verificamos a prova de Merkle, não precisamos nos preocupar se devemos colocar o valor da prova antes ou depois do valor calculado. A verificação da prova de Merkle é feita na cadeia, portanto, quanto menos precisarmos fazer lá, melhor. -Atenção: A criptografia é mais difícil do que parece. A versão inicial deste artigo tinha a função hash `hash(a^b)`. Essa foi uma **má** ideia, porque significava que se você conhecesse os valores legítimos de `a` e de `b`, você poderia usar `b' = a^b^a'` para provar qualquer valor `a'` desejado. Com essa função, você teria que calcular `b'`, de forma que `hash(a') ^ hash(b')` fosse igual a um valor conhecido (o próximo branch a caminho da raiz), o que é muito mais difícil. +Atenção: A criptografia é mais difícil do que parece. +A versão inicial deste artigo tinha a função de hash `hash(a^b)`. +Essa foi uma **má** ideia, porque significava que se você conhecesse os valores legítimos de `a` e `b`, você poderia usar `b' = a^b^a'` para provar qualquer valor `a'` desejado. +Com esta função, você teria que calcular `b'` de tal forma que `hash(a') ^ hash(b')` seja igual a um valor conhecido (o próximo ramo a caminho da raiz), o que é muito mais difícil. ```javascript -// The value to denote that a certain branch is empty, doesn't -// have a value +// O valor para denotar que um determinado ramo está vazio, não +// tem um valor const empty = 0n ``` Quando o número de valores não é uma potência inteira de dois, precisamos lidar com branches vazios. O programa faz isso colocando zero como espaço reservado. -![Árvore de Merkle com branches faltando](merkle-empty-hash.png) +![Árvore de Merkle com ramos ausentes](merkle-empty-hash.png) ```javascript -// Calculate one level up the tree of a hash array by taking the hash of -// each pair in sequence +// Calcula um nível acima na árvore de uma matriz de hash, obtendo o hash de +// cada par em sequência const oneLevelUp = (inputArray) => { var result = [] - var inp = [...inputArray] // To avoid over writing the input // Add an empty value if necessary (we need all the leaves to be // paired) + var inp = [...inputArray] // Para evitar sobrescrever a entrada // Adicione um valor vazio se necessário (precisamos que todas as folhas sejam // pareadas) if (inp.length % 2 === 1) inp.push(empty) @@ -110,13 +114,13 @@ const oneLevelUp = (inputArray) => { } // oneLevelUp ``` -Esta função “escala” um nível na árvore de Merkle, fazendo hash dos pares de valores na camada atual. Observe que esta não é a implementação mais eficiente. Poderíamos ter evitado copiar a entrada e apenas adicionar `hashEmpty` quando apropriado no loop, mas este código é otimizado para melhorar a legibilidade. +Esta função “escala” um nível na árvore de Merkle, fazendo hash dos pares de valores na camada atual. Observe que esta não é a implementação mais eficiente, poderíamos ter evitado copiar a entrada e apenas adicionado `hashEmpty` quando apropriado no loop, mas este código é otimizado para legibilidade. ```javascript const getMerkleRoot = (inputArray) => { var result - result = [...inputArray] // Climb up the tree until there is only one value, that is the // root. // // If a layer has an odd number of entries the // code in oneLevelUp adds an empty value, so if we have, for example, // 10 leaves we'll have 5 branches in the second layer, 3 // branches in the third, 2 in the fourth and the root is the fifth + result = [...inputArray] // Sobe na árvore até que haja apenas um valor, que é a // raiz. // // Se uma camada tem um número ímpar de entradas, o // código em oneLevelUp adiciona um valor vazio, então se tivermos, por exemplo, // 10 folhas, teremos 5 ramos na segunda camada, 3 // ramos na terceira, 2 na quarta e a raiz é a quinta while (result.length > 1) result = oneLevelUp(result) @@ -131,41 +135,41 @@ Para obter a raiz, suba até que haja apenas um valor restante. Uma prova de Merkle é o conjunto de valores a fazer hash junto com o valor que está sendo provado para recuperar a raiz de Merkle. O valor a provar está frequentemente disponível a partir de outros dados, então eu prefiro fornecê-lo separadamente do que como parte do código. ```javascript -// A merkle proof consists of the value of the list of entries to -// hash with. Because we use a symmetrical hash function, we don't -// need the item's location to verify the proof, only to create it +// Uma prova de merkle consiste no valor da lista de entradas para +// fazer o hash. Como usamos uma função de hash simétrica, não +// precisamos da localização do item para verificar a prova, apenas para criá-la const getMerkleProof = (inputArray, n) => {     var result = [], currentLayer = [...inputArray], currentN = n -    // Until we reach the top +    // Até chegarmos ao topo     while (currentLayer.length > 1) { -        // No odd length layers +        // Nenhuma camada de comprimento ímpar         if (currentLayer.length % 2)             currentLayer.push(empty)         result.push(currentN % 2 -               // If currentN is odd, add with the value before it to the proof +               // Se currentN for ímpar, adicione o valor anterior a ele à prova             ? currentLayer[currentN-1] -               // If it is even, add the value after it +               // Se for par, adicione o valor depois dele             : currentLayer[currentN+1]) ``` -Fazemos o hash `(v[0],v[1])`, `(v[2],v[3])`, etc. Portanto, para valores pares, precisamos do próximo e, para valores ímpares, precisamos do anterior. +Fazemos o hash de `(v[0],v[1])`, `(v[2],v[3])`, etc. Portanto, para valores pares, precisamos do próximo e, para valores ímpares, precisamos do anterior. ```javascript -        // Move to the next layer up +        // Move para a próxima camada acima         currentN = Math.floor(currentN/2)         currentLayer = oneLevelUp(currentLayer) -    }   // while currentLayer.length > 1 +    }   // enquanto currentLayer.length > 1     return result }   // getMerkleProof ``` -### Código on-chain {#on-chain-code} +### Código na cadeia {#onchain-code} -Por fim, temos o código que verifica a prova. O código on-chain é escrito em [Solidity](https://docs.soliditylang.org/en/v0.8.11/). A otimização é aqui muito mais importante, porque o gás é relativamente caro. +Por fim, temos o código que verifica a prova. O código na cadeia é escrito em [Solidity](https://docs.soliditylang.org/en/v0.8.11/). A otimização é aqui muito mais importante, porque o gás é relativamente caro. ```solidity //SPDX-License-Identifier: Public Domain @@ -174,7 +178,7 @@ pragma solidity ^0.8.0; import "hardhat/console.sol"; ``` -Escrevi isso usando o [ambiente de desenvolvimento de hardware](https://hardhat.org/), que nos permite ter [saída do console do Solidity](https://hardhat.org/docs/cookbook/debug-logs) em desenvolvimento. +Escrevi isso usando o [ambiente de desenvolvimento Hardhat](https://hardhat.org/), que nos permite ter uma [saída de console do Solidity](https://hardhat.org/docs/cookbook/debug-logs) durante o desenvolvimento. ```solidity @@ -185,15 +189,15 @@ contract MerkleProof {       return merkleRoot;     } -    // Extremely insecure, in production code access to -    // this function MUST BE strictly limited, probably to an -    // owner +    // Extremamente inseguro, em código de produção, o acesso a +    // esta função DEVE SER estritamente limitado, provavelmente a um +    // proprietário     function setRoot(uint _merkleRoot) external {       merkleRoot = _merkleRoot;     }   // setRoot ``` -Configure e obtenha funções para a raiz de Merkle. Deixar que todo mundo atualize a raiz de Merkle é uma _ideia extremamente má_ em um sistema de produção. Aqui, faço isso por uma questão de simplicidade no código de exemplo. **Não faça isso em um sistema no qual a integridade de dados realmente importa**. +Configure e obtenha funções para a raiz de Merkle. Permitir que todos atualizem a raiz de Merkle é uma _péssima ideia_ em um sistema de produção. Aqui, faço isso por uma questão de simplicidade no código de exemplo. **Não faça isso em um sistema onde a integridade dos dados realmente importa**. ```solidity     function hash(uint _a) internal pure returns(uint) { @@ -205,12 +209,12 @@ Configure e obtenha funções para a raiz de Merkle. Deixar que todo mundo atual     } ``` -Essa função gera um par de hashes. Ela é simplesmente a tradução do Solidity do código em JavaScript para `hash` e `pairHash`. +Essa função gera um par de hashes. É apenas a tradução em Solidity do código JavaScript para `hash` e `pairHash`. -**Observação:** Este é outro caso de otimização para facilidade de leitura. Baseado em [a definição da função](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm), é possível armazenar os dados como um valor de [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) e evitar as conversões. +**Observação:** este é outro caso de otimização para legibilidade. Com base na [definição da função](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm), pode ser possível armazenar os dados como um valor [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) e evitar as conversões. ```solidity -    // Verify a Merkle proof +    // Verifica uma prova de Merkle     function verifyProof(uint _value, uint[] calldata _proof)         public view returns (bool) {       uint temp = _value; @@ -226,16 +230,18 @@ Essa função gera um par de hashes. Ela é simplesmente a tradução do Solidit }  // MarkleProof ``` -Na notação matemática, a verificação pela prova de Merkle tem esta aparência: `H(proof_n, H(proof_n-1, H(proof_n-2, ... H(prova_1, H(prova_0, valor)...)))`. Este código implementa-o. +Em notação matemática, a verificação da prova de Merkle se parece com isto: `H(proof_n, H(proof_n-1, H(proof_n-2, ...` `H(proof_1, H(proof_0, value))...)))`. Este código implementa-o. -## Provas de Merkle e rollups não se misturam {#merkle-proofs-and-rollups} +## Provas de Merkle e rollups não combinam {#merkle-proofs-and-rollups} As provas de Merkle não funcionam bem com [rollups](/developers/docs/scaling/#rollups). O motivo é que os rollups escrevem todos os dados da transação no L1, mas são processadas no L2. O custo para enviar uma prova de Merkle com uma média de transação a 638 gás por camada (atualmente, um byte nos dados de chamadas custa 16 gás se não for zero, e 4 se for zero). Se temos 1024 palavras de dados, uma prova de Merkle requer dez camadas, ou um total de 6380 gás. -Procurando um exemplo no [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m), escrever custos de gás L1 custa cerca de 100 gwei e escrever custos de gás L2 custa 0,001 gwei (esse é o preço normal, que pode aumentar com o congestionamento). Portanto, pelo custo de um gás L1 podemos gastar cem mil gás no processamento L2. Supondo que não sobrescrevamos o armazenamento, isso significa que podemos escrever cerca de cinco palavras para armazenamento na L2 pelo preço de um gás L1. Para uma única prova de Merkle, podemos escrever todas as 1024 palavras para armazenamento (assumindo que elas podem ser calculadas em cadeia para começar, em vez de serem fornecidos em uma transação) e ainda restam a maior parte do gás. +Olhando, por exemplo, para o [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m), escrever na L1 custa cerca de 100 gwei de gás e na L2 custa 0,001 gwei de gás (este é o preço normal, pode aumentar com o congestionamento). Portanto, pelo custo de um gás L1 podemos gastar cem mil gás no processamento L2. Supondo que não sobrescrevamos o armazenamento, isso significa que podemos escrever cerca de cinco palavras para armazenamento na L2 pelo preço de um gás L1. Para uma única prova de Merkle, podemos escrever todas as 1024 palavras no armazenamento (supondo que elas possam ser calculadas na cadeia para começar, em vez de serem fornecidas em uma transação) e ainda ter a maior parte do gás restante. ## Conclusão {#conclusion} Na vida real, você pode nunca implementar Merkle por conta própria. Existem bibliotecas conhecidas e auditadas que você pode usar e, de um modo geral, é melhor não implementar primitivos criptográficos por conta própria. Mas espero que agora você compreenda melhor as provas de Merkle e que possa decidir quando é que vale a pena utilizar. -Observe que, enquanto as provas de Merkle preservam a _integridade_, elas não preservam a disponibilidade __. Saber que mais ninguém pode tomar seus ativos é uma pequena consolação se o armazenamento de dados decidir impedir o acesso e você não pode construir uma Merkle para acessá-los também. Portanto, as árvores de Merkle são melhor usadas com algum tipo de armazenamento descentralizado, como IPFS. +Observe que, embora as provas de Merkle preservem a _integridade_, elas não preservam a _disponibilidade_. Saber que mais ninguém pode tomar seus ativos é uma pequena consolação se o armazenamento de dados decidir impedir o acesso e você não pode construir uma Merkle para acessá-los também. Portanto, as árvores de Merkle são melhor usadas com algum tipo de armazenamento descentralizado, como IPFS. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/pt-br/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md index 272f63231a3..8c0b48d93f2 100644 --- a/public/content/translations/pt-br/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md +++ b/public/content/translations/pt-br/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md @@ -1,26 +1,24 @@ --- title: Monitorando o Geth com InfluxDB e Grafana -description: -author: "Mário Havel" -tags: - - "clientes" - - "nós" +description: "Configure o monitoramento para seu nó Geth usando InfluxDB e Grafana para acompanhar o desempenho e identificar problemas." +author: "Mario Havel" +tags: [ "clientes", "nós" ] skill: intermediate lang: pt-br published: 2021-01-13 --- -Esse tutorial ajudará você a configurar o monitoramento do seu Geth para você poder entender melhor o seu desempenho e identificar possíveis problemas. +Este tutorial irá ajudá-lo a configurar o monitoramento do seu nó Geth para que você possa entender melhor seu desempenho e identificar possíveis problemas. -## Pré-Requisitos {#prerequisites} +## Pré-requisitos {#prerequisites} -- Você já deveria estar executando uma instância de Geth. -- A maioria dos passos e exemplos são para o ambiente Linux, o conhecimento básico sobre terminais será útil. -- Confira este vídeo da visão geral da suíte de métricas do Geth: [Monitoring an Ethereum infrastructure by Péter Szilágyi](https://www.youtube.com/watch?v=cOBab8IJMYI). +- Você já deve estar executando uma instância do Geth. +- A maioria das etapas e exemplos é para o ambiente Linux, portanto, conhecimento básico de terminal será útil. +- Confira esta visão geral em vídeo do conjunto de métricas do Geth: [Monitoring an Ethereum infrastructure por Péter Szilágyi](https://www.youtube.com/watch?v=cOBab8IJMYI). -## Stack de monitoramento {#monitoring-stack} +## Pilha de monitoramento {#monitoring-stack} -Um cliente Ethereum coleta muitos dados que podem ser lidos na forma de uma base de dados cronológica. Para facilitar o monitoramento, você pode inserir isso em um software de visualização de dados. Existem múltiplas opções disponíveis: +Um cliente Ethereum coleta muitos dados que podem ser lidos na forma de um banco de dados cronológico. Para facilitar o monitoramento, você pode fornecer esses dados para um software de visualização de dados. Há várias opções disponíveis: - [Prometheus](https://prometheus.io/) (modelo pull) - [InfluxDB](https://www.influxdata.com/get-influxdb/) (modelo push) @@ -29,13 +27,14 @@ Um cliente Ethereum coleta muitos dados que podem ser lidos na forma de uma base - [Datadog](https://www.datadoghq.com/) - [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/) -Também há o [Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter), uma opção pré-configurada com InfluxDB e Grafana. +Há também o [Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter), uma opção pré-configurada com InfluxDB e Grafana. -Neste tutorial, nós configuramos seu cliente Geth para enviar dados para o InfluxDB para criar um banco de dados e o Grafana para criar um gráfico de visualização dos dados. Fazer isso manualmente ajudará você a entender melhor o processo, alterá-lo e fazer deploy em diferentes ambientes. +Neste tutorial, vamos configurar seu cliente Geth para enviar dados para o InfluxDB a fim de criar um banco de dados e para o Grafana a fim de criar uma visualização gráfica dos dados. Fazer isso manualmente o ajudará a entender melhor o processo, alterá-lo e implantá-lo em diferentes ambientes. ## Configurando o InfluxDB {#setting-up-influxdb} -Primeiro, vamos baixar e instalar o InfluxDB. Várias opções de download podem ser encontradas na [página de release do Influxdata](https://portal.influxdata.com/downloads/). Escolha o que mais se adequa ao seu ambiente. Você também pode instalá-lo a partir de um [repositório](https://repos.influxdata.com/). Por exemplo, em uma distribuição baseada em Debian: +Primeiro, vamos baixar e instalar o InfluxDB. Várias opções de download podem ser encontradas na [página de lançamentos do Influxdata](https://portal.influxdata.com/downloads/). Escolha a que melhor se adapta ao seu ambiente. +Você também pode instalá-lo a partir de um [repositório](https://repos.influxdata.com/). Por exemplo, em uma distribuição baseada em Debian: ``` curl -tlsv1.3 --proto =https -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add @@ -48,7 +47,8 @@ sudo systemctl start influxdb sudo apt install influxdb-client ``` -Após instalar o InfluxDB com sucesso, certifique-se de que ele está sendo executado em segundo plano. Por padrão, ele é acessível em `localhost:8086`. Antes de usar o cliente `influx` você tem que criar um novo usuário com privilégios de administrador. Este usuário servirá para gerenciamento de alto nível, criando bancos de dados e usuários. +Após instalar o InfluxDB com sucesso, certifique-se de que ele está sendo executado em segundo plano. Por padrão, ele pode ser acessado em `localhost:8086`. +Antes de usar o cliente `influx`, você deve criar um novo usuário com privilégios de administrador. Este usuário servirá para o gerenciamento de alto nível, criação de bancos de dados e usuários. ``` curl -XPOST "http://localhost:8086/query" --data-urlencode "q=CREATE USER username WITH PASSWORD 'password' WITH ALL PRIVILEGES" @@ -60,7 +60,7 @@ Agora você pode usar o cliente influx para entrar no [shell do InfluxDB](https: influx -username 'username' -password 'password' ``` -Comunificando diretamente com o InfluxDB em seu shell, você pode criar banco de dados e usuário para métricas do geth. +Comunicando-se diretamente com o InfluxDB em seu shell, você pode criar um banco de dados e um usuário para as métricas do Geth. ``` create database geth @@ -74,25 +74,26 @@ show databases show users ``` -Saia do Shell InfluxDB. +Saia do shell do InfluxDB. ``` exit ``` -O InfluxDB está rodando e configurado para armazenar métricas do Geth. +O InfluxDB está em execução e configurado para armazenar as métricas do Geth. ## Preparando o Geth {#preparing-geth} -Depois de configurar o banco de dados, precisamos habilitar a coleção de métricas no Geth. Preste atenção em `METRICS AND STATS OPTIONS` com `geth --help`. Várias opções podem ser encontradas lá, neste caso queremos que o Geth envie dados para o InfluxDB. A configuração básica especifica o endpoint onde o InfluxDB é acessível e a autenticação para o banco de dados. +Após configurar o banco de dados, precisamos habilitar a coleta de métricas no Geth. Preste atenção em `METRICS AND STATS OPTIONS` em `geth --help`. Várias opções podem ser encontradas lá. Neste caso, queremos que o Geth envie dados para o InfluxDB. +A configuração básica especifica o endpoint onde o InfluxDB pode ser acessado e a autenticação para o banco de dados. ``` geth --metrics --metrics.influxdb --metrics.influxdb.endpoint "http://0.0.0.0:8086" --metrics.influxdb.username "geth" --metrics.influxdb.password "chosenpassword" ``` -Estas flags podem ser anexadas a um comando que inicie o cliente ou salvas no arquivo de configuração. +Essas flags podem ser anexadas a um comando que inicia o cliente ou salvas no arquivo de configuração. -Você pode verificar que o Geth está fazendo push de dados com sucesso, por exemplo, listando as métricas no banco de dados. Saia do shell do InfluxDB: +Você pode verificar se o Geth está enviando dados com sucesso, por exemplo, listando as métricas no banco de dados. No shell do InfluxDB: ``` use geth @@ -101,7 +102,8 @@ show measurements ## Configurando o Grafana {#setting-up-grafana} -O próximo passo é instalar o Grafana que interpretará os dados graficamente. Siga o processo de instalação do seu ambiente na documentação do Grafana. Certifique-se de instalar a versão OSS se você não quiser o contrário. Etapas de instalação de exemplo para distribuições Debian usando o repositório: +A próxima etapa é instalar o Grafana, que interpretará os dados graficamente. Siga o processo de instalação para o seu ambiente na documentação do Grafana. Certifique-se de instalar a versão OSS, a menos que queira de outra forma. +Exemplo de etapas de instalação para distribuições Debian usando o repositório: ``` curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add - @@ -112,15 +114,16 @@ sudo systemctl enable grafana-server sudo systemctl start grafana-server ``` -Quando você estiver rodando o Grafana, ele deve ser acessível em `localhost:3000`. Use seu navegador preferido para acessar esta URL e, em seguida, faça login com as credenciais padrão (usuário: `admin` e senha: `admin`). Quando solicitado, altere a senha padrão e salve. +Quando o Grafana estiver em execução, ele deverá estar acessível em `localhost:3000`. +Use seu navegador preferido para acessar este caminho e faça login com as credenciais padrão (usuário: `admin` e senha: `admin`). Quando solicitado, altere a senha padrão e salve. ![Captura de tela do painel Grafana para monitoramento Geth (painel 1)](./grafana1.png) -Você vai ser redirecionado para a página principal do Grafana. Primeiro, configure seu source data. Clique no ícone de configuração na barra esquerda e selecione "Data sources". +Você será redirecionado para a página inicial do Grafana. Primeiro, configure sua fonte de dados. Clique no ícone de configuração na barra esquerda e selecione "Fontes de dados". ![Captura de tela do painel Grafana para monitoramento Geth (painel 2)](./grafana2.png) -Ainda não existem data sources criados, clique em "Add data source" para definir um. +Ainda não há nenhuma fonte de dados criada. Clique em "Adicionar fonte de dados" para definir uma. ![Captura de tela do painel Grafana para monitoramento Geth (painel 3)](./grafana3.png) @@ -128,20 +131,21 @@ Para esta configuração, selecione "InfluxDB" e prossiga. ![Captura de tela do painel Grafana para monitoramento Geth (painel 4)](./grafana4.png) -A configuração do data source é bem simples se você estiver rodando ferramentas na mesma máquina. Você precisa configurar o endereço e os detalhes do InfluxDB para acessar o banco de dados. Consulte a imagem abaixo. +A configuração da fonte de dados é bastante simples se você estiver executando as ferramentas na mesma máquina. Você precisa definir o endereço do InfluxDB e os detalhes para acessar o banco de dados. Consulte a imagem abaixo. ![Captura de tela do painel Grafana para monitoramento Geth (painel 5)](./grafana5.png) -Se tudo estiver completo e o InfluxDB estiver acessível, clique em "Save and test" e aguarde a confirmação aparecer. +Se tudo estiver correto e o InfluxDB estiver acessível, clique em "Salvar e testar" e aguarde o surgimento da confirmação. ![Captura de tela do painel Grafana para monitoramento Geth (painel 6)](./grafana6.png) -O Grafana está agora configurado para ler dados do InfluxDB. Agora você precisa criar um painel que o interprete e o exiba. As propriedades dos Dashboards são codificadas em arquivos JSON que podem ser criados por qualquer um e podem ser facilmente importados. Na barra esquerda, clique em "Create and Import". +O Grafana agora está configurado para ler dados do InfluxDB. Agora você precisa criar um dashboard que irá interpretá-los e exibi-los. As propriedades dos dashboards são codificadas em arquivos JSON que podem ser criados por qualquer pessoa e facilmente importados. Na barra à esquerda, clique em "Criar e importar". ![Captura de tela do painel Grafana para monitoramento Geth (painel 7)](./grafana7.png) -Para um dashboard de monitoramento do Geth, copie o ID [deste dashboard](https://grafana.com/grafana/dashboards/13877/) e cole-o em "Import page" no Grafana. Depois de salvar o dashboard, ele deve ficar assim: +Para um dashboard de monitoramento do Geth, copie o ID [deste dashboard](https://grafana.com/grafana/dashboards/13877/) e cole-o na "Página de importação" do Grafana. Depois de salvar o dashboard, ele deve ter a seguinte aparência: ![Captura de tela do painel Grafana para monitoramento Geth (painel 8)](./grafana8.png) -Você pode modificar seus dashboards. Cada dashboard pode ser editado, movido, removido ou adicionado. Você pode alterar suas configurações. É com você! Para saber mais sobre como os dashboards funcionam, consulte a [documentação do Grafana](https://grafana.com/docs/grafana/latest/dashboards/). Você também pode estar interessado sobre [Notificações / Alertas](https://grafana.com/docs/grafana/latest/alerting/). Isso permite configurar notificações de alerta para quando as métricas alcançarem certos valores. Vários canais de comunicação são suportados. +Você pode modificar seus dashboards. Cada painel pode ser editado, movido, removido ou adicionado. Você pode alterar suas configurações. A decisão é sua! Para saber mais sobre como os dashboards funcionam, consulte a [documentação do Grafana](https://grafana.com/docs/grafana/latest/dashboards/). +Você também pode se interessar por [Alertas](https://grafana.com/docs/grafana/latest/alerting/). Isso permite que você configure notificações de alerta para quando as métricas atingirem determinados valores. Vários canais de comunicação são suportados. diff --git a/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md b/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md index 7915b9561ce..1e531af54cb 100644 --- a/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md @@ -1,14 +1,16 @@ --- -title: Tutorial de criação de uma NFT -description: Neste tutorial, você irá construir um minter NFT e, também, aprender a como criar um full stack dapp conectando seu contrato inteligente a um React frontend usando MetaMask e ferramentas Web3. +title: "Tutorial de criação de uma NFT" +description: "Neste tutorial, você irá construir um minter NFT e, também, aprender a como criar um full stack dapp conectando seu contrato inteligente a um React frontend usando MetaMask e ferramentas Web3." author: "smudgil" tags: - - "solidity" - - "NFT" - - "alchemy" - - "contratos inteligentes" - - "front-end" - - "Pinata" + [ + "Solidity", + "NFT", + "Alchemy", + "smart contracts", + "front-end", + "Pinata" + ] skill: intermediate lang: pt-br published: 2021-10-06 @@ -22,11 +24,11 @@ Ao criar um minter NFT — uma simples UI onde você pode inserir um link para s - Chamar métodos de contrato inteligentes no seu frontend - Assine transações usando MetaMask -Neste tutorial, usaremos o [React](https://reactjs.org/) como nossa estrutura de frontend. Como este tutorial está focado principalmente no desenvolvimento da Web3, nós não passaremos muito tempo detalhando os fundamentos do React. Em vez disso, nós focaremos em trazer funcionalidade para o nosso projeto. +Neste tutorial, usaremos o [React](https://react.dev/) como nossa estrutura de frontend. Como este tutorial está focado principalmente no desenvolvimento da Web3, nós não passaremos muito tempo detalhando os fundamentos do React. Em vez disso, nós focaremos em trazer funcionalidade para o nosso projeto. -Como pré-requisito, você deve ter uma compreensão mínima do React – saber como funcionam componentes, props, useState/useEffect e chamadas de funções básicas. Se você nunca ouviu falar de nenhum desses termos antes, você pode querer conferir este [Intro to React tutorial](https://reactjs.org/tutorial/tutorial.html). Para os que apreciam mais visualidade, é altamente recomendável esta excelente série de vídeos [Full Modern React Tutorial](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-TvwTutorialfod2gaISzfRiP9d) por Net Ninja. +Como pré-requisito, você deve ter uma compreensão mínima do React – saber como funcionam componentes, props, useState/useEffect e chamadas de funções básicas. Se você nunca ouviu falar de nenhum desses termos antes, talvez queira conferir este [tutorial de Introdução ao React](https://react.dev/learn/tutorial-tic-tac-toe). Para os alunos mais visuais, recomendamos fortemente esta excelente série de vídeos [Full Modern React Tutorial](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d) do Net Ninja. -E se você ainda não fez, você definitivamente precisará criar uma conta Alchemy para concluir este tutorial, bem como construir qualquer coisa no blockchain. Inscreva-se para uma conta gratuita [aqui](https://alchemy.com/). +E se você ainda não fez, você definitivamente precisará criar uma conta Alchemy para concluir este tutorial, bem como construir qualquer coisa no blockchain. Cadastre-se para uma conta gratuita [aqui](https://alchemy.com/). Sem mais delongas, vamos começar! @@ -34,51 +36,51 @@ Sem mais delongas, vamos começar! Antes de começarmos a olhar para qualquer código, é importante entender como funciona fazer uma NFT. Envolve duas etapas: -### Publicar um contrato inteligente da NFT no blockchain Ethereum {#publish-nft} +### Publique um contrato inteligente de NFT na blockchain da Ethereum {#publish-nft} A maior diferença entre os dois padrões de contrato inteligente NFT é que o ERC-1155 é um padrão multi-token e inclui a funcionalidade de lote, enquanto o ERC-721 é um padrão de token único, portanto, suporta apenas a transferência de um token por vez. -### Chamar a função mint {#minting-function} +### Chame a função de mintagem {#minting-function} -Normalmente, esta função mint requer que você passe duas variáveis como parâmetros, primeiro o destinatário `recipient`, que especifica o endereço que receberá a sua NFT recém-mintada, e segundo o `tokenURI` da NFT, uma string que indica a um documento JSON que descreve os metadados da NFT. +Normalmente, esta função de mintagem exige que você passe duas variáveis como parâmetros: primeiro o `recipient`, que especifica o endereço que receberá seu NFT recém-mintado, e segundo o `tokenURI` do NFT, uma string que resolve para um documento JSON descrevendo os metadados do NFT. -Os metadados de uma NFT são o que realmente a torna realidade, permitindo que tenha propriedades configuráveis, como um nome, descrição, imagem (ou diferentes ativos digitais), e outros atributos. Aqui está [um exemplo de um tokenURI](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2), que contém os metadados de uma NFT. +Os metadados de uma NFT são o que realmente a torna realidade, permitindo que tenha propriedades configuráveis, como um nome, descrição, imagem (ou diferentes ativos digitais), e outros atributos. Aqui está [um exemplo de um tokenURI](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2), que contém os metadados de um NFT. Neste tutorial, vamos nos concentrar na parte 2, chamando a função mint de contrato inteligente de uma NFT existente usando nossa interface do React. -[Aqui está um link](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) para o contrato inteligente NFT ERC-721 que vamos chamar neste tutorial. Se você gostaria de saber como o fizemos, é altamente recomendável que você veja nosso outro tutorial, ["Como criar uma NFT"](https://docs.alchemyapi.io/alchemy/tutorials/how-to-create-an-nft). +[Aqui está um link](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) para o contrato inteligente de NFT ERC-721 que chamaremos neste tutorial. Se você quiser saber como o fizemos, recomendamos que confira nosso outro tutorial, ["Como Criar um NFT"](https://www.alchemy.com/docs/how-to-create-an-nft). Legal, agora que entendemos como fazer uma NFT funcionar, vamos clonar nossos arquivos iniciais! -## Clonar os arquivos iniciais {#clone-the-starter-files} +## Clone os arquivos iniciais {#clone-the-starter-files} -Primeiro, vá para o [repositório GitHub do nft-minter-tutorial](https://github.com/alchemyplatform/nft-minter-tutorial) para obter os arquivos iniciais para este projeto. Clone este repositório para o seu ambiente local.= +Primeiro, acesse o [repositório do GitHub nft-minter-tutorial](https://github.com/alchemyplatform/nft-minter-tutorial) para obter os arquivos iniciais deste projeto. Clone este repositório para o seu ambiente local. -Quando você abrir este repositório clonado `nft-minter-tutorial`, irá notar que ele contém duas pastas: `minter-starter-files` e `nft-minter`. +Ao abrir este repositório `nft-minter-tutorial` clonado, você notará que ele contém duas pastas: `minter-starter-files` e `nft-minter`. -- `minter-starter-files` contém os arquivos iniciais (essencialmente a interface do React) para este projeto. Neste tutorial, **trabalharemos nesse diretório**, enquanto você aprende a dar vida a sua interface do usuário, conectando-a à sua carteira Ethereum e a um contrato inteligente de NFT. -- `nft-minter` contém o tutorial completo e serve para você como uma **referência** **se você ficar preso.** +- `minter-starter-files` contém os arquivos iniciais (essencialmente a UI do React) para este projeto. Neste tutorial, **estaremos trabalhando neste diretório**, à medida que você aprende como dar vida a esta UI, conectando-a à sua carteira Ethereum e a um contrato inteligente de NFT. +- `nft-minter` contém o tutorial completo e está lá para você como uma **referência** **caso você trave.** -Em seguida, abra sua cópia de `minter-starter-files` no seu editor de código e navegue para a pasta `src`. +Em seguida, abra sua cópia de `minter-starter-files` em seu editor de código e navegue até a pasta `src`. -Todo o código que vamos escrever será exibido na pasta `src`. Vamos editar o componente `Minter.js` e escrever arquivos javascript adicionais para dar funcionalidades Web3 ao nosso projeto. +Todo o código que escrevermos ficará na pasta `src`. Estaremos editando o componente `Minter.js` e escrevendo arquivos javascript adicionais para dar ao nosso projeto a funcionalidade Web3. ## Passo 2: Confira nossos arquivos iniciais {#step-2-check-out-our-starter-files} Antes de começarmos a codificar, é importante verificar o que já está fornecido para nós nos arquivos iniciais. -### Tenha seu projeto React em execução {#get-your-react-project-running} +### Coloque seu projeto react para funcionar {#get-your-react-project-running} Vamos começar executando o projeto React em nosso navegador. A beleza do React é que uma vez que nosso projeto esteja sendo executado no nosso navegador, qualquer alteração que salvarmos será atualizada ao vivo em nosso navegador. -Para fazer com que o projeto funcione, navegue até o diretório raiz da pasta `minter-starter-files`, e execute`npm install` no seu terminal para instalar as dependências do projeto: +Para colocar o projeto para funcionar, navegue até o diretório raiz da pasta `minter-starter-files` e execute `npm install` em seu terminal para instalar as dependências do projeto: ```bash cd minter-starter-files npm install ``` -Uma vez terminada a instalação, execute `npm start` em seu terminal: +Assim que a instalação for concluída, execute `npm start` em seu terminal: ```bash npm start @@ -90,14 +92,14 @@ Se você tentar clicar nos botões "Connectar Wallet" ou "Mint NFT", você notar ### O componente Minter.js {#minter-js} -**NOTA:** Certifique-se de estar na pasta `minter-starter-files` e não na pasta `nft-minter`! +**OBSERVAÇÃO:** Certifique-se de que você está na pasta `minter-starter-files` e não na pasta `nft-minter`! -Vamos voltar à pasta `src` no nosso editor e abrir o arquivo `Minter.js`. É muito importante que entendamos tudo neste arquivo, pois é o principal componente do React no qual vamos trabalhar. +Vamos voltar para a pasta `src` em nosso editor e abrir o arquivo `Minter.js`. É muito importante que entendamos tudo neste arquivo, pois é o principal componente do React no qual vamos trabalhar. No topo do nosso arquivo, temos nossas variáveis de estado que serão atualizadas após eventos específicos. ```javascript -//State variables +//Variáveis de estado const [walletAddress, setWallet] = useState("") const [status, setStatus] = useState("") const [name, setName] = useState("") @@ -105,93 +107,93 @@ const [description, setDescription] = useState("") const [url, setURL] = useState("") ``` -Nunca ouviu falar de variáveis de estado do React ou State Hooks? Confira [está](https://reactjs.org/docs/hooks-state.html) documentação. +Nunca ouviu falar de variáveis de estado do React ou State Hooks? Confira [esta](https://legacy.reactjs.org/docs/hooks-state.html) documentação. Veja aqui o que cada uma das variáveis representa: - `walletAddress` - uma string que armazena o endereço da carteira do usuário -- `status` - uma string que contém uma mensagem a ser exibida na parte inferior da interface do usuário -- `name` - uma string que armazena o nome da NFT -- `descrição` - uma string que armazena a descrição da NFT -- `url` - uma string que é um link para o ativo digital da NFT +- `status` - uma string que contém uma mensagem para exibir na parte inferior da UI +- `name` - uma string que armazena o nome do NFT +- `description` - uma string que armazena a descrição do NFT +- `url` - uma string que é um link para o ativo digital do NFT -Após as variáveis de estado, você verá três funções não implementadas: `useEffect`, `connectWalletPressed`, e `onMintPressed`. Você irá notar que todas essas funções são `async`, isso é porque iremos fazer chamadas assíncronas da API nelas! Os nomes delas são relacionadas com sua funcionalidade: +Após as variáveis de estado, você verá três funções não implementadas: `useEffect`, `connectWalletPressed` e `onMintPressed`. Você notará que todas essas funções são `async`, porque faremos chamadas de API assíncronas nelas! Os nomes delas são relacionadas com sua funcionalidade: ```javascript useEffect(async () => { - //TODO: implement + //TODO: implementar }, []) const connectWalletPressed = async () => { - //TODO: implement + //TODO: implementar } const onMintPressed = async () => { - //TODO: implement + //TODO: implementar } ``` -- [`useEffect`](https://reactjs.org/docs/hooks-effect.html) - este é um React Hook que é chamado depois que seu componente é renderizado. Porque ele tem uma array vazia `[]` "prop" passada para ela (veja a linha 3), ela só será chamada na _primeira_ renderização do componente. Aqui vamos chamar nosso ouvinte de carteira e outra função de carteira para atualizar nossa interface de usuário para refletir se uma carteira já está conectada. +- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) - este é um hook do React que é chamado depois que seu componente é renderizado. Como ele tem uma `prop` de array vazio `[]` passada para ele (veja a linha 3), ele só será chamado na _primeira_ renderização do componente. Aqui vamos chamar nosso ouvinte de carteira e outra função de carteira para atualizar nossa interface de usuário para refletir se uma carteira já está conectada. - `connectWalletPressed` - esta função será chamada para conectar a carteira MetaMask do usuário ao nosso dapp. -- `onMintPressed` - esta função será chamada para mintar a NFT do usuário. +- `onMintPressed` - esta função será chamada para mintar o NFT do usuário. -Perto do final desse arquivo, temos a interface de usuário do nosso componente. Se você escanear este código com cuidado, notará que atualizamos nossa `url`, `name`, e `description` variáveis de estado quando a entrada em seus campos de texto correspondentes muda. +Perto do final desse arquivo, temos a interface de usuário do nosso componente. Se você analisar este código com atenção, notará que atualizamos nossas variáveis de estado `url`, `name` e `description` quando a entrada em seus campos de texto correspondentes muda. -Você também verá que `connectWalletPressed` e `onMintPressed` são chamadas quando os botões com IDs `mintButton` e `walletButton` são clicados respectivamente. +Você também verá que `connectWalletPressed` e `onMintPressed` são chamadas quando os botões com os IDs `mintButton` e `walletButton` são clicados, respectivamente. ```javascript -//the UI of our component +//a UI do nosso componente return (


-

🧙‍♂️ Alchemy NFT Minter

+

🧙‍♂️ Mintador de NFT da Alchemy

- Simply add your asset's link, name, and description, then press "Mint." + Basta adicionar o link, nome e descrição do seu ativo e, em seguida, pressione "Mintar".

-

🖼 Link to asset:

+

🖼 Link para o ativo:

setURL(event.target.value)} /> -

🤔 Name:

+

🤔 Nome:

setName(event.target.value)} /> -

✍️ Description:

+

✍️ Descrição:

setDescription(event.target.value)} />

{status}

-
+ ) ``` Finalmente, vamos endereçar onde esse componente Minter será adicionado. -Se você for ao arquivo `App.js`, que é o componente principal do React que atua como um contêiner para todos os outros componentes, você verá que nosso componente Minter é injetado na linha 7. +Se você for ao arquivo `App.js`, que é o componente principal no React que atua como um contêiner para todos os outros componentes, você verá que nosso componente Minter é injetado na linha 7. -**Neste tutorial, vamos apenas editar o arquivo `Minter.js` e adicionar arquivos em nossa pasta `src`.** +**Neste tutorial, editaremos apenas o arquivo `Minter.js` e adicionaremos arquivos em nossa pasta `src`.** Agora que entendemos com o que estamos trabalhando, vamos configurar a nossa carteira Ethereum! @@ -199,41 +201,41 @@ Agora que entendemos com o que estamos trabalhando, vamos configurar a nossa car Para que os usuários possam interagir com o seu contrato inteligente, eles precisarão conectar a sua carteira Ethereum ao seu dapp. -### Baixar MetaMask {#download-metamask} +### Baixe o MetaMask {#download-metamask} -Para este tutorial, usaremos uma carteira virtual no navegador, a MetaMask, para gerenciar o endereço da sua conta Ethereum. Se você quiser entender mais sobre como as transações no Ethereum funcionam, confira [esta página](/developers/docs/transactions/) na Fundação Ethereum. +Para este tutorial, usaremos uma carteira virtual no navegador, a MetaMask, para gerenciar o endereço da sua conta Ethereum. Se você quiser entender mais sobre como as transações na Ethereum funcionam, confira [esta página](/developers/docs/transactions/). -Você pode baixar e criar uma conta MetaMask gratuitamente [neste link](https://metamask.io/download). Quando estiver criando uma conta, ou se já tiver uma, certifique-se de mudar para a "Ropsten Test Network", no canto superior direito (para não precisar lidar com dinheiro de verdade\). +Você pode baixar e criar uma conta MetaMask gratuitamente [aqui](https://metamask.io/download). Quando estiver criando uma conta, ou se já tiver uma, certifique-se de mudar para a "Ropsten Test Network", no canto superior direito (para não precisar lidar com dinheiro de verdade\). -### Etapa: Adicionar Faucet ether {#add-ether-from-faucet} +### Adicione ether de um Faucet {#add-ether-from-faucet} -Para mintar as nossas NFT (ou assinar quaisquer transações no blockchain Ethereum), precisaremos de alguns Eth falsos. Para obter Eth você pode ir para o [faucet da Ropsten](https://faucet.ropsten.be/), inserir seu endereço de conta Ropsten e clicar em "Send Ropsten Eth." Em seguida, você deve ver Eth em sua conta Metamask! +Para mintar as nossas NFT (ou assinar quaisquer transações no blockchain Ethereum), precisaremos de alguns Eth falsos. Para obter Eth, você pode ir ao [Ropsten faucet](https://faucet.ropsten.be/) e inserir o endereço da sua conta Ropsten, depois clicar em “Send Ropsten Eth.” Em seguida, você deve ver Eth em sua conta MetaMask! -### Conferir o seu saldo {#check-your-balance} +### Verifique seu saldo {#check-your-balance} -Para verificar novamente que tem saldo, vamos fazer uma solicitação através da ferramenta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) fornecida pelo [compositor da Alchemy](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ela mostrará a quantidade de Eth na sua carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: +Para verificar novamente se nosso saldo está lá, vamos fazer uma solicitação [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando a [ferramenta de composição da Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Ela mostrará a quantidade de Eth na sua carteira. Depois de inserir o endereço da sua conta da MetaMask e clicar em "Send Request", você verá uma resposta como esta: ```text {"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} ``` -**NOTA:** Este resultado está em wei, não em ETH. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para eth é: 1 eth = 10¹⁸ wei. Então, se convertemos 0xde0b6b3a7640000 para decimal, temos 1\*10¹⁸ wei, que é igual a 1 eth. +**OBSERVAÇÃO:** Este resultado está em wei, não em eth. Lembre-se de que "Wei" é a menor unidade de ether. A conversão de wei para eth é: 1 eth = 10¹⁸ wei. Então, se convertemos 0xde0b6b3a7640000 para decimal, temos 1\*10¹⁸ wei, que é igual a 1 eth. Ufa! Nosso dinheiro falso está todo lá! -## Conecte o MetaMask à sua interface {#connect-metamask-to-your-UI} +## Conecte o MetaMask à sua UI {#connect-metamask-to-your-UI} Agora que nossa carteira MetaMask está configurada, vamos conectar nosso dapp a ela! -Como queremos prescrever conforme o paradigma [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), vamos criar um arquivo separado que contém nossas funções para gerenciar a lógica, dados e regras de nosso dapp, e então passar essas funções para nosso frontend (nosso componente Minter.js). +Como queremos aderir ao paradigma [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), vamos criar um arquivo separado que contém nossas funções para gerenciar a lógica, os dados e as regras do nosso dapp e, em seguida, passar essas funções para o nosso frontend (nosso componente Minter.js). -### Função `connectWallet` {#connect-wallet-function} +### A função `connectWallet` {#connect-wallet-function} -Para fazer isso, vamos criar uma nova pasta chamada `utils` em seu diretório `src` e adicionar um arquivo chamado `interact.js` dentro dele, que conterá todas as funções de nossa carteira e da interação com o contrato inteligente. +Para fazer isso, vamos criar uma nova pasta chamada `utils` em seu diretório `src` e adicionar um arquivo chamado `interact.js` dentro dela, que conterá todas as nossas funções de interação com a carteira e o contrato inteligente. -No nosso arquivo `interact.js`, vamos escrever uma função `connectWallet`, que então importar e chamará nosso componente `Minter.js`. +Em nosso arquivo `interact.js`, escreveremos uma função `connectWallet`, que então importaremos e chamaremos em nosso componente `Minter.js`. -No seu arquivo`interact.js`, adicione o seguinte +No seu arquivo `interact.js`, adicione o seguinte ```javascript export const connectWallet = async () => { @@ -243,7 +245,7 @@ export const connectWallet = async () => { method: "eth_requestAccounts", }) const obj = { - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 Escreva uma mensagem no campo de texto acima.", address: addressArray[0], } return obj @@ -261,8 +263,7 @@ export const connectWallet = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + Você deve instalar o MetaMask, uma carteira virtual Ethereum, em seu navegador.

@@ -274,26 +275,26 @@ export const connectWallet = async () => { Vamos dividir o que este código faz: -Primeiro, nossa função verifica se o `window.ethereum` está habilitado no seu navegador. +Primeiro, nossa função verifica se o `window.ethereum` está ativado em seu navegador. -`window.ethereum` é uma API global injetada pela MetaMask e outros provedores de carteira que permitem que sites solicitem contas Ethereum dos usuários. Se aprovada, ela pode ler dados das blockchains ao qual o usuário está conectado e sugerir que o usuário assine mensagens e transações. Confira a [documentação da MetaMask](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) para obter mais informações! +`window.ethereum` é uma API global injetada pelo MetaMask e outros provedores de carteira que permite que sites solicitem as contas Ethereum dos usuários. Se aprovada, ela pode ler dados das blockchains ao qual o usuário está conectado e sugerir que o usuário assine mensagens e transações. Confira a [documentação do MetaMask](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) para mais informações! -Se `window.ethereum` _não está_ presente, então isso significa que o MetaMask não está instalado. Isso resulta em um objeto JSON sendo retornado, onde o `endereço` retornado é uma string vazia, e o `status` do objeto JSX repassa que o usuário deve instalar o MetaMask. +Se o `window.ethereum` _não estiver_ presente, isso significa que o MetaMask não está instalado. Isso resulta no retorno de um objeto JSON, onde o `address` retornado é uma string vazia, e o objeto JSX `status` informa que o usuário deve instalar o MetaMask. -**A maioria das funções que escrevermos retornarão objetos JSON que podemos usar para atualizar nossas variáveis de estado e interface de usuário.** +**A maioria das funções que escrevermos retornará objetos JSON que podemos usar para atualizar nossas variáveis de estado e UI.** -Agora se `window.ethereum` _estiver_ presente, e é aí que as coisas ficam interessantes. +Agora, se o `window.ethereum` _estiver_ presente, é aí que as coisas ficam interessantes. -Usando um loop de try/catch, tentaremos nos conectar a MetaMask chamando`[window.ethereum.request({ method: "eth_requestAccounts" });](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts)`. Chamando esta função o MetaMask irá abrir no navegador, onde o usuário será solicitado a conectar sua carteira ao seu dapp. +Usando um loop try/catch, tentaremos nos conectar ao MetaMask chamando [`window.ethereum.request({ method: \"eth_requestAccounts\" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts). Chamando esta função o MetaMask irá abrir no navegador, onde o usuário será solicitado a conectar sua carteira ao seu dapp. -- Se o usuário escolher conectar-se, `método: "eth_requestAccounts"` retornará um array que contém todos os endereços de conta do usuário que estão conectados ao dapp. No total, nossa função `connectWallet` retornará um objeto JSON que contém o _primeiro_ `address` desta matriz \(ver linha 9\) e uma mensagem `status` que pede que o usuário escreva uma mensagem para o contrato inteligente. -- Se o usuário rejeitar a conexão, então o objeto JSON vai conter uma string vazia para o `address` retornado e uma mensagem de `status` que reflete que o usuário rejeitou a conexão. +- Se o usuário optar por se conectar, o `method: \"eth_requestAccounts\"` retornará um array que contém todos os endereços de conta do usuário que estão conectados ao dapp. No total, nossa função `connectWallet` retornará um objeto JSON que contém o _primeiro_ `address` neste array (veja a linha 9) e uma mensagem de `status` que solicita ao usuário que escreva uma mensagem para o contrato inteligente. +- Se o usuário rejeitar a conexão, o objeto JSON conterá uma string vazia para o `address` retornado e uma mensagem de `status` que reflete que o usuário rejeitou a conexão. -### Adicionar função connectWallet ao seu componente UI Minter.js {#add-connect-wallet} +### Adicione a função connectWallet ao seu Componente de UI Minter.js {#add-connect-wallet} -Agora que escrevemos esta função `connectWallet`, vamos conectá-la ao nosso componente `Minter.js.`. +Agora que escrevemos esta função `connectWallet`, vamos conectá-la ao nosso componente `Minter.js`. -Primeiro, teremos que importar nossa função para o arquivo `Minter.js` adicionando `import { connectWallet } from "./utils/interact.js";` para o topo do arquivo `Minter.js`. Suas primeiras 11 linhas de `Minter.js` agora devem se parecer com isto: +Primeiro, teremos que importar nossa função para o nosso arquivo `Minter.js`, adicionando `import { connectWallet } from "./utils/interact.js";` no topo do arquivo `Minter.js`. Suas primeiras 11 linhas de `Minter.js` agora devem se parecer com isto: ```javascript import { useEffect, useState } from "react"; @@ -301,7 +302,7 @@ import { connectWallet } from "./utils/interact.js"; const Minter = (props) => { - //State variables + //Variáveis de estado const [walletAddress, setWallet] = useState(""); const [status, setStatus] = useState(""); const [name, setName] = useState(""); @@ -319,9 +320,9 @@ const connectWalletPressed = async () => { } ``` -Observe como a maior parte das nossas funcionalidades está abstraída do nosso componente `Minter.js` do arquivo `interact.js`? É assim que respeitamos o paradigma M-V-C! +Observe como a maior parte da nossa funcionalidade é abstraída do nosso componente `Minter.js` a partir do arquivo `interact.js`? É assim que respeitamos o paradigma M-V-C! -Em `connectWalletPressed`, simplesmente fazemos uma chamada de espera (await) para a função `connectWallet`, importada, e usando sua resposta, nós atualizaremos nossas variáveis `status` e `walletAddress` através de seus state hooks. +Em `connectWalletPressed`, nós simplesmente fazemos uma chamada `await` para a nossa função `connectWallet` importada e, usando sua resposta, atualizamos nossas variáveis `status` e `walletAddress` através de seus hooks de estado. Agora, vamos salvar os dois arquivos `Minter.js` e `interact.js` e testar nossa UI até agora. @@ -331,13 +332,13 @@ Se você tiver o MetaMask instalado, você será solicitado a conectar sua carte Você verá que o botão da carteira agora reflete que seu endereço está conectado. -Em seguida, tente atualizar a página... isso é estranho. Nosso botão de carteira está nos pedindo para conectar o MetaMask, mesmo que já esteja conectado... +Em seguida, tente atualizar a página... que estranho. Nosso botão de carteira está nos pedindo para conectar o MetaMask, mesmo que já esteja conectado... -Mas não se preocupe! Nós podemos facilmente corrigir isso implementando uma função chamada `getCurrentWalletConnected`, que irá verificar se um endereço já está conectado ao nosso dapp e atualizará nossa interface do usuário adequadamente! +Mas não se preocupe! Podemos corrigir isso facilmente implementando uma função chamada `getCurrentWalletConnected`, que verificará se um endereço já está conectado ao nosso dapp e atualizará nossa UI de acordo! -### Função getCurrentWalletConnected {#get-current-wallet} +### A função getCurrentWalletConnected {#get-current-wallet} -Em seu arquivo `interact.js`, adicione a função`getCurrentWalletConnected`: +No seu arquivo `interact.js`, adicione a seguinte função `getCurrentWalletConnected`: ```javascript export const getCurrentWalletConnected = async () => { @@ -349,12 +350,12 @@ export const getCurrentWalletConnected = async () => { if (addressArray.length > 0) { return { address: addressArray[0], - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 Escreva uma mensagem no campo de texto acima.", } } else { return { address: "", - status: "🦊 Connect to MetaMask using the top right button.", + status: "🦊 Conecte-se ao MetaMask usando o botão no canto superior direito.", } } } catch (err) { @@ -371,8 +372,7 @@ export const getCurrentWalletConnected = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + Você deve instalar o MetaMask, uma carteira virtual Ethereum, em seu navegador.

@@ -382,23 +382,23 @@ export const getCurrentWalletConnected = async () => { } ``` -Este código é _muito_ semelhante à função `connectWallet` que acabamos de escrever. +Este código é _muito_ semelhante à função `connectWallet` que escrevemos anteriormente. -A diferença principal é que, em vez de chamar o método `eth_requestAccounts`, que abre o MetaMask para o usuário conectar sua carteira, aqui chamamos o método `eth_accounts`, que simplesmente retorna uma matriz que contém os endereços MetaMask atualmente conectados ao nosso dapp. +A principal diferença é que, em vez de chamar o método `eth_requestAccounts`, que abre o MetaMask para o usuário conectar sua carteira, aqui chamamos o método `eth_accounts`, que simplesmente retorna uma matriz contendo os endereços do MetaMask atualmente conectados ao nosso dapp. Para ver essa função em ação, vamos chamá-la na função `useEffect` do nosso componente `Minter.js`. -Como fizemos para `connectWallet`, devemos importar essa função do nosso arquivo `interact.js` para o `Minter.js`, assim: +Como fizemos para `connectWallet`, devemos importar essa função do nosso arquivo `interact.js` para o nosso arquivo `Minter.js` da seguinte forma: ```javascript import { useEffect, useState } from "react" import { connectWallet, - getCurrentWalletConnected, //import here + getCurrentWalletConnected, //importar aqui } from "./utils/interact.js" ``` -Agora, simplesmente a chamamos em nossa função `useEffect`: +Agora, nós simplesmente a chamamos em nossa função `useEffect`: ```javascript useEffect(async () => { @@ -408,15 +408,15 @@ useEffect(async () => { }, []) ``` -Note que nós usamos a resposta da nossa chamada a `getCurrentWalletConnected` para atualizar nossa `walletAddress` e nossa variável de estado `status`. +Observe que usamos a resposta da nossa chamada para `getCurrentWalletConnected` para atualizar nossas variáveis de estado `walletAddress` e `status`. Depois de adicionar este código, tente atualizar a janela do navegador. O botão deve dizer que você está conectado e mostrar uma visualização do endereço de sua carteira conectada - mesmo depois de atualizar! -### Implementar addWalletListener {#implement-add-wallet-listener} +### Implemente addWalletListener {#implement-add-wallet-listener} O passo final na configuração da nossa carteira dapp é implementar o ouvinte de carteira, para que nossa interface atualize quando o estado mudar, como quando o usuário desconecta ou troca de contas. -No seu arquivo `Minter.js`, adicione a função `addWalletListener` que se parece com o seguinte: +No seu arquivo `Minter.js`, adicione uma função `addWalletListener` que se pareça com o seguinte: ```javascript function addWalletListener() { @@ -424,10 +424,10 @@ function addWalletListener() { window.ethereum.on("accountsChanged", (accounts) => { if (accounts.length > 0) { setWallet(accounts[0]) - setStatus("👆🏽 Write a message in the text-field above.") + setStatus("👆🏽 Escreva uma mensagem no campo de texto acima.") } else { setWallet("") - setStatus("🦊 Connect to MetaMask using the top right button.") + setStatus("🦊 Conecte-se ao MetaMask usando o botão superior direito.") } }) } else { @@ -435,7 +435,7 @@ function addWalletListener() {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your browser. + Você deve instalar o MetaMask, uma carteira virtual Ethereum, em seu navegador.

) @@ -445,9 +445,9 @@ function addWalletListener() { Vamos dividir rapidamente o que está acontecendo aqui: -- Primeiro, nossa função verifica se o `window.ethereum` está habilitado no seu navegador \(ex. MetaMask instalado\). - - Caso contrário, nós simplesmente configuramos a variável de estado `status` para uma JSX string que solicita o usuário instalar a MetaMask. - - Se estiver habilitado, configuramos o ouvinte `window.ethereum.on("accountsChanged")` na linha 3 que houve mudança de estado na carteira MetaMask, inclusive quando o usuário conecta uma conta adicional ao dapp, troca de conta ou desconecta uma conta. Se houver pelo menos uma conta conectada, a variável de estado `walletAddress` é atualizada como a primeira conta no array `accounts` retornada pelo ouvinte. Caso contrário, `walletAddress` é definida como uma string vazia. +- Primeiro, nossa função verifica se o `window.ethereum` está ativado (ou seja, se o MetaMask está instalado). + - Se não estiver, simplesmente definimos nossa variável de estado `status` como uma string JSX que solicita ao usuário que instale o MetaMask. + - Se estiver habilitado, configuramos o listener `window.ethereum.on("accountsChanged")` na linha 3 que escuta por mudanças de estado na carteira MetaMask, que incluem quando o usuário conecta uma conta adicional ao dapp, troca de contas ou desconecta uma conta. Se houver pelo menos uma conta conectada, a variável de estado `walletAddress` é atualizada como a primeira conta no array `accounts` retornado pelo listener. Caso contrário, o `walletAddress` é definido como uma string vazia. Finalmente, nós devemos chamá-la em nossa função `useEffect`: @@ -463,11 +463,11 @@ useEffect(async () => { E Voila! Concluímos a programação de toda a funcionalidade da nossa carteira! Agora que a nossa carteira está pronta, vamos descobrir como mintar nossa NFT! -## Metadados NFT 101 {#nft-metadata-101} +## Metadados de NFT 101 {#nft-metadata-101} Lembra dos metadados da NFT que acabamos de falar no Passo 0 deste tutorial - ele dá vida a uma NFT, permitindo que tenha propriedades, como um ativo digital, nome, descrição e outros atributos. -Vamos precisar configurar esse metadado como um objeto JSON e amarzena-lo, para que possamos passa-lo como parâmetro `tokenURI` quando chamarmos a função `mintNFT` do nosso contrato inteligente. +Vamos precisar configurar esses metadados como um objeto JSON e armazená-lo, para que possamos passá-lo como o parâmetro `tokenURI` ao chamar a função `mintNFT` do nosso contrato inteligente. No campo texto "Link to Asset", "Name", "Description" inclui as diferentes propriedades dos metadados de nosso NFT. Nós vamos formatar estes metadados como um objeto JSON, mas há algumas opções para onde podemos armazenar este objeto JSON: @@ -475,39 +475,39 @@ No campo texto "Link to Asset", "Name", "Description" inclui as diferentes propr - Nós poderíamos armazená-lo em um servidor centralizado, como AWS ou Firebase. Mas isso iria contra nossa ética de descentralização. - Poderíamos usar o IPFS, um protocolo descentralizado e uma rede peer-to-peer para armazenar e compartilhar dados em um sistema de arquivos distribuído. Como este protocolo é descentralizado e gratuito, essa é a melhor opção! -Para armazenar nossos metadados no IPFS, vamos usar [Pinata](https://pinata.cloud/), uma conveniente API IPFS e um conjunto de ferramentas. Na próxima etapa, vamos explicar exatamente como fazer isso! +Para armazenar nossos metadados no IPFS, usaremos o [Pinata](https://pinata.cloud/), uma API e um kit de ferramentas IPFS convenientes. Na próxima etapa, vamos explicar exatamente como fazer isso! ## Use o Pinata para fixar seus metadados no IPFS {#use-pinata-to-pin-your-metadata-to-IPFS} -Se você não tem uma conta no [Pinata](https://pinata.cloud/), cadastre-se [aqui](https://pinata.cloud/) gratuitamente e conclua as etapas de confirmação do seu e-mail e conta. +Se você não tiver uma conta no [Pinata](https://pinata.cloud/), cadastre-se para obter uma conta gratuita [aqui](https://app.pinata.cloud/auth/signup) e conclua as etapas para verificar seu e-mail e conta. -### Crie sua chave API do Pinata {#create-pinata-api-key} +### Crie sua chave de API do Pinata {#create-pinata-api-key} -Navegue para a página[https://pinata.cloud/keys](https://pinata.cloud/keys), então selecione o botão "New Key" no topo da página, defina o Admin widget como ativado, e nomeie sua chave. +Navegue até a página [https://pinata.cloud/keys](https://pinata.cloud/keys), selecione o botão "Nova Chave" na parte superior, defina o widget Admin como ativado e nomeie sua chave. Será mostrado a você um pop-up com as informações da sua API. Certifique-se de colocar isto num lugar seguro. Agora que a nossa chave está configurada, vamos adicioná-la ao nosso projeto para que possamos usá-la. -### Criar o arquivo .env {#create-a-env} +### Crie um arquivo .env {#create-a-env} Podemos armazenar com segurança nossa chave e segredo do Pinata em um arquivo de ambiente. Vamos instalar o [pacote dotenv](https://www.npmjs.com/package/dotenv) no diretório do seu projeto. -Abra uma nova aba no seu terminal \(separado do terminal executando o local host\) e certifique-se de estar na pasta `minter-starter-files`, então execute o seguinte comando no seu terminal: +Abra uma nova aba em seu terminal (separada da que está executando o host local) e certifique-se de estar na pasta `minter-starter-files`. Em seguida, execute o seguinte comando em seu terminal: ```text npm install dotenv --save ``` -Em seguida, crie um arquivo `.env` no diretório raiz dos seus `minter-starter-files` inserindo o seguinte na sua linha de comando: +Em seguida, crie um arquivo `.env` no diretório raiz de seus `minter-starter-files` inserindo o seguinte na sua linha de comando: ```javascript vim.env ``` -Isto abrirá seu arquivo `.env` no formato vim \(um editor de texto\). Para salvar, aperte "esc" + ":" + "q" no seu teclado nesta ordem. +Isso abrirá seu arquivo `.env` no vim (um editor de texto). Para salvar, aperte "esc" + ":" + "q" no seu teclado nesta ordem. -Em seguida, no VSCode, navegue até o seu arquivo `.env` e adicione sua chave de API Pinata e sua API secreta, assim: +Em seguida, no VSCode, navegue até o seu arquivo .env e adicione sua chave de API e segredo de API da Pinata a ele, da seguinte forma: ```text REACT_APP_PINATA_KEY = @@ -516,11 +516,11 @@ REACT_APP_PINATA_SECRET = Salve o arquivo e então você estará pronto para começar a escrever a função de enviar seus metadados JSON para IPFS! -### Implementar pinJSONToIPFS {#pin-json-to-ipfs} +### Implemente pinJSONToIPFS {#pin-json-to-ipfs} -Felizmente para nós, a Pinata tem uma API [especificamente para carregar dados JSON para o IPFS](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) e um JavaScript conveniente com axios de exemplo que podemos usar, com algumas pequenas modificações. +Felizmente para nós, a Pinata tem uma [API especificamente para carregar dados JSON para o IPFS](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) e um exemplo conveniente em JavaScript com axios que podemos usar, com algumas pequenas modificações. -Na sua pasta `utils`, vamos criar outro arquivo chamado `pinata.js` e então importar nossa chave Pinata do arquivo .env assim: +Na sua pasta `utils`, vamos criar outro arquivo chamado `pinata.js` e então importar nosso segredo e chave do Pinata do arquivo .env da seguinte forma: ```javascript require("dotenv").config() @@ -539,7 +539,7 @@ const axios = require("axios") export const pinJSONToIPFS = async (JSONBody) => { const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS` - //making axios POST request to Pinata ⬇️ + //fazendo a requisição axios POST para o Pinata ⬇️ return axios .post(url, JSONBody, { headers: { @@ -566,30 +566,30 @@ export const pinJSONToIPFS = async (JSONBody) => { Então, o que esse código faz exatamente? -Primeiro, importa [axios](https://www.npmjs.com/package/axios), a um cliente HTTP baseado em promessas para o navegador e node.js, que utilizaremos para fazer um pedido a Pinata. +Primeiro, ele importa o [axios](https://www.npmjs.com/package/axios), um cliente HTTP baseado em promessas para o navegador e node.js, que usaremos para fazer uma requisição para o Pinata. -Em seguida, temos nossa função assíncrona `pinJSONToIPFS`, que recebe um `JSONBody` como sua entrada e a chave e senha do API Pinata em seu cabeçalho, tudo para fazer uma solicitação POST para sua API `pinJSONToIPFS`. +Em seguida, temos nossa função assíncrona `pinJSONToIPFS`, que recebe um `JSONBody` como entrada e a chave e segredo da API da Pinata em seu cabeçalho, tudo para fazer uma requisição POST para sua API `pinJSONToIPFS`. -- Se esta solicitação POST for bem sucedida, então nossa função retorna um objeto JSON com o valor booleano `sucess` como verdadeiro e a `pinataUrl` onde nossos metadados foram fixados. Nós usaremos a `pinataUrl` retornada, como entrada na `tokenURI` para a função mint do nosso contrato inteligente. -- Se esta solicitação POST falhar, então, nossa função retorna um objeto JSON com o booleano `success` como falso e uma `message` que transmite nosso erro. +- Se esta requisição POST for bem-sucedida, nossa função retornará um objeto JSON com o booleano `success` como verdadeiro e o `pinataUrl` onde nossos metadados foram fixados. Usaremos este `pinataUrl` retornado como a entrada `tokenURI` para a função de mintagem do nosso contrato inteligente. +- Se esta solicitação de post falhar, nossa função retornará um objeto JSON com o booleano de `success` como falso e uma string `message` que transmite nosso erro. -Assim como na nossa função `connectWallet`retorna tipos, estamos retornando objetos JSON para que possamos usar seus parâmetros para atualizar nossas variáveis de estado e nossa interface de usuário. +Assim como nos tipos de retorno da nossa função `connectWallet`, estamos retornando objetos JSON para que possamos usar seus parâmetros para atualizar nossas variáveis de estado e a UI. -## Carregar seu contrato inteligente {#load-your-smart-contract} +## Carregue seu contrato inteligente {#load-your-smart-contract} -Agora que temos uma maneira de enviar nossos metadados NFT para IPFS através de nossa função de `pinJSONToIPFS`, vamos precisar de uma forma de carregar uma instância do nosso contrato inteligente para que possamos chamar a função `mintNFT`. +Agora que temos uma maneira de enviar nossos metadados de NFT para o IPFS através de nossa função `pinJSONToIPFS`, vamos precisar de uma forma de carregar uma instância do nosso contrato inteligente para que possamos chamar sua função `mintNFT`. -Como mencionado anteriormente, neste tutorial usaremos [este é um contrato inteligente NFT existente](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE); no entanto, se você quer aprender como o fizemos ou como fazer um você mesmo, é altamente recomendável que você confira nosso outro tutorial, ["Como criar uma NFT.](https://docs.alchemyapi.io/alchemy/tutorials/how-to-create-an-nft). +Como mencionamos anteriormente, neste tutorial usaremos [este contrato inteligente de NFT existente](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE); no entanto, se você quiser aprender como o fizemos ou criar um você mesmo, recomendamos fortemente que você confira nosso outro tutorial, ["Como Criar um NFT."](https://www.alchemy.com/docs/how-to-create-an-nft). -### O contrato ABI {#contract-abi} +### A ABI do contrato {#contract-abi} -Se você examinar de perto nossos arquivos, você notará que no nosso diretório `src`, há um arquivo `contract-abi.json`. Um ABI é necessário para especificar qual função um contrato irá invocar, como também garantir que a função retornará dados no formato que você espera. +Se você examinou nossos arquivos de perto, deve ter notado que em nosso diretório `src`, há um arquivo `contract-abi.json`. Um ABI é necessário para especificar qual função um contrato irá invocar, como também garantir que a função retornará dados no formato que você espera. Também precisaremos de uma chave API Alchemy e da API Alchemy Web3 para conectar ao blockchain Ethereum e carregar o nosso contrato inteligente. -### Crie a sua chave API Alchemy {#create-alchemy-api} +### Crie sua chave de API da Alchemy {#create-alchemy-api} -Se ainda não tiver uma conta na Alchemy, você pode se cadastrar gratuitamente [neste link](https://alchemy.com/?a=eth-org-nft-minter) +Se você ainda não tem uma conta na Alchemy, [inscreva-se gratuitamente aqui.](https://alchemy.com/?a=eth-org-nft-minter) Assim que criar uma conta na Alchemy, você pode gerar uma chave de API criando um "app". Isso nos permitirá fazer solicitações à rede de testes Ropsten. @@ -609,18 +609,18 @@ REACT_APP_PINATA_SECRET = REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/ ``` -Agora que temos nosso contrato ABI e nossa chave API do Alchemy, estamos prontos para carregar o nosso contrato inteligente usando [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3). +Agora que temos nossa ABI de contrato e nossa chave de API da Alchemy, estamos prontos para carregar nosso contrato inteligente usando o [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3). -### Configure seu Alchemy Web3 endpoint e contrato {#setup-alchemy-endpoint} +### Configure seu endpoint e contrato do Alchemy Web3 {#setup-alchemy-endpoint} -Primeiro, se você ainda não tiver, você precisará instalar [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navegando até o diretório home: `nft-minter-tutorial` no terminal: +Primeiro, se você ainda não o tiver, precisará instalar o [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navegando até o diretório inicial: `nft-minter-tutorial` no terminal: ```text cd .. -yarn add @alch/alchemy-web3 +npm install @alch/alchemy-web3 ``` -Em seguida, voltaremos para o nosso arquivo `interact.js`. No topo do arquivo, adicione o seguinte código para importar a chave de Alchemy do seu arquivo .env e configure seu Alchemy Web3 endpoint: +Em seguida, vamos voltar ao nosso arquivo `interact.js`. No topo do arquivo, adicione o seguinte código para importar a chave de Alchemy do seu arquivo .env e configure seu Alchemy Web3 endpoint: ```javascript require("dotenv").config() @@ -629,7 +629,7 @@ const { createAlchemyWeb3 } = require("@alch/alchemy-web3") const web3 = createAlchemyWeb3(alchemyKey) ``` -[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) é um invólucro em torno do [Web3.js](https://docs.web3js.org/), fornecendo métodos aprimorados da API e outros benefícios cruciais para tornar a sua vida de desenvolvedor da Web3 mais fácil. Ele foi projetado para exigir uma configuração mínima, para que você possa começar a usá-la no seu aplicativo imediatamente! +O [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) é um wrapper em torno do [Web3.js](https://docs.web3js.org/), fornecendo métodos de API aprimorados e outros benefícios cruciais para facilitar sua vida como desenvolvedor web3. Ele foi projetado para exigir uma configuração mínima, para que você possa começar a usá-la no seu aplicativo imediatamente! Em seguida, vamos adicionar nosso contrato ABI e endereço do contrato ao nosso arquivo. @@ -645,83 +645,83 @@ const contractAddress = "0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE" Assim que tivermos ambas as coisas, estaremos prontos para começar a codificar a nossa função "mint"! -## Implementar a função mintNFT {#implement-the-mintnft-function} +## Implemente a função mintNFT {#implement-the-mintnft-function} -Dentro do seu arquivo `interact.js`, vamos definir nossa função, `mintNFT`, que deliberadamente vai criar nossa NFT. +Dentro do seu arquivo `interact.js`, vamos definir nossa função, `mintNFT`, que, de forma homônima, irá mintar nosso NFT. Porque vamos fazer numerosas chamadas assíncronas \(para o Pinata fixar nossos metadados para IPFS, Alchemy Web3 para carregar o nosso contrato inteligente, e MetaMask para assinar nossas transações\), nossa função também será assíncrona. -As três entradas para nossa função serão a `url` do nosso ativo digital, `name`e `description`. Adicione a seguinte assinatura da função abaixo da função `connectWallet`: +As três entradas para nossa função serão a `url` do nosso ativo digital, o `name` e a `description`. Adicione a seguinte assinatura da função abaixo da função `connectWallet`: ```javascript export const mintNFT = async (url, name, description) => {} ``` -### Manipulação de erros de script {#input-error-handling} +### Tratamento de erros de entrada {#input-error-handling} Naturalmente, faz sentido ter algum tipo de tratamento de erro de entrada no início da função, então vamos sair desta função se nossos parâmetros de entrada não estiverem corretos. Dentro da nossa função, vamos adicionar o seguinte código: ```javascript export const mintNFT = async (url, name, description) => { - //error handling + //tratamento de erros if (url.trim() == "" || name.trim() == "" || description.trim() == "") { return { success: false, - status: "❗Please make sure all fields are completed before minting.", + status: "❗Certifique-se de que todos os campos estão preenchidos antes de mintar.", } } } ``` -Essencialmente, se algum dos parâmetros de entrada for uma string vazia, então retornamos um objeto JSON onde o valor booleano `success` é falso, e a string `status` repassa que todos os campos na nossa UI precisam estar completos. +Essencialmente, se algum dos parâmetros de entrada for uma string vazia, retornamos um objeto JSON onde o booleano `success` é falso, e a string `status` informa que todos os campos em nossa UI devem ser preenchidos. -### Carregar os metadados para o IPFS {#upload-metadata-to-ipfs} +### Envie os metadados para o IPFS {#upload-metadata-to-ipfs} -Assim que soubermos que nossos metadados estão formatados corretamente, o próximo passo é envolvê-lo em um objeto JSON e enviá-lo para IPFS através do `pinJSONToIPFS` que escrevemos! +Assim que soubermos que nossos metadados estão formatados corretamente, o próximo passo é envolvê-lo em um objeto JSON e enviá-lo para o IPFS através do `pinJSONToIPFS` que escrevemos! -Para fazer isso, precisamos primeiro importar a função `pinJSONToIPFS` para nosso arquivo `interact.js`. No topo do `interact.js`, vamos adicionar: +Para fazer isso, primeiro precisamos importar a função `pinJSONToIPFS` para nosso arquivo `interact.js`. No topo do `interact.js`, vamos adicionar: ```javascript import { pinJSONToIPFS } from "./pinata.js" ``` -Lembre-se que `pinJSONToIPFS` recebe um corpo JSON. Então, antes de fazer a chamada, precisaremos formatar a nossa `url`, `name`e `description` parâmetros em um objeto JSON. +Lembre-se que o `pinJSONToIPFS` recebe um corpo JSON. Então, antes de fazer uma chamada para ele, precisaremos formatar nossos parâmetros `url`, `name` e `description` em um objeto JSON. -Vamos atualizar nosso código para criar um objeto JSON chamado `metadada` e então fazer uma chamada para `pinJSONToIPFS` com este parâmetro `metadada`: +Vamos atualizar nosso código para criar um objeto JSON chamado `metadata` e então fazer uma chamada para `pinJSONToIPFS` com este parâmetro `metadata`: ```javascript export const mintNFT = async (url, name, description) => { - //error handling + //tratamento de erros if (url.trim() == "" || name.trim() == "" || description.trim() == "") { return { success: false, - status: "❗Please make sure all fields are completed before minting.", + status: "❗Certifique-se de que todos os campos estão preenchidos antes de mintar.", } } - //make metadata + //criar metadados const metadata = new Object() metadata.name = name metadata.image = url metadata.description = description - //make pinata call + //fazer chamada ao pinata const pinataResponse = await pinJSONToIPFS(metadata) if (!pinataResponse.success) { return { success: false, - status: "😢 Something went wrong while uploading your tokenURI.", + status: "😢 Algo deu errado durante o upload do seu tokenURI.", } } const tokenURI = pinataResponse.pinataUrl } ``` -Note, nós armazenamos a resposta de nossa chamada para `pinJSONToIPFS(metadada)` no objeto `pinataResponse`. Então, analisamos esse objeto para quaisquer erros. +Observe que armazenamos a resposta da nossa chamada para `pinJSONToIPFS(metadata)` no objeto `pinataResponse`. Então, analisamos esse objeto para quaisquer erros. -Se houver um erro, nós retornamos um objeto JSON onde o `sucess` booleano é falso e nossa string `status` relata que nossa chamada falhou. Caso contrário, nós extraímos a `pinataURL` da `pinataResponse` e armazenamos como nossa variável `tokenURI`. +Se houver um erro, retornamos um objeto JSON onde o booleano `success` é falso e nossa string `status` informa que nossa chamada falhou. Caso contrário, extraímos o `pinataURL` da `pinataResponse` e o armazenamos como nossa variável `tokenURI`. -Agora é hora de carregar o nosso contrato inteligente usando a API da Alchemy Web3 que inicializamos no topo do nosso arquivo. Adicione a seguinte linha de código na parte inferior da função `mintNFT` para definir o contrato na `window.contract` variável global: +Agora é hora de carregar o nosso contrato inteligente usando a API da Alchemy Web3 que inicializamos no topo do nosso arquivo. Adicione a seguinte linha de código na parte inferior da função `mintNFT` para definir o contrato na variável global `window.contract`: ```javascript window.contract = await new web3.eth.Contract(contractABI, contractAddress) @@ -730,16 +730,16 @@ window.contract = await new web3.eth.Contract(contractABI, contractAddress) A última coisa a adicionar em nossa função `mintNFT` é a nossa transação Ethereum: ```javascript -//set up your Ethereum transaction +//configure sua transação Ethereum const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: window.ethereum.selectedAddress, // must match user's active address. + to: contractAddress, // Obrigatório, exceto durante a publicação de contratos. + from: window.ethereum.selectedAddress, // deve corresponder ao endereço ativo do usuário. data: window.contract.methods .mintNFT(window.ethereum.selectedAddress, tokenURI) - .encodeABI(), //make call to NFT smart contract + .encodeABI(), //faz uma chamada para o contrato inteligente de NFT } -//sign the transaction via MetaMask +//assine a transação via MetaMask try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -748,13 +748,13 @@ try { return { success: true, status: - "✅ Check out your transaction on Etherscan: https://ropsten.etherscan.io/tx/" + + "✅ Confira sua transação no Etherscan: https://ropsten.etherscan.io/tx/" + txHash, } } catch (error) { return { success: false, - status: "😥 Something went wrong: " + error.message, + status: "😥 Algo deu errado: " + error.message, } } ``` @@ -762,54 +762,54 @@ try { Se você já está familiarizado com as transações na Ethereum, perceberá que a estrutura é bem parecida com a que você já viu. - Primeiro, nós configuramos nossos parâmetros de transações. - - `to` especificar o endereço do destinatário \(nosso contrato inteligente\) - - `from` especifica o signatário da transação \(o endereço conectado ao MetaMask: `window.ethereum.selectedAddress`\) - - `data` contém a chamada para nosso contrato inteligente do método `mintNFT`, que recebe nossa `tokenURI` e o endereço da carteira do usuário, `window.ethereum.selectedAddress` como entradas -- Então, faremos uma chamada para, `window.ethereum.request,` onde pedimos ao MetaMask para assinar a transação. Note que nessa solicitação, estamos especificando nosso método eth \(eth_SentTransaction\) e passando em nossos `transactionParameters`. Neste ponto, a MetaMask irá abrir no navegador e pedirá que o usuário assine ou rejeite a transação. - - Se a transação for bem-sucedida, a função retornará um objeto JSON onde o booleano `success` é definido como verdadeiro e a string `status` pede que o usuário verifique o Etherscan para obter mais informações sobre sua transação. - - Se a transação falhar, a função retornará um objeto JSON onde o booleano `success` é definido como falso, `status` string retransmite a mensagem de erro. + - `to` especifica o endereço do destinatário (nosso contrato inteligente) + - `from` especifica o assinante da transação (o endereço conectado do usuário ao MetaMask: `window.ethereum.selectedAddress`) + - `data` contém a chamada para o nosso método `mintNFT` de contrato inteligente, que recebe o nosso `tokenURI` e o endereço da carteira do usuário, `window.ethereum.selectedAddress`, como entradas +- Então, fazemos uma chamada de `await`, `window.ethereum.request`, onde pedimos ao MetaMask para assinar a transação. Observe que, nesta solicitação, estamos especificando nosso método eth (`eth_SentTransaction`) e passando nossos `transactionParameters`. Neste ponto, a MetaMask irá abrir no navegador e pedirá que o usuário assine ou rejeite a transação. + - Se a transação for bem-sucedida, a função retornará um objeto JSON onde o booleano `success` é definido como verdadeiro e a string `status` solicita que o usuário verifique o Etherscan para obter mais informações sobre sua transação. + - Se a transação falhar, a função retornará um objeto JSON onde o booleano `success` é definido como falso, e a string `status` retransmite a mensagem de erro. -Ao todo, nossa função `mintNFT` deve-se parecer com isto: +No total, nossa função `mintNFT` deve se parecer com isto: ```javascript export const mintNFT = async (url, name, description) => { - //error handling + //tratamento de erros if (url.trim() == "" || name.trim() == "" || description.trim() == "") { return { success: false, - status: "❗Please make sure all fields are completed before minting.", + status: "❗Certifique-se de que todos os campos estão preenchidos antes de mintar.", } } - //make metadata + //criar metadados const metadata = new Object() metadata.name = name metadata.image = url metadata.description = description - //pinata pin request + //solicitação de fixação do pinata const pinataResponse = await pinJSONToIPFS(metadata) if (!pinataResponse.success) { return { success: false, - status: "😢 Something went wrong while uploading your tokenURI.", + status: "😢 Algo deu errado durante o upload do seu tokenURI.", } } const tokenURI = pinataResponse.pinataUrl - //load smart contract + //carregar contrato inteligente window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract(); - //set up your Ethereum transaction + //configure sua transação Ethereum const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: window.ethereum.selectedAddress, // must match user's active address. + to: contractAddress, // Obrigatório, exceto durante a publicação de contratos. + from: window.ethereum.selectedAddress, // deve corresponder ao endereço ativo do usuário. data: window.contract.methods .mintNFT(window.ethereum.selectedAddress, tokenURI) - .encodeABI(), //make call to NFT smart contract + .encodeABI(), //faz uma chamada para o contrato inteligente de NFT } - //sign transaction via MetaMask + //assinar transação via MetaMask try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -818,23 +818,23 @@ export const mintNFT = async (url, name, description) => { return { success: true, status: - "✅ Check out your transaction on Etherscan: https://ropsten.etherscan.io/tx/" + + "✅ Confira sua transação no Etherscan: https://ropsten.etherscan.io/tx/" + txHash, } } catch (error) { return { success: false, - status: "😥 Something went wrong: " + error.message, + status: "😥 Algo deu errado: " + error.message, } } } ``` -Essa é uma função gigante! Agora, só precisamos conectar nossa função `mintNFT` com nosso componente `Minter.js`... +Essa é uma função gigante! Agora, só precisamos conectar nossa função `mintNFT` ao nosso componente `Minter.js`... -## Conectando mintNFT ao nosso frontend Minter.js {#connect-our-frontend} +## Conecte o mintNFT ao nosso frontend Minter.js {#connect-our-frontend} -Abra o seu arquivo `Minter.js` e atualize `import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";` a linha em cima deve ser: +Abra seu arquivo `Minter.js` e atualize a linha `import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";` no topo para ser: ```javascript import { @@ -844,7 +844,7 @@ import { } from "./utils/interact.js" ``` -Finalmente, implemente a função `onMintPressed` para fazer a chamada(await call) para a função `mintNFT`importada e atualize a variável de estado `status` para refletir se nossa transação foi bem-sucedida ou falhou: +Finalmente, implemente a função `onMintPressed` para fazer a chamada `await` para a sua função `mintNFT` importada e atualize a variável de estado `status` para refletir se nossa transação foi bem-sucedida ou falhou: ```javascript const onMintPressed = async () => { @@ -853,13 +853,13 @@ const onMintPressed = async () => { } ``` -## Implante seu NFT a um site ao vivo {#deploy-your-NFT} +## Implante seu NFT em um site ativo {#deploy-your-NFT} -Pronto para deixar seu projeto ao vivo para que usuários interajam? Confira [este tutorial](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) para implantar seu Minter em um site ao vivo. +Pronto para deixar seu projeto ao vivo para que usuários interajam? Confira [este tutorial](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) para implantar seu Mintador em um site ativo. Um último passo... -## Leve o mundo blockchain numa enxurrada {#take-the-blockchain-world-by-storm} +## Conquiste o mundo da blockchain {#take-the-blockchain-world-by-storm} Só uma brincadeira, você chegou ao fim do tutorial! @@ -869,6 +869,6 @@ Para recapitular, construindo um minter NFT, você aprendeu com sucesso como: - Chamar métodos de contrato inteligentes no seu frontend - Assine transações usando MetaMask -Provavelmente você gostaria de poder exibir seu NFT na sua carteira — então certifique-se de conferir [ a parte Como ver seu NFT na sua carteira](https://docs.alchemyapi.io/alchemy/tutorials/how-to-write-and-deploy-a-nft-smart-contract/how-to-view-your-nft-in-your-wallet)! +Presumivelmente, você gostaria de poder exibir os NFTs mintados através do seu dapp em sua carteira — então, certifique-se de conferir nosso rápido tutorial [Como Visualizar seu NFT em sua Carteira](https://www.alchemy.com/docs/how-to-view-your-nft-in-your-mobile-wallet)! -E, como sempre, se você tiver alguma dúvida, estamos aqui para ajudar no [Alchemy Discord](https://discord.gg/gWuC7zB). Mal podemos esperar para ver como você aplicará os conceitos deste tutorial em seus projetos futuros! +E, como sempre, se você tiver alguma dúvida, estamos aqui para ajudar no [Discord da Alchemy](https://discord.gg/gWuC7zB). Mal podemos esperar para ver como você aplicará os conceitos deste tutorial em seus projetos futuros! diff --git a/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 563bb7c50e7..e6259320790 100644 --- a/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -1,84 +1,89 @@ --- -title: "Passo a passo do contrato de ponte padrão da Optimism" -description: Como funciona a ponte padrão para a Optimism? Porque funciona desta maneira? +title: "Passo a passo do contrato da ponte padrão do Optimism" +description: "Como funciona a ponte padrão para o Optimism? Por que funciona desta maneira?" author: Ori Pomerantz -tags: - - "solidity" - - "ponte" - - "camada 2" +tags: [ "Solidity", "ponte", "camada 2" ] skill: intermediate published: 2022-03-30 lang: pt-br --- -[Optimism](https://www.optimism.io/) é uma [ Optimistic Rollup](/developers/docs/scaling/optimistic-rollups/). Optimistic rollups podem processar transações por um preço muito inferior ao Ethereum Mainnet (também conhecido como layer 1 ou L1) porque as transações são processadas apenas por alguns nós, em vez de cada nó na rede. Ao mesmo tempo, os dados são todos escritos em L1, de modo que tudo pode ser provado e reconstruído com todas as garantias de integridade e disponibilidade da rede principal. +[Optimism](https://www.optimism.io/) é um [Optimistic Rollup](/developers/docs/scaling/optimistic-rollups/). +Os optimistic rollups podem processar transações por um preço muito mais baixo do que a Rede Principal da Ethereum (também conhecida como camada 1 ou L1), porque as transações são processadas apenas por alguns nós, em vez de por todos os nós na rede. +Ao mesmo tempo, todos os dados são escritos na L1, para que tudo possa ser provado e reconstruído com todas as garantias de integridade e disponibilidade da Rede Principal. -Para usar ativos L1 na Optimism (ou qualquer outra L2), os ativos precisam ser [enviados pela ponte](/bridges/#prerequisites). Uma maneira de conseguir isso é os usuários bloquearem ativos (ETH e [tokens ERC-20](/developers/docs/standards/tokens/erc-20/) são os mais comuns) na L1, e receber ativos equivalentes para usar na L2. Por fim, quem for que acabe com eles, talvez queira enviá-los de volta para a L1. Ao fazer isso, os ativos são queimados na L2 e, em seguida, liberados para o usuário na L1. +Para usar ativos da L1 no Optimism (ou em qualquer outra L2), os ativos precisam ser [transferidos por ponte](/bridges/#prerequisites). +Uma maneira de conseguir isso é os usuários bloquearem ativos (ETH e [tokens ERC-20](/developers/docs/standards/tokens/erc-20/) são os mais comuns) na L1 e receberem ativos equivalentes para usar na L2. +Eventualmente, quem quer que acabe com eles pode querer transferi-los por ponte de volta para a L1. +Ao fazer isso, os ativos são queimados na L2 e então liberados de volta para o usuário na L1. -É assim que a [ponte padrão Optimism](https://docs.optimism.io/app-developers/bridging/standard-bridge) funciona. Neste artigo, passamos pelo código-fonte para essa ponte para ver como ele funciona e estudá-lo como um exemplo de código Solidity bem escrito. +É assim que a [ponte padrão do Optimism](https://docs.optimism.io/app-developers/bridging/standard-bridge) funciona. +Neste artigo, analisamos o código-fonte dessa ponte para ver como ela funciona e estudá-la como um exemplo de código Solidity bem escrito. -## Fluxo de controle {#control-flows} +## Fluxos de controle {#control-flows} A ponte tem dois fluxos principais: -- Depósito (de L1 a L2) -- Saque de (L2 para L1) +- Depósito (da L1 para a L2) +- Retirada (da L2 para a L1) -### Fluxo de depósitos {#deposit-flow} +### Fluxo de depósito {#deposit-flow} #### Camada 1 {#deposit-flow-layer-1} -1. Se depositar um ERC-20, o depositante dá à ponte uma permissão para gastar o valor que está sendo depositado -2. O depositor chama a ponte L1(`depositERC20`, `depositERC20To`, `depositETH`, ou `depositETHTo`) -3. A ponte L1 toma posse do ativo que está na ponte - - ETH: O ativo é transferido pelo depositante como parte da chamada - - ERC-20: O ativo é transferido pela ponte para si mesmo usando a permissão fornecida pelo depositante -4. A ponte L1 usa o mecanismo de mensagem entre domínios para chamar `finalizeDeposit` na ponte L2 +1. Ao depositar um ERC-20, o depositante concede à ponte uma autorização para gastar o valor que está sendo depositado +2. O depositante chama a ponte da L1 (`depositERC20`, `depositERC20To`, `depositETH` ou `depositETHTo`) +3. A ponte da L1 toma posse do ativo transferido pela ponte + - ETH: o ativo é transferido pelo depositante como parte da chamada + - ERC-20: o ativo é transferido pela ponte para si mesma usando a autorização fornecida pelo depositante +4. A ponte da L1 usa o mecanismo de mensagens entre domínios para chamar `finalizeDeposit` na ponte da L2 #### Camada 2 {#deposit-flow-layer-2} -5. A ponte L2 verifica que a chamada do `finalizeDeposit` é legítima: - - Se veio do contrato de mensagem entre domínios - - Era originalmente da ponte em L1 -6. A ponte L2 checa se o contrato do token ERC-20 na L2 é o correto: - - O contrato L2 reporta que sua contraparte L1 é a mesma de onde vieram os tokens da L1 - - O contrato L2 reporta que suporta a interface correta ([usando ERC-165](https://eips.ethereum.org/EIPS/eip-165)). -7. Se o contrato L2 é o correto, chame-o para cunhar o número apropriado de tokens para o endereço apropriado. Se não, comece o processo de retirada para permitir o usuário reclamar os tokens no L1. +5. A ponte da L2 verifica se a chamada para `finalizeDeposit` é legítima: + - Veio do contrato de mensagens entre domínios + - Era originalmente da ponte na L1 +6. A ponte da L2 verifica se o contrato do token ERC-20 na L2 é o correto: + - O contrato da L2 informa que sua contraparte da L1 é a mesma de onde os tokens vieram na L1 + - O contrato da L2 informa que suporta a interface correta ([usando ERC-165](https://eips.ethereum.org/EIPS/eip-165)). +7. Se o contrato da L2 for o correto, chame-o para cunhar o número apropriado de tokens para o endereço apropriado. Caso contrário, inicie um processo de retirada para permitir que o usuário resgate os tokens na L1. ### Fluxo de retirada {#withdrawal-flow} -#### Camada 2 {#withdrawl-flow-layer-2} +#### Camada 2 {#withdrawal-flow-layer-2} -1. O sacador chama a ponte L2 (`withdraw` ou `withdrawTo`) -2. A ponte L2 queima o número apropriado de tokens pertencentes a `msg.sender` -3. A ponte L2 usa o mecanismo de mensagens entre domínios para chamar `finalizeETHWithdrawal` ou `finalizeERC20Withdrawal` na ponte L1 +1. O sacador chama a ponte da L2 (`withdraw` ou `withdrawTo`) +2. A ponte da L2 queima o número apropriado de tokens pertencentes a `msg.sender` +3. A ponte da L2 usa o mecanismo de mensagens entre domínios para chamar `finalizeETHWithdrawal` ou `finalizeERC20Withdrawal` na ponte da L1 -#### Camada 1 {#withdrawl-flow-layer-1} +#### Camada 1 {#withdrawal-flow-layer-1} -4. A ponte L1 verifica a chamada a `finalizeETHWithdrawal` ou `finalizeERC20Withdrawal` é legitima: - - Veio de um mecanismo de mensagens entre domínios - - Foi originada da ponte no L2 -5. A ponte L1 transfere o ativo apropriado (ETH ou ERC-20) para o endereço apropriado +4. A ponte da L1 verifica se a chamada para `finalizeETHWithdrawal` ou `finalizeERC20Withdrawal` é legítima: + - Veio do mecanismo de mensagens entre domínios + - Foi originada da ponte na L2 +5. A ponte da L1 transfere o ativo apropriado (ETH ou ERC-20) para o endereço apropriado -## Código Camada 1 {#layer-1-code} +## Código da Camada 1 {#layer-1-code} -Este é o código que roda na L1, a Rede Principal do Ethereum. +Este é o código que é executado na L1, a Rede Principal da Ethereum. ### IL1ERC20Bridge {#IL1ERC20Bridge} -[Esta interface é definida aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol). Ela inclui funções e definições exigidas para realizar a ponte de tokens ERC-20. +[Esta interface é definida aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol). +Ela inclui funções e definições necessárias para a transferência de tokens ERC-20 por ponte. ```solidity // SPDX-License-Identifier: MIT ``` -[Maioria do código da Optimism é lançada sob a licença MIT](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-). +[A maior parte do código do Optimism é lançada sob a licença MIT](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-). ```solidity pragma solidity >0.5.0 <0.9.0; ``` -Neste momento, a última versão do Solidity é 0.8.12. Até versão 0.9.0 ser lançada, nós não sabemos se este código é compatível com ele ou não. +No momento em que este artigo foi escrito, a versão mais recente do Solidity era a 0.8.12. +Até que a versão 0.9.0 seja lançada, não sabemos se este código é compatível com ela ou não. ```solidity /** @@ -86,20 +91,23 @@ Neste momento, a última versão do Solidity é 0.8.12. Até versão 0.9.0 ser l */ interface IL1ERC20Bridge { /********** - * Events * + * Eventos * **********/ event ERC20DepositInitiated( ``` -Na terminologia de ponte Optimism _deposit_ significa transferência de L2 para L2, e _withdrawal_ significa uma transferência de L2 para L1. +Na terminologia de ponte do Optimism, _deposit_ (depósito) significa transferência da L1 para a L2, e _withdrawal_ (retirada) significa uma transferência da L2 para a L1. ```solidity address indexed _l1Token, address indexed _l2Token, ``` -Na maioria dos casos o endereço de um ERC-20 na L1 não é o mesmo endereço do equivalente ERC-20 na L2. [Você pode ver a lista de endereços de tokens aqui](https://static.optimism.io/optimism.tokenlist.json). O endereço com `chainId` 1 está na L1 (Mainnet) e o endereço com `chainId` 10 está na L2 (Optimism). Os outros dois valores `chainId` são para a rede de testes Kovan (42) e a rede de testes Optimistic Kovan (69). +Na maioria dos casos, o endereço de um ERC-20 na L1 não é o mesmo que o endereço do ERC-20 equivalente na L2. +[Você pode ver a lista de endereços de token aqui](https://static.optimism.io/optimism.tokenlist.json). +O endereço com `chainId` 1 está na L1 (Rede Principal) e o endereço com `chainId` 10 está na L2 (Optimism). +Os outros dois valores de `chainId` são para a rede de teste Kovan (42) e a rede de teste Optimistic Kovan (69). ```solidity address indexed _from, @@ -109,7 +117,7 @@ Na maioria dos casos o endereço de um ERC-20 na L1 não é o mesmo endereço do ); ``` -É possível adicionar notas para transferências, caso no qual elas são adicionadas para os eventos que as reportam. +É possível adicionar anotações às transferências, e nesse caso, elas são adicionadas aos eventos que as relatam. ```solidity event ERC20WithdrawalFinalized( @@ -122,33 +130,35 @@ Na maioria dos casos o endereço de um ERC-20 na L1 não é o mesmo endereço do ); ``` -O mesmo contrato de ponte manipula transferências em ambas as direções. No caso da ponte L1, isto significa inicialização de depósitos e finalização de retiradas. +O mesmo contrato de ponte lida com transferências em ambas as direções. +No caso da ponte da L1, isso significa a inicialização de depósitos e a finalização de retiradas. ```solidity /******************** - * Public Functions * + * Funções Públicas * ********************/ /** - * @dev get the address of the corresponding L2 bridge contract. - * @return Address of the corresponding L2 bridge contract. + * @dev obtém o endereço do contrato da ponte da L2 correspondente. + * @return Endereço do contrato da ponte da L2 correspondente. */ function l2TokenBridge() external returns (address); ``` -Esta função não é realmente necessária, porque na L2 ela é um contrato pré-implantado, então ela está sempre no endereço `0x4200000000000000000000000000000000000010`. Ela está aqui por simetria com a ponte L2, porque o endereço da ponte L1 _não_ é trivial de saber. +Esta função não é realmente necessária, porque na L2 ela é um contrato pré-implantado, então está sempre no endereço `0x4200000000000000000000000000000000000010`. +Ela está aqui por simetria com a ponte da L2, porque o endereço da ponte da L1 _não_ é trivial de saber. ```solidity /** - * @dev deposit an amount of the ERC20 to the caller's balance on L2. - * @param _l1Token Address of the L1 ERC20 we are depositing - * @param _l2Token Address of the L1 respective L2 ERC20 - * @param _amount Amount of the ERC20 to deposit - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev deposita uma quantia do ERC20 no saldo do chamador na L2. + * @param _l1Token Endereço do ERC20 da L1 que estamos depositando + * @param _l2Token Endereço do respectivo ERC20 da L2 + * @param _amount Quantia do ERC20 a ser depositada + * @param _l2Gas Limite de gás necessário para completar o depósito na L2. + * @param _data Dados opcionais para encaminhar para a L2. Estes dados são fornecidos + * apenas como uma conveniência para contratos externos. Além de impor um comprimento + * máximo, estes contratos não fornecem garantias sobre seu conteúdo. */ function depositERC20( address _l1Token, @@ -159,19 +169,21 @@ Esta função não é realmente necessária, porque na L2 ela é um contrato pr ) external; ``` -O parâmetro `_l2Gas` é a quantidade de gas L2 que a transação tem permissão de gastar. [Até um certo (alto) limite, isto é grátis](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2), portanto a menos que o contrato ERC-20 faça algo realmente estranho quando cunhando, isto não deveria ser um problema. Esta função cuida do cenário comum, onde um usuário faz a ponte dos ativos para o mesmo endereço em uma blockchain diferente. +O parâmetro `_l2Gas` é a quantidade de gás da L2 que a transação pode gastar. +[Até um certo limite (alto), isso é gratuito](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2), então, a menos que o contrato ERC-20 faça algo muito estranho durante a cunhagem, não deve ser um problema. +Esta função cuida do cenário comum, em que um usuário transfere ativos por ponte para o mesmo endereço em uma blockchain diferente. ```solidity /** - * @dev deposit an amount of ERC20 to a recipient's balance on L2. - * @param _l1Token Address of the L1 ERC20 we are depositing - * @param _l2Token Address of the L1 respective L2 ERC20 - * @param _to L2 address to credit the withdrawal to. - * @param _amount Amount of the ERC20 to deposit. - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev deposita uma quantia de ERC20 no saldo de um destinatário na L2. + * @param _l1Token Endereço do ERC20 da L1 que estamos depositando + * @param _l2Token Endereço do respectivo ERC20 da L2 + * @param _to endereço da L2 para creditar a retirada. + * @param _amount Quantia do ERC20 a ser depositada. + * @param _l2Gas Limite de gás necessário para completar o depósito na L2. + * @param _data Dados opcionais para encaminhar para a L2. Estes dados são fornecidos + * apenas como uma conveniência para contratos externos. Além de impor um comprimento + * máximo, estes contratos não fornecem garantias sobre seu conteúdo. */ function depositERC20To( address _l1Token, @@ -183,26 +195,26 @@ O parâmetro `_l2Gas` é a quantidade de gas L2 que a transação tem permissão ) external; ``` -Esta função é quase idêntica a `depositERC20`, mas ela deixa você enviar o ERC-20 para diferentes endereços. +Esta função é quase idêntica a `depositERC20`, mas permite que você envie o ERC-20 para um endereço diferente. ```solidity /************************* - * Cross-chain Functions * + * Funções entre cadeias * *************************/ /** - * @dev Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the - * L1 ERC20 token. - * This call will fail if the initialized withdrawal from L2 has not been finalized. + * @dev Completa uma retirada da L2 para a L1 e credita fundos no saldo do destinatário do + * token ERC20 da L1. + * Esta chamada falhará se a retirada iniciada da L2 não tiver sido finalizada. * - * @param _l1Token Address of L1 token to finalizeWithdrawal for. - * @param _l2Token Address of L2 token where withdrawal was initiated. - * @param _from L2 address initiating the transfer. - * @param _to L1 address to credit the withdrawal to. - * @param _amount Amount of the ERC20 to deposit. - * @param _data Data provided by the sender on L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @param _l1Token Endereço do token da L1 para o qual finalizeWithdrawal será executado. + * @param _l2Token Endereço do token da L2 onde a retirada foi iniciada. + * @param _from Endereço da L2 que iniciou a transferência. + * @param _to Endereço da L1 para creditar a retirada. + * @param _amount Quantia do ERC20 a ser depositada. + * @param _data Dados fornecidos pelo remetente na L2. Estes dados são fornecidos + * apenas como uma conveniência para contratos externos. Além de impor um comprimento + * máximo, estes contratos não fornecem garantias sobre seu conteúdo. */ function finalizeERC20Withdrawal( address _l1Token, @@ -215,16 +227,20 @@ Esta função é quase idêntica a `depositERC20`, mas ela deixa você enviar o } ``` -Saques (e outras mensagens de L2 para L1) na Optimism é um processo em duas etapas: +As retiradas (e outras mensagens da L2 para a L1) no Optimism são um processo de duas etapas: -1. Uma transação inicial no L2. -2. Uma transação de finalização ou de reclamação na L1. Esta transação precisa acontecer depois do [período de desafio de falha](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) para a transação L2 terminar. +1. Uma transação de iniciação na L2. +2. Uma transação de finalização ou de resgate na L1. + Essa transação precisa acontecer após o término do [período de contestação de falhas](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) para a transação da L2. ### IL1StandardBridge {#il1standardbridge} -[Esta interface é definida aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol). Este arquivo contém definições de evento e função para ETH. Estas definições são muito similares com aquelas definidas em `IL1ERC20Bridge` acima para ERC-20. +[Esta interface é definida aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol). +Este arquivo contém definições de evento e função para ETH. +Essas definições são muito semelhantes às definidas em `IL1ERC20Bridge` acima para ERC-20. -A ponte interface é dividida entre dois arquivos, porque alguns tokens ERC-20 requerem processamento customizado e não podem ser manipulados pela ponte padrão. Dessa maneira a ponte customizada que manipula este token pode implementar `IL1ERC20Bridge` e não ter que também fazer a ponte ETH. +A interface da ponte é dividida em dois arquivos porque alguns tokens ERC-20 exigem processamento personalizado e não podem ser tratados pela ponte padrão. +Dessa forma, a ponte personalizada que lida com esse token pode implementar `IL1ERC20Bridge` e não precisar também transferir ETH por ponte. ```solidity // SPDX-License-Identifier: MIT @@ -237,7 +253,7 @@ import "./IL1ERC20Bridge.sol"; */ interface IL1StandardBridge is IL1ERC20Bridge { /********** - * Events * + * Eventos * **********/ event ETHDepositInitiated( address indexed _from, @@ -247,7 +263,8 @@ interface IL1StandardBridge is IL1ERC20Bridge { ); ``` -Este evento é praticamente idêntico à versão ERC-20 (`ERC20DepositInitiated`), exceto por não ter os endereços de token L1 e L2. O mesmo é verdade para outros eventos e funções. +Este evento é quase idêntico à versão ERC-20 (`ERC20DepositInitiated`), exceto que não tem os endereços de token da L1 e da L2. +O mesmo se aplica aos outros eventos e funções. ```solidity event ETHWithdrawalFinalized( @@ -257,11 +274,11 @@ Este evento é praticamente idêntico à versão ERC-20 (`ERC20DepositInitiated` ); /******************** - * Public Functions * + * Funções Públicas * ********************/ /** - * @dev Deposit an amount of the ETH to the caller's balance on L2. + * @dev Deposita uma quantia de ETH no saldo do chamador na L2. . . . @@ -269,7 +286,7 @@ Este evento é praticamente idêntico à versão ERC-20 (`ERC20DepositInitiated` function depositETH(uint32 _l2Gas, bytes calldata _data) external payable; /** - * @dev Deposit an amount of ETH to a recipient's balance on L2. + * @dev Deposita uma quantia de ETH no saldo de um destinatário na L2. . . . @@ -281,13 +298,13 @@ Este evento é praticamente idêntico à versão ERC-20 (`ERC20DepositInitiated` ) external payable; /************************* - * Cross-chain Functions * + * Funções entre cadeias * *************************/ /** - * @dev Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the - * L1 ETH token. Since only the xDomainMessenger can call this function, it will never be called - * before the withdrawal is finalized. + * @dev Completa uma retirada da L2 para a L1 e credita os fundos no saldo do destinatário do + * token ETH da L1. Como apenas o xDomainMessenger pode chamar esta função, ela nunca será chamada + * antes da finalização da retirada. . . . @@ -303,83 +320,87 @@ Este evento é praticamente idêntico à versão ERC-20 (`ERC20DepositInitiated` ### CrossDomainEnabled {#crossdomainenabled} -[Este contrato](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol) é herdado por ambas pontes ([L1](#the-l1-bridge-contract) e [L2](#the-l2-bridge-contract)) para enviar mensagens para a outra camada. +[Este contrato](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol) é herdado por ambas as pontes ([L1](#the-l1-bridge-contract) e [L2](#the-l2-bridge-contract)) para enviar mensagens para a outra camada. ```solidity // SPDX-License-Identifier: MIT pragma solidity >0.5.0 <0.9.0; -/* Interface Imports */ +/* Importações de Interface */ import { ICrossDomainMessenger } from "./ICrossDomainMessenger.sol"; ``` -[Esta interface](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) mostra ao contrato como enviar mensagens para a outra camada, usando o mensageiro entre domínios. Este mensageiro entre domínios é todo um outro sistema, e merece um artigo próprio, que espero escrever no futuro. +[Esta interface](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) informa ao contrato como enviar mensagens para a outra camada, usando o mensageiro entre domínios. +Este mensageiro entre domínios é um sistema completamente diferente, e merece seu próprio artigo, que espero escrever no futuro. ```solidity /** * @title CrossDomainEnabled - * @dev Helper contract for contracts performing cross-domain communications + * @dev Contrato auxiliar para contratos que realizam comunicações entre domínios * - * Compiler used: defined by inheriting contract + * Compilador usado: definido pelo contrato herdado */ contract CrossDomainEnabled { /************* - * Variables * + * Variáveis * *************/ - // Messenger contract used to send and receive messages from the other domain. + // Contrato de mensageiro usado para enviar e receber mensagens do outro domínio. address public messenger; /*************** - * Constructor * + * Construtor * ***************/ /** - * @param _messenger Address of the CrossDomainMessenger on the current layer. + * @param _messenger Endereço do CrossDomainMessenger na camada atual. */ constructor(address _messenger) { messenger = _messenger; } ``` -O único parâmetro que o contrato precisa saber é o endereço do mensageiro entre domínios nessa camada. Este parâmetro é configurado uma vez, no construtor, e nunca muda. +O único parâmetro que o contrato precisa saber é o endereço do mensageiro entre domínios nessa camada. +Este parâmetro é definido uma vez, no construtor, e nunca muda. ```solidity /********************** - * Function Modifiers * + * Modificadores de Função * **********************/ /** - * Enforces that the modified function is only callable by a specific cross-domain account. - * @param _sourceDomainAccount The only account on the originating domain which is - * authenticated to call this function. + * Garante que a função modificada só pode ser chamada por uma conta específica de outro domínio. + * @param _sourceDomainAccount A única conta no domínio de origem que está + * autenticada para chamar esta função. */ modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) { ``` -O mensageiro entre domínios é acessível por qualquer contrato na blockchain onde estiver rodando (seja Ethereum mainnet ou Optimism). Mas nós precisamos da ponte em cada lado para _apenas_ confiar em certas mensagens se eles vierem da ponte do outro lado. +O sistema de mensagens entre domínios é acessível por qualquer contrato na blockchain em que está sendo executado (seja a Rede Principal da Ethereum ou o Optimism). +Mas precisamos que a ponte de cada lado confie _apenas_ em certas mensagens se elas vierem da ponte do outro lado. ```solidity require( msg.sender == address(getCrossDomainMessenger()), - "OVM_XCHAIN: messenger contract unauthenticated" + "OVM_XCHAIN: contrato de mensageiro não autenticado" ); ``` -Somente mensagens do mensageiro entre domínios apropriado (`messenger`, como você vê abaixo) pode ser confiado. +Apenas mensagens do mensageiro entre domínios apropriado (`messenger`, como você verá abaixo) são confiáveis. ```solidity require( getCrossDomainMessenger().xDomainMessageSender() == _sourceDomainAccount, - "OVM_XCHAIN: wrong sender of cross-domain message" + "OVM_XCHAIN: remetente incorreto da mensagem entre domínios" ); ``` -A maneira que o mensageiro entre domínios fornece o endereço que enviou uma mensagem com a outra camada é [a função `.xDomainMessageSender()`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128). Enquanto ele for chamado na transação que foi iniciada pela mensagem, ele pode fornecer esta informação. +A forma como o mensageiro entre domínios fornece o endereço que enviou uma mensagem para a outra camada é através da [função `.xDomainMessageSender()`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128). +Desde que seja chamada na transação que foi iniciada pela mensagem, ela pode fornecer esta informação. -Nós precisamos nos certificar que a mensagem que nós recebemos veio da outra ponte. +Precisamos ter certeza de que a mensagem que recebemos veio da outra ponte. ```solidity @@ -387,29 +408,30 @@ Nós precisamos nos certificar que a mensagem que nós recebemos veio da outra p } /********************** - * Internal Functions * + * Funções Internas * **********************/ /** - * Gets the messenger, usually from storage. This function is exposed in case a child contract - * needs to override. - * @return The address of the cross-domain messenger contract which should be used. + * Obtém o mensageiro, geralmente do armazenamento. Esta função é exposta caso um contrato filho + * precise substituí-la. + * @return O endereço do contrato do mensageiro entre domínios que deve ser usado. */ function getCrossDomainMessenger() internal virtual returns (ICrossDomainMessenger) { return ICrossDomainMessenger(messenger); } ``` -Esta função retorna o mensageiro entre domínios. Nós usamos uma função ao invés da variável `messenger` para permitir contratos que herdam deste para usar um algoritmo para especificar qual mensageiro entre domínios usar. +Esta função retorna o mensageiro entre domínios. +Usamos uma função em vez da variável `messenger` para permitir que contratos que herdam deste usem um algoritmo para especificar qual mensageiro entre domínios usar. ```solidity /** - * Sends a message to an account on another domain - * @param _crossDomainTarget The intended recipient on the destination domain - * @param _message The data to send to the target (usually calldata to a function with + * Envia uma mensagem para uma conta em outro domínio + * @param _crossDomainTarget O destinatário pretendido no domínio de destino + * @param _message Os dados a serem enviados para o destino (geralmente calldata para uma função com * `onlyFromCrossDomainAccount()`) - * @param _gasLimit The gasLimit for the receipt of the message on the target domain. + * @param _gasLimit O gasLimit para o recebimento da mensagem no domínio de destino. */ function sendCrossDomainMessage( address _crossDomainTarget, @@ -417,17 +439,18 @@ Esta função retorna o mensageiro entre domínios. Nós usamos uma função ao bytes memory _message ``` -Finalmente, a função que envia a mensagem para a outra camada. +Finalmente, a função que envia uma mensagem para a outra camada. ```solidity ) internal { // slither-disable-next-line reentrancy-events, reentrancy-benign ``` -[Slither](https://github.com/crytic/slither)é um analisador estático que a Optimism roda em cada contrato para procurar por vulnerabilidades e outros problemas em potencial. Nesse caso, as seguintes linhas disparam duas vulnerabilidades: +[Slither](https://github.com/crytic/slither) é um analisador estático que o Optimism executa em cada contrato para procurar por vulnerabilidades e outros problemas em potencial. +Nesse caso, a linha seguinte aciona duas vulnerabilidades: 1. [Eventos de reentrância](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3) -2. [Reentrância Benigna](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2) +2. [Reentrância benigna](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2) ```solidity getCrossDomainMessenger().sendMessage(_crossDomainTarget, _message, _gasLimit); @@ -435,9 +458,9 @@ Finalmente, a função que envia a mensagem para a outra camada. } ``` -Neste caso nós não estamos preocupados sobre reentrância. Nós sabemos que `getCrossDomainMessenger()` returna um endereço confiável, mesmo se Slither não tem como saber isso. +Neste caso, não estamos preocupados com a reentrância, pois sabemos que `getCrossDomainMessenger()` retorna um endereço confiável, mesmo que o Slither não tenha como saber disso. -### O contrato da ponte L1 {#the-l1-bridge-contract} +### O contrato da ponte da L1 {#the-l1-bridge-contract} [O código-fonte para este contrato está aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol). @@ -446,10 +469,11 @@ Neste caso nós não estamos preocupados sobre reentrância. Nós sabemos que `g pragma solidity ^0.8.9; ``` -A interface pode ser parte de outros contratos, então eles têm de suportar uma larga faixa de versões de Solidity. Mas a ponte por ela mesma é o nosso contrato, e nós podemos ser estritos sobre qual versão Solidity ela usa. +As interfaces podem fazer parte de outros contratos, por isso precisam suportar uma ampla gama de versões do Solidity. +Mas a ponte em si é nosso contrato, e podemos ser rigorosos sobre qual versão do Solidity ela usa. ```solidity -/* Interface Imports */ +/* Importações de Interface */ import { IL1StandardBridge } from "./IL1StandardBridge.sol"; import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol"; ``` @@ -460,118 +484,134 @@ import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol"; import { IL2ERC20Bridge } from "../../L2/messaging/IL2ERC20Bridge.sol"; ``` -[Esta interface](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) nos deixa criar mensagens para controlar a ponte padrão em L2. +[Esta interface](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) nos permite criar mensagens para controlar a ponte padrão na L2. ```solidity import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; ``` -[Esta interface](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) nos deixa controlar contratos ERC-20. [Você pode ler mais sobre ela aqui](/developers/tutorials/erc20-annotated-code/#the-interface). +[Esta interface](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) nos permite controlar contratos ERC-20. +[Você pode ler mais sobre isso aqui](/developers/tutorials/erc20-annotated-code/#the-interface). ```solidity -/* Library Imports */ +/* Importações de Biblioteca */ import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol"; ``` -[Como explicado acima](#crossdomainenabled), este contrato é usado para mensageria entre camadas. +[Como explicado acima](#crossdomainenabled), este contrato é usado para mensagens entre camadas. ```solidity import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol"; ``` -[`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) tem os endereços dos contratos L2 que sempre tem o mesmo endereço. Isto inclui a ponte padrão em L2. +`Lib_PredeployAddresses` (https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) tem os endereços para os contratos da L2 que sempre têm o mesmo endereço. Isso inclui a ponte padrão na L2. ```solidity import { Address } from "@openzeppelin/contracts/utils/Address.sol"; ``` -[Utilitários de endereços OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol). Ele é usado para distinguir entre endereços de contrato e aqueles pertencentes a contas de propriedade externa (EOA). +[Utilitários de Endereço do OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol). É usado para distinguir entre endereços de contrato e aqueles pertencentes a contas de propriedade externa (EOA). -Note que isto não é a solução perfeita, porque não há como distinguir entre chamadas diretas e chamadas feitas de um construtor de contrato, mas pelo menos isto nos deixa identificar e evitar alguns erros comuns de usuário. +Note que esta não é uma solução perfeita, porque não há como distinguir entre chamadas diretas e chamadas feitas a partir do construtor de um contrato, mas pelo menos isso nos permite identificar e prevenir alguns erros comuns de usuários. ```solidity import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol"; ``` -[O padrão ERC-20 ](https://eips.ethereum.org/EIPS/eip-20) suporta duas maneiras para um contrato reportar falha: +[O padrão ERC-20](https://eips.ethereum.org/EIPS/eip-20) suporta duas maneiras para um contrato relatar falhas: -1. Revert -2. Return `false` +1. Reverter +2. Retornar `false` -Gerenciar ambos casos faria nosso código mais complicado, então ao invés disso, usamos [OpenZeppelin `SafeERC20`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol), que garante [ que todas as falhas resultem num revert](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96). +Lidar com ambos os casos tornaria nosso código mais complicado, então, em vez disso, usamos o [`SafeERC20` do OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol), que garante que [todas as falhas resultem em uma reversão](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96). ```solidity /** * @title L1StandardBridge - * @dev The L1 ETH and ERC20 Bridge is a contract which stores deposited L1 funds and standard - * tokens that are in use on L2. It synchronizes a corresponding L2 Bridge, informing it of deposits - * and listening to it for newly finalized withdrawals. + * @dev A Ponte de ETH e ERC20 da L1 é um contrato que armazena fundos depositados da L1 e tokens padrão + * que estão em uso na L2. Ela sincroniza uma Ponte da L2 correspondente, informando-a sobre depósitos + * e escutando-a para novas retiradas finalizadas. * */ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { using SafeERC20 for IERC20; ``` -Esta linha é como especificamos para usar o wrapper `SafeERC20` cada vez que nós usamos a interface `IERC20`. +Esta linha é como especificamos o uso do wrapper `SafeERC20` toda vez que usamos a interface `IERC20`. ```solidity /******************************** - * External Contract References * + * Referências de Contratos Externos * ********************************/ address public l2TokenBridge; ``` -O endereço de [L2StandardBridge](#the-l2-bridge-contract). +O endereço do [L2StandardBridge](#the-l2-bridge-contract). ```solidity - // Maps L1 token to L2 token to balance of the L1 token deposited + // Mapeia o token da L1 para o token da L2 para o saldo do token da L1 depositado mapping(address => mapping(address => uint256)) public deposits; ``` -Um [mapeamento](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) em dobro como este é a maneira de você definir uma [array esparsa bi-dimensional](https://en.wikipedia.org/wiki/Sparse_matrix). Valores nesta estrutura de dados são identificados como `deposit[L1 token addr][L2 token addr]`. O valor padrão é zero. Somente células que são configuradas para um valor diferente são escritas no storage. +Um [mapeamento](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) duplo como este é a maneira de definir uma [matriz esparsa bidimensional](https://en.wikipedia.org/wiki/Sparse_matrix). +Os valores nesta estrutura de dados são identificados como `deposit[L1 token addr][L2 token addr]`. +O valor padrão é zero. +Apenas as células que são definidas com um valor diferente são escritas no armazenamento. ```solidity /*************** - * Constructor * + * Construtor * ***************/ - // This contract lives behind a proxy, so the constructor parameters will go unused. + // Este contrato vive por trás de um proxy, então os parâmetros do construtor não serão utilizados. constructor() CrossDomainEnabled(address(0)) {} ``` -Para querer ser capaz de atualizar este contrato sem ter que copiar todas as variáveis no storage. Para fazer isso, nós usamos um [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy), um contrato que usa [`delegatecall`](https://solidity-by-example.org/delegatecall/) para transferir chamadas para um contato separado cujo endereço é armazenado pelo contrato proxy (quando você atualiza, você diz ao proxy para mudar o endereço). Quando você usa `delegatecall` o storage permanece com o valor do contrato _chamador_, então os valores de todas as variáveis de estado do contrato não são afetadas. +Para poder atualizar este contrato sem ter que copiar todas as variáveis no armazenamento. +Para fazer isso, usamos um [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy), um contrato que usa [`delegatecall`](https://solidity-by-example.org/delegatecall/) para transferir chamadas para um contrato separado cujo endereço é armazenado pelo contrato proxy (quando você atualiza, você diz ao proxy para mudar esse endereço). +Quando você usa `delegatecall`, o armazenamento permanece o armazenamento do contrato _chamador_, então os valores de todas as variáveis de estado do contrato não são afetados. -Um efeito deste padrão é que o storage do contrato que é _chamado_ pelo `delegatecall` não é usado, e portanto os valores do construtor passados para ele não importam. Esta é a razão pela qual nós podemos fornecer um valor sem sentido para o construtor `CrossDomainEnabled`. É também a razão que a inicialização abaixo é separada do construtor. +Um efeito deste padrão é que o armazenamento do contrato que é o _chamado_ de `delegatecall` não é usado e, portanto, os valores do construtor passados para ele não importam. +Esta é a razão pela qual podemos fornecer um valor sem sentido para o construtor `CrossDomainEnabled`. +É também a razão pela qual a inicialização abaixo é separada do construtor. ```solidity /****************** - * Initialization * + * Inicialização * ******************/ /** - * @param _l1messenger L1 Messenger address being used for cross-chain communications. - * @param _l2TokenBridge L2 standard bridge address. + * @param _l1messenger Endereço do Mensageiro da L1 sendo usado para comunicações entre cadeias. + * @param _l2TokenBridge Endereço da ponte padrão da L2. */ // slither-disable-next-line external-function ``` -Este [teste Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external) identifica funções que não são chamadas do código do contrato e poderiam portanto serem declaradas `external` ao invés de `public`. As funções de custo de gas `external` podem ser menores, porque elas podem ser fornecidas com parâmetros no calldata. Funções declaradas `public` têm de ser acessíveis de dentro do contrato. Contratos não podem modificar seus próprios calldata, então os parâmetros têm que estar na memória. Quando esta função é chamada externamente, é necessário copiar o calldata para a memória, que custa gas. Nesse caso a função é chamada somente uma vez, então a ineficiência não importa para nós. +Este [teste do Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external) identifica funções que não são chamadas do código do contrato e que, portanto, poderiam ser declaradas `external` em vez de `public`. +O custo de gás de funções `external` pode ser menor, porque elas podem receber parâmetros no calldata. +Funções declaradas como `public` precisam ser acessíveis de dentro do contrato. +Contratos não podem modificar seu próprio calldata, então os parâmetros precisam estar na memória. +Quando tal função é chamada externamente, é necessário copiar o calldata para a memória, o que custa gás. +Neste caso, a função é chamada apenas uma vez, então a ineficiência não importa para nós. ```solidity function initialize(address _l1messenger, address _l2TokenBridge) public { - require(messenger == address(0), "Contract has already been initialized."); + require(messenger == address(0), "O contrato já foi inicializado."); ``` -A função `initialize` deve ser chamada só uma vez. Se o endereço do mensageiro entre domínios L1 ou se a ponte do token L2 mudam, nós criamos um novo proxy e uma nova ponte que chama ele. Isto é improvável de acontecer, exceto quando o sistema inteiro é atualizado, uma ocorrência muito rara. +A função `initialize` deve ser chamada apenas uma vez. +Se o endereço do mensageiro entre domínios da L1 ou da ponte de token da L2 mudar, criamos um novo proxy e uma nova ponte que o chama. +Isso é improvável de acontecer, exceto quando todo o sistema é atualizado, uma ocorrência muito rara. -Note que esta função não tem nenhum mecanismo que restringe _quem_ pode chamá-la. Isto significa que em teoria um atacante poderia esperar até que nós implantassemos o proxy e a primeira versão da ponte e então [front-run](https://solidity-by-example.org/hacks/front-running/)para pegar a função `initialize` antes que o usuário legítimo o faça. Mas há dois métodos para evitar isso: +Note que esta função não tem nenhum mecanismo que restringe _quem_ pode chamá-la. +Isso significa que, em teoria, um invasor poderia esperar até que implantemos o proxy e a primeira versão da ponte e, em seguida, usar [front-run](https://solidity-by-example.org/hacks/front-running/) para chegar à função `initialize` antes que o usuário legítimo o faça. Mas há dois métodos para evitar isso: -1. Se o contrato for implantado não diretamente por um EOA mas [em uma transação que tem outro contrato criando eles,](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595) o processo inteiro pode ser atômico, e finalizar antes que qualquer outra transação seja executada. -2. Se a chamada legítima para `initialize` falhar, é sempre possível ignorar o proxy recém-criado e fazer a ponte para criar outros novos. +1. Se os contratos forem implantados não diretamente por uma EOA, mas [em uma transação que tem outro contrato para criá-los](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595), todo o processo pode ser atômico e terminar antes que qualquer outra transação seja executada. +2. Se a chamada legítima para `initialize` falhar, é sempre possível ignorar o proxy e a ponte recém-criados e criar novos. ```solidity messenger = _l1messenger; @@ -579,20 +619,20 @@ Note que esta função não tem nenhum mecanismo que restringe _quem_ pode cham } ``` -Estes são dois parâmetros que a ponte precisa conhecer. +Estes são os dois parâmetros que a ponte precisa conhecer. ```solidity /************** - * Depositing * + * Depósito * **************/ - /** @dev Modifier requiring sender to be EOA. This check could be bypassed by a malicious - * contract via initcode, but it takes care of the user error we want to avoid. + /** @dev Modificador que exige que o remetente seja uma EOA. Esta verificação poderia ser contornada por um + * contrato malicioso via initcode, mas cuida do erro de usuário que queremos evitar. */ modifier onlyEOA() { - // Used to stop deposits from contracts (avoid accidentally lost tokens) - require(!Address.isContract(msg.sender), "Account not EOA"); + // Usado para impedir depósitos de contratos (evita a perda acidental de tokens) + require(!Address.isContract(msg.sender), "Conta não é EOA"); _; } ``` @@ -601,17 +641,18 @@ Estes são dois parâmetros que a ponte precisa conhecer. ```solidity /** - * @dev This function can be called with no data - * to deposit an amount of ETH to the caller's balance on L2. - * Since the receive function doesn't take data, a conservative - * default amount is forwarded to L2. + * @dev Esta função pode ser chamada sem dados + * para depositar uma quantia de ETH no saldo do chamador na L2. + * Como a função receive não aceita dados, uma quantia + * padrão conservadora é encaminhada para a L2. */ receive() external payable onlyEOA { _initiateETHDeposit(msg.sender, msg.sender, 200_000, bytes("")); } ``` -A função existe para finalidade de testes. Note que ela não aparece nas definições de interface - não é para uso corrente. +A função existe para finalidade de testes. +Note que ela não aparece nas definições de interface - não é para uso corrente. ```solidity /** @@ -633,18 +674,18 @@ A função existe para finalidade de testes. Note que ela não aparece nas defin } ``` -Estas duas funções são wrappers em volta do `_initiateETHDeposit`, a função que manipula o depósito do ETH real. +Estas duas funções são wrappers em volta do `_initiateETHDeposit`, a função que lida com o depósito real de ETH. ```solidity /** - * @dev Performs the logic for deposits by storing the ETH and informing the L2 ETH Gateway of - * the deposit. - * @param _from Account to pull the deposit from on L1. - * @param _to Account to give the deposit to on L2. - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev Executa a lógica para depósitos armazenando o ETH e informando o Gateway de ETH da L2 sobre + * o depósito. + * @param _from Conta da qual o depósito será retirado na L1. + * @param _to Conta para a qual o depósito será creditado na L2. + * @param _l2Gas Limite de gás necessário para completar o depósito na L2. + * @param _data Dados opcionais para encaminhar para a L2. Estes dados são fornecidos + * apenas como uma conveniência para contratos externos. Além de impor um comprimento + * máximo, estes contratos não fornecem garantias sobre seu conteúdo. */ function _initiateETHDeposit( address _from, @@ -652,11 +693,14 @@ Estas duas funções são wrappers em volta do `_initiateETHDeposit`, a função uint32 _l2Gas, bytes memory _data ) internal { - // Construct calldata for finalizeDeposit call + // Constrói o calldata para a chamada finalizeDeposit bytes memory message = abi.encodeWithSelector( ``` -A maneira que mensagens entre domínios trabalham é que o contrato de destino é chamado com a mensagem como o seu calldata. Contratos Solidity sempre interpretam seu calldata de acordo com [a especificação ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html). A função Solidity [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) cria este calldata. +A maneira como as mensagens entre domínios funcionam é que o contrato de destino é chamado com a mensagem como seu calldata. +Os contratos Solidity sempre interpretam seu calldata de acordo com +[as especificações da ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html). +A função do Solidity [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) cria esse calldata. ```solidity IL2ERC20Bridge.finalizeDeposit.selector, @@ -669,24 +713,24 @@ A maneira que mensagens entre domínios trabalham é que o contrato de destino ); ``` -A mensagem aqui é chamar [a função `finalizeDeposit`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148) com estes parâmetros: +A mensagem aqui é para chamar [a função `finalizeDeposit`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148) com estes parâmetros: -| Parâmetro | Valores | Significado | -| ----------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | -| \_l1Token | address(0) | Valor especial para o ETH (que não é um token ERC-20) na L1 | -| \_l2Token | Lib_PredeployAddresses.OVM_ETH | O contrato L2 que gerencia ETH na Optimism, `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (este contrato é apenas para uso interno da Optimism) | -| \_from | \_from | Os endereços na L1 que enviam o ETH | -| \_to | \_to | O endereço na L2 que recebe o ETH | -| amount | msg.value | Quantidade de wei enviado (que já foi enviado para a ponte) | -| \_data | \_data | Dados adicionais para anexar ao depósito | +| Parâmetro | Valor | Significado | +| ------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| \_l1Token | address(0) | Valor especial para representar ETH (que não é um token ERC-20) na L1 | +| \_l2Token | Lib_PredeployAddresses.OVM_ETH | O contrato da L2 que gerencia ETH no Optimism, `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (este contrato é para uso interno do Optimism apenas) | +| \_from | \_from | O endereço na L1 que envia o ETH | +| \_to | \_to | O endereço na L2 que recebe o ETH | +| quantidade | msg.value | Quantidade de wei enviado (que já foi enviado para a ponte) | +| \_data | \_data | Dados adicionais para anexar ao depósito | ```solidity - // Send calldata into L2 + // Envia o calldata para a L2 // slither-disable-next-line reentrancy-events sendCrossDomainMessage(l2TokenBridge, _l2Gas, message); ``` -Enviar a mensagem através de mensageiro entre domínios. +Envia a mensagem através do mensageiro entre domínios. ```solidity // slither-disable-next-line reentrancy-events @@ -694,16 +738,16 @@ Enviar a mensagem através de mensageiro entre domínios. } ``` -Emitir um evento para informar qualquer aplicação descentralizada que escuta esta transferência. +Emite um evento para informar qualquer aplicativo descentralizado que escuta esta transferência. ```solidity /** * @inheritdoc IL1ERC20Bridge */ function depositERC20( - . - . - . + . + . + . ) external virtual onlyEOA { _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data); } @@ -712,9 +756,9 @@ Emitir um evento para informar qualquer aplicação descentralizada que escuta e * @inheritdoc IL1ERC20Bridge */ function depositERC20To( - . - . - . + . + . + . ) external virtual { _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, _to, _amount, _l2Gas, _data); } @@ -724,18 +768,18 @@ Estas duas funções são wrappers em volta do `_initiateERC20Deposit`, a funç ```solidity /** - * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) + * @dev Executa a lógica para depósitos, informando o contrato do Token Depositado da L2 + * sobre o depósito e chamando um manipulador para bloquear os fundos da L1. (ex: transferFrom) * - * @param _l1Token Address of the L1 ERC20 we are depositing - * @param _l2Token Address of the L1 respective L2 ERC20 - * @param _from Account to pull the deposit from on L1 - * @param _to Account to give the deposit to on L2 - * @param _amount Amount of the ERC20 to deposit. - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @param _l1Token Endereço do ERC20 da L1 que estamos depositando + * @param _l2Token Endereço do respectivo ERC20 da L2 + * @param _from Conta da qual o depósito será retirado na L1 + * @param _to Conta para a qual o depósito será creditado na L2 + * @param _amount Quantia do ERC20 a ser depositada. + * @param _l2Gas Limite de gás necessário para completar o depósito na L2. + * @param _data Dados opcionais para encaminhar para a L2. Estes dados são fornecidos + * apenas como uma conveniência para contratos externos. Além de impor um comprimento + * máximo, estes contratos não fornecem garantias sobre seu conteúdo. */ function _initiateERC20Deposit( address _l1Token, @@ -748,26 +792,29 @@ Estas duas funções são wrappers em volta do `_initiateERC20Deposit`, a funç ) internal { ``` -Esta função é similiar a `_initiateETHDeposit` acima, com algumas poucas diferenças importantes. A primeira diferença é que esta função recebe o endereço de token e a quantia a transferir como parâmetros. No caso do ETH, a chamada para a ponte já inclui a transferência do ativo para a conta da ponte (`msg.value`). +Esta função é semelhante a `_initiateETHDeposit` acima, com algumas diferenças importantes. +A primeira diferença é que esta função recebe os endereços de token e a quantia a ser transferida como parâmetros. +No caso do ETH, a chamada para a ponte já inclui a transferência do ativo para a conta da ponte (`msg.value`). ```solidity - // When a deposit is initiated on L1, the L1 Bridge transfers the funds to itself for future - // withdrawals. safeTransferFrom also checks if the contract has code, so this will fail if - // _from is an EOA or address(0). + // Quando um depósito é iniciado na L1, a Ponte da L1 transfere os fundos para si mesma para futuras + // retiradas. safeTransferFrom também verifica se o contrato tem código, então isso falhará se + // _from for uma EOA ou address(0). // slither-disable-next-line reentrancy-events, reentrancy-benign IERC20(_l1Token).safeTransferFrom(_from, address(this), _amount); ``` -Transferências de tokens ERC-20 seguem um processo diferente do ETH: +As transferências de token ERC-20 seguem um processo diferente do ETH: -1. O usuário (`_from`) dá uma permissão para a ponte para transferir os tokens apropriados. +1. O usuário (`_from`) concede uma autorização à ponte para transferir os tokens apropriados. 2. O usuário chama a ponte com o endereço do contrato do token, a quantia, etc. -3. A ponte transfere os tokens (para ela mesmo) como parte do processo de depósito. +3. A ponte transfere os tokens (para si mesma) como parte do processo de depósito. -O primeiro passo pode acontecer em uma transação separada das últimas duas. Entretanto, front-running não é um problema porque as duas funções que chamam `_initiateERC20Deposit` (`depositERC20` e `depositERC20To`) somente chamam essa função com `msg.sender` como parâmetro `_from`. +O primeiro passo pode acontecer em uma transação separada dos dois últimos. +No entanto, o front-running não é um problema porque as duas funções que chamam `_initiateERC20Deposit` (`depositERC20` e `depositERC20To`) só chamam esta função com `msg.sender` como o parâmetro `_from`. ```solidity - // Construct calldata for _l2Token.finalizeDeposit(_to, _amount) + // Constrói o calldata para _l2Token.finalizeDeposit(_to, _amount) bytes memory message = abi.encodeWithSelector( IL2ERC20Bridge.finalizeDeposit.selector, _l1Token, @@ -778,7 +825,7 @@ O primeiro passo pode acontecer em uma transação separada das últimas duas. E _data ); - // Send calldata into L2 + // Envia o calldata para a L2 // slither-disable-next-line reentrancy-events, reentrancy-benign sendCrossDomainMessage(l2TokenBridge, _l2Gas, message); @@ -786,7 +833,8 @@ O primeiro passo pode acontecer em uma transação separada das últimas duas. E deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] + _amount; ``` -Adicione a quantia depositada de tokens para a estrutura de dados `deposits`. Pode haver múltiplos endereços em L2 que correspondam ao mesmo token ERC-20 L1, portanto não é suficiente usar saldo de ponte de token ERC-20 L1 para rastrear os depósitos. +Adiciona a quantia depositada de tokens à estrutura de dados `deposits`. +Pode haver múltiplos endereços na L2 que correspondem ao mesmo token ERC-20 da L1, então não é suficiente usar o saldo da ponte do token ERC-20 da L1 para rastrear os depósitos. ```solidity @@ -795,7 +843,7 @@ Adicione a quantia depositada de tokens para a estrutura de dados `deposits`. Po } /************************* - * Cross-chain Functions * + * Funções entre cadeias * *************************/ /** @@ -808,29 +856,30 @@ Adicione a quantia depositada de tokens para a estrutura de dados `deposits`. Po bytes calldata _data ``` -A ponte L2 envia uma mensagem para o mensageiro entre domínios L2 que causa o mensageiro entre domínios L1 chamar esta função (uma vez que a [transação que finaliza a mensagem](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions) é submetida no L1, claro). +A ponte da L2 envia uma mensagem para o mensageiro entre domínios da L2, o que faz com que o mensageiro entre domínios da L1 chame esta função (uma vez que a [transação que finaliza a mensagem](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions) seja enviada na L1, é claro). ```solidity ) external onlyFromCrossDomainAccount(l2TokenBridge) { ``` -Certifique-se que isto é uma mensagem _legítima_, vinda do mensageiro entre domínios e originada com o token da ponte L2. Esta função é usada para retirar ETH da ponte, então nós temos que nos certificar que é somente chamada pelo chamador autorizado. +Certifique-se de que esta é uma mensagem _legítima_, vinda do mensageiro entre domínios e originada na ponte de tokens da L2. +Esta função é usada para retirar ETH da ponte, então temos que ter certeza de que ela só é chamada pelo chamador autorizado. ```solidity // slither-disable-next-line reentrancy-events (bool success, ) = _to.call{ value: _amount }(new bytes(0)); ``` -A maneira de transferir ETH é chamar o recebedor com a quantia de wei no `msg.value`. +A maneira de transferir ETH é chamar o destinatário com a quantia de wei no `msg.value`. ```solidity - require(success, "TransferHelper::safeTransferETH: ETH transfer failed"); + require(success, "TransferHelper::safeTransferETH: falha na transferência de ETH"); // slither-disable-next-line reentrancy-events emit ETHWithdrawalFinalized(_from, _to, _amount, _data); ``` -Emitir um evento sobre o saque. +Emite um evento sobre a retirada. ```solidity } @@ -848,17 +897,17 @@ Emitir um evento sobre o saque. ) external onlyFromCrossDomainAccount(l2TokenBridge) { ``` -Esta função é similar a `finalizeETHWithdrawal` acima, com as mudanças necessárias para os tokens ERC-20. +Esta função é semelhante a `finalizeETHWithdrawal` acima, com as alterações necessárias para tokens ERC-20. ```solidity deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] - _amount; ``` -Atualiza a estrutura de dados`deposits`. +Atualiza a estrutura de dados `deposits`. ```solidity - // When a withdrawal is finalized on L1, the L1 Bridge transfers the funds to the withdrawer + // Quando uma retirada é finalizada na L1, a Ponte da L1 transfere os fundos para o sacador // slither-disable-next-line reentrancy-events IERC20(_l1Token).safeTransfer(_to, _amount); @@ -868,28 +917,35 @@ Atualiza a estrutura de dados`deposits`. /***************************** - * Temporary - Migrating ETH * + * Temporário - Migrando ETH * *****************************/ /** - * @dev Adds ETH balance to the account. This is meant to allow for ETH - * to be migrated from an old gateway to a new gateway. - * NOTE: This is left for one upgrade only so we are able to receive the migrated ETH from the - * old contract + * @dev Adiciona saldo de ETH à conta. Isso serve para permitir que o ETH + * seja migrado de um gateway antigo para um novo gateway. + * OBS: Isso é deixado para apenas uma atualização, para que possamos receber o ETH migrado do + * contrato antigo */ function donateETH() external payable {} } ``` -Houve uma implementação anterior dessa ponte. Quando nos movemos da implementação para esta ponte, tivemos que mover todos os ativos. Tokens ERC-20 podem serem simplesmente movidos. Entretanto, para transferir ETH para um contrato, você precisa da aprovação do contrato, que é o que `donateETH` nos fornece. +Havia uma implementação anterior da ponte. +Quando mudamos da implementação anterior para esta, tivemos que mover todos os ativos. +Os tokens ERC-20 podem simplesmente ser movidos. +No entanto, para transferir ETH para um contrato, você precisa da aprovação desse contrato, que é o que `donateETH` nos fornece. ## Tokens ERC-20 na L2 {#erc-20-tokens-on-l2} -Para um token ERC-20 servir na ponte padrão, ele precisa permitir que a ponte padrão, e _somente_ a ponte padrão, cunhe token. Isto é necessário porque as pontes precisam garantir que o número de tokens circulando na Optimism é igual ao número de tokens travados dentro do contrato da ponte L1. Se houver tokens demais na L2, alguns usuários ficarão incapazes de usar a ponte de volta para os seus ativos para a L1. Ao invés de uma ponte confiável, nós iriamos essencialmente recriar [reserva fracionária bancária](https://www.investopedia.com/terms/f/fractionalreservebanking.asp). Se houver tokens demais em L1, alguns desses tokens estaria travados dentro do contrato da ponte para sempre, porque não há maneira de liberá-los sem queimar tokens L2. +Para um token ERC-20 se encaixar na ponte padrão, ele precisa permitir que a ponte padrão, e _apenas_ a ponte padrão, cunhe o token. +Isso é necessário porque as pontes precisam garantir que o número de tokens circulando no Optimism seja igual ao número de tokens bloqueados dentro do contrato da ponte da L1. +Se houver muitos tokens na L2, alguns usuários não conseguirão transferir seus ativos de volta para a L1 por meio da ponte. +Em vez de uma ponte confiável, estaríamos essencialmente recriando o [sistema de reservas fracionárias](https://www.investopedia.com/terms/f/fractionalreservebanking.asp). +Se houver tokens demais na L1, alguns desses tokens ficariam bloqueados dentro do contrato da ponte para sempre, porque não há como liberá-los sem queimar tokens da L2. ### IL2StandardERC20 {#il2standarderc20} -Cada token ERC-20 na L2 que usa a ponte padrão precisa fornecer [esta interface](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol), que tem as funções e eventos que a ponte padrão necessita. +Todo token ERC-20 na L2 que usa a ponte padrão precisa fornecer [esta interface](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol), que tem as funções e eventos de que a ponte padrão precisa. ```solidity // SPDX-License-Identifier: MIT @@ -898,20 +954,24 @@ pragma solidity ^0.8.9; import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; ``` -[A interface padrão ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) não inclui as funções `mint` e `burn`. Estes métodos não são necessários pelo [padrão ERC-20](https://eips.ethereum.org/EIPS/eip-20), que não deixa especificado os mecanismos para criar e destruir tokens. +[A interface padrão ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) não inclui as funções `mint` e `burn`. +Esses métodos não são exigidos pelo [padrão ERC-20](https://eips.ethereum.org/EIPS/eip-20), que não especifica os mecanismos para criar e destruir tokens. ```solidity import { IERC165 } from "@openzeppelin/contracts/utils/introspection/IERC165.sol"; ``` -[A interface ERC-165 ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol)é usada para especificar que funções um contrato fornece. [Você pode ler o padrão aqui](https://eips.ethereum.org/EIPS/eip-165). +[A interface ERC-165](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol) é usada para especificar quais funções um contrato fornece. +[Você pode ler o padrão aqui](https://eips.ethereum.org/EIPS/eip-165). ```solidity interface IL2StandardERC20 is IERC20, IERC165 { function l1Token() external returns (address); ``` -Esta função fornece o endereço do token L1 que usa a ponte para este contrato. Note que nós não temos uma função similar na direção oposta. Nós precisamos ser capazes de usar a ponte para qualquer token L1, independente se o suporte L2 foi planejado quando foi implementado ou não. +Esta função fornece o endereço do token da L1 que é transferido por ponte para este contrato. +Observe que não temos uma função semelhante na direção oposta. +Precisamos ser capazes de transferir por ponte qualquer token da L1, independentemente de o suporte à L2 ter sido planejado quando ele foi implementado ou não. ```solidity @@ -924,11 +984,13 @@ Esta função fornece o endereço do token L1 que usa a ponte para este contrato } ``` -Funções e eventos para cunhar (criar) e queimar (destruir) tokens. A ponte deveria ser a única entidade que pode rodar estas funções para garantir que o número de tokens esteja correto (igual ao número de tokens travados na L1). +Funções e eventos para cunhar (criar) e queimar (destruir) tokens. +A ponte deve ser a única entidade que pode executar essas funções para garantir que o número de tokens esteja correto (igual ao número de tokens bloqueados na L1). ### L2StandardERC20 {#L2StandardERC20} -[Essa é a nossa implementação da interface `IL2StandardERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol). A não ser que você precise de algum tipo de lógica customizada, você deveria usar esta. +[Esta é a nossa implementação da interface `IL2StandardERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol). +A menos que você precise de algum tipo de lógica personalizada, você deve usar esta. ```solidity // SPDX-License-Identifier: MIT @@ -937,7 +999,8 @@ pragma solidity ^0.8.9; import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; ``` -[O contrato ERC-20 OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). A Optimism não acredita em reinventar a roda, especialmente quando a roda é bem auditada e precisa ser estimada o suficiente para manter ativos. +[O contrato ERC-20 do OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). +O Optimism não acredita em reinventar a roda, especialmente quando a roda é bem auditada e precisa ser confiável o suficiente para guardar ativos. ```solidity import "./IL2StandardERC20.sol"; @@ -947,15 +1010,15 @@ contract L2StandardERC20 is IL2StandardERC20, ERC20 { address public l2Bridge; ``` -Há dois parâmetros de configuração adicionais que nós precisamos, e um ERC-20 normalmente não precisa. +Estes são os dois parâmetros de configuração adicionais que exigimos e que um ERC-20 normalmente não exige. ```solidity /** - * @param _l2Bridge Address of the L2 standard bridge. - * @param _l1Token Address of the corresponding L1 token. - * @param _name ERC20 name. - * @param _symbol ERC20 symbol. + * @param _l2Bridge Endereço da ponte padrão da L2. + * @param _l1Token Endereço do token correspondente da L1. + * @param _name Nome do ERC20. + * @param _symbol Símbolo do ERC20. */ constructor( address _l2Bridge, @@ -968,12 +1031,12 @@ Há dois parâmetros de configuração adicionais que nós precisamos, e um ERC- } ``` -Primeiro chame o construtor do contrato que nós herdamos (`ERC20(_name, _symbol)`) e então configure suas próprias variáveis. +Primeiro chame o construtor do contrato que herdamos (`ERC20(_name, _symbol)`) e depois defina nossas próprias variáveis. ```solidity modifier onlyL2Bridge() { - require(msg.sender == l2Bridge, "Only L2 Bridge can mint and burn"); + require(msg.sender == l2Bridge, "Apenas a Ponte da L2 pode cunhar e queimar"); _; } @@ -988,11 +1051,12 @@ Primeiro chame o construtor do contrato que nós herdamos (`ERC20(_name, _symbol } ``` -Essa é a maneira que o[ERC-165](https://eips.ethereum.org/EIPS/eip-165) funciona. Cada interface é um número de funções suportadas, como identificadas no [ou exclusivo](https://en.wikipedia.org/wiki/Exclusive_or) dos [seletores de funções ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) destas funções. +É assim que o [ERC-165](https://eips.ethereum.org/EIPS/eip-165) funciona. +Cada interface é um número de funções suportadas e é identificada como o [ou exclusivo](https://en.wikipedia.org/wiki/Exclusive_or) dos [seletores de função da ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) dessas funções. -A ponte L2 usa ERC-165 como checagem de sanidade para garantir que o contrato ERC-20 para o qual ela envia ativos é um `IL2StandardERC20`. +A ponte da L2 usa o ERC-165 como uma verificação de sanidade para garantir que o contrato ERC-20 para o qual envia ativos é um `IL2StandardERC20`. -**Note:** Não há nada para evitar contratos trapaceiros de fornecer falsas respostas para `supportsInterface`, portanto isto é um mecanismo de checagem de sanidade, _não_ um mecanismo de segurança. +**Observação:** Não há nada que impeça um contrato mal-intencionado de fornecer respostas falsas para `supportsInterface`, portanto, este é um mecanismo de verificação de sanidade, _não_ um mecanismo de segurança. ```solidity // slither-disable-next-line external-function @@ -1011,66 +1075,73 @@ A ponte L2 usa ERC-165 como checagem de sanidade para garantir que o contrato ER } ``` -Somente a ponte L2 pode cunhar e queimar ativos. +Apenas a ponte da L2 pode cunhar e queimar ativos. -`_mint` e `_burn` são na verdade definidos no [contrato ERC-20 OpenZeppelin](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn). Este contrato só não os expõem externamente, porque as condições para cunhar e queimar tokens são tão variadas como o número de maneiras de usar ERC-20. +`_mint` e `_burn` são, na verdade, definidos no [contrato ERC-20 da OpenZeppelin](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn). +Aquele contrato simplesmente não os expõe externamente, porque as condições para cunhar e queimar tokens são tão variadas quanto o número de maneiras de usar o ERC-20. -## Código da ponte L2 {#l2-bridge-code} +## Código da Ponte da L2 {#l2-bridge-code} -Este é o código que roda na ponte na Optimism. [A fonte deste contrato é aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol). +Este é o código que executa a ponte no Optimism. +[A fonte para este contrato está aqui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol). ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.9; -/* Interface Imports */ +/* Importações de Interface */ import { IL1StandardBridge } from "../../L1/messaging/IL1StandardBridge.sol"; import { IL1ERC20Bridge } from "../../L1/messaging/IL1ERC20Bridge.sol"; import { IL2ERC20Bridge } from "./IL2ERC20Bridge.sol"; ``` -A interface [IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) é muito similar ao [equivalente L1](#IL1ERC20Bridge) que nós vimos acima. Há duas diferenças significantes: +A interface [IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) é muito semelhante ao [equivalente da L1](#IL1ERC20Bridge) que vimos acima. +Há duas diferenças significativas: -1. Na L1 você inicia depósitos e finaliza retiradas. Aqui você inicia retiradas e finaliza depósitos. -2. Na L1 é necessário distinguir entre ETH e tokens ERC-20. Na L2 nós podemos usar as mesmas funções para ambos os casos porque internamente saldos ETH na Optimism são manipulados por um token ERC-20 com o endereço [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://optimistic.etherscan.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000). +1. Na L1, você inicia depósitos e finaliza retiradas. + Aqui, você inicia retiradas e finaliza depósitos. +2. Na L1, é necessário distinguir entre tokens ETH e ERC-20. + Na L2, podemos usar as mesmas funções para ambos, porque internamente os saldos de ETH no Optimism são tratados como um token ERC-20 com o endereço [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000). ```solidity -/* Library Imports */ +/* Importações de Biblioteca */ import { ERC165Checker } from "@openzeppelin/contracts/utils/introspection/ERC165Checker.sol"; import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol"; import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol"; -/* Contract Imports */ +/* Importações de Contrato */ import { IL2StandardERC20 } from "../../standards/IL2StandardERC20.sol"; /** * @title L2StandardBridge - * @dev The L2 Standard bridge is a contract which works together with the L1 Standard bridge to - * enable ETH and ERC20 transitions between L1 and L2. - * This contract acts as a minter for new tokens when it hears about deposits into the L1 Standard - * bridge. - * This contract also acts as a burner of the tokens intended for withdrawal, informing the L1 - * bridge to release L1 funds. + * @dev A ponte Padrão da L2 é um contrato que funciona em conjunto com a ponte Padrão da L1 para + * permitir transições de ETH e ERC20 entre L1 e L2. + * Este contrato atua como um cunhador para novos tokens quando ouve sobre depósitos na Ponte Padrão + * da L1. + * Este contrato também atua como um queimador dos tokens destinados à retirada, informando à ponte + * da L1 para liberar fundos da L1. */ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { /******************************** - * External Contract References * + * Referências de Contratos Externos * ********************************/ address public l1TokenBridge; ``` -Acompanhe o endereço da ponte L1. Observe que, em contraste com o equivalente L1, aqui _precisamos_ desta variável. O endereço da ponte L1 não é conhecido antecipadamente. +Acompanhe o endereço da ponte da L1. +Observe que, em contraste com o equivalente da L1, aqui _precisamos_ desta variável. +O endereço da ponte da L1 não é conhecido antecipadamente. ```solidity /*************** - * Constructor * + * Construtor * ***************/ /** - * @param _l2CrossDomainMessenger Cross-domain messenger used by this contract. - * @param _l1TokenBridge Address of the L1 bridge deployed to the main chain. + * @param _l2CrossDomainMessenger Mensageiro entre domínios usado por este contrato. + * @param _l1TokenBridge Endereço da ponte da L1 implantada na cadeia principal. */ constructor(address _l2CrossDomainMessenger, address _l1TokenBridge) CrossDomainEnabled(_l2CrossDomainMessenger) @@ -1079,7 +1150,7 @@ Acompanhe o endereço da ponte L1. Observe que, em contraste com o equivalente L } /*************** - * Withdrawing * + * Retirada * ***************/ /** @@ -1108,21 +1179,23 @@ Acompanhe o endereço da ponte L1. Observe que, em contraste com o equivalente L } ``` -Estas duas funções iniciam retiradas. Observe que não há necessidade de especificar o endereço do token L1. Espera-se que os tokens L2 nos digam o endereço do equivalente L1. +Estas duas funções iniciam as retiradas. +Observe que não há necessidade de especificar o endereço do token da L1. +Espera-se que os tokens da L2 nos digam o endereço do equivalente da L1. ```solidity /** - * @dev Performs the logic for withdrawals by burning the token and informing - * the L1 token Gateway of the withdrawal. - * @param _l2Token Address of L2 token where withdrawal is initiated. - * @param _from Account to pull the withdrawal from on L2. - * @param _to Account to give the withdrawal to on L1. - * @param _amount Amount of the token to withdraw. - * @param _l1Gas Unused, but included for potential forward compatibility considerations. - * @param _data Optional data to forward to L1. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev Executa a lógica para retiradas, queimando o token e informando + * o Gateway de Token da L1 sobre a retirada. + * @param _l2Token Endereço do token da L2 onde a retirada é iniciada. + * @param _from Conta da qual a retirada será retirada na L2. + * @param _to Conta para a qual a retirada será creditada na L1. + * @param _amount Quantidade do token a ser retirado. + * @param _l1Gas Não utilizado, mas incluído para possíveis considerações de compatibilidade futura. + * @param _data Dados opcionais para encaminhar para a L1. Estes dados são fornecidos + * apenas como uma conveniência para contratos externos. Além de impor um comprimento + * máximo, estes contratos não fornecem garantias sobre seu conteúdo. */ function _initiateWithdrawal( address _l2Token, @@ -1132,17 +1205,17 @@ Estas duas funções iniciam retiradas. Observe que não há necessidade de espe uint32 _l1Gas, bytes calldata _data ) internal { - // When a withdrawal is initiated, we burn the withdrawer's funds to prevent subsequent L2 - // usage + // Quando uma retirada é iniciada, nós queimamos os fundos do sacador para evitar o uso subsequente na L2 + // // slither-disable-next-line reentrancy-events IL2StandardERC20(_l2Token).burn(msg.sender, _amount); ``` -Observe que _não_ estamos contando com o parâmetro `_from`, mas com o `msg.sender` que é muito mais difícil de falsificar (impossível, até onde eu sei). +Observe que não estamos confiando no parâmetro `_from`, mas em `msg.sender`, que é muito mais difícil de falsificar (impossível, até onde eu sei). ```solidity - // Construct calldata for l1TokenBridge.finalizeERC20Withdrawal(_to, _amount) + // Constrói o calldata para l1TokenBridge.finalizeERC20Withdrawal(_to, _amount) // slither-disable-next-line reentrancy-events address l1Token = IL2StandardERC20(_l2Token).l1Token(); bytes memory message; @@ -1150,7 +1223,7 @@ Observe que _não_ estamos contando com o parâmetro `_from`, mas com o `msg.sen if (_l2Token == Lib_PredeployAddresses.OVM_ETH) { ``` -Na L1 é necessário distinguir entre ETH e ERC-20. +Na L1, é necessário distinguir entre ETH e ERC-20. ```solidity message = abi.encodeWithSelector( @@ -1172,7 +1245,7 @@ Na L1 é necessário distinguir entre ETH e ERC-20. ); } - // Send message up to L1 bridge + // Envia a mensagem para a ponte da L1 // slither-disable-next-line reentrancy-events sendCrossDomainMessage(l1TokenBridge, _l1Gas, message); @@ -1181,7 +1254,7 @@ Na L1 é necessário distinguir entre ETH e ERC-20. } /************************************ - * Cross-chain Function: Depositing * + * Função entre cadeias: Depósito * ************************************/ /** @@ -1202,11 +1275,12 @@ Essa função é chamada pelo `L1StandardBridge`. ) external virtual onlyFromCrossDomainAccount(l1TokenBridge) { ``` -Certifique-se que a origem da mensagem é legítima. Isso é importante porque a função chama `_mint` e poderia ser usada para dar tokens que não foram cobertos pelos tokens que a ponte tem na L1. +Certifique-se de que a origem da mensagem é legítima. +Isso é importante porque a função chama `_mint` e poderia ser usada para dar tokens que não são cobertos pelos tokens que a ponte possui na L1. ```solidity - // Check the target token is compliant and - // verify the deposited token on L1 matches the L2 deposited token representation here + // Verifica se o token de destino é compatível e + // verifica se o token depositado na L1 corresponde à representação do token depositado na L2 aqui if ( // slither-disable-next-line reentrancy-events ERC165Checker.supportsInterface(_l2Token, 0x1d1d8b63) && @@ -1216,11 +1290,11 @@ Certifique-se que a origem da mensagem é legítima. Isso é importante porque a Verificações de sanidade: 1. A interface correta é suportada -2. O endereço L1 do contrato ERC-20 L2 bate com a fonte L1 dos tokens +2. O endereço L1 do contrato ERC-20 da L2 corresponde à origem dos tokens na L1 ```solidity ) { - // When a deposit is finalized, we credit the account on L2 with the same amount of + // Quando um depósito é finalizado, creditamos na conta da L2 a mesma quantidade de // tokens. // slither-disable-next-line reentrancy-events IL2StandardERC20(_l2Token).mint(_to, _amount); @@ -1228,37 +1302,38 @@ Verificações de sanidade: emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data); ``` -Se a checagem de sanidade passar, finalize o depósito: +Se a verificação de sanidade passar, finalize o depósito: -1. Cunhe os tokens -2. Emita o evento apropriado +1. Cunhar os tokens +2. Emitir o evento apropriado ```solidity } else { - // Either the L2 token which is being deposited-into disagrees about the correct address - // of its L1 token, or does not support the correct interface. - // This should only happen if there is a malicious L2 token, or if a user somehow - // specified the wrong L2 token address to deposit into. - // In either case, we stop the process here and construct a withdrawal - // message so that users can get their funds out in some cases. - // There is no way to prevent malicious token contracts altogether, but this does limit - // user error and mitigate some forms of malicious contract behavior. + // Ou o token da L2 que está sendo depositado discorda sobre o endereço correto + // de seu token da L1, ou não suporta a interface correta. + // Isso só deve acontecer se houver um token malicioso na L2, ou se um usuário de alguma forma + // especificou o endereço errado do token da L2 para depositar. + // Em ambos os casos, paramos o processo aqui e construímos uma mensagem de retirada + // para que os usuários possam retirar seus fundos em alguns casos. + // Não há como evitar contratos de token maliciosos completamente, mas isso limita + // o erro do usuário e mitiga algumas formas de comportamento de contrato malicioso. ``` -Se um usuário fez um erro detectável usando o endereço de token L2 errado, nós queremos cancelar o depósito e retornar os tokens na L1. A única maneira que nós podemos fazer isso de L2 é enviar uma mensagem que irá ter que esperar pelo período de desafio de falha, mas isto é muito melhor para o usuário que perder seus tokens permanentemente. +Se um usuário cometeu um erro detectável usando o endereço de token da L2 errado, queremos cancelar o depósito e retornar os tokens na L1. +A única maneira de fazer isso a partir da L2 é enviar uma mensagem que terá que esperar o período de contestação de falhas, mas isso é muito melhor para o usuário do que perder os tokens permanentemente. ```solidity bytes memory message = abi.encodeWithSelector( IL1ERC20Bridge.finalizeERC20Withdrawal.selector, _l1Token, _l2Token, - _to, // switched the _to and _from here to bounce back the deposit to the sender + _to, // trocou o _to e o _from aqui para devolver o depósito ao remetente _from, _amount, _data ); - // Send message up to L1 bridge + // Envia a mensagem para a ponte da L1 // slither-disable-next-line reentrancy-events sendCrossDomainMessage(l1TokenBridge, 0, message); // slither-disable-next-line reentrancy-events @@ -1270,8 +1345,13 @@ Se um usuário fez um erro detectável usando o endereço de token L2 errado, n ## Conclusão {#conclusion} -A ponte padrão é o mecanismo mais flexível para transferência de ativos. Porém, por ser genérico não é sempre o mecanismo mais fácil de usar. Especialmente para retiradas, a maioria dos usuários prefere usar [pontes de terceiros](https://optimism.io/apps#bridge) a esperar o período de desafio e também não precisar de uma prova de Merkle para finalizar a retirada. +A ponte padrão é o mecanismo mais flexível para transferência de ativos. +Porém, por ser genérico não é sempre o mecanismo mais fácil de usar. +Especialmente para retiradas, a maioria dos usuários prefere usar [pontes de terceiros](https://optimism.io/apps#bridge) que não esperam o período de desafio e não exigem uma prova de Merkle para finalizar a retirada. + +Estas pontes tipicamente funcionam tendo ativos na L1, que elas fornecem imediatamente por uma taxa pequena (geralmente menor que o custo de gás para uma retirada de uma ponte padrão). +Quando a ponte (ou as pessoas que a administram) antecipa a falta de ativos da L1, ela transfere ativos suficientes da L2. Como estes são saques muito grandes, o custo do saque é amortizado por uma grande quantia e é um percentual muito menor. -Estas pontes tipicamente funcionam tendo ativos na L1, que elas fornecem imediatamente por uma taxa pequena (geralmente menor que o custo de gas para uma retirada de uma ponte padrão). Quando a ponte (ou as pessoas que a administram) antecipa a falta de ativos L1, ela transfere ativos suficientes da L2. Como estes são saques muito grandes, o custo do saque é amortizado por uma larga quantia e é um percentual muito menor. +Esperamos que este artigo tenha ajudado você a entender mais sobre como a camada 2 funciona e como escrever um código Solidity claro e seguro. -Esperamos que este artigo tenha ajudado você a entender mais sobre como a camada 2 funciona, e como escrever um código Solidity claro e seguro. +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/pt-br/developers/tutorials/reverse-engineering-a-contract/index.md index 8c95b9ec979..2e7be918d57 100644 --- a/public/content/translations/pt-br/developers/tutorials/reverse-engineering-a-contract/index.md +++ b/public/content/translations/pt-br/developers/tutorials/reverse-engineering-a-contract/index.md @@ -1,309 +1,307 @@ --- -title: "Engenharia reversa de um contrato" -description: Como entender um contrato quando você não tem o código-fonte +title: "Engenharia Reversa de um Contrato" +description: "Como entender um contrato quando você não tem o código-fonte" author: Ori Pomerantz lang: pt-br -tags: - - "evm" - - "códigos de operação" +tags: [ "evm", "códigos de operação" ] skill: advanced published: 2021-12-30 --- ## Introdução {#introduction} -_Não há segredos no blockchain_. Tudo o que acontece é consistente, verificável e está disponível publicamente. O ideal é que os contratos [tenham seu código-fonte publicado e verificado na Etherscan](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code). No entanto, [nem sempre isso acontece](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code). Neste artigo, você aprenderá a usar engenharia reversa em contratos analisando um contrato sem código-fonte, [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f). +_Não há segredos no blockchain, tudo o que acontece é consistente, verificável e está disponível publicamente._ Idealmente, [os contratos devem ter seu código-fonte publicado e verificado no Etherscan](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code). No entanto, [nem sempre é o caso](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code). Neste artigo, você aprenderá como fazer engenharia reversa de contratos analisando um contrato sem código-fonte, [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f). -Existem compiladores reversos, mas eles nem sempre produzem [resultados utilizáveis](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f). Neste artigo, você aprenderá como usar engenharia reversa manualmente e entender um contrato dos [opcodes](https://github.com/wolflo/evm-opcodes), além de interpretar os resultados de um descompilador. +Existem compiladores reversos, mas eles nem sempre produzem [resultados utilizáveis](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f). Neste artigo, você aprenderá a fazer engenharia reversa manualmente e a entender um contrato a partir dos [códigos de operação](https://github.com/wolflo/evm-opcodes), bem como a interpretar os resultados de um descompilador. -Para entender este artigo, é preciso saber o básico de EVM e pelo menos estar um pouco familiarizado com a montagem de EVM. [Você pode ler sobre estes tópicos aqui](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e). +Para entender este artigo, você já deve saber o básico da EVM e estar pelo menos um pouco familiarizado com a linguagem de montagem da EVM. [Você pode ler sobre esses tópicos aqui](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e). -## Preparar o Código Executável {#prepare-the-executable-code} +## Preparar o código executável {#prepare-the-executable-code} -Você pode obter os opcodes acessando o contrato no Etherscan clicando na guia **Contrato** e depois em **Alternar para a Visualização de Opcodes**. Você poderá visualizar um opcode por linha. +Você pode obter os códigos de operação indo para o Etherscan para o contrato, clicando na guia **Contrato** e depois em **Mudar para Visualização de Opcodes**. Você obterá uma visualização de um código de operação por linha. -![Visualização do Opcode no Etherscan](opcode-view.png) +![Visualização de código de operação do Etherscan](opcode-view.png) -Para entender os saltos, no entanto, você precisa saber onde no código cada opcode está localizado. Uma maneira de fazer isso é abrir uma planilha do Google e colar os opcodes na coluna C. [Você pode pular as seguintes etapas ao fazer uma cópia desta planilha já preparada](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing). +Para entender os saltos, no entanto, você precisa saber onde no código cada código de operação está localizado. Para fazer isso, uma maneira é abrir uma planilha do Google e colar os códigos de operação na coluna C. [Você pode pular as etapas a seguir fazendo uma cópia desta planilha já preparada](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing). -O próximo passo é obter os locais de código corretos para que possamos entender os saltos. Colocaremos o tamanho do opcode na coluna B e o local (em hexadecimal) na coluna A. Digite esta função na célula `B1` e então copie e cole para o resto da coluna B, até o final do código. Depois de fazer isso, você pode ocultar a coluna B. +O próximo passo é obter os locais corretos do código para que possamos entender os saltos. Colocaremos o tamanho do código de operação na coluna B e o local (em hexadecimal) na coluna A. Digite esta função na célula `B1` e depois copie e cole no resto da coluna B, até o final do código. Depois de fazer isso, você pode ocultar a coluna B. ``` =1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0) ``` -Primeiro essa função adiciona um byte no opcode em si e depois procura por `PUSH`. Opcodes de push são especiais porque eles precisam ter bytes adicionais para o valor que está sendo enviado. Se o opcode é um `PUSH`, extraímos o número de bytes e adicionamos isso. +Primeiro, esta função adiciona um byte para o próprio código de operação e, em seguida, procura por `PUSH`. Os códigos de operação de push são especiais porque precisam ter bytes adicionais para o valor que está sendo inserido. Se o código de operação for um `PUSH`, extraímos o número de bytes e o adicionamos. -Em `A1` coloque o primeiro offset (descolamento de bits), para zero. Depois, em `A2`, insira esta função e copie e cole novamente para o resto da coluna A: +Em `A1`, coloque o primeiro deslocamento, zero. Depois, em `A2`, insira esta função e copie e cole novamente para o resto da coluna A: ``` =dec2hex(hex2dec(A1)+B1) ``` -Nós precisamos desta função, para nos dar o valor hexadecimal, porque os valores que são enviados antes dos saltos (`JUMP` e `JUMPI`) são dados a nós em hexadecimal. +Precisamos desta função para nos dar o valor hexadecimal, porque os valores que são inseridos antes dos saltos (`JUMP` e `JUMPI`) são nos dados em hexadecimal. -## O Ponto de Entrada (0x00) {#the-entry-point-0x00} +## O ponto de entrada (0x00) {#the-entry-point-0x00} -Os contratos são sempre executados a partir do primeiro byte. Essa é a parte inicial do código: +Os contratos são sempre executados a partir do primeiro byte. Esta é a parte inicial do código: -| Deslocamento | Código de Operação | Montante (depois do opcode) | -| ------------:| ------------------ | --------------------------- | -| 0 | PUSH1 0x80 | 0x80 | -| 2 | PUSH1 0x40 | 0x40, 0x80 | -| 4 | MSTORE | Vazio | -| 5 | PUSH1 0x04 | 0x04 | -| 7 | CALLDATASIZE | CALLDATASIZE 0x04 | -| 8 | LT | CALLDATASIZE\<4 | -| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 | -| C | JUMPI | Vazio | +| Deslocamento | Código de Operação | Pilha (após o código de operação) | +| -----------: | ------------------ | ---------------------------------------------------- | +| 0 | PUSH1 0x80 | 0x80 | +| 2 | PUSH1 0x40 | 0x40, 0x80 | +| 4 | MSTORE | Vazio | +| 5 | PUSH1 0x04 | 0x04 | +| 7 | CALLDATASIZE | CALLDATASIZE 0x04 | +| 8 | LT | CALLDATASIZE\<4 | +| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 | +| C | JUMPI | Vazio | -Esse código faz duas coisas: +Este código faz duas coisas: -1. Escreva 0x80 como um valor de 32 bytes para locais da memória 0x40-0x5F (0x80 é armazenado em 0x5F, e 0x40-0x5E são todos zeros). -2. Leia o tamanho dos dados de chamada. Normalmente, os dados de chamada para um contrato Ethereum seguem [a ABI (interface binária do aplicativo)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html), o qual requer no mínimo quatro bytes para o seletor de função. Se o tamanho dos dados da chamada for menor que quatro, pule para 0x5E. +1. Escreve 0x80 como um valor de 32 bytes para os locais de memória 0x40-0x5F (0x80 é armazenado em 0x5F e 0x40-0x5E são todos zeros). +2. Lê o tamanho dos dados de chamada. Normalmente, os dados de chamada para um contrato Ethereum seguem [a ABI (interface binária de aplicativo)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html), que no mínimo requer quatro bytes para o seletor de função. Se o tamanho dos dados da chamada for menor que quatro, salta para 0x5E. ![Fluxograma para esta parte](flowchart-entry.png) -### O controlador em 0x5E (para dados de chamada não ABI) {#the-handler-at-0x5e-for-non-abi-call-data} +### O manipulador em 0x5E (para dados de chamada não ABI) {#the-handler-at-0x5e-for-non-abi-call-data} | Deslocamento | Código de Operação | -| ------------:| ------------------ | +| -----------: | ------------------ | | 5E | JUMPDEST | | 5F | CALLDATASIZE | | 60 | PUSH2 0x007c | | 63 | JUMPI | -Este trecho começa com um `JUMPDEST`. Os programas EVM (Máquina Virtual Ethereum) lançam uma exceção se você pular para um opcode que não for `JUMPDEST`. Então, ele examina o CALLDATASIZE e, se for "verdadeiro" (ou seja, não for zero), pula para 0x7C. Veremos isso abaixo. +Este trecho começa com um `JUMPDEST`. Programas EVM (máquina virtual Ethereum) lançam uma exceção se você saltar para um código de operação que não seja `JUMPDEST`. Em seguida, ele analisa o CALLDATASIZE e, se for "verdadeiro" (ou seja, diferente de zero), salta para 0x7C. Veremos isso abaixo. -| Deslocamento | Código de Operação | Montante (depois do opcode) | -| ------------:| ------------------ | ----------------------------------------------------------------------------- | -| 64 | CALLVALUE | [Wei](/glossary/#wei) fornecido pela chamada. Chamado `msg.value` no Solidity | -| 65 | PUSH1 0x06 | 6 CALLVALUE | -| 67 | PUSH1 0x00 | 0 6 CALLVALUE | -| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE | -| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE | -| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE | +| Deslocamento | Código de Operação | Pilha (após o código de operação) | +| -----------: | ------------------ | ------------------------------------------------------------------------------------------------ | +| 64 | CALLVALUE | [Wei](/glossary/#wei) fornecido pela chamada. Chamado de `msg.value` no Solidity | +| 65 | PUSH1 0x06 | 6 CALLVALUE | +| 67 | PUSH1 0x00 | 0 6 CALLVALUE | +| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE | +| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE | +| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE | -Portanto, quando não há dados de chamada, nós lemos o valor de Storage[6]. Ainda não sabemos que valor é esse, mas podemos buscar as transações que o contrato recebeu sem nenhum dado de chamada. Transações que apenas transferem ETH sem nenhum dado de chamada (e, portanto, nenhum método) têm no Etherscan o método `Transfer`. De fato, [a primeira transação que o contrato recebeu](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7) é uma transferência. +Então, quando não há dados de chamada, lemos o valor de Storage[6]. Ainda não sabemos qual é esse valor, mas podemos procurar transações que o contrato recebeu sem dados de chamada. As transações que apenas transferem ETH sem quaisquer dados de chamada (e, portanto, sem método) têm no Etherscan o método `Transfer`. Na verdade, [a primeira transação que o contrato recebeu](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7) é uma transferência. -Se nós olharmos nessa transação e clicarmos em **Clique para ver mais**, veremos que os dados da chamada, chamados de dados de entrada, estão de fato vazios (`0x`). Observe também que o valor é 1.559 ETH, que será relevante mais tarde. +Se olharmos nessa transação e clicarmos em **Clique para ver mais**, vemos que os dados da chamada, chamados de dados de entrada, estão de fato vazios (`0x`). Observe também que o valor é 1,559 ETH, o que será relevante mais tarde. ![Os dados da chamada estão vazios](calldata-empty.png) -Em seguida, clique na guia o **Estado** e expanda o contrato que estamos fazendo engenharia reversa (0x2510...). Você pode ver que `Storage[6]` (armazenamento) mudou durante a transação e, se você alterar Hex para **Número**, verá que se tornou 1.559.000.000.000.000.000, o valor transferido em wei (adicionei as vírgulas para maior clareza), que corresponde ao próximo valor do contrato. +Em seguida, clique na guia **Estado** e expanda o contrato do qual estamos fazendo engenharia reversa (0x2510...). Você pode ver que `Storage[6]` mudou durante a transação, e se você mudar de Hex para **Número**, verá que se tornou 1.559.000.000.000.000.000, o valor transferido em wei (adicionei os pontos para maior clareza), correspondendo ao próximo valor do contrato. -![A mudança no Armazenamento[6]](storage6.png) +![A mudança em Storage[6]](storage6.png) -Se observarmos as mudanças de estado causadas por [outras transações de `Transfer` (transferência) do mesmo período](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange), vemos que `Storage[6]` rastreou o valor do contrato por um tempo. Por enquanto, vamos chamá-lo de `Value*` (valor). O asterisco (`*`) nos lembra que não _sabemos_ o que esta variável faz, ainda, mas não pode ser apenas para rastrear o valor do contrato porque não há necessidade de usar armazenamento, o que é muito caro, quando você pode obter o saldo de suas contas usando `ADDRESS BALANCE`. O primeiro opcode envia o próprio endereço do contrato. O segundo lê o endereço no topo da pilha e o substitui com o saldo desse endereço. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | --------------------------------------------- | -| 6C | PUSH2 0x0075 | 0x75 Value\* CALLVALUE 0 6 CALLVALUE | -| 6F | SWAP2 | CALLVALUE Value\* 0x75 0 6 CALLVALUE | -| 70 | SWAP1 | Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 71 | PUSH2 0x01a7 | 0x01A7 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 74 | JUMP | | - -Nós continuaremos a rastrear esse código no destino do salto (desvio). - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------------------------- | -| 1A7 | JUMPDEST | Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1A8 | PUSH1 0x00 | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1AA | DUP3 | CALLVALUE 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | - -O `NOT` é bit a bit, portanto, ele inverte o valor de cada bit no valor da chamada. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------------------------------------------- | -| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1B2 | JUMPI | | - -Nós pulamos se `Value*` (o valor) for menor que 2^256-CALLVALUE-1 ou igual a ele. Isso parece lógico para evitar vazamento (overflow). E, de fato, vemos que depois de algumas operações sem sentido (escrever na memória que está prestes a ser excluída, por exemplo) no deslocamento 0x01DE, o contrato é revertido se o vazamento for detectado, o que é um comportamento normal. - -Note que esse vazamento é extremamente improvável, porque exigiria que o valor da chamada mais o `Value*` fosse comparável a 2^256 wei, em torno de 10^59 ETH. [O suprimento total de ETH, no momento desta redação, é inferior a duzentos milhões](https://etherscan.io/stat/supply). +Se olharmos nas mudanças de estado causadas por [outras transações de `Transfer` do mesmo período](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange), vemos que `Storage[6]` rastreou o valor do contrato por um tempo. Por enquanto, vamos chamá-lo de `Valor*`. O asterisco (`*`) nos lembra que ainda não _sabemos_ o que essa variável faz, mas não pode ser apenas para rastrear o valor do contrato porque não há necessidade de usar o armazenamento, que é muito caro, quando você pode obter o saldo de suas contas usando `ADDRESS BALANCE`. O primeiro código de operação insere o próprio endereço do contrato. O segundo lê o endereço no topo da pilha e o substitui pelo saldo desse endereço. | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------- | -| 1DF | JUMPDEST | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1E0 | POP | Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1E1 | ADD | Value\*+CALLVALUE 0x75 0 6 CALLVALUE | -| 1E2 | SWAP1 | 0x75 Value\*+CALLVALUE 0 6 CALLVALUE | -| 1E3 | JUMP | | +| -----------: | ------------------ | ------------------------------------------- | +| 6C | PUSH2 0x0075 | 0x75 Valor\* CALLVALUE 0 6 CALLVALUE | +| 6F | SWAP2 | CALLVALUE Valor\* 0x75 0 6 CALLVALUE | +| 70 | SWAP1 | Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 71 | PUSH2 0x01a7 | 0x01A7 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 74 | JUMP | | + +Continuaremos a rastrear este código no destino do salto. + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ----------------------------------------------------------- | +| 1A7 | JUMPDEST | Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1A8 | PUSH1 0x00 | 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AA | DUP3 | CALLVALUE 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | + +O `NOT` é bit a bit, então ele inverte o valor de cada bit no valor da chamada. + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------------------------------------ | +| 1AC | DUP3 | Valor\* 2^256-CALLVALUE-1 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AD | GT | Valor\*>2^256-CALLVALUE-1 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AE | ISZERO | Valor\*\<=2^256-CALLVALUE-1 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AF | PUSH2 0x01df | 0x01DF Valor\*\<=2^256-CALLVALUE-1 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1B2 | JUMPI | | + +Saltamos se `Valor*` for menor ou igual a 2^256-CALLVALUE-1. Isso parece uma lógica para evitar overflow. E, de fato, vemos que, após algumas operações sem sentido (escrever na memória que está prestes a ser excluída, por exemplo), no deslocamento 0x01DE, o contrato reverte se o overflow for detectado, o que é um comportamento normal. + +Note que tal overflow é extremamente improvável, porque exigiria que o valor da chamada mais `Valor*` fosse comparável a 2^256 wei, cerca de 10^59 ETH. [O fornecimento total de ETH, no momento da escrita, é inferior a duzentos milhões](https://etherscan.io/stat/supply). + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ----------------------------------------- | +| 1DF | JUMPDEST | 0x00 Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1E0 | POP | Valor\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1E1 | ADD | Valor\*+CALLVALUE 0x75 0 6 CALLVALUE | +| 1E2 | SWAP1 | 0x75 Valor\*+CALLVALUE 0 6 CALLVALUE | +| 1E3 | JUMP | | + +Se chegamos aqui, obtemos `Valor* + CALLVALUE` e saltamos para o deslocamento 0x75. -Se chegamos aqui, pegue `Value* + CALLVALUE` e salte para o offset 0x75. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | --------------------------------- | -| 75 | JUMPDEST | Value\*+CALLVALUE 0 6 CALLVALUE | -| 76 | SWAP1 | 0 Value\*+CALLVALUE 6 CALLVALUE | -| 77 | SWAP2 | 6 Value\*+CALLVALUE 0 CALLVALUE | -| 78 | SSTORE | 0 CALLVALUE | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------- | +| 75 | JUMPDEST | Valor\*+CALLVALUE 0 6 CALLVALUE | +| 76 | SWAP1 | 0 Valor\*+CALLVALUE 6 CALLVALUE | +| 77 | SWAP2 | 6 Valor\*+CALLVALUE 0 CALLVALUE | +| 78 | SSTORE | 0 CALLVALUE | -Se nós chegarmos aqui (o que requer que os dados da chamada estejam vazios), adicionamos o `Value*` ao valor da chamada. Isso é consistente com o que dizemos que as transações de `Transfer` fazem. +Se chegarmos aqui (o que exige que os dados da chamada estejam vazios), adicionamos o valor da chamada a `Valor*`. Isso é consistente com o que dizemos que as transações de `Transfer` fazem. | Deslocamento | Código de Operação | -| ------------:| ------------------ | +| -----------: | ------------------ | | 79 | POP | | 7A | POP | | 7B | STOP | Finalmente, limpe a pilha (o que não é necessário) e sinalize o fim bem-sucedido da transação. -Para simplificar tudo, aqui está um fluxograma para o código inicial. +Para resumir tudo, aqui está um fluxograma para o código inicial. ![Fluxograma do ponto de entrada](flowchart-entry.png) -## O Controlador em 0x7C {#the-handler-at-0x7c} +## O manipulador em 0x7C {#the-handler-at-0x7c} -Eu propositalmente não coloquei no cabeçalho o que esse controlador faz. O propósito não é ensinar como esse contrato específico funciona, mas como fazer engenharia reversa de contratos. Você irá aprender o que ele faz da mesma forma que eu, seguindo o código. +Eu propositalmente não coloquei no título o que este manipulador faz. O objetivo não é ensinar como este contrato específico funciona, mas como fazer engenharia reversa de contratos. Você aprenderá o que ele faz da mesma maneira que eu, seguindo o código. -Nós chegamos aqui a partir de vários locais: +Chegamos aqui de vários lugares: -- Se houver dados de chamada de 1, 2 ou 3 bytes (a partir do deslocamento 0x63) -- Se a assinatura do método for desconhecida (dos offsets 0x42 e 0x5D) +- Se houver dados de chamada de 1, 2 ou 3 bytes (do deslocamento 0x63) +- Se a assinatura do método for desconhecida (dos deslocamentos 0x42 e 0x5D) -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------------- | -| 7C | JUMPDEST | | -| 7D | PUSH1 0x00 | 0x00 | -| 7F | PUSH2 0x009d | 0x9D 0x00 | -| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------ | +| 7C | JUMPDEST | | +| 7D | PUSH1 0x00 | 0x00 | +| 7F | PUSH2 0x009d | 0x9D 0x00 | +| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 | | 84 | SLOAD | Storage[3] 0x9D 0x00 | -Esta é outra célula de armazenamento, que não poderia encontrar em nenhuma transação, portanto, é mais difícil saber o que significa. O código abaixo deixará isso mais claro. +Esta é outra célula de armazenamento, uma que não consegui encontrar em nenhuma transação, então é mais difícil saber o que significa. O código abaixo tornará isso mais claro. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------------------------------------- | ------------------------------- | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 | -| 9A | AND | Storage[3]-as-address 0x9D 0x00 | +| 9A | AND | Storage[3]-como-endereço 0x9D 0x00 | -Esses opcodes truncam o valor que lemos do Armazenamento[3] para 160 bits, o tamanho de um endereço Ethereum. +Esses códigos de operação truncam o valor que lemos de Storage[3] para 160 bits, o comprimento de um endereço Ethereum. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------- | -| 9B | SWAP1 | 0x9D Storage[3]-as-address 0x00 | -| 9C | JUMP | Storage[3]-as-address 0x00 | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | -------------------------------------------------------------------------------------- | +| 9B | SWAP1 | 0x9D Storage[3]-como-endereço 0x00 | +| 9C | JUMP | Storage[3]-como-endereço 0x00 | -Este salto é supérfluo, pois estamos indo para o próximo opcode. Esse código não é tão eficiente em relação ao consumo de gás quanto ele poderia ser. +Este salto é supérfluo, já que estamos indo para o próximo código de operação. Este código não é tão eficiente em termos de gás quanto poderia ser. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------- | -| 9D | JUMPDEST | Storage[3]-as-address 0x00 | -| 9E | SWAP1 | 0x00 Storage[3]-as-address | -| 9F | POP | Storage[3]-as-address | -| A0 | PUSH1 0x40 | 0x40 Storage[3]-as-address | -| A2 | MLOAD | Mem[0x40] Storage[3]-as-address | - -Bem no início do código, definimos Mem[0x40] como 0x80. Se procurarmos 0x40 posteriormente, veremos que nós não o alteramos - então podemos assumir que é 0x80. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------------- | -| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-as-address | -| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-as-address | -| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-as-address | -| A7 | CALLDATACOPY | 0x80 Storage[3]-as-address | - -Copie todos os dados da chamada para a memória, começando por 0x80. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------------------------------------------------------------------------- | -| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-as-address | -| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-as-address | -| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AD | DUP6 | Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AE | GAS | GAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AF | DELEGATE_CALL | | - -Agora as coisas estão muito mais claras. Este contrato pode atuar como um [proxy](https://blog.openzeppelin.com/proxy-patterns/), chamando o endereço no Armazenamento[3] para fazer o trabalho real. `DELEGATE_CALL` chama um contrato separado, mas permanece no mesmo armazenamento. Isto significa que o contrato delegado, aquele para o qual somos proxy, acessa o mesmo espaço de armazenamento. Os parâmetros para a chamada são: - -- _Gas_: Todo o gas restante -- _Endereço chamado_: Armazenamento[3] como endereço -- _Dados da chamada_: Os bytes CALLDATASIZE começando em 0x80, que é onde colocamos os dados originais da chamada -- _Dados de retorno_: Nenhum (0x00 - 0x00) Nós vamos obter os dados de retorno por outros meios (veja abaixo) - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | --------------------------------------------------------------------------------------------- | -| B0 | RETURNDATASIZE | RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B5 | RETURNDATACOPY | RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | +| 9D | JUMPDEST | Storage[3]-como-endereço 0x00 | +| 9E | SWAP1 | 0x00 Storage[3]-como-endereço | +| 9F | POP | Storage[3]-como-endereço | +| A0 | PUSH1 0x40 | 0x40 Storage[3]-como-endereço | +| A2 | MLOAD | Mem[0x40] Storage[3]-como-endereço | + +Bem no início do código, definimos Mem[0x40] como 0x80. Se procurarmos por 0x40 mais tarde, veremos que não o alteramos - então podemos assumir que é 0x80. + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | -------------------------------------------------------------------------------------------------------- | +| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-como-endereço | +| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-como-endereço | +| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-como-endereço | +| A7 | CALLDATACOPY | 0x80 Storage[3]-como-endereço | + +Copie todos os dados da chamada para a memória, começando em 0x80. + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-como-endereço | +| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-como-endereço | +| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-como-endereço | +| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-como-endereço | +| AD | DUP6 | Storage[3]-como-endereço 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-como-endereço | +| AE | GAS | GAS Storage[3]-como-endereço 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-como-endereço | +| AF | DELEGATE_CALL | | + +Agora as coisas estão muito mais claras. Este contrato pode atuar como um [proxy](https://blog.openzeppelin.com/proxy-patterns/), chamando o endereço em Storage[3] para fazer o trabalho real. `DELEGATE_CALL` chama um contrato separado, mas permanece no mesmo armazenamento. Isso significa que o contrato delegado, para o qual somos um proxy, acessa o mesmo espaço de armazenamento. Os parâmetros para a chamada são: + +- _Gás_: todo o gás restante +- _Endereço chamado_: Storage[3]-como-endereço +- _Dados de chamada_: Os bytes CALLDATASIZE começando em 0x80, que é onde colocamos os dados de chamada originais +- _Dados de retorno_: Nenhum (0x00 - 0x00) Obteremos os dados de retorno por outros meios (veja abaixo) + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| B0 | RETURNDATASIZE | RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B5 | RETURNDATACOPY | RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | Aqui copiamos todos os dados de retorno para o buffer de memória começando em 0x80. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ---------------------------------------------------------------------------------------------------------------------------- | -| B6 | DUP2 | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B7 | DUP1 | (((call success/failure))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B8 | ISZERO | (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| B9 | PUSH2 0x00c0 | 0xC0 (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BC | JUMPI | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BD | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BE | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BF | RETURN | | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| B6 | DUP2 | (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B7 | DUP1 | (((sucesso/falha da chamada))) (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B8 | ISZERO | (((a chamada falhou))) (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| B9 | PUSH2 0x00c0 | 0xC0 (((a chamada falhou))) (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| BC | JUMPI | (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| BD | DUP2 | RETURNDATASIZE (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| BE | DUP5 | 0x80 RETURNDATASIZE (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| BF | RETURN | | -Então, após a chamada, nós copiamos os dados de retorno para o buffer 0x80 - 0x80+RETURNDATASIZE e, se a chamada for bem-sucedida, nós então fazemos o `RETURN` com exatamente este buffer. +Então, após a chamada, copiamos os dados de retorno para o buffer 0x80 - 0x80+RETURNDATASIZE e, se a chamada for bem-sucedida, fazemos um `RETURN` com exatamente esse buffer. -### DELEGATECALL falhou {#delegatecall-failed} +### DELEGATECALL Falhou {#delegatecall-failed} -Se chegarmos aqui, para 0xC0, significa que o contrato que chamamos foi revertido. Como somos apenas um proxy para esse contrato, queremos retornar os mesmos dados e também reverter. +Se chegarmos aqui, em 0xC0, significa que o contrato que chamamos reverteu. Como somos apenas um proxy para esse contrato, queremos retornar os mesmos dados e também reverter. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------------------------------------------------------------------------------- | -| C0 | JUMPDEST | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| C1 | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| C2 | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| C3 | REVERT | | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| C0 | JUMPDEST | (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| C1 | DUP2 | RETURNDATASIZE (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| C2 | DUP5 | 0x80 RETURNDATASIZE (((sucesso/falha da chamada))) RETURNDATASIZE (((sucesso/falha da chamada))) 0x80 Storage[3]-como-endereço | +| C3 | REVERT | | -Portanto, fazemos o `REVERT` com o mesmo buffer que usamos para o `RETURN` anteriormente: 0x80 - 0x80+RETURNDATASIZE +Portanto, fazemos `REVERT` com o mesmo buffer que usamos para `RETURN` anteriormente: 0x80 - 0x80+RETURNDATASIZE -![Fluxograma de chamada ao proxy](flowchart-proxy.png) +![Fluxograma de chamada para proxy](flowchart-proxy.png) -## Chamadas da ABI {#abi-calls} +## Chamadas ABI {#abi-calls} -Se o tamanho dos dados da chamada for quatro bytes ou mais, pode ser uma chamada ABI válida. +Se o tamanho dos dados da chamada for de quatro bytes ou mais, pode ser uma chamada ABI válida. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------------- | -| D | PUSH1 0x00 | 0x00 | -| F | CALLDATALOAD | (((First word (256 bits) of the call data))) | -| 10 | PUSH1 0xe0 | 0xE0 (((First word (256 bits) of the call data))) | -| 12 | SHR | (((first 32 bits (4 bytes) of the call data))) | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | +| D | PUSH1 0x00 | 0x00 | +| F | CALLDATALOAD | (((Primeira palavra (256 bits) dos dados da chamada))) | +| 10 | PUSH1 0xe0 | 0xE0 (((Primeira palavra (256 bits) dos dados da chamada))) | +| 12 | SHR | (((primeiros 32 bits (4 bytes) dos dados de chamada))) | -O Etherscan nos conta que `1C` é um opcode desconhecido, porque [ele foi adicionado depois que o Etherscan escreveu essa funcionalidade](https://eips.ethereum.org/EIPS/eip-145) e eles não o atualizaram. An [up to date opcode table](https://github.com/wolflo/evm-opcodes) shows us that this is shift right +O Etherscan nos diz que `1C` é um código de operação desconhecido, porque [foi adicionado depois que o Etherscan escreveu este recurso](https://eips.ethereum.org/EIPS/eip-145) e eles não o atualizaram. Uma [tabela de códigos de operação atualizada](https://github.com/wolflo/evm-opcodes) nos mostra que isso é um deslocamento para a direita -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------------------------------------------------------------------------------------------------- | -| 13 | DUP1 | (((first 32 bits (4 bytes) of the call data))) (((first 32 bits (4 bytes) of the call data))) | -| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((first 32 bits (4 bytes) of the call data))) (((first 32 bits (4 bytes) of the call data))) | -| 19 | GT | 0x3CD8045E>first-32-bits-of-the-call-data (((first 32 bits (4 bytes) of the call data))) | -| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>first-32-bits-of-the-call-data (((first 32 bits (4 bytes) of the call data))) | -| 1D | JUMPI | (((first 32 bits (4 bytes) of the call data))) | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 13 | DUP1 | (((primeiros 32 bits (4 bytes) dos dados de chamada))) (((primeiros 32 bits (4 bytes) dos dados de chamada))) | +| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((primeiros 32 bits (4 bytes) dos dados de chamada))) (((primeiros 32 bits (4 bytes) dos dados de chamada))) | +| 19 | GT | 0x3CD8045E>primeiros-32-bits-dos-dados-de-chamada (((primeiros 32 bits (4 bytes) dos dados de chamada))) | +| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>primeiros-32-bits-dos-dados-de-chamada (((primeiros 32 bits (4 bytes) dos dados de chamada))) | +| 1D | JUMPI | (((primeiros 32 bits (4 bytes) dos dados de chamada))) | -Ao dividir os testes de correspondência da assinatura do método em dois, dessa forma, economiza metade dos testes, em média. O código que segue imediatamente e o código em 0x43 seguem o mesmo padrão: `DUP1` os primeiros 32 bits dos dados da chamada, `PUSH4 (((method signature>`, executa `EQ` para verificar a igualdade e, então, fazer o `JUMPI` se a assinatura do método corresponder. Aqui estão as assinaturas de método, seus endereços e, se conhecido [a definição de método correspondente](https://www.4byte.directory/): +Dividir os testes de correspondência da assinatura do método em dois, dessa forma, economiza metade dos testes, em média. O código que se segue imediatamente e o código em 0x43 seguem o mesmo padrão: `DUP1` os primeiros 32 bits dos dados da chamada, `PUSH4 (((assinatura do método`, executa `EQ` para verificar a igualdade e, em seguida, `JUMPI` se a assinatura do método corresponder. Aqui estão as assinaturas do método, seus endereços e, se conhecida, [a definição do método correspondente](https://www.4byte.directory/): -| Método | Assinatura do método | Deslocamento por salto | -| -------------------------------------------------------------------------------------- | -------------------- | ---------------------- | -| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 | -| ??? | 0x81e580d3 | 0x0138 | -| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 | -| ??? | 0x1f135823 | 0x00C4 | -| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED | +| Método | Assinatura do método | Deslocamento para saltar | +| --------------------------------------------------------------------------------------------------------- | -------------------- | ------------------------ | +| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 | +| ??? | 0x81e580d3 | 0x0138 | +| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 | +| ??? | 0x1f135823 | 0x00C4 | +| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED | -Se nenhuma combinação for encontrada, o código pula para [o controlador do proxy em 0x7C](#the-handler-at-0x7c), na esperança de que o contrato para o qual somos um proxy tenha uma correspondência. +Se nenhuma correspondência for encontrada, o código salta para [o manipulador de proxy em 0x7C](#the-handler-at-0x7c), na esperança de que o contrato para o qual somos um proxy tenha uma correspondência. ![Fluxograma de chamadas ABI](flowchart-abi.png) ## splitter() {#splitter} | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ----------------------------- | +| -----------: | ------------------ | ----------------------------- | | 103 | JUMPDEST | | | 104 | CALLVALUE | CALLVALUE | | 105 | DUP1 | CALLVALUE CALLVALUE | @@ -314,38 +312,38 @@ Se nenhuma combinação for encontrada, o código pula para [o controlador do pr | 10D | DUP1 | 0x00 0x00 CALLVALUE | | 10E | REVERT | | -A primeira coisa que esta função faz é verificar que a chamada não enviou nenhum ETH. Esta função não é [`payable`](https://solidity-by-example.org/payable/) pagável. Se alguém nos enviou ETH, isso deve ser um erro, e queremos fazer o `REVERT` para evitar ter esse ETH que eles não possam recuperá-lo. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------------------------------------- | --------------------------------------------------------------------------- | -| 10F | JUMPDEST | | -| 110 | POP | | -| 111 | PUSH1 0x03 | 0x03 | -| 113 | SLOAD | (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 114 | PUSH1 0x40 | 0x40 (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 116 | MLOAD | 0x80 (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 12D | SWAP2 | (((Storage[3] a.k.a the contract for which we are a proxy))) 0xFF...FF 0x80 | -| 12E | AND | ProxyAddr 0x80 | -| 12F | DUP2 | 0x80 ProxyAddr 0x80 | -| 130 | MSTORE | 0x80 | +A primeira coisa que esta função faz é verificar se a chamada não enviou nenhum ETH. Esta função não é [`payable`](https://solidity-by-example.org/payable/). Se alguém nos enviou ETH, deve ter sido um erro, e queremos fazer um `REVERT` para evitar que esse ETH fique onde eles não possam recuperá-lo. + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 10F | JUMPDEST | | +| 110 | POP | | +| 111 | PUSH1 0x03 | 0x03 | +| 113 | SLOAD | (((Storage[3] ou seja, o contrato para o qual somos um proxy))) | +| 114 | PUSH1 0x40 | 0x40 (((Storage[3] ou seja, o contrato para o qual somos um proxy))) | +| 116 | MLOAD | 0x80 (((Storage[3] ou seja, o contrato para o qual somos um proxy))) | +| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] ou seja, o contrato para o qual somos um proxy))) | +| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] ou seja, o contrato para o qual somos um proxy))) | +| 12D | SWAP2 | (((Storage[3] ou seja, o contrato para o qual somos um proxy))) 0xFF...FF 0x80 | +| 12E | AND | EndereçoProxy 0x80 | +| 12F | DUP2 | 0x80 EndereçoProxy 0x80 | +| 130 | MSTORE | 0x80 | E 0x80 agora contém o endereço do proxy | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | --------- | +| -----------: | ------------------ | --------- | | 131 | PUSH1 0x20 | 0x20 0x80 | | 133 | ADD | 0xA0 | | 134 | PUSH2 0x00e4 | 0xE4 0xA0 | | 137 | JUMP | 0xA0 | -### O código E4 {#the-e4-code} +### O Código E4 {#the-e4-code} -Essa é a primeira vez que vemos essas linhas, mas elas são compartilhadas com outros métodos (veja abaixo). Então, vamos chamar o valor na pilha de X, e lembre-se que em `splitter()` o valor desse X é 0xA0. +Essa é a primeira vez que vemos essas linhas, mas elas são compartilhadas com outros métodos (veja abaixo). Então, vamos chamar o valor na pilha de X e apenas lembrar que em `splitter()` o valor desse X é 0xA0. | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ----------- | +| -----------: | ------------------ | ----------- | | E4 | JUMPDEST | X | | E5 | PUSH1 0x40 | 0x40 X | | E7 | MLOAD | 0x80 X | @@ -355,30 +353,30 @@ Essa é a primeira vez que vemos essas linhas, mas elas são compartilhadas com | EB | SWAP1 | 0x80 X-0x80 | | EC | RETURN | | -Portanto, esse código recebe um ponteiro de memória no montante (X) e faz com que o contrato faça o `RETURN` com um buffer que é 0x80 - X. +Portanto, esse código recebe um ponteiro de memória na pilha (X) e faz com que o contrato retorne (`RETURN`) com um buffer que é 0x80 - X. -No caso do `splitter()`, isto retorna o endereço do qual somos um proxy. O `RETURN` devolve o buffer em 0x80-0x9F, que é onde escrevemos esses dados (offset 0x130 acima). +No caso do `splitter()`, isso retorna o endereço para o qual somos um proxy. `RETURN` retorna o buffer em 0x80-0x9F, que é onde escrevemos esses dados (deslocamento 0x130 acima). ## currentWindow() {#currentwindow} -O código nos deslocamentos 0x158-0x163 é idêntico ao que vimos em 0x103-0x10E em `splitter()` (que não seja o destino `JUMPI`), então sabemos que `currentWindow()` também não é `payable` (pagável). +O código nos deslocamentos 0x158-0x163 é idêntico ao que vimos em 0x103-0x10E em `splitter()` (além do destino de `JUMPI`), então sabemos que `currentWindow()` também não é `payable`. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------------- | -| 164 | JUMPDEST | | -| 165 | POP | | -| 166 | PUSH2 0x00da | 0xDA | -| 169 | PUSH1 0x01 | 0x01 0xDA | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------ | +| 164 | JUMPDEST | | +| 165 | POP | | +| 166 | PUSH2 0x00da | 0xDA | +| 169 | PUSH1 0x01 | 0x01 0xDA | | 16B | SLOAD | Storage[1] 0xDA | | 16C | DUP2 | 0xDA Storage[1] 0xDA | | 16D | JUMP | Storage[1] 0xDA | ### O código DA {#the-da-code} -Esse código também é compartilhado com outros métodos. Então, chamaremos o valor na pilha de Y e lembre-se de que em `currentWindow()` o valor desse Y é o Armazenamento[1]. +Esse código também é compartilhado com outros métodos. Então, chamaremos o valor na pilha de Y e lembre-se de que em `currentWindow()` o valor desse Y é Storage[1]. | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ---------------- | +| -----------: | ------------------ | ---------------- | | DA | JUMPDEST | Y 0xDA | | DB | PUSH1 0x40 | 0x40 Y 0xDA | | DD | MLOAD | 0x80 Y 0xDA | @@ -386,107 +384,107 @@ Esse código também é compartilhado com outros métodos. Então, chamaremos o | DF | DUP2 | 0x80 Y 0x80 0xDA | | E0 | MSTORE | 0x80 0xDA | -Escreva Y em 0x80-0x9F. +Escreve Y em 0x80-0x9F. | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------- | +| -----------: | ------------------ | -------------- | | E1 | PUSH1 0x20 | 0x20 0x80 0xDA | | E3 | ADD | 0xA0 0xDA | -E o resto já está explicado conforme [acima](#the-e4-code). Portanto, salte para 0xDA, escreva no topo da pilha (Y) para 0x80-0x9F e retorne esse valor. No caso de `currentWindow()`, retorne o Armazenamento[1]. +E o resto já foi explicado [acima](#the-e4-code). Portanto, saltos para 0xDA escrevem o valor do topo da pilha (Y) em 0x80-0x9F e retornam esse valor. No caso de `currentWindow()`, ele retorna Storage[1]. ## merkleRoot() {#merkleroot} -O código nos deslocamentos 0xED-0xF8 é idêntico ao que vimos em 0x103-0x10E em `splitter()` (além do alvo `JUMPI`), então sabemos `merkleRoot()` também não é `payable`. +O código nos deslocamentos 0xED-0xF8 é idêntico ao que vimos em 0x103-0x10E em `splitter()` (além do destino de `JUMPI`), então sabemos que `merkleRoot()` também não é `payable`. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------------- | -| F9 | JUMPDEST | | -| FA | POP | | -| FB | PUSH2 0x00da | 0xDA | -| FE | PUSH1 0x00 | 0x00 0xDA | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------ | +| F9 | JUMPDEST | | +| FA | POP | | +| FB | PUSH2 0x00da | 0xDA | +| FE | PUSH1 0x00 | 0x00 0xDA | | 100 | SLOAD | Storage[0] 0xDA | | 101 | DUP2 | 0xDA Storage[0] 0xDA | | 102 | JUMP | Storage[0] 0xDA | -O que acontece após o salto [já descobrimos](#the-da-code). Portanto, `merkleRoot()` retorna o Armazenamento[0]. +O que acontece após o salto [já descobrimos](#the-da-code). Portanto, `merkleRoot()` retorna Storage[0]. ## 0x81e580d3 {#0x81e580d3} -O código nos deslocamentos 0x138-0x143 é idêntico ao que vimos em 0x103-0x10E em `splitter()` (além do alvo `JUMPI`), então sabemos que esta função também é não `payable`. - -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ------------------------------------------------------------ | -| 144 | JUMPDEST | | -| 145 | POP | | -| 146 | PUSH2 0x00da | 0xDA | -| 149 | PUSH2 0x0153 | 0x0153 0xDA | -| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA | -| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA | -| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA | -| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA | -| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA | -| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | - -Parece que esta função leva ao menos 32 bytes (uma palavra) de dados da chamada. +O código nos deslocamentos 0x138-0x143 é idêntico ao que vimos em 0x103-0x10E em `splitter()` (além do destino de `JUMPI`), então sabemos que esta função também não é `payable`. + +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ------------------------------------------------------------------------------- | +| 144 | JUMPDEST | | +| 145 | POP | | +| 146 | PUSH2 0x00da | 0xDA | +| 149 | PUSH2 0x0153 | 0x0153 0xDA | +| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA | +| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA | +| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA | +| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA | +| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA | +| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | + +Parece que esta função leva pelo menos 32 bytes (uma palavra) de dados de chamada. | Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | -------------------------------------------- | +| -----------: | ------------------ | -------------------------------------------- | | 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA | | 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA | | 19F | REVERT | | Se não obtiver os dados da chamada, a transação é revertida sem nenhum dado de retorno. -Vamos ver o que acontece se a função _obtiver_ os dados de chamada necessários. +Vamos ver o que acontece se a função _receber_ os dados de chamada de que precisa. -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ---------------------------------------- | -| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | ----------------------------------------------------------- | +| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA | | 1A2 | CALLDATALOAD | calldataload(4) CALLDATASIZE 0x0153 0xDA | `calldataload(4)` é a primeira palavra dos dados da chamada _após_ a assinatura do método -| Deslocamento | Código de Operação | Pilha | -| ------------:| ------------------ | ---------------------------------------------------------------------------- | -| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA | -| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA | -| 1A5 | POP | 0x0153 calldataload(4) 0xDA | -| 1A6 | JUMP | calldataload(4) 0xDA | -| 153 | JUMPDEST | calldataload(4) 0xDA | -| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA | -| 157 | JUMP | calldataload(4) 0xDA | -| 16E | JUMPDEST | calldataload(4) 0xDA | -| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA | -| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA | -| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA | -| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | -| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | +| Deslocamento | Código de Operação | Pilha | +| -----------: | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA | +| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA | +| 1A5 | POP | 0x0153 calldataload(4) 0xDA | +| 1A6 | JUMP | calldataload(4) 0xDA | +| 153 | JUMPDEST | calldataload(4) 0xDA | +| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA | +| 157 | JUMP | calldataload(4) 0xDA | +| 16E | JUMPDEST | calldataload(4) 0xDA | +| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA | +| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA | +| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA | +| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | +| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | | 175 | LT | calldataload(4)\)`, e outro é `isClaimed()`, então parece como um contrato airdrop. Em vez de passar pelo restante opcode por opcode, podemos [tentar o descompilador](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761), que produz resultados uteis para três funções deste contrato. A engenharia reversa dos outros é deixada como um exercício para o leitor. +Um dos métodos restantes é `claim()`, e outro é `isClaimed()`, então parece um contrato de airdrop. Em vez de passar pelo restante código de operação por código de operação, podemos [tentar o descompilador](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761), que produz resultados úteis para três funções deste contrato. A engenharia reversa dos outros é deixada como um exercício para o leitor. ### scaleAmountByPercentage {#scaleamountbypercentage} @@ -592,13 +590,13 @@ def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable: return (_param1 * _param2 / 100 * 10^6) ``` -O primeiro `require` testa que os dados da chamada tenham, além dos quatro bytes da assinatura da função, ao menos 64 bytes, suficientes para os dois parâmetros. Do contrário, obviamente, há algo errado. +O primeiro `require` testa que os dados da chamada tenham, além dos quatro bytes da assinatura da função, pelo menos 64 bytes, suficientes para os dois parâmetros. Do contrário, obviamente, há algo errado. -A instrução `if` da sentença parece verificar que `_param1` não é zero e que `_param1 * _param2` não é negativo. Provavelmente, isso é para evitar casos de desvios. +A instrução `if` parece verificar se `_param1` não é zero e se `_param1 * _param2` não é negativo. Provavelmente, isso é para evitar casos de wrap around (retorno). -Finalmente, a função retorna um valor em escala. +Finalmente, a função retorna um valor escalado. -### Reivindicação {#claim} +### claim {#claim} O código que o descompilador cria é complexo, e nem todo ele é relevante para nós. Vou pular algumas partes para focar nas linhas que acredito fornecerem informações úteis @@ -608,21 +606,21 @@ def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _pa require _param2 == addr(_param2) ... if currentWindow <= _param1: - revert with 0, 'cannot claim for a future window' + revert with 0, 'não é possível reivindicar para uma janela futura' ``` Vemos aqui duas coisas importantes: - `_param2`, embora esteja declarado como um `uint256`, é na verdade um endereço -- `_param1` é a janela que está sendo reivindicada, o qual tem de ser `currentWindow` ou a anterior. +- `_param1` é a janela que está sendo reivindicada, que tem que ser `currentWindow` ou anterior. ```python ... if stor5[_claimWindow][addr(_claimFor)]: - revert with 0, 'Account already claimed the given window' + revert with 0, 'A conta já reivindicou a janela fornecida' ``` -Ou seja, agora sabemos que Armazenamento[5] é uma matriz de janelas e endereços e se o endereço reivindicou a recompensa por essa janela. +Então, agora sabemos que Storage[5] é uma matriz de janelas e endereços, e se o endereço reivindicou a recompensa por essa janela. ```python ... @@ -639,10 +637,10 @@ Ou seja, agora sabemos que Armazenamento[5] é uma matriz de janelas e endereço s = sha3(mem[_66 + 32 len mem[_66]]) continue if unknown2eb4a7ab != s: - revert with 0, 'Invalid proof' + revert with 0, 'Prova inválida' ``` -Sabemos que `unknown2eb4a7ab` é na verdade a função `merkleRoot()`, então este código parece estar verificando um [prova de merkle](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5). Isso significa que `_param4` é uma prova de merkle. +Sabemos que `unknown2eb4a7ab` é, na verdade, a função `merkleRoot()`, então este código parece estar verificando uma [prova de Merkle](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5). Isso significa que `_param4` é uma prova de Merkle. ```python call addr(_param2) with: @@ -650,7 +648,7 @@ Sabemos que `unknown2eb4a7ab` é na verdade a função `merkleRoot()`, então es gas 30000 wei ``` -É assim que um contrato transfere seu próprio ETH para outro endereço (de contrato ou de propriedade externa). Ele o chama com um valor que é a quantidade a ser transferida. Logo, parece que isso é um airdrop do ETH. +É assim que um contrato transfere seu próprio ETH para outro endereço (de contrato ou de propriedade externa). Ele o chama com um valor que é a quantidade a ser transferida. Logo, parece que isso é um airdrop de ETH. ```python if not return_data.size: @@ -660,22 +658,22 @@ Sabemos que `unknown2eb4a7ab` é na verdade a função `merkleRoot()`, então es value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei ``` -As duas linhas mais abaixo nos dizem que o Armazenamento[2] também é um contrato que chamamos. Se nós [olharmos a transação do construtor](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange), veremos que este contrato é o [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), um contrato de Ether encapsulado [cujo código-fonte foi carregado no Etherscan](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code). +As duas linhas inferiores nos dizem que Storage[2] também é um contrato que chamamos. Se [olharmos para a transação do construtor](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange) vemos que este contrato é [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), um contrato de Wrapped Ether [cujo código-fonte foi carregado no Etherscan](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code). -Assim, parece que os contratos tentam enviar ETH para `_param2`. Se puder fazer isso, ótimo. Se não, ele tenta enviar [WETH](https://weth.tkn.eth.limo/). Se `_param2` for uma conta de propriedade externa (EOA), então ele sempre pode receber ETH, mas os contratos podem se recusar a receber ETH. No entanto, WETH é ERC-20 e os contratos não podem se recusar a aceitar isso. +Assim, parece que os contratos tentam enviar ETH para `_param2`. Se puder fazer isso, ótimo. Caso contrário, ele tenta enviar [WETH](https://weth.tkn.eth.limo/). Se `_param2` for uma conta de propriedade externa (EOA), então ela sempre pode receber ETH, mas os contratos podem se recusar a receber ETH. No entanto, WETH é ERC-20 e os contratos não podem se recusar a aceitar isso. ```python ... log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success) ``` -No final da função, nós vemos uma entrada de log sendo gerada. [Veja as entradas de log geradas](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) e filtre pelo tópico que começa com `0xdbd5...`. Se nós [clicarmos em uma das transações que gerou tal entrada](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274), veremos que realmente parece uma reivindicação - a conta enviou uma mensagem para o contrato, que estamos fazendo engenharia reversa e, em troca, recebemos ETH. +No final da função, vemos uma entrada de log sendo gerada. [Veja as entradas de log geradas](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) e filtre pelo tópico que começa com `0xdbd5...`. Se [clicarmos em uma das transações que gerou tal entrada](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274), veremos que realmente parece uma reivindicação - a conta enviou uma mensagem para o contrato do qual estamos fazendo engenharia reversa e, em troca, recebeu ETH. ![Uma transação de reivindicação](claim-tx.png) ### 1e7df9d3 {#1e7df9d3} -Esta função é muito semelhante à [`claim`](#claim) (reinvidicação) acima. Ela também verifica uma prova de merkle, que tenta transferir ETH para o primeiro e produz o mesmo tipo de entrada de log. +Esta função é muito semelhante a `claim` acima. Ela também verifica uma prova de Merkle, tenta transferir ETH para o primeiro e produz o mesmo tipo de entrada de log. ```python def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable: @@ -693,7 +691,7 @@ def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable: mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) ... if unknown2eb4a7ab != s: - revert with 0, 'Invalid proof' + revert with 0, 'Prova inválida' ... call addr(_param1) with: value s wei @@ -708,7 +706,7 @@ def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable: log 0xdbd5389f: addr(_param1), s, bool(ext_call.success) ``` -A principal diferença é que o primeiro parâmetro, a janela para retirada, não está lá. Em vez disso, há um loop em todas as janelas que podem ser reivindicadas. +A principal diferença é que o primeiro parâmetro, a janela para retirada, não está lá. Em vez disso, há um loop sobre todas as janelas que podem ser reivindicadas. ```python idx = 0 @@ -737,8 +735,10 @@ A principal diferença é que o primeiro parâmetro, a janela para retirada, nã continue ``` -Portanto, parece uma variante da `claim` que reivindica todas as janelas. +Portanto, parece uma variante de `claim` que reivindica todas as janelas. ## Conclusão {#conclusion} -A esta altura, você já deveria saber como entender os contratos cujo código-fonte não está disponível, usando os opcodes ou (quando funciona) o descompilador. Como é evidente na extensão deste artigo, a engenharia reversa de um contrato não é trivial, mas em um sistema em que a segurança é essencial, é uma habilidade importante ser capaz de verificar se os contratos funcionam como prometido. +Até agora você já deve saber como entender contratos cujo código-fonte não está disponível, usando os códigos de operação ou (quando funciona) o descompilador. Como é evidente pela extensão deste artigo, a engenharia reversa de um contrato não é trivial, mas em um sistema onde a segurança é essencial, é uma habilidade importante ser capaz de verificar se os contratos funcionam como prometido. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/pt-br/developers/tutorials/run-node-raspberry-pi/index.md index 71efde63434..08a5523288e 100644 --- a/public/content/translations/pt-br/developers/tutorials/run-node-raspberry-pi/index.md +++ b/public/content/translations/pt-br/developers/tutorials/run-node-raspberry-pi/index.md @@ -1,12 +1,14 @@ --- -title: Como transformar o Raspberry Pi 4 em um nó apenas instalando o cartão MicroSD -description: Piscar seu Raspberry Pi 4, plugar em um cabo ethernet, conectar o disco SSD e ligar o dispositivo para transformar o Raspberry Pi 4 em um nó Ethereum completo + validador +title: "Execute um nó Ethereum em um Raspberry Pi 4" +description: "Flasheie seu Raspberry Pi 4, conecte um cabo de ethernet, conecte o disco SSD e ligue o dispositivo para transformar o Raspberry Pi 4 em um nó Ethereum completo + validador" author: "EthereumOnArm" tags: - - "clientes" - - "camada de execução" - - "camada de consenso" - - "nós" + [ + "clientes", + "camada de execução", + "camada de consenso", + "nós" + ] lang: pt-br skill: intermediate published: 2022-06-10 @@ -14,34 +16,34 @@ source: Ethereum on ARM sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/ --- -**A Ethereum on Arm é uma imagem personalizada de Linux que pode transformar um Raspberry Pi em um nó Ethereum.** +**O Ethereum on Arm é uma imagem Linux personalizada que pode transformar um Raspberry Pi em um nó Ethereum.** -Para usar Ethereum on Arm para transformar um Raspberry Pi em um nó Ethereum, recomenda-se o seguinte hardware: +Para usar o Ethereum on Arm para transformar um Raspberry Pi em um nó Ethereum, o seguinte hardware é recomendado: -- Raspberry 4 (modelo B 8 GB), placa mãe Odroid M1 ou Rock 5B (8 GB/16 GB RAM) -- Cartão MicroSD (mínimo 16 GB Classe 10) -- 2 TB SSD minimum USB 3.0 disk ou um SSD com USB para SATA case. +- Placa Raspberry 4 (modelo B 8GB), Odroid M1 ou Rock 5B (8GB/16GB de RAM) +- Cartão MicroSD (mínimo de 16 GB Classe 10) +- Disco SSD de no mínimo 2 TB com USB 3.0 ou um SSD com um case USB para SATA. - Fonte de alimentação -- Cabo da Ethernet +- Cabo de Ethernet - Encaminhamento de porta (consulte os clientes para obter mais informações) -- Uma case com dissipador de calor e cooler -- Teclado USB, Monitor e cabo HDMI (micro-HDMI) (Opcional) +- Um case com dissipador de calor e ventoinha +- Teclado USB, monitor e cabo HDMI (micro-HDMI) (Opcional) -## Por que executar Ethereum no ARM? {#why-run-ethereum-on-arm} +## Por que executar o Ethereum em ARM? {#why-run-ethereum-on-arm} -Os painéis ARM são computadores muito acessíveis, flexíveis e pequenos. Eles são boas escolhas para rodar os nós do Ethereum porque são baratos, configurados de forma que todos os recursos foquem em apenas um nó, tornando-os mais eficiente; eles consomem energia e são fisicamente menores, assim cabendo em qualquer casa. Também é muito fácil de rodar nós porque o cartão de memória do Raspberry Pi pode simplesmente ser ligado com uma imagem pré montada, sem precisar de download ou software de montagem. +As placas ARM são computadores pequenos, flexíveis e muito acessíveis. Elas são boas escolhas para executar nós Ethereum por serem baratas e configuráveis para que todos os seus recursos se concentrem apenas no nó, tornando-as eficientes. Consomem pouca energia e são fisicamente pequenas, cabendo discretamente em qualquer casa. Também é muito fácil iniciar nós, pois o MicroSD do Raspberry Pi pode simplesmente ser gravado com uma imagem pré-construída, sem a necessidade de baixar ou construir nenhum software. -## Como funciona? {#how-does-it-work} +## Como isso funciona? {#how-does-it-work} -O cartão de memória do Raspberry Pi já vem com uma imagem pré montada. Esta imagem contém tudo o que é necessário para executar um nó da Ethereum. Com um cartão flash, tudo o que o usuário precisa fazer é ligar o Raspberry Pi. Todos os processos necessários para executar o nó são iniciados automaticamente. Isso funciona porque o cartão de memória contém um sistema operacional baseado no Linux (OS) na qual os processos em nível de sistema rodam automaticamente e se tornam a unidade em um nó de Ethereum. +O cartão de memória do Raspberry Pi é gravado com uma imagem pré-construída. Esta imagem contém tudo o que é necessário para executar um nó da Ethereum. Com um cartão flasheado, tudo o que o usuário precisa fazer é ligar o Raspberry Pi. Todos os processos necessários para executar o nó são iniciados automaticamente. Isso funciona porque o cartão de memória contém um sistema operacional (SO) baseado em Linux, sobre o qual processos de nível de sistema são executados automaticamente que transformam a unidade em um nó Ethereum. -O Ethereum não pode rodar usando o popular Raspberry Pi Linux "Raspbian" porque o Raspbian ainda usa uma arquitetura de 32 bits que leva os Usuários do Ethereum a ter problemas com memória e o cliente de consenso não suporta binários de 32-bits. Para superar isso, a Ethereum on Arm migrou para um OS nativo de 64 bits chamado "Armbian". +O Ethereum não pode ser executado usando o popular SO Linux para Raspberry Pi "Raspbian", pois o Raspbian ainda usa uma arquitetura de 32 bits, o que leva os usuários do Ethereum a terem problemas de memória, e os clientes de consenso não suportam binários de 32 bits. Para superar isso, a equipe Ethereum on Arm migrou para um SO nativo de 64 bits chamado "Armbian". -**As imagens cuidam de todos os passos necessários**, desde configurar o ambiente e formatar o disco SSD até instalar e executar o “software” Ethereum, bem como iniciar a sincronização da blockchain. +**As imagens cuidam de todas as etapas necessárias**, desde a configuração do ambiente e a formatação do disco SSD até a instalação e execução do software Ethereum, bem como o início da sincronização da cadeia de blocos. -## Execução de acoplamento e clientes de consenso {#note-on-execution-and-consensus-clients} +## Nota sobre clientes de execução e de consenso {#note-on-execution-and-consensus-clients} -A imagem do Ethereum on Arm incluí uma execução pré construída e o cliente de consenso como serviços. Um nó Ethereum exige que ambos os clientes estejam sincronizados e executados. Você só precisa fazer o download, instalar a imagem flash e iniciar os serviços. A imagem é pré carregada com os seguintes clientes de execução: +A imagem do Ethereum on Arm inclui clientes de execução e de consenso pré-construídos como serviços. Um nó Ethereum exige que ambos os clientes estejam sincronizados e em execução. Você só precisa baixar e gravar a imagem e, em seguida, iniciar os serviços. A imagem é pré-carregada com os seguintes clientes de execução: - Geth - Nethermind @@ -54,61 +56,61 @@ e os seguintes clientes de consenso: - Prysm - Teku -Você deve escolher um de cada para executar - todos os clientes de execução são compatíveis com todos os clientes de consenso. Se você não selecionar explicitamente um cliente, o nó vai voltar aos seus padrões - Geth e Lighthouse - e executá-los automaticamente quando o quadro estiver ligado. Você precisa abrir a porta 30303 no seu roteador para o Geth Encontrar e conectar-se aos pares. +Você deve escolher um de cada para executar. Todos os clientes de execução são compatíveis com todos os clientes de consenso. Se você não selecionar explicitamente um cliente, o nó voltará aos padrões — Geth e Lighthouse — e os executará automaticamente quando a placa for ligada. Você precisa abrir a porta 30303 no seu roteador para que o Geth possa encontrar e se conectar aos pares. -## Baixando imagem {#downloading-the-image} +## Baixando a imagem {#downloading-the-image} -A imagem Ethereum Raspberry Pi 4 é uma imagem "plug and play" que vai instalar automaticamente e configurar ambos clientes de consenso e de execução, configurando-os para conversarem entre si e conectarem-se à rede Ethereum. Tudo o que o usuário precisa fazer é iniciar seus processos usando um simples comando. +A imagem Ethereum para Raspberry Pi 4 é uma imagem "plug and play" que instala e configura automaticamente os clientes de execução e de consenso, configurando-os para se comunicarem e se conectarem à rede Ethereum. Tudo o que o usuário precisa fazer é iniciar seus processos usando um comando simples. -Baixe a imagem do Raspberry Pi em [Ethereum no Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1) e verifique o hash SHA256: +Baixe a imagem do Raspberry Pi do [Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1) e verifique o hash SHA256: ```sh -# From directory containing the downloaded image +# Do diretório que contém a imagem baixada shasum -a 256 ethonarm_22.04.00.img.zip -# Hash should output: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f +# A saída do hash deve ser: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f ``` -Note que as imagens para as placas Rock 5B e Odroid M1 estão disponíveis no Ethereum-On-Arm [página de downloads](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/). +Observe que as imagens para as placas Rock 5B e Odroid M1 estão disponíveis na [página de downloads](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html) do Ethereum-on-Arm. -## Instalando o MicroSD {#flashing-the-microsd} +## Gravando a imagem no MicroSD {#flashing-the-microsd} -O cartão MicroSD que vai ser usado no Raspberry Pi deve ser primeiro inserido em um desktop ou laptop para que seja instalado. Em seguida, os seguintes comandos do terminal instalarão a imagem baixada no cartão SD: +O cartão MicroSD que será usado para o Raspberry Pi deve primeiro ser inserido em um desktop ou laptop para que possa ser gravado. Em seguida, os seguintes comandos do terminal gravarão a imagem baixada no cartão SD: ```shell -# check the MicroSD card name +# verifique o nome do cartão MicroSD sudo fdisk -l >> sdxxx ``` -É muito importante se atentar ao nome correto pois o próximo comando inclui`dd` que apaga completamente o conteúdo existente do cartão antes de instalar a imagem dentro nele. Para continuar, navegue até o diretório que contém a imagem compactada: +É muito importante usar o nome correto, pois o próximo comando inclui `dd`, que apaga completamente o conteúdo existente do cartão antes de gravar a imagem nele. Para continuar, navegue até o diretório que contém a imagem compactada: ```shell -# unzip and flash image +# descompacte e grave a imagem unzip ethonarm_22.04.00.img.zip sudo dd bs=1M if=ethonarm_22.04.00.img of=/dev/ conv=fdatasync status=progress ``` -O cartão esta instalado, para que seja inserido no Raspberry Pi. +O cartão agora está gravado, então pode ser inserido no Raspberry Pi. ## Inicie o nó {#start-the-node} -Com o cartão SD inserido no Raspberry Pi, conecte o cabo Ethernet e SSD e então ligue o aparelho. O OS vai iniciar e automaticamente começará a executar as tarefas pré-configuradas que transformam o Raspberry Pi em um nó de Ethereum, incluindo a instalação e construção de um software cliente. Isso levará provavelmente 10-15 minutos. +Com o cartão SD inserido no Raspberry Pi, conecte o cabo de Ethernet e o SSD e, em seguida, ligue o dispositivo. O SO será inicializado e começará a executar automaticamente as tarefas pré-configuradas que transformam o Raspberry Pi em um nó Ethereum, incluindo a instalação e a criação do software do cliente. Isso provavelmente levará de 10 a 15 minutos. -Assim que tudo estiver instalado e configurado, faça login no dispositivo via uma conecção ssh ou usando o terminal diretamente se um monitor e teclado estiverem conectados à placa. Use a conta `ethereum` para logar, pois isso tem as permissões necessárioas para iniciar o nó. +Depois que tudo estiver instalado e configurado, faça login no dispositivo por meio de uma conexão ssh ou usando o terminal diretamente se um monitor e um teclado estiverem conectados à placa. Use a conta `ethereum` para fazer login, pois ela tem as permissões necessárias para iniciar o nó. ```shell Usuário: ethereum -Senha: Ethereum +Senha: ethereum ``` -O cliente de execução padrão, Geth, irá iniciar automaticamente. Você pode confirmar isso checando os logs usando o seguinte comando no terminal: +O cliente de execução padrão, Geth, iniciará automaticamente. Você pode confirmar isso verificando os logs com o seguinte comando de terminal: ```sh sudo journalctl -u geth -f ``` -O cliente de consenso precisa de ser iniciado explicitamente. Para fazer isso, primeiro abra a porta 9000 no seu roteador para que o farol possa encontrar e se conectar a pares. Então habilite e inicie o serviço de lighthouse: +O cliente de consenso precisa ser iniciado explicitamente. Para fazer isso, primeiro abra a porta 9000 no seu roteador para que o Lighthouse possa encontrar e se conectar aos pares. Em seguida, ative e inicie o serviço Lighthouse: ```sh sudo systemctl enable lighthouse-beacon @@ -121,15 +123,15 @@ Verifique o cliente usando os logs: sudo journalctl -u lighthouse-beacon ``` -Observe que o cliente de consenso irá sincronizar em alguns minutos porque ele usa a sincronização do ponto de controle. O cliente de execução vai levar mais tempo - Potencialmente algumas horas, e ele não vai executar até que o cliente de consenso termine de sincronizar (isso porque o cliente de execução precisa de um alvo para sincronizar, que o cliente de consenso sincronizado fornece). +Observe que o cliente de consenso será sincronizado em poucos minutos, pois ele usa a sincronização por checkpoint. O cliente de execução levará mais tempo (potencialmente várias horas) e não será iniciado até que o cliente de consenso termine a sincronização (isso ocorre porque o cliente de execução precisa de um alvo para sincronizar, que é fornecido pelo cliente de consenso já sincronizado). -Com os serviços Geth e Lighthouse sincronizados e rodando, seu Raspberry Pi agora é um nó de Ethereum! É mais comum interagir com a rede Ethereum utilizando o console Javascript do Geth, que pode ser anexado ao cliente Geth na porta 8545. Também é possível enviar comandos formatados como objetos JSON usando uma ferramenta de solicitação como o Curl. Veja mais em [Documentação Geth](https://geth.ethereum.org/). +Com os serviços Geth e Lighthouse em execução e sincronizados, seu Raspberry Pi agora é um nó Ethereum! É mais comum interagir com a rede Ethereum utilizando o console Javascript do Geth, que pode ser anexado ao cliente Geth na porta 8545. Também é possível enviar comandos formatados como objetos JSON usando uma ferramenta de solicitação como o Curl. Veja mais na [documentação do Geth](https://geth.ethereum.org/). -Geth é pré configurado para enviar relatórios pro painel Grafana, que pode ser visto no seu navegador. Usuários mais avançados podem querer usar este recurso para monitorar a saúde do seu nó navegando para `ipaddress.3000`, passing`usuário: admin` e `senha:ethereum`. +O Geth é pré-configurado para relatar métricas a um painel do Grafana que pode ser visualizado no navegador. Usuários mais avançados podem querer usar este recurso para monitorar a saúde de seu nó navegando para `ipaddress:3000`, passando `usuário: admin` e `senha: ethereum`. ## Validadores {#validators} -Um validador também pode ser opcionalmente adicionado ao cliente de consenso. O software validador permite seu nó de participar ativamente no consenso e fornece a rede com segurança criptoeconomica. Você será recompensado por este trabalho em ETH. Para rodar um validador, você precisa primeiro ter 32 ETH, que precisa ser depositado em um contrato de depósito. **Este é um termo de compromisso a longo prazo - ainda não é possível sacar este ETH!**. O depósito pode ser feito seguindo o passo a passo no [Launchpad](https://launchpad.ethereum.org/). Faça isso em um desktop/laptop, mas não gere chaves — isso pode ser feito diretamente no Raspberry Pi. +Um validador também pode ser adicionado opcionalmente ao cliente de consenso. O software do validador permite que seu nó participe ativamente do consenso e fornece segurança criptoeconômica à rede. Você é recompensado por este trabalho em ETH. Para executar um validador, você deve primeiro ter 32 ETH, que devem ser depositados no contrato de depósito. O depósito pode ser feito seguindo o guia passo a passo na [Plataforma de lançamento](https://launchpad.ethereum.org/). Faça isso em um desktop/laptop, mas não gere chaves — isso pode ser feito diretamente no Raspberry Pi. Abra um terminal no Raspberry Pi e execute o seguinte comando para gerar as chaves de depósito: @@ -139,32 +141,35 @@ sudo apt-get install staking-deposit-cli cd && deposit new-mnemonic --num_validators 1 ``` -Mantenha a frase mnemônica segura! O comando acima gerou dois arquivos no keystore: as chaves validadoras e um arquivo de dados de depósito. Os dados do depósito precisam ser carregados no launchpad, portanto, devem ser copiados do Raspberry Pi para o desktop/laptop. Isso pode ser feito usando uma conexão ssh ou qualquer outro método de copiar/colar. +(Ou baixe o [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) para executar em uma máquina isolada (air-gapped) e execute o comando `deposit new-mnemnonic`) -Uma vez que o arquivo de dados do depósito estiver disponível no computador que executa o launchpad, ele pode ser arrastado e solto no `+` na tela do launchpad. Siga as instruções na tela para enviar uma transação para o contrato de depósito. +Mantenha a frase mnemônica segura! O comando acima gerou dois arquivos no keystore do nó: as chaves do validador e um arquivo de dados de depósito. Os dados de depósito precisam ser carregados na plataforma de lançamento, portanto, eles devem ser copiados do Raspberry Pi para o desktop/laptop. Isso pode ser feito usando uma conexão ssh ou qualquer outro método de copiar/colar. -De volta ao Raspberry Pi, um validador pode ser iniciado. Isso requer importar as chaves do validador, definir o endereço para coletar recompensas e, em seguida, iniciar o processo do validador pré-configurado. O exemplo abaixo é para o Lighthouse - instruções para outros clientes de consenso estão disponíveis na [Ethereum on Arm docs](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/): +Quando o arquivo de dados de depósito estiver disponível no computador que executa a plataforma de lançamento, ele poderá ser arrastado e solto no `+` na tela da plataforma de lançamento. Siga as instruções na tela para enviar uma transação para o contrato de depósito. + +De volta ao Raspberry Pi, um validador pode ser iniciado. Isso requer importar as chaves do validador, definir o endereço para coletar recompensas e, em seguida, iniciar o processo do validador pré-configurado. O exemplo abaixo é para o Lighthouse — as instruções para outros clientes de consenso estão disponíveis nos [documentos do Ethereum on Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/): ```shell -# import the validator keys +# importe as chaves do validador lighthouse account validator import --directory=/home/ethereum/validator_keys -# set the reward address +# defina o endereço de recompensa sudo sed -i 's/' /etc/ethereum/lighthouse-validator.conf -# start the validator +# inicie o validador sudo systemctl start lighthouse-validator ``` -Parabéns, agora você tem um nó Ethereum completo e um validador rodando em um Raspberry Pi! +Parabéns, agora você tem um nó e validador Ethereum completos em execução em um Raspberry Pi! ## Mais detalhes {#more-details} -Esta página deu uma visão geral de como configurar um nó e validador Geth-Lighthouse usando Raspberry Pi. Instruções mais detalhadas estão disponíveis no [site Ethereum-on-Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/). +Esta página deu uma visão geral de como configurar um nó e validador Geth-Lighthouse usando Raspberry Pi. Instruções mais detalhadas estão disponíveis no [site do Ethereum-on-Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html). -## Agradecemos o feedback {#feedback-appreciated} +## Agradecemos o seu feedback {#feedback-appreciated} -Sabemos que o Raspberry Pi tem uma enorme base de usuários, que pode ter um impacto muito positivo na saúde da rede Ethereum. Por favor, explore os detalhes deste tutorial, tente rodar em redes de teste, confira o Ethereum on Arm pelo GitHub, dê feedback, levante questões e pull requests e ajude a avançar a tecnologia e a documentação! +Sabemos que o Raspberry Pi tem uma enorme base de usuários, que pode ter um impacto muito positivo na saúde da rede Ethereum. +Por favor, aprofunde-se nos detalhes deste tutorial, tente executá-lo em redes de teste, confira o GitHub do Ethereum on Arm, dê seu feedback, relate problemas e envie pull requests para ajudar no avanço da tecnologia e da documentação! ## Referências {#references} @@ -178,7 +183,7 @@ Sabemos que o Raspberry Pi tem uma enorme base de usuários, que pode ter um imp 8. https://www.hyperledger.org/projects/besu 9. https://github.com/prysmaticlabs/prysm 10. https://lighthouse.sigmaprime.io -11. https://docs.ethswarm.org/ +11. https://ethersphere.github.io/swarm-home 12. https://raiden.network 13. https://ipfs.io 14. https://status.im diff --git a/public/content/translations/pt-br/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/pt-br/developers/tutorials/scam-token-tricks/index.md new file mode 100644 index 00000000000..25354c9d166 --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/scam-token-tricks/index.md @@ -0,0 +1,470 @@ +--- +title: "Alguns truques usados por tokens fraudulentos e como detectá-los" +description: "Neste tutorial, dissecamos um token fraudulento para ver alguns dos truques que os golpistas usam, como eles os implementam e como podemos detectá-los." +author: Ori Pomerantz +tags: + [ + "fraude", + "Solidity", + "erc-20", + "JavaScript", + "TypeScript" + ] +skill: intermediate +published: 2023-09-15 +lang: pt-br +--- + +Neste tutorial, dissecamos [um token fraudulento](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) para ver alguns dos truques que os golpistas usam e como eles os implementam. Ao final do tutorial, você terá uma visão mais abrangente dos contratos de token ERC-20, suas capacidades e por que o ceticismo é necessário. Então, olhamos para os eventos emitidos por esse token fraudulento e vemos como podemos identificar que ele não é legítimo automaticamente. + +## Tokens fraudulentos - o que são, por que as pessoas os criam e como evitá-los {#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. Entretanto, sempre onde há casos de uso legítimos que agregam valor, também haverá criminosos que tentam roubar esse valor. + +Você pode ler mais sobre este assunto [em outro lugar em ethereum.org](/guides/how-to-id-scam-tokens/) da perspectiva do usuário. Este tutorial foca em dissecar um token fraudulento para ver como é feito e como ele pode ser detectado. + +### Como eu sei que o wARB é uma fraude? {#warb-scam} + +O token que dissecamos é o [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code), que finge ser equivalente ao [token ARB](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) legítimo. + +A maneira mais fácil de saber qual é o token legítimo é olhar para a organização de origem, a [Arbitrum](https://arbitrum.foundation/). Os endereços legítimos são especificados [na documentação deles](https://docs.arbitrum.foundation/deployment-addresses#token). + +### Por que o código-fonte está disponível? {#why-source} + +Normalmente, esperaríamos que pessoas que tentam enganar outras fossem sigilosas e, de fato, muitos tokens fraudulentos não têm seu código disponível (por exemplo, [este](https://optimistic.etherscan.io/token/0x15992f382d8c46d667b10dc8456dc36651af1452#code) e [este](https://optimistic.etherscan.io/token/0x026b623eb4aada7de37ef25256854f9235207178#code)). + +No entanto, os tokens legítimos geralmente publicam seu código-fonte, então, para parecerem legítimos, os autores de tokens fraudulentos às vezes fazem o mesmo. O [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) é um desses tokens com código-fonte disponível, o que facilita o seu entendimento. + +Embora os implantadores de contratos possam escolher publicar ou não o código-fonte, eles _não podem_ publicar o código-fonte errado. O explorador de blocos compila o código-fonte fornecido de forma independente e, se não obtiver o mesmo bytecode exato, ele rejeita esse código-fonte. [Você pode ler mais sobre isso no site do Etherscan](https://etherscan.io/verifyContract). + +## Comparação com tokens ERC-20 legítimos {#compare-legit-erc20} + +Vamos comparar este token com tokens ERC-20 legítimos. Se você não está familiarizado com a forma como os tokens ERC-20 legítimos são normalmente escritos, [veja este tutorial](/developers/tutorials/erc20-annotated-code/). + +### Constantes para endereços privilegiados {#constants-for-privileged-addresses} + +Os contratos às vezes precisam de endereços privilegiados. Contratos projetados para uso a longo prazo permitem que alguns endereços privilegiados alterem esses endereços, por exemplo, para permitir o uso de um novo contrato multisig. Existem várias maneiras de fazer isso. + +O [contrato do token `HOP`](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code) usa o padrão [`Ownable`](https://docs.openzeppelin.com/contracts/2.x/access-control#ownership-and-ownable). O endereço privilegiado é mantido no armazenamento, em um campo chamado `_owner` (veja o terceiro arquivo, `Ownable.sol`). + +```solidity +abstract contract Ownable is Context { + address private _owner; + . + . + . +} +``` + +O [contrato do token `ARB`](https://etherscan.io/address/0xad0c361ef902a7d9851ca7dcc85535da2d3c6fc7#code) não tem um endereço privilegiado diretamente. No entanto, ele não precisa de um. Ele está por trás de um [`proxy`](https://docs.openzeppelin.com/contracts/5.x/api/proxy) no [endereço `0xb50721bcf8d664c30412cfbc6cf7a15145234ad1`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1#code). Esse contrato tem um endereço privilegiado (veja o quarto arquivo, `ERC1967Upgrade.sol`) que pode ser usado para atualizações. + +```solidity + /** + * @dev Armazena um novo endereço no slot de administrador do EIP1967. + */ + function _setAdmin(address newAdmin) private { + require(newAdmin != address(0), "ERC1967: new admin is the zero address"); + StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin; + } +``` + +Em contraste, o contrato `wARB` tem um `contract_owner` codificado permanentemente. + +```solidity +contract WrappedArbitrum is Context, IERC20 { + . + . + . + address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1; + address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33; + . + . + . +} +``` + +[Este proprietário do contrato](https://etherscan.io/address/0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33) não é um contrato que poderia ser controlado por contas diferentes em momentos diferentes, mas uma [conta de propriedade externa](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs). Isso significa que ele provavelmente foi projetado para uso a curto prazo por um indivíduo, em vez de uma solução de longo prazo para controlar um ERC-20 que permanecerá valioso. + +E, de fato, se olharmos no Etherscan, vemos que o golpista usou este contrato por apenas 12 horas ([primeira transação](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2) até a [última transação](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b)) durante o dia 19 de maio de 2023. + +### A função `_transfer` falsa {#the-fake-transfer-function} + +É padrão que as transferências reais aconteçam usando [uma função `_transfer` interna](/developers/tutorials/erc20-annotated-code/#the-_transfer-function-_transfer). + +No `wARB`, esta função parece quase legítima: + +```solidity + function _transfer(address sender, address recipient, uint256 amount) internal virtual{ + require(sender != address(0), "ERC20: transfer from the zero address"); + require(recipient != address(0), "ERC20: transfer to the zero address"); + + _beforeTokenTransfer(sender, recipient, amount); + + _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance"); + _balances[recipient] = _balances[recipient].add(amount); + if (sender == contract_owner){ + sender = deployer; + } + emit Transfer(sender, recipient, amount); + } +``` + +A parte suspeita é: + +```solidity + if (sender == contract_owner){ + sender = deployer; + } + emit Transfer(sender, recipient, amount); +``` + +Se o proprietário do contrato envia tokens, por que o evento `Transfer` mostra que eles vêm do `deployer`? + +No entanto, há um problema mais importante. Quem chama esta função `_transfer`? Não pode ser chamada de fora, ela está marcada como `internal`. E o código que temos não inclui nenhuma chamada para `_transfer`. Claramente, está aqui como uma isca. + +```solidity + function transfer(address recipient, uint256 amount) public virtual override returns (bool) { + _f_(_msgSender(), recipient, amount); + return true; + } + + function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { + _f_(sender, recipient, amount); + _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance")); + return true; + } +``` + +Quando olhamos para as funções que são chamadas para transferir tokens, `transfer` e `transferFrom`, vemos que elas chamam uma função completamente diferente, `_f_`. + +### A função `_f_` real {#the-real-f-function} + +```solidity + function _f_(address sender, address recipient, uint256 amount) internal _mod_(sender,recipient,amount) virtual { + require(sender != address(0), "ERC20: transfer from the zero address"); + require(recipient != address(0), "ERC20: transfer to the zero address"); + + _beforeTokenTransfer(sender, recipient, amount); + + _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance"); + _balances[recipient] = _balances[recipient].add(amount); + if (sender == contract_owner){ + + sender = deployer; + } + emit Transfer(sender, recipient, amount); + } +``` + +Há duas bandeiras vermelhas em potencial nesta função. + +- O uso do [modificador de função](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_`. No entanto, quando olhamos o código-fonte, vemos que `_mod_` é na verdade inofensivo. + + ```solidity + modifier _mod_(address sender, address recipient, uint256 amount){ + _; + } + ``` + +- O mesmo problema que vimos em `_transfer`, que é quando o `contract_owner` envia tokens, eles parecem vir do `deployer`. + +### A função de eventos falsos `dropNewTokens` {#the-fake-events-function-dropNewTokens} + +Agora chegamos a algo que parece uma fraude real. Editei um pouco a função para facilitar a leitura, mas é funcionalmente equivalente. + +```solidity +function dropNewTokens(address uPool, + address[] memory eReceiver, + uint256[] memory eAmounts) public auth() +``` + +Esta função tem o modificador `auth()`, o que significa que só pode ser chamada pelo proprietário do contrato. + +```solidity +modifier auth() { + require(msg.sender == contract_owner, "Not allowed to interact"); + _; +} +``` + +Essa restrição faz todo o sentido, porque não queremos que contas aleatórias distribuam tokens. No entanto, o resto da função é suspeito. + +```solidity +{ + for (uint256 i = 0; i < eReceiver.length; i++) { + emit Transfer(uPool, eReceiver[i], eAmounts[i]); + } +} +``` + +Uma função para transferir de uma conta de pool para uma matriz de receptores e uma matriz de valores faz todo o sentido. Existem muitos casos de uso em que você desejará distribuir tokens de uma única fonte para vários destinos, como folha de pagamento, airdrops, etc. É mais barato (em gás) fazer em uma única transação em vez de emitir várias transações, ou até mesmo chamar o ERC-20 várias vezes de um contrato diferente como parte da mesma transação. + +No entanto, `dropNewTokens` não faz isso. Ele emite [eventos `Transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer-1), mas na verdade não transfere nenhum token. Não há razão legítima para confundir aplicações off-chain informando-as de uma transferência que não aconteceu de verdade. + +### A função de queima `Approve` {#the-burning-approve-function} + +Contratos ERC-20 devem ter [uma função `approve`](/developers/tutorials/erc20-annotated-code/#approve) para permissões e, de fato, nosso token fraudulento tem essa função, e ela está até correta. No entanto, como o Solidity descende do C, ele diferencia maiúsculas de minúsculas. "Approve" e "approve" são strings diferentes. + +Além disso, a funcionalidade não está relacionada a `approve`. + +```solidity + function Approve( + address[] memory holders) +``` + +Esta função é chamada com uma matriz de endereços para detentores do token. + +```solidity + public approver() { +``` + +O modificador `approver()` garante que apenas o `contract_owner` tenha permissão para chamar esta função (veja abaixo). + +```solidity + for (uint256 i = 0; i < holders.length; i++) { + uint256 amount = _balances[holders[i]]; + _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount); + _balances[holders[i]] = _balances[holders[i]].sub(amount, + "ERC20: burn amount exceeds balance"); + _balances[0x0000000000000000000000000000000000000001] = + _balances[0x0000000000000000000000000000000000000001].add(amount); + } + } + +``` + +Para cada endereço de detentor, a função move todo o saldo do detentor para o endereço `0x00...01`, efetivamente queimando-o (o `burn` real no padrão também altera o fornecimento total e transfere os tokens para `0x00...00`). Isso significa que o `contract_owner` pode remover os ativos de qualquer usuário. Isso não parece um recurso que você gostaria em um token de governança. + +### Problemas de qualidade do código {#code-quality-issues} + +Esses problemas de qualidade do código não _provam_ que este código é uma fraude, mas o tornam suspeito. Empresas organizadas como a Arbitrum geralmente não lançam códigos tão ruins. + +#### A função `mount` {#the-mount-function} + +Embora não seja especificado no [padrão](https://eips.ethereum.org/EIPS/eip-20), geralmente, a função que cria novos tokens é chamada de [`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn). + +Se olharmos no construtor do `wARB`, vemos que a função de cunhagem foi renomeada para `mount` por algum motivo e é chamada cinco vezes com um quinto do fornecimento inicial, em vez de uma vez para o valor total por eficiência. + +```solidity + constructor () public { + + _name = "Wrapped Arbitrum"; + _symbol = "wARB"; + _decimals = 18; + uint256 initialSupply = 1000000000000; + + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + } +``` + +A própria função `mount` também é suspeita. + +```solidity + function mount(address account, uint256 amount) public { + require(msg.sender == contract_owner, "ERC20: mint to the zero address"); +``` + +Olhando para o `require`, vemos que apenas o proprietário do contrato tem permissão para cunhar. Isso é legítimo. Mas a mensagem de erro deveria ser _apenas o proprietário tem permissão para cunhar_ ou algo parecido. Em vez disso, é o irrelevante _ERC20: cunhar para o endereço zero_. O teste correto para cunhagem para o endereço zero é `require(account != address(0), "")`, que o contrato nunca se preocupa em verificar. + +```solidity + _totalSupply = _totalSupply.add(amount); + _balances[contract_owner] = _balances[contract_owner].add(amount); + emit Transfer(address(0), account, amount); + } +``` + +Existem mais dois fatos suspeitos, diretamente relacionados à cunhagem: + +- Existe um parâmetro `account`, que é presumivelmente a conta que deve receber o valor cunhado. Mas o saldo que aumenta é na verdade o do `contract_owner`. + +- Embora o saldo aumentado pertença ao `contract_owner`, o evento emitido mostra uma transferência para `account`. + +### Por que tanto `auth` quanto `approver`? Por que o `mod` que não faz nada? {#why-both-autho-and-approver-why-the-mod-that-does-nothing} + +Este contrato contém três modificadores: `_mod_`, `auth` e `approver`. + +```solidity + modifier _mod_(address sender, address recipient, uint256 amount){ + _; + } +``` + +`_mod_` recebe três parâmetros e não faz nada com eles. Por que tê-lo? + +```solidity + modifier auth() { + require(msg.sender == contract_owner, "Not allowed to interact"); + _; + } + + modifier approver() { + require(msg.sender == contract_owner, "Not allowed to interact"); + _; + } +``` + +`auth` e `approver` fazem mais sentido, porque verificam se o contrato foi chamado pelo `contract_owner`. Esperaríamos que certas ações privilegiadas, como a cunhagem, fossem limitadas a essa conta. No entanto, qual é o sentido de ter duas funções separadas que fazem _precisamente a mesma coisa_? + +## O que podemos detectar automaticamente? {#what-can-we-detect-automatically} + +Podemos ver que o `wARB` é um token fraudulento olhando no Etherscan. No entanto, essa é uma solução centralizada. Em teoria, o Etherscan poderia ser subvertido ou hackeado. É melhor ser capaz de descobrir independentemente se um token é legítimo ou não. + +Existem alguns truques que podemos usar para identificar que um token ERC-20 é suspeito (seja uma fraude ou muito mal escrito), olhando para os eventos que eles emitem. + +## Eventos `Approval` suspeitos {#suspicious-approval-events} + +[Eventos de `Approval`](https://eips.ethereum.org/EIPS/eip-20#approval) devem ocorrer apenas com uma solicitação direta (em contraste com os [eventos de `Transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer-1), que podem ocorrer como resultado de uma permissão). [Veja a documentação do Solidity](https://docs.soliditylang.org/en/v0.8.20/security-considerations.html#tx-origin) para uma explicação detalhada sobre este problema e por que as solicitações precisam ser diretas, em vez de mediadas por um contrato. + +Isso significa que os eventos `Approval` que aprovam o gasto de uma [conta de propriedade externa](/developers/docs/accounts/#types-of-account) devem vir de transações que se originam nessa conta e cujo destino é o contrato ERC-20. Qualquer outro tipo de aprovação de uma conta de propriedade externa é suspeito. + +Aqui está [um programa que identifica esse tipo de evento](https://github.com/qbzzt/20230915-scam-token-detection), usando [viem](https://viem.sh/) e [TypeScript](https://www.typescriptlang.org/docs/), uma variante do JavaScript com segurança de tipo. Para executá-lo: + +1. Copie `.env.example` para `.env`. +2. Edite `.env` para fornecer o URL para um nó da rede principal do Ethereum. +3. Execute `pnpm install` para instalar os pacotes necessários. +4. Execute `pnpm susApproval` para procurar aprovações suspeitas. + +Aqui está uma explicação linha por linha: + +```typescript +import { + Address, + TransactionReceipt, + createPublicClient, + http, + parseAbiItem, +} from "viem" +import { mainnet } from "viem/chains" +``` + +Importe definições de tipo, funções e a definição da cadeia de `viem`. + +```typescript +import { config } from "dotenv" +config() +``` + +Leia `.env` para obter o URL. + +```typescript +const client = createPublicClient({ + chain: mainnet, + transport: http(process.env.URL), +}) +``` + +Crie um cliente Viem. Só precisamos ler da blockchain, então este cliente não precisa de uma chave privada. + +```typescript +const testedAddress = "0xb047c8032b99841713b8e3872f06cf32beb27b82" +const fromBlock = 16859812n +const toBlock = 16873372n +``` + +O endereço do contrato ERC-20 suspeito e os blocos dentro dos quais procuraremos por eventos. Os provedores de nó normalmente limitam nossa capacidade de ler eventos porque a largura de banda pode ficar cara. Felizmente, o `wARB` não foi usado por um período de dezoito horas, então podemos procurar por todos os eventos (havia apenas 13 no total). + +```typescript +const approvalEvents = await client.getLogs({ + address: testedAddress, + fromBlock, + toBlock, + event: parseAbiItem( + "event Approval(address indexed _owner, address indexed _spender, uint256 _value)" + ), +}) +``` + +Esta é a maneira de solicitar informações de eventos ao Viem. Quando fornecemos a assinatura exata do evento, incluindo os nomes dos campos, ele analisa o evento para nós. + +```typescript +const isContract = async (addr: Address): boolean => + await client.getBytecode({ address: addr }) +``` + +Nosso algoritmo é aplicável apenas a contas de propriedade externa. Se houver algum bytecode retornado por `client.getBytecode`, isso significa que se trata de um contrato e devemos simplesmente pulá-lo. + +Se você nunca usou o TypeScript antes, a definição da função pode parecer um pouco estranha. Não apenas dizemos que o primeiro (e único) parâmetro é chamado `addr`, mas também que ele é do tipo `Address`. Da mesma forma, a parte `: boolean` diz ao TypeScript que o valor de retorno da função é um booleano. + +```typescript +const getEventTxn = async (ev: Event): TransactionReceipt => + await client.getTransactionReceipt({ hash: ev.transactionHash }) +``` + +Esta função obtém o recibo da transação de um evento. Precisamos do recibo para garantir que sabemos qual foi o destino da transação. + +```typescript +const suspiciousApprovalEvent = async (ev : Event) : (Event | null) => { +``` + +Esta é a função mais importante, a que realmente decide se um evento é suspeito ou não. O tipo de retorno, `(Event | null)`, informa ao TypeScript que esta função pode retornar um `Event` ou `null`. Retornamos `null` se o evento não for suspeito. + +```typescript +const owner = ev.args._owner +``` + +O Viem tem os nomes dos campos, então ele analisou o evento para nós. `_owner` é o proprietário dos tokens a serem gastos. + +```typescript +// Aprovações por contratos não são suspeitas +if (await isContract(owner)) return null +``` + +Se o proprietário for um contrato, presuma que essa aprovação não é suspeita. Para verificar se a aprovação de um contrato é suspeita ou não, precisaremos rastrear a execução completa da transação para ver se ela chegou ao contrato do proprietário e se esse contrato chamou o contrato ERC-20 diretamente. Isso consome muito mais recursos do que gostaríamos. + +```typescript +const txn = await getEventTxn(ev) +``` + +Se a aprovação vier de uma conta de propriedade externa, obtenha a transação que a causou. + +```typescript +// A aprovação é suspeita se vier de um proprietário de EOA que não é o `from` da transação +if (owner.toLowerCase() != txn.from.toLowerCase()) return ev +``` + +Não podemos simplesmente verificar a igualdade de strings porque os endereços são hexadecimais, então eles contêm letras. Às vezes, por exemplo em `txn.from`, essas letras são todas minúsculas. Em outros casos, como `ev.args._owner`, o endereço está em [maiúsculas e minúsculas misturadas para identificação de erros](https://eips.ethereum.org/EIPS/eip-55). + +Mas se a transação não for do proprietário, e esse proprietário for de propriedade externa, então temos uma transação suspeita. + +```typescript +// Também é suspeito se o destino da transação não for o contrato ERC-20 que estamos +// investigando +if (txn.to.toLowerCase() != testedAddress) return ev +``` + +Da mesma forma, se o endereço `to` da transação, o primeiro contrato chamado, não for o contrato ERC-20 sob investigação, então é suspeito. + +```typescript + // Se não houver motivo para suspeitar, retorne nulo. + return null +} +``` + +Se nenhuma das condições for verdadeira, o evento `Approval` não é suspeito. + +```typescript +const testPromises = approvalEvents.map((ev) => suspiciousApprovalEvent(ev)) +const testResults = (await Promise.all(testPromises)).filter((x) => x != null) + +console.log(testResults) +``` + +[Uma função `async`](https://www.w3schools.com/js/js_async.asp) retorna um objeto `Promise`. Com a sintaxe comum, `await x()`, esperamos que essa `Promise` seja cumprida antes de continuarmos o processamento. Isso é simples de programar e seguir, mas também é ineficiente. Enquanto esperamos que a `Promise` de um evento específico seja cumprida, já podemos começar a trabalhar no próximo evento. + +Aqui usamos [`map`](https://www.w3schools.com/jsref/jsref_map.asp) para criar uma matriz de objetos `Promise`. Em seguida, usamos [`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/) para esperar que todas essas promessas sejam resolvidas. Em seguida, [`filter`](https://www.w3schools.com/jsref/jsref_filter.asp) esses resultados para remover os eventos não suspeitos. + +### Eventos `Transfer` suspeitos {#suspicious-transfer-events} + +Outra maneira possível de identificar tokens fraudulentos é ver se eles têm alguma transferência suspeita. Por exemplo, transferências de contas que não têm tantos tokens. Você pode ver [como implementar este teste](https://github.com/qbzzt/20230915-scam-token-detection/blob/main/susTransfer.ts), mas o `wARB` não tem este problema. + +## Conclusão {#conclusion} + +A detecção automatizada de fraudes ERC-20 sofre de [falsos negativos](https://en.wikipedia.org/wiki/False_positives_and_false_negatives#False_negative_error), porque uma fraude pode usar um contrato de token ERC-20 perfeitamente normal que simplesmente não representa nada real. Portanto, você deve sempre tentar _obter o endereço do token de uma fonte confiável_. + +A detecção automatizada pode ajudar em certos casos, como peças de DeFi, onde há muitos tokens e eles precisam ser tratados automaticamente. Mas como sempre [caveat emptor](https://www.investopedia.com/terms/c/caveatemptor.asp), faça sua própria pesquisa e incentive seus usuários a fazerem o mesmo. + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). diff --git a/public/content/translations/pt-br/developers/tutorials/secret-state/index.md b/public/content/translations/pt-br/developers/tutorials/secret-state/index.md new file mode 100644 index 00000000000..8609bc79fed --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/secret-state/index.md @@ -0,0 +1,740 @@ +--- +title: Usando conhecimento zero para um estado secreto +description: "Os jogos em cadeia são limitados porque não conseguem manter nenhuma informação oculta. Após ler este tutorial, o leitor será capaz de combinar provas de conhecimento zero e componentes de servidor para criar jogos verificáveis com um estado secreto, fora da cadeia, componente. A técnica para fazer isso será demonstrada com a criação de um jogo de campo minado." +author: Ori Pomerantz +tags: + [ + "servidor", + "fora da cadeia", + "centralizado", + "conhecimento zero", + "zokrates", + "mud" + ] +skill: advanced +lang: pt-br +published: 2025-03-15 +--- + +_Não há segredos na blockchain_. Tudo o que é publicado na cadeia de blocos é aberto para que todos leiam. Isso é necessário, porque a cadeia de blocos se baseia na capacidade de qualquer pessoa poder verificá-la. No entanto, os jogos geralmente dependem de um estado secreto. Por exemplo, o jogo de [campo minado](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) não faz o menor sentido se você puder simplesmente acessar um explorador da cadeia de blocos e ver o mapa. + +A solução mais simples é usar um [componente de servidor](/developers/tutorials/server-components/) para manter o estado secreto. No entanto, a razão pela qual usamos a cadeia de blocos é para impedir que o desenvolvedor do jogo trapaceie. Precisamos garantir a honestidade do componente do servidor. O servidor pode fornecer um hash do estado e usar [provas de conhecimento zero](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) para provar que o estado usado para calcular o resultado de um movimento é o correto. + +Após ler este artigo, você saberá como criar este tipo de servidor que detém o estado secreto, um cliente para mostrar o estado e um componente em cadeia para comunicação entre os dois. As principais ferramentas que usaremos serão: + +| Ferramenta | Propósito | Verificado na versão | +| --------------------------------------------- | ---------------------------------------------------- | --------------------------------------: | +| [Zokrates](https://zokrates.github.io/) | Provas de conhecimento zero e sua verificação | 1.1.9 | +| [Typescript](https://www.typescriptlang.org/) | Linguagem de programação para o servidor e o cliente | 5.4.2 | +| [Node](https://nodejs.org/en) | Executando o servidor | 20.18.2 | +| [Viem](https://viem.sh/) | Comunicação com a cadeia de blocos | 2.9.20 | +| [MUD](https://mud.dev/) | Gerenciamento de dados em cadeia | 2.0.12 | +| [React](https://react.dev/) | Interface do usuário do cliente | 18.2.0 | +| [Vite](https://vitejs.dev/) | Servindo o código do cliente | 4.2.1 | + +## Exemplo de Campo Minado {#minesweeper} + +[Campo Minado](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) é um jogo que inclui um mapa secreto com um campo minado. O jogador escolhe cavar em um local específico. Se esse local tiver uma mina, o jogo acaba. Caso contrário, o jogador obtém o número de minas nos oito quadrados ao redor daquele local. + +Esta aplicação é escrita usando [MUD](https://mud.dev/), uma estrutura que nos permite armazenar dados em cadeia usando um [banco de dados chave-valor](https://aws.amazon.com/nosql/key-value/) e sincronizar esses dados automaticamente com componentes fora da cadeia. Além da sincronização, o MUD facilita o controle de acesso e permite que outros usuários [estendam](https://mud.dev/guides/extending-a-world) nossa aplicação sem permissão. + +### Executando o exemplo de Campo Minado {#running-minesweeper-example} + +Para executar o exemplo do Campo Minado: + +1. Certifique-se de que você [tenha os pré-requisitos instalados](https://mud.dev/quickstart#prerequisites): [Node](https://mud.dev/quickstart#prerequisites), [Foundry](https://book.getfoundry.sh/getting-started/installation), [`git`](https://git-scm.com/downloads), [`pnpm`](https://git-scm.com/downloads) e [`mprocs`](https://github.com/pvolok/mprocs). + +2. Clone o repositório. + + ```sh copy + git clone https://github.com/qbzzt/20240901-secret-state.git + ``` + +3. Instale os pacotes. + + ```sh copy + cd 20240901-secret-state/ + pnpm install + npm install -g mprocs + ``` + + Se o Foundry foi instalado como parte do `pnpm install`, você precisa reiniciar o shell da linha de comando. + +4. Compile os contratos + + ```sh copy + cd packages/contracts + forge build + cd ../.. + ``` + +5. Inicie o programa (incluindo uma cadeia de blocos [anvil](https://book.getfoundry.sh/anvil/)) e aguarde. + + ```sh copy + mprocs + ``` + + Observe que a inicialização leva muito tempo. Para ver o progresso, primeiro use a seta para baixo para rolar até a guia _contracts_ para ver os contratos MUD sendo implantados. Quando você receber a mensagem _Waiting for file changes…_, os contratos serão implantados e o progresso adicional ocorrerá na guia _server_. Lá, você espera até receber a mensagem _Verifier address: 0x...._. + + Se esta etapa for bem-sucedida, você verá a tela `mprocs`, com os diferentes processos à esquerda e a saída do console para o processo atualmente selecionado à direita. + + ![A tela mprocs](./mprocs.png) + + Se houver um problema com `mprocs`, você pode executar os quatro processos manualmente, cada um em sua própria janela de linha de comando: + + - **Anvil** + + ```sh + cd packages/contracts + anvil --base-fee 0 --block-time 2 + ``` + + - **Contratos** + + ```sh + cd packages/contracts + pnpm mud dev-contracts --rpc http://127.0.0.1:8545 + ``` + + - **Servidor** + + ```sh + cd packages/server + pnpm start + ``` + + - **Cliente** + + ```sh + cd packages/client + pnpm run dev + ``` + +6. Agora você pode navegar para [o cliente](http://localhost:3000), clicar em **Novo Jogo** e começar a jogar. + +### Tabelas {#tables} + +Precisamos de [várias tabelas](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts) em cadeia. + +- `Configuration`: esta tabela é um singleton, não tem chave e um único registro. É usada para manter informações de configuração do jogo: + - `height`: a altura de um campo minado + - `width`: a largura de um campo minado + - `numberOfBombs`: o número de bombas em cada campo minado + +- `VerifierAddress`: esta tabela também é um singleton. É usada para conter uma parte da configuração, o endereço do contrato do verificador (`verifier`). Poderíamos ter colocado essa informação na tabela `Configuration`, mas ela é definida por um componente diferente, o servidor, então é mais fácil colocá-la em uma tabela separada. + +- `PlayerGame`: a chave é o endereço do jogador. Os dados são: + + - `gameId`: valor de 32 bytes que é o hash do mapa em que o jogador está jogando (o identificador do jogo). + - `win`: um booleano que indica se o jogador ganhou o jogo. + - `lose`: um booleano que indica se o jogador perdeu o jogo. + - `digNumber`: o número de escavações bem-sucedidas no jogo. + +- `GamePlayer`: esta tabela contém o mapeamento inverso, do `gameId` para o endereço do jogador. + +- `Map`: a chave é uma tupla de três valores: + + - `gameId`: valor de 32 bytes que é o hash do mapa em que o jogador está jogando (o identificador do jogo). + - coordenada `x` + - coordenada `y` + + O valor é um único número. É 255 se uma bomba foi detectada. Caso contrário, é o número de bombas ao redor desse local mais um. Não podemos usar apenas o número de bombas, porque, por padrão, todo o armazenamento na EVM e todos os valores de linha no MUD são zero. Precisamos distinguir entre "o jogador ainda não cavou aqui" e "o jogador cavou aqui e descobriu que há zero bombas por perto". + +Além disso, a comunicação entre o cliente e o servidor ocorre por meio do componente em cadeia. Isso também é implementado usando tabelas. + +- `PendingGame`: solicitações não atendidas para iniciar um novo jogo. +- `PendingDig`: solicitações não atendidas para cavar em um local específico em um jogo específico. Esta é uma [tabela fora da cadeia](https://mud.dev/store/tables#types-of-tables), o que significa que não é gravada no armazenamento da EVM, é apenas legível fora da cadeia usando eventos. + +### Fluxos de execução e de dados {#execution-data-flows} + +Esses fluxos coordenam a execução entre o cliente, o componente em cadeia e o servidor. + +#### Inicialização {#initialization-flow} + +Quando você executa `mprocs`, estas etapas ocorrem: + +1. [`mprocs`](https://github.com/pvolok/mprocs) executa quatro componentes: + + - [Anvil](https://book.getfoundry.sh/anvil/), que executa uma cadeia de blocos local + - [Contracts](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/contracts), que compila (se necessário) e implanta os contratos para o MUD + - [Client](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/client), que executa o [Vite](https://vitejs.dev/) para servir a UI e o código do cliente para navegadores da web. + - [Server](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/server), que executa as ações do servidor + +2. O pacote `contracts` implanta os contratos MUD e, em seguida, executa [o script `PostDeploy.s.sol`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol). Este script define a configuração. O código do GitHub especifica [um campo minado de 10x5 com oito minas nele](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol#L23). + +3. [O servidor](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts) começa por [configurar o MUD](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L6). Entre outras coisas, isso ativa a sincronização de dados, para que uma cópia das tabelas relevantes exista na memória do servidor. + +4. O servidor inscreve uma função para ser executada [quando a tabela `Configuration` muda](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L23). [Esta função](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L24-L168) é chamada depois que `PostDeploy.s.sol` é executado e modifica a tabela. + +5. Quando a função de inicialização do servidor tem a configuração, [ela chama `zkFunctions`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L34-L35) para inicializar [a parte de conhecimento zero do servidor](#using-zokrates-from-typescript). Isso não pode acontecer até que obtenhamos a configuração, porque as funções de conhecimento zero devem ter a largura e a altura do campo minado como constantes. + +6. Depois que a parte de conhecimento zero do servidor é inicializada, o próximo passo é [implantar o contrato de verificação de conhecimento zero na cadeia de blocos](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L42-L53) e definir o endereço do verificador no MUD. + +7. Finalmente, nos inscrevemos para atualizações para que vejamos quando um jogador solicita [iniciar um novo jogo](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71) ou [cavar em um jogo existente](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73-L108). + +#### Novo jogo {#new-game-flow} + +Isto é o que acontece quando o jogador solicita um novo jogo. + +1. Se não houver nenhum jogo em andamento para este jogador, ou se houver um, mas com um gameId de zero, o cliente exibe um [botão de novo jogo](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175). Quando o usuário pressiona este botão, o [React executa a função `newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L96). + +2. [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L43-L46) é uma chamada `System`. No MUD, todas as chamadas são roteadas através do contrato `World` e, na maioria dos casos, você chama `__`. Nesse caso, a chamada é para `app__newGame`, que o MUD então roteia para [`newGame` em `GameSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L16-L22). + +3. A função em cadeia verifica se o jogador não tem um jogo em andamento e, se não houver, [adiciona a solicitação à tabela `PendingGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L21). + +4. O servidor detecta a alteração em `PendingGame` e [executa a função inscrita](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71). Essa função chama [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L110-L114), que por sua vez chama [`createGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L116-L144). + +5. A primeira coisa que `createGame` faz é [criar um mapa aleatório com o número apropriado de minas](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L120-L135). Em seguida, ele chama [`makeMapBorders`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L147-L166) para criar um mapa com bordas em branco, o que é necessário para o Zokrates. Finalmente, `createGame` chama [`calculateMapHash`](#calculateMapHash) para obter o hash do mapa, que é usado como o ID do jogo. + +6. A função `newGame` adiciona o novo jogo a `gamesInProgress`. + +7. A última coisa que o servidor faz é chamar [`app__newGameResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L38-L43), que está em cadeia. Esta função está em um `System` diferente, [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol), para habilitar o controle de acesso. O controle de acesso é definido no [arquivo de configuração MUD](https://mud.dev/config), [`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72). + + A lista de acesso permite que apenas um único endereço chame o `System`. Isso restringe o acesso às funções do servidor a um único endereço, para que ninguém possa se passar pelo servidor. + +8. O componente em cadeia atualiza as tabelas relevantes: + + - Crie o jogo em `PlayerGame`. + - Defina o mapeamento reverso em `GamePlayer`. + - Remova a solicitação de `PendingGame`. + +9. O servidor identifica a alteração em `PendingGame`, mas não faz nada porque [`wantsGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L58-L60) é falso. + +10. No cliente, [`gameRecord`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L143-L148) é definido para a entrada `PlayerGame` para o endereço do jogador. Quando `PlayerGame` muda, `gameRecord` muda também. + +11. Se houver um valor em `gameRecord` e o jogo não tiver sido ganho ou perdido, o cliente [exibe o mapa](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190). + +#### Cavar {#dig-flow} + +1. O jogador [clica no botão da célula do mapa](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L188), que chama a [função `dig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L33-L36). Essa função chama [`dig` em cadeia](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L24-L32). + +2. O componente em cadeia [realiza uma série de verificações de sanidade](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L25-L30) e, se bem-sucedido, adiciona a solicitação de escavação a [`PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L31). + +3. O servidor [detecta a alteração em `PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73). [Se for válido](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L75-L84), ele [chama o código de conhecimento zero](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L86-L95) (explicado abaixo) para gerar tanto o resultado quanto uma prova de que ele é válido. + +4. [O servidor](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L97-L107) chama [`digResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L45-L64) em cadeia. + +5. `digResponse` faz duas coisas. Primeiro, ele verifica a [prova de conhecimento zero](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L47-L61). Então, se a prova for verificada, ele chama [`processDigResult`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L67-L86) para processar o resultado. + +6. `processDigResult` verifica se o jogo foi [perdido](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L76-L78) ou [ganho](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L83-L86) e [atualiza o `Map`, o mapa em cadeia](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L80). + +7. O cliente recebe as atualizações automaticamente e [atualiza o mapa exibido para o jogador](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190) e, se aplicável, informa ao jogador se é uma vitória ou uma derrota. + +## Usando Zokrates {#using-zokrates} + +Nos fluxos explicados acima, pulamos as partes de conhecimento zero, tratando-as como uma caixa preta. Agora vamos abri-la e ver como esse código é escrito. + +### Hashing do mapa {#hashing-map} + +Podemos usar [este código JavaScript](https://github.com/ZK-Plus/ICBC24_Tutorial_Compute-Offchain-Verify-onchain/tree/solutions/exercise) para implementar [Poseidon](https://www.poseidon-hash.info), a função de hash do Zokrates que usamos. No entanto, embora isso fosse mais rápido, também seria mais complicado do que simplesmente usar a função de hash do Zokrates para fazê-lo. Este é um tutorial e, portanto, o código é otimizado para simplicidade, não para desempenho. Portanto, precisamos de dois programas Zokrates diferentes, um para apenas calcular o hash de um mapa (`hash`) e outro para realmente criar uma prova de conhecimento zero do resultado da escavação em um local no mapa (`dig`). + +### A função de hash {#hash-function} + +Esta é a função que calcula o hash de um mapa. Vamos analisar este código linha por linha. + +``` +import "hashes/poseidon/poseidon.zok" as poseidon; +import "utils/pack/bool/pack128.zok" as pack128; +``` + +Essas duas linhas importam duas funções da [biblioteca padrão do Zokrates](https://zokrates.github.io/toolbox/stdlib.html). [A primeira função](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/hashes/poseidon/poseidon.zok) é um [hash Poseidon](https://www.poseidon-hash.info/). Ela recebe um array de elementos [`field`](https://zokrates.github.io/language/types.html#field) e retorna um `field`. + +O elemento de campo no Zokrates é normalmente menor que 256 bits, mas não por muito. Para simplificar o código, restringimos o mapa a até 512 bits e fazemos o hash de um array de quatro campos, e em cada campo usamos apenas 128 bits. [A função `pack128`](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok) transforma um array de 128 bits em um `field` para este propósito. + +``` + def hashMap(bool[${width+2}][${height+2}] map) -> field { +``` + +Esta linha inicia uma definição de função. `hashMap` recebe um único parâmetro chamado `map`, um array `bool`(eano) bidimensional. O tamanho do mapa é `width+2` por `height+2` por razões que são [explicadas abaixo](#why-map-border). + +Podemos usar `${width+2}` e `${height+2}` porque os programas Zokrates são armazenados nesta aplicação como [template strings](https://www.w3schools.com/js/js_string_templates.asp). O código entre `${` e `}` é avaliado pelo JavaScript e, dessa forma, o programa pode ser usado para diferentes tamanhos de mapa. O parâmetro do mapa tem uma borda de um local de largura ao seu redor sem nenhuma bomba, que é a razão pela qual precisamos adicionar dois à largura e à altura. + +O valor de retorno é um `field` que contém o hash. + +``` + bool[512] mut map1d = [false; 512]; +``` + +O mapa é bidimensional. No entanto, a função `pack128` não funciona com arrays bidimensionais. Então, primeiro achatamos o mapa em um array de 512 bytes, usando `map1d`. Por padrão, as variáveis do Zokrates são constantes, mas precisamos atribuir valores a este array em um loop, então o definimos como [`mut`](https://zokrates.github.io/language/variables.html#mutability). + +Precisamos inicializar o array porque o Zokrates não tem `undefined`. A expressão `[false; 512]` significa [um array de 512 valores `false`](https://zokrates.github.io/language/types.html#declaration-and-initialization). + +``` + u32 mut counter = 0; +``` + +Também precisamos de um contador para distinguir entre os bits que já preenchemos em `map1d` e os que não preenchemos. + +``` + for u32 x in 0..${width+2} { +``` + +É assim que se declara um [loop `for`](https://zokrates.github.io/language/control_flow.html#for-loops) no Zokrates. Um loop `for` do Zokrates tem que ter limites fixos, porque embora pareça ser um loop, o compilador na verdade o "desenrola". A expressão `${width+2}` é uma constante em tempo de compilação porque `width` é definida pelo código TypeScript antes de chamar o compilador. + +``` + for u32 y in 0..${height+2} { + map1d[counter] = map[x][y]; + counter = counter+1; + } + } +``` + +Para cada local no mapa, coloque esse valor no array `map1d` e incremente o contador. + +``` + field[4] hashMe = [ + pack128(map1d[0..128]), + pack128(map1d[128..256]), + pack128(map1d[256..384]), + pack128(map1d[384..512]) + ]; +``` + +Usamos `pack128` para criar um array de quatro valores `field` a partir de `map1d`. No Zokrates, `array[a..b]` significa a fatia do array que começa em `a` e termina em `b-1`. + +``` + return poseidon(hashMe); +} +``` + +Use `poseidon` para converter este array em um hash. + +### O programa de hash {#hash-program} + +O servidor precisa chamar `hashMap` diretamente para criar identificadores de jogo. No entanto, Zokrates só pode chamar a função `main` em um programa para iniciar, então criamos um programa com uma `main` que chama a função de hash. + +``` +${hashFragment} + +def main(bool[${width+2}][${height+2}] map) -> field { + return hashMap(map); +} +``` + +### O programa dig {#dig-program} + +Este é o coração da parte de conhecimento zero da aplicação, onde produzimos as provas que são usadas para verificar os resultados da escavação. + +``` +${hashFragment} + +// O número de minas no local (x,y) +def map2mineCount(bool[${width+2}][${height+2}] map, u32 x, u32 y) -> u8 { + return if map[x+1][y+1] { 1 } else { 0 }; +} +``` + +#### Por que borda do mapa {#why-map-border} + +As provas de conhecimento zero usam [circuitos aritméticos](https://medium.com/web3studio/simple-explanations-of-arithmetic-circuits-and-zero-knowledge-proofs-806e59a79785), que não têm um equivalente fácil para uma declaração `if`. Em vez disso, eles usam o equivalente do [operador condicional](https://en.wikipedia.org/wiki/Ternary_conditional_operator). Se `a` pode ser zero ou um, você pode calcular `if a { b } else { c }` como `ab+(1-a)c`. + +Por causa disso, uma instrução `if` do Zokrates sempre avalia ambas as ramificações. Por exemplo, se você tiver este código: + +``` +bool[5] arr = [false; 5]; +u32 index=10; +return if index>4 { 0 } else { arr[index] } +``` + +Ele vai dar erro, porque precisa calcular `arr[10]`, mesmo que esse valor seja posteriormente multiplicado por zero. + +Esta é a razão pela qual precisamos de uma borda com uma casa de largura em todo o mapa. Precisamos calcular o número total de minas ao redor de um local, e isso significa que precisamos ver o local uma linha acima e abaixo, à esquerda e à direita, do local onde estamos cavando. O que significa que esses locais precisam existir no array do mapa que é fornecido ao Zokrates. + +``` +def main(private bool[${width+2}][${height+2}] map, u32 x, u32 y) -> (field, u8) { +``` + +Por padrão, as provas Zokrates incluem suas entradas. Não adianta saber que há cinco minas ao redor de um ponto, a menos que você saiba qual é o ponto (e você não pode simplesmente combiná-lo com sua solicitação, porque então o provador poderia usar valores diferentes e não lhe contar sobre isso). No entanto, precisamos manter o mapa em segredo, enquanto o fornecemos ao Zokrates. A solução é usar um parâmetro `private`, que _não_ é revelado pela prova. + +Isso abre outra via para abuso. O provador poderia usar as coordenadas corretas, mas criar um mapa com qualquer número de minas ao redor do local, e possivelmente no próprio local. Para evitar esse abuso, fazemos com que a prova de conhecimento zero inclua o hash do mapa, que é o identificador do jogo. + +``` + return (hashMap(map), +``` + +O valor de retorno aqui é uma tupla que inclui o array de hash do mapa, bem como o resultado da escavação. + +``` + if map2mineCount(map, x, y) > 0 { 0xFF } else { +``` + +Usamos 255 como um valor especial caso o próprio local tenha uma bomba. + +``` + map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) + + map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) + + map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1) + } + ); +} +``` + +Se o jogador não atingiu uma mina, some as contagens de minas da área ao redor do local e retorne isso. + +### Usando Zokrates a partir do TypeScript {#using-zokrates-from-typescript} + +O Zokrates tem uma interface de linha de comando, mas neste programa nós o usamos no [código TypeScript](https://zokrates.github.io/toolbox/zokrates_js.html). + +A biblioteca que contém as definições do Zokrates é chamada [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts). + +```typescript +import { initialize as zokratesInitialize } from "zokrates-js" +``` + +Importe as [ligações JavaScript do Zokrates](https://zokrates.github.io/toolbox/zokrates_js.html). Só precisamos da função [`initialize`](https://zokrates.github.io/toolbox/zokrates_js.html#initialize) porque ela retorna uma promessa que resolve para todas as definições do Zokrates. + +```typescript +export const zkFunctions = async (width: number, height: number) : Promise => { +``` + +Semelhante ao próprio Zokrates, também exportamos apenas uma função, que também é [assíncrona](https://www.w3schools.com/js/js_async.asp). Quando ela finalmente retorna, ela fornece várias funções, como veremos abaixo. + +```typescript +const zokrates = await zokratesInitialize() +``` + +Inicialize o Zokrates, obtenha tudo o que precisamos da biblioteca. + +```typescript +const hashFragment = ` + import "utils/pack/bool/pack128.zok" as pack128; + import "hashes/poseidon/poseidon.zok" as poseidon; + . + . + . + } + ` + +const hashProgram = ` + ${hashFragment} + . + . + . + ` + +const digProgram = ` + ${hashFragment} + . + . + . + ` +``` + +A seguir, temos a função de hash e dois programas Zokrates que vimos acima. + +```typescript +const digCompiled = zokrates.compile(digProgram) +const hashCompiled = zokrates.compile(hashProgram) +``` + +Aqui compilamos esses programas. + +```typescript +// Crie as chaves para a verificação de conhecimento zero. +// Em um sistema de produção, você desejaria usar uma cerimônia de configuração. +// (https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony). +const keySetupResults = zokrates.setup(digCompiled.program, "") +const verifierKey = keySetupResults.vk +const proverKey = keySetupResults.pk +``` + +Em um sistema de produção, poderíamos usar uma [cerimônia de configuração](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony) mais complicada, mas isso é suficiente para uma demonstração. Não é um problema que os usuários possam conhecer a chave do provador - eles ainda não podem usá-la para provar coisas, a menos que sejam verdadeiras. Como especificamos a entropia (o segundo parâmetro, `""`), os resultados serão sempre os mesmos. + +**Observação:** a compilação de programas Zokrates e a criação de chaves são processos lentos. Não há necessidade de repeti-los sempre, apenas quando o tamanho do mapa muda. Em um sistema de produção, você os faria uma vez e depois armazenaria a saída. A única razão pela qual não estou fazendo isso aqui é por uma questão de simplicidade. + +#### `calculateMapHash` {#calculateMapHash} + +```typescript +const calculateMapHash = function (hashMe: boolean[][]): string { + return ( + "0x" + + BigInt(zokrates.computeWitness(hashCompiled, [hashMe]).output.slice(1, -1)) + .toString(16) + .padStart(64, "0") + ) +} +``` + +A função [`computeWitness`](https://zokrates.github.io/toolbox/zokrates_js.html#computewitnessartifacts-args-options) realmente executa o programa Zokrates. Ela retorna uma estrutura com dois campos: `output`, que é a saída do programa como uma string JSON, e `witness`, que é a informação necessária para criar a prova de conhecimento zero do resultado. Aqui só precisamos da saída. + +A saída é uma string no formato `"31337"`, um número decimal entre aspas. Mas a saída que precisamos para o `viem` é um número hexadecimal no formato `0x60A7`. Portanto, usamos `.slice(1,-1)` para remover as aspas e, em seguida, `BigInt` para transformar a string restante, que é um número decimal, em um [`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt). `.toString(16)` converte este `BigInt` em uma string hexadecimal, e `"0x"+` adiciona o marcador para números hexadecimais. + +```typescript +// Escave e retorne uma prova de conhecimento zero do resultado +// (código do lado do servidor) +``` + +A prova de conhecimento zero inclui as entradas públicas (`x` e `y`) e os resultados (hash do mapa e número de bombas). + +```typescript + const zkDig = function(map: boolean[][], x: number, y: number) : any { + if (x<0 || x>=width || y<0 || y>=height) + throw new Error("Tentando cavar fora do mapa") +``` + +É um problema verificar se um índice está fora dos limites no Zokrates, então fazemos isso aqui. + +```typescript +const runResults = zokrates.computeWitness(digCompiled, [map, `${x}`, `${y}`]) +``` + +Execute o programa dig. + +```typescript + const proof = zokrates.generateProof( + digCompiled.program, + runResults.witness, + proverKey) + + return proof + } +``` + +Use [`generateProof`](https://zokrates.github.io/toolbox/zokrates_js.html#generateproofprogram-witness-provingkey-entropy) e retorne a prova. + +```typescript +const solidityVerifier = ` + // Tamanho do mapa: ${width} x ${height} + \n${zokrates.exportSolidityVerifier(verifierKey)} + ` +``` + +Um verificador Solidity, um contrato inteligente que podemos implantar na cadeia de blocos e usar para verificar as provas geradas por `digCompiled.program`. + +```typescript + return { + zkDig, + calculateMapHash, + solidityVerifier, + } +} +``` + +Finalmente, retorne tudo o que outro código possa precisar. + +## Testes de segurança {#security-tests} + +Os testes de segurança são importantes porque um bug de funcionalidade acabará por se revelar. Mas se a aplicação for insegura, é provável que isso permaneça oculto por muito tempo antes de ser revelado por alguém que trapaceia e obtém recursos que pertencem a outros. + +### Permissões {#permissions} + +Há uma entidade privilegiada neste jogo, o servidor. É o único usuário autorizado a chamar as funções em [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol). Podemos usar [`cast`](https://book.getfoundry.sh/cast/) para verificar se as chamadas para funções permissionadas são permitidas apenas como a conta do servidor. + +[A chave privada do servidor está em `setupNetwork.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/mud/setupNetwork.ts#L52). + +1. No computador que executa o `anvil` (a cadeia de blocos), defina estas variáveis de ambiente. + + ```sh copy + WORLD_ADDRESS=0x8d8b6b8414e1e3dcfd4168561b9be6bd3bf6ec4b + UNAUTHORIZED_KEY=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a + AUTHORIZED_KEY=0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d + ``` + +2. Use `cast` para tentar definir o endereço do verificador como um endereço não autorizado. + + ```sh copy + cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $UNAUTHORIZED_KEY + ``` + + O `cast` não apenas relata uma falha, mas você também pode abrir as **Ferramentas de Desenvolvedor MUD** no jogo no navegador, clicar em **Tabelas** e selecionar **app\_\_VerifierAddress**. Veja que o endereço não é zero. + +3. Defina o endereço do verificador como o endereço do servidor. + + ```sh copy + cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $AUTHORIZED_KEY + ``` + + O endereço em **app\_\_VerifiedAddress** agora deve ser zero. + +Todas as funções MUD no mesmo `System` passam pelo mesmo controle de acesso, então considero este teste suficiente. Caso contrário, você pode verificar as outras funções em [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol). + +### Abusos de conhecimento zero {#zero-knowledge-abuses} + +A matemática para verificar o Zokrates está além do escopo deste tutorial (e das minhas habilidades). No entanto, podemos executar várias verificações no código de conhecimento zero para verificar se, se não for feito corretamente, ele falha. Todos esses testes exigirão que alteremos [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts) e reiniciemos toda a aplicação. Não é suficiente reiniciar o processo do servidor, porque isso coloca a aplicação em um estado impossível (o jogador tem um jogo em andamento, mas o jogo não está mais disponível para o servidor). + +#### Resposta errada {#wrong-answer} + +A possibilidade mais simples é fornecer a resposta errada na prova de conhecimento zero. Para fazer isso, entramos em `zkDig` e [modificamos a linha 91](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L91): + +```ts +proof.inputs[3] = "0x" + "1".padStart(64, "0") +``` + +Isso significa que sempre alegaremos que há uma bomba, independentemente da resposta correta. Tente jogar com esta versão e você verá na guia **servidor** da tela `pnpm dev` este erro: + +``` + cause: { + code: 3, + message: 'execution reverted: revert: Falha na verificação de conhecimento zero', + data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000 +000000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6 +e206661696c' + }, +``` + +Portanto, esse tipo de trapaça falha. + +#### Prova errada {#wrong-proof} + +O que acontece se fornecermos as informações corretas, mas tivermos os dados de prova errados? Agora, substitua a linha 91 por: + +```ts +proof.proof = { + a: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + b: [ + ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + ], + c: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], +} +``` + +Ele ainda falha, mas agora falha sem motivo, porque acontece durante a chamada do verificador. + +### Como um usuário pode verificar o código de confiança zero? {#user-verify-zero-trust} + +Contratos inteligentes são relativamente fáceis de verificar. Normalmente, o desenvolvedor publica o código-fonte em um explorador de blocos, e o explorador de blocos verifica se o código-fonte compila para o código na [transação de implantação do contrato](/developers/docs/smart-contracts/deploying/). No caso dos `System`s MUD, isso é [um pouco mais complicado](https://mud.dev/cli/verify), mas não muito. + +Isso é mais difícil com conhecimento zero. O verificador inclui algumas constantes e executa alguns cálculos sobre elas. Isso não lhe diz o que está sendo provado. + +```solidity + function verifyingKey() pure internal returns (VerifyingKey memory vk) { + vk.alpha = Pairing.G1Point(uint256(0x0f43f4fe7b5c2326fed4ac6ed2f4003ab9ab4ea6f667c2bdd77afb068617ee16), uint256(0x25a77832283f9726935219b5f4678842cda465631e72dbb24708a97ba5d0ce6f)); + vk.beta = Pairing.G2Point([uint256(0x2cebd0fbd21aca01910581537b21ae4fed46bc0e524c055059aa164ba0a6b62b), uint256(0x18fd4a7bc386cf03a95af7163d5359165acc4e7961cb46519e6d9ee4a1e2b7e9)], [uint256(0x11449dee0199ef6d8eebfe43b548e875c69e7ce37705ee9a00c81fe52f11a009), uint256(0x066d0c83b32800d3f335bb9e8ed5e2924cf00e77e6ec28178592eac9898e1a00)]); +``` + +A solução, pelo menos até que os exploradores de blocos adicionem a verificação do Zokrates às suas interfaces de usuário, é que os desenvolvedores de aplicações disponibilizem os programas Zokrates, e que pelo menos alguns usuários os compilem com a chave de verificação apropriada. + +Para fazer isso: + +1. [Instale o Zokrates](https://zokrates.github.io/gettingstarted.html). + +2. Crie um arquivo, `dig.zok`, com o programa Zokrates. O código abaixo presume que você manteve o tamanho original do mapa, 10x5. + + ```zokrates + import "utils/pack/bool/pack128.zok" as pack128; + import "hashes/poseidon/poseidon.zok" as poseidon; + + def hashMap(bool[12][7] map) -> field { + bool[512] mut map1d = [false; 512]; + u32 mut counter = 0; + + for u32 x in 0..12 { + for u32 y in 0..7 { + map1d[counter] = map[x][y]; + counter = counter+1; + } + } + + field[4] hashMe = [ + pack128(map1d[0..128]), + pack128(map1d[128..256]), + pack128(map1d[256..384]), + pack128(map1d[384..512]) + ]; + + return poseidon(hashMe); + } + + + // O número de minas no local (x,y) + def map2mineCount(bool[12][7] map, u32 x, u32 y) -> u8 { + return if map[x+1][y+1] { 1 } else { 0 }; + } + + def main(private bool[12][7] map, u32 x, u32 y) -> (field, u8) { + return (hashMap(map) , + if map2mineCount(map, x, y) > 0 { 0xFF } else { + map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) + + map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) + + map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1) + } + ); + } + ``` + +3. Compile o código Zokrates e crie a chave de verificação. A chave de verificação deve ser criada com a mesma entropia usada no servidor original, [neste caso, uma string vazia](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L67). + + ```sh copy + zokrates compile --input dig.zok + zokrates setup -e "" + ``` + +4. Crie o verificador Solidity por conta própria e verifique se ele é funcionalmente idêntico ao da cadeia de blocos (o servidor adiciona um comentário, mas isso não é importante). + + ```sh copy + zokrates export-verifier + diff verifier.sol ~/20240901-secret-state/packages/contracts/src/verifier.sol + ``` + +## Decisões de design {#design} + +Em qualquer aplicação suficientemente complexa, existem objetivos de design concorrentes que exigem trade-offs. Vamos analisar alguns dos trade-offs e por que a solução atual é preferível a outras opções. + +### Por que conhecimento zero {#why-zero-knowledge} + +Para o Campo Minado, você não precisa realmente de conhecimento zero. O servidor pode sempre manter o mapa e depois revelá-lo por completo quando o jogo terminar. Então, no final do jogo, o contrato inteligente pode calcular o hash do mapa, verificar se corresponde e, se não, penalizar o servidor ou desconsiderar o jogo completamente. + +Não usei essa solução mais simples porque ela só funciona para jogos curtos com um estado final bem definido. Quando um jogo é potencialmente infinito (como no caso dos [mundos autônomos](https://0xparc.org/blog/autonomous-worlds)), você precisa de uma solução que prove o estado _sem_ revelá-lo. + +Como um tutorial, este artigo precisava de um jogo curto que fosse fácil de entender, mas essa técnica é mais útil para jogos mais longos. + +### Por que Zokrates? {#why-zokrates} + +[Zokrates](https://zokrates.github.io/) não é a única biblioteca de conhecimento zero disponível, mas é semelhante a uma linguagem de programação normal e [imperativa](https://en.wikipedia.org/wiki/Imperative_programming) e suporta variáveis ​​booleanas. + +Para sua aplicação, com requisitos diferentes, você pode preferir usar [Circum](https://docs.circom.io/getting-started/installation/) ou [Cairo](https://www.cairo-lang.org/tutorials/getting-started-with-cairo/). + +### Quando compilar o Zokrates {#when-compile-zokrates} + +Neste programa, compilamos os programas Zokrates [toda vez que o servidor é iniciado](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L60-L61). Isso é claramente um desperdício de recursos, mas este é um tutorial, otimizado para simplicidade. + +Se eu estivesse escrevendo uma aplicação de nível de produção, verificaria se tenho um arquivo com os programas Zokrates compilados neste tamanho de campo minado e, se sim, usaria isso. O mesmo vale para implantar um contrato de verificador em cadeia. + +### Criando as chaves do verificador e do provador {#key-creation} + +A [criação de chaves](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L63-L69) é outro cálculo puro que não precisa ser feito mais de uma vez para um determinado tamanho de campo minado. Novamente, é feito apenas uma vez por uma questão de simplicidade. + +Além disso, poderíamos usar [uma cerimônia de configuração](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony). A vantagem de uma cerimônia de configuração é que você precisa da entropia ou de algum resultado intermediário de cada participante para trapacear na prova de conhecimento zero. Se pelo menos um participante da cerimônia for honesto e excluir essa informação, as provas de conhecimento zero estarão seguras contra certos ataques. No entanto, _não há mecanismo_ para verificar se a informação foi excluída de todos os lugares. Se as provas de conhecimento zero são de importância crítica, você vai querer participar da cerimônia de configuração. + +Aqui, contamos com [poderes perpétuos de tau](https://github.com/privacy-scaling-explorations/perpetualpowersoftau), que teve dezenas de participantes. Provavelmente é seguro o suficiente e muito mais simples. Também não adicionamos entropia durante a criação da chave, o que facilita para os usuários [verificarem a configuração de conhecimento zero](#user-verify-zero-trust). + +### Onde verificar {#where-verification} + +Podemos verificar as provas de conhecimento zero em cadeia (o que custa gás) ou no cliente (usando [`verify`](https://zokrates.github.io/toolbox/zokrates_js.html#verifyverificationkey-proof)). Eu escolhi a primeira, porque isso permite que você [verifique o verificador](#user-verify-zero-trust) uma vez e depois confie que ele não muda, desde que o endereço do contrato para ele permaneça o mesmo. Se a verificação fosse feita no cliente, você teria que verificar o código que recebe cada vez que baixa o cliente. + +Além disso, embora este jogo seja para um jogador, muitos jogos de cadeia de blocos são para vários jogadores. a verificação em cadeia significa que você só verifica a prova de conhecimento zero uma vez. Fazer isso no cliente exigiria que cada cliente verificasse independentemente. + +### Achatar o mapa em TypeScript ou Zokrates? {#where-flatten} + +Em geral, quando o processamento pode ser feito em TypeScript ou Zokrates, é melhor fazê-lo em TypeScript, que é muito mais rápido e não requer provas de conhecimento zero. Essa é a razão, por exemplo, pela qual não fornecemos ao Zokrates o hash e o fazemos verificar se está correto. O hashing deve ser feito dentro do Zokrates, mas a correspondência entre o hash retornado e o hash em cadeia pode ocorrer fora dele. + +No entanto, ainda [achatamos o mapa em Zokrates](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L15-L20), enquanto poderíamos tê-lo feito em TypeScript. A razão é que as outras opções são, na minha opinião, piores. + +- Forneça um array unidimensional de booleanos para o código Zokrates e use uma expressão como `x*(height+2)+y` para obter o mapa bidimensional. Isso tornaria [o código](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L44-L47) um pouco mais complicado, então decidi que o ganho de desempenho não vale a pena para um tutorial. + +- Envie ao Zokrates tanto o array unidimensional quanto o array bidimensional. No entanto, esta solução não nos traz nenhum ganho. O código Zokrates teria que verificar se o array unidimensional fornecido é realmente a representação correta do array bidimensional. Portanto, não haveria nenhum ganho de desempenho. + +- Achatar o array bidimensional em Zokrates. Esta é a opção mais simples, então eu a escolhi. + +### Onde armazenar mapas {#where-store-maps} + +Nesta aplicação, [`gamesInProgress`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L20) é simplesmente uma variável na memória. Isso significa que se o seu servidor parar de funcionar e precisar ser reiniciado, todas as informações armazenadas serão perdidas. Os jogadores não apenas não conseguem continuar o jogo, como também não conseguem iniciar um novo, porque o componente em cadeia pensa que eles ainda têm um jogo em andamento. + +Isso é claramente um mau design para um sistema de produção, no qual você armazenaria essa informação em um banco de dados. A única razão pela qual usei uma variável aqui é porque este é um tutorial e a simplicidade é a principal consideração. + +## Conclusão: Em que condições esta é a técnica apropriada? {#conclusion} + +Então, agora você sabe como escrever um jogo com um servidor que armazena um estado secreto que não pertence à cadeia. Mas em que casos você deve fazer isso? Existem duas considerações principais. + +- _Jogo de longa duração_: [Como mencionado acima](#why-zero-knowledge), em um jogo curto, você pode simplesmente publicar o estado quando o jogo terminar e ter tudo verificado então. Mas essa não é uma opção quando o jogo leva um tempo longo ou indefinido, e o estado precisa permanecer secreto. + +- _Alguma centralização aceitável_: As provas de conhecimento zero podem verificar a integridade, que uma entidade não está falsificando os resultados. O que elas não podem fazer é garantir que a entidade ainda estará disponível e responderá às mensagens. Em situações em que a disponibilidade também precisa ser descentralizada, as provas de conhecimento zero não são uma solução suficiente, e você precisa de [computação multipartidária](https://en.wikipedia.org/wiki/Secure_multi-party_computation). + +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). + +### Agradecimentos {#acknowledgements} + +- Alvaro Alonso leu um rascunho deste artigo e esclareceu alguns dos meus mal-entendidos sobre Zokrates. + +Quaisquer erros remanescentes são de minha responsabilidade. diff --git a/public/content/translations/pt-br/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/pt-br/developers/tutorials/secure-development-workflow/index.md index 7caf23f4aca..5faabf18098 100644 --- a/public/content/translations/pt-br/developers/tutorials/secure-development-workflow/index.md +++ b/public/content/translations/pt-br/developers/tutorials/secure-development-workflow/index.md @@ -1,44 +1,41 @@ --- -title: Checklist de segurança para smart contracts +title: "Checklist de segurança para smart contracts" description: Um workflow sugerido para escrever smart contracts seguros author: "Trailofbits" -tags: - - "contratos inteligentes" - - "segurança" - - "solidity" +tags: [ "smart contracts", "segurança", "Solidity" ] skill: intermediate lang: pt-br published: 2020-09-07 -source: Construindo contratos seguros +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md --- -## Processo de desenvolvimento do contrato inteligente {#smart-contract-development-checklist} +## Lista de verificação de desenvolvimento de contrato inteligente {#smart-contract-development-checklist} Aqui temos um processo de alto nível que recomendamos seguir enquanto você escreve seus contratos inteligentes. Verificar problemas de segurança conhecidos: -- Reveja seus contratos com o [Slither](https://github.com/crytic/slither). Tem mais de 40 detectores internos para vulnerabilidades comuns. Execute em cada check-in com um novo código e certifique-se de que ele recebe um relatório limpo (ou use o modo de triagem para silenciar certos problemas). -- Reveja seus contratos com o [Crytic](https://crytic.io/). Ele verifica 50 problemas que o Slither não tem. O Crytic também pode ajudar sua equipe a se manter atualizada, resolvendo problemas de segurança facilmente nas solicitações de pull no GitHub. +- Revise seus contratos com [Slither](https://github.com/crytic/slither). Tem mais de 40 detectores internos para vulnerabilidades comuns. Execute em cada check-in com um novo código e certifique-se de que ele recebe um relatório limpo (ou use o modo de triagem para silenciar certos problemas). +- Revise seus contratos com [Crytic](https://crytic.io/). Ele verifica 50 problemas que o Slither não tem. O Crytic também pode ajudar sua equipe a se manter atualizada, resolvendo problemas de segurança facilmente nas solicitações de pull no GitHub. Considere as características especiais do seu contrato: -- Os seus contratos são atualizáveis? Verifique se há defeitos em seu código de capacidade de atualização com o [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) ou [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/). Documentamos 17 situações em que as atualizações podem correr mal. -- Seus contratos pretendem estar em conformidade com os ERCs? Verifique com [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance). Esta ferramenta identifica instantaneamente desvios de seis especificações comuns. -- Você faz integrações com tokens de outras empresas? Revise nossa [lista de verificação de integração de tokens](/developers/tutorials/token-integration-checklist/) antes de confiar em contratos externos. +- Os seus contratos são atualizáveis? Revise seu código de capacidade de atualização em busca de falhas com [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) ou [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/). Documentamos 17 situações em que as atualizações podem correr mal. +- Seus contratos pretendem estar em conformidade com os ERCs? Verifique-os com [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance). Esta ferramenta identifica instantaneamente desvios de seis especificações comuns. +- Você faz integrações com tokens de outras empresas? Revise nossa [lista de verificação de integração de token](/developers/tutorials/token-integration-checklist/) antes de depender de contratos externos. Visualmente inspecione recursos críticos de segurança com seu código: -- Analise o printer [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) do Slither. Evite problemas de linearização de sombras e C3 involuntários. -- Analise o printer [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) do Slither. Reporta a visibilidade da função e os controles de acesso. -- Analise o printer [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) do Slither. Ele relata os controles de acesso às variáveis de estado. +- Revise o impressor [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) do Slither. Evite problemas de linearização de sombras e C3 involuntários. +- Revise o impressor [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) do Slither. Reporta a visibilidade da função e os controles de acesso. +- Revise o impressor [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) do Slither. Ele relata os controles de acesso às variáveis de estado. Propriedades de segurança críticas do documento e use geradores de testes automatizados para avaliá-las: -- Aprenda com [as propriedades de segurança de documentos para o seu código](/developers/tutorials/guide-to-smart-contract-security-tools/). É difícil no início, mas é a atividade mais importante para alcançar um bom resultado. Também é um pré-requisito para usar qualquer uma das técnicas avançadas neste tutorial. -- Defina as propriedades de segurança no Solidity, para usar com [Echidna](https://github.com/crytic/echidna) e [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html). Concentre-se na sua máquina do estado, controles de acesso, operações aritméticas, interações externas e padrões de conformidade. -- Defina as propriedades de segurança com [API Python do Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/). Concentre-se na herança, nas dependências variáveis, nos controles de acesso e em outras questões estruturais. +- Aprenda a [documentar as propriedades de segurança para o seu código](/developers/tutorials/guide-to-smart-contract-security-tools/). É difícil no início, mas é a atividade mais importante para alcançar um bom resultado. Também é um pré-requisito para usar qualquer uma das técnicas avançadas neste tutorial. +- Defina as propriedades de segurança em Solidity para uso com [Echidna](https://github.com/crytic/echidna) e [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html). Concentre-se na sua máquina do estado, controles de acesso, operações aritméticas, interações externas e padrões de conformidade. +- Defina as propriedades de segurança com a [API Python do Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/). Concentre-se na herança, nas dependências variáveis, nos controles de acesso e em outras questões estruturais. - Execute seus testes de propriedade em cada commit com [Crytic](https://crytic.io). Critica pode consumir e avaliar testes de propriedade de segurança para que todos na sua equipe possam facilmente ver que eles passam no GitHub. Os testes que falharam podem bloquear os commits. Finalmente, esteja atento a questões que as ferramentas automatizadas não conseguem facilmente encontrar: @@ -48,8 +45,8 @@ Finalmente, esteja atento a questões que as ferramentas automatizadas não cons - Operações criptográficas - Interações arriscadas com componentes externos de DeFi -## Pedir ajuda {#ask-for-help} +## Peça ajuda {#ask-for-help} -[Horário de escritório Ethereum](https://calendly.com/dan-trailofbits/office-hours) executa todas as terças da tarde. Essas sessões presenciais de uma hora são uma oportunidade para você nos fazer quaisquer perguntas que sobre segurança, solucionar problemas usando nossas ferramentas e obter comentários de especialistas sobre sua abordagem atual. Vamos ajudá-lo a trabalhar neste guia. +Os [horários de expediente do Ethereum](https://calendly.com/dan-trailofbits/office-hours) acontecem toda terça-feira à tarde. Essas sessões presenciais de uma hora são uma oportunidade para você nos fazer quaisquer perguntas que sobre segurança, solucionar problemas usando nossas ferramentas e obter comentários de especialistas sobre sua abordagem atual. Vamos ajudá-lo a trabalhar neste guia. Junte-se ao nosso Slack: [Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw). Sempre estaremos disponíveis nos canais #crytic e #ethereum caso tenha alguma dúvida. diff --git a/public/content/translations/pt-br/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/pt-br/developers/tutorials/send-token-ethersjs/index.md index f57529f2ef8..f35890853ce 100644 --- a/public/content/translations/pt-br/developers/tutorials/send-token-ethersjs/index.md +++ b/public/content/translations/pt-br/developers/tutorials/send-token-ethersjs/index.md @@ -1,11 +1,8 @@ --- -title: Envio de fichas usando ethers.js -description: Guia amigo para iniciantes enviarem tokens usando ethers.js. +title: Enviando Tokens Usando ethers.js +description: Guia para iniciantes sobre o envio de tokens usando ethers.js. author: Kim YongJun -tags: - - "ETHERS.JS" - - "ERC-20" - - "TOKENS" +tags: [ "ETHERS.JS", "ERC-20", "TOKENS" ] skill: beginner lang: pt-br published: 2021-04-06 @@ -13,32 +10,33 @@ published: 2021-04-06 ## Enviar Token usando ethers.js(5.0) {#send-token} -### Neste tutorial, você aprenderá {#you-learn-about} +### Neste tutorial, você aprenderá como {#you-learn-about} - Importar ethers.js -- Transferência de tokens -- Defina o preço do gás de acordo com a situação do tráfego de rede +- Transferir token +- Definir o preço do gás de acordo com a situação do tráfego da rede -### Iniciado {#to-get-started} +### Para começar {#to-get-started} -Para começar, primeiro devemos importar a biblioteca ethers.js para nossa javascript Incluir ethers.js(5.0) +Para começar, devemos primeiro importar a biblioteca ethers.js em nosso javascript +Incluir ethers.js(5.0) -### Instalando {#install-ethersjs} +### Instalação {#install-ethersjs} ```shell /home/ricmoo> npm install --save ethers ``` -ES6 no Navegador +ES6 no navegador ```html ``` -ES3(UMD) no Navegador +ES3(UMD) no navegador ```html ``` -Se você preferir instalar a biblioteca para usar em seu backend ou um projeto do frontend que usa build, você pode instalá-la usando o npm: +Se preferir instalar a biblioteca para usar no seu back-end ou em um projeto de front-end que use um processo de build, você pode instalá-la usando o npm: ```bash npm install web3 --save ``` -Em seguida, para importar o Web3.js em um script Node.js ou projeto front-end do Browserify, você pode usar a seguinte linha de JavaScript: +Em seguida, para importar o Web3.js em um script Node.js ou projeto de front-end do Browserify, você pode usar a seguinte linha de JavaScript: ```js const Web3 = require("web3") ``` -Agora que incluímos a biblioteca no projeto, precisamos inicializá-la. Seu projeto precisa ser capaz de se comunicar com a blockchain. A maioria das bibliotecas Ethereum se comunicam com um [nó](/developers/docs/nodes-and-clients/) através de chamadas RPC. Para iniciar nosso provedor Web3, nós criaremos uma instância Web3 passando como construtor a URL do provedor. Se você tiver uma instância de um nó ou [ganache executando no seu computador](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/) será parecido com isto: +Agora que incluímos a biblioteca no projeto, precisamos inicializá-la. Seu projeto precisa ser capaz de se comunicar com a blockchain. A maioria das bibliotecas Ethereum se comunica com um [nó](/developers/docs/nodes-and-clients/) por meio de chamadas RPC. Para iniciar nosso provedor Web3, vamos instanciar o Web3 passando a URL do provedor para o construtor. Se você tiver um nó ou uma [instância do ganache em execução em seu computador](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/), o código será parecido com este: ```js const web3 = new Web3("http://localhost:8545") ``` -Se você deseja acessar diretamente um nó hospedado, poderá encontrar opções em [nós como um serviço](/developers/docs/nodes-and-clients/nodes-as-a-service). +Se quiser acessar diretamente um nó hospedado, você pode encontrar opções em [nós como serviço](/developers/docs/nodes-and-clients/nodes-as-a-service). ```js const web3 = new Web3("https://cloudflare-eth.com") ``` -Para testar se configuramos corretamente nossa instância Web3, tentaremos recuperar o número do último bloco usando a função `getBlockNumber`. Esta função aceita uma chamada de callback como parâmetro e retorna o número do bloco como um inteiro. +Para testar se configuramos nossa instância do Web3 corretamente, vamos tentar recuperar o número do bloco mais recente usando a função `getBlockNumber`. Essa função aceita um callback como parâmetro e retorna o número do bloco como um inteiro. ```js var Web3 = require("web3") @@ -56,7 +54,7 @@ web3.eth.getBlockNumber(function (error, result) { }) ``` -Se você executar este programa, ele simplesmente imprimirá o bloco mais recente: o topo do blockchain. Você também pode usar chamadas de função `await/async` para evitar aninhar (encadear por identação) chamadas de callback em seu código: +Se você executar este programa, ele simplesmente imprimirá o número do bloco mais recente: o topo da blockchain. Você também pode usar chamadas de função `async/await` para evitar o aninhamento de callbacks em seu código: ```js async function getBlockNumber() { @@ -68,27 +66,27 @@ async function getBlockNumber() { getBlockNumber() ``` -Você pode ver todas as funções disponíveis da instância Web3 na [documentação oficial do web3.js](https://docs.web3js.org/). +Você pode ver todas as funções disponíveis na instância do Web3 na [documentação oficial do web3.js](https://docs.web3js.org/). -A maioria das bibliotecas Web3 são assíncronas porque em segundo plano a biblioteca faz chamadas JSON RPC para o nó que envia os resultados. +A maioria das bibliotecas Web3 é assíncrona porque, em segundo plano, a biblioteca faz chamadas JSON-RPC para o nó, que envia o resultado de volta. -Se você estiver trabalhando no navegador, algumas carteiras injetam diretamente uma instância Web3, e você deveria tentar usá-la sempre que possível, especialmente se planeja interagir com o endereço Ethereum do usuário para fazer transações. +Se você estiver trabalhando no navegador, algumas carteiras injetam diretamente uma instância do Web3, e você deve tentar usá-la sempre que possível, especialmente se planeja interagir com o endereço Ethereum do usuário para realizar transações. -Aqui está o trecho de código para detectar se uma carteira MetaMask está disponível e tentar habilitá-la se estiver. Isso permitirá mais tarde você ler o saldo do usuário e permitir-lhe-á validar as transações que gostaria de fazer na blockchain Ethereum: +Aqui está o trecho de código para detectar se uma carteira MetaMask está disponível e tentar habilitá-la, se for o caso. Isso permitirá que você leia o saldo do usuário e que ele valide as transações que você deseja que ele realize na blockchain da Ethereum: ```js if (window.ethereum != null) { state.web3 = new Web3(window.ethereum) try { - // Request account access if needed + // Solicita acesso à conta, se necessário await window.ethereum.enable() - // Accounts now exposed + // Contas agora expostas } catch (error) { - // User denied account access... + // O usuário negou o acesso à conta... } } ``` -Alternativas para web3.js como [Ethers.js](https://docs.ethers.io/) existem e também são comumente usadas. No próximo tutorial, veremos [como escutar facilmente novos blocos recebidos na blockchain e ver o que eles contêm](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/). +Existem alternativas ao web3.js, como o [Ethers.js](https://docs.ethers.io/), que também são comumente usadas. No próximo tutorial, veremos [como escutar facilmente os novos blocos que chegam na blockchain e ver o que eles contêm](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/). diff --git a/public/content/translations/pt-br/developers/tutorials/short-abi/index.md b/public/content/translations/pt-br/developers/tutorials/short-abi/index.md index 4ce396e010e..92a65ea54f3 100644 --- a/public/content/translations/pt-br/developers/tutorials/short-abi/index.md +++ b/public/content/translations/pt-br/developers/tutorials/short-abi/index.md @@ -1,85 +1,106 @@ --- -title: "ABIs curtos para otimização de dados de chamada" -description: Otimizando contratos inteligentes para Rollups Otimistas +title: "ABIs curtos para otimização de Calldata" +description: Otimizando contratos inteligentes para Optimistic Rollups author: Ori Pomerantz lang: pt-br -tags: - - "camada 2" +tags: [ "camada 2" ] skill: intermediate published: 2022-04-01 --- ## Introdução {#introduction} -Neste artigo, você aprenderá sobre [optimistic rollups](/developers/docs/scaling/optimistic-rollups), os custos das transações e como essa estrutura de custos diferente nos obriga a otimizar coisas diferentes do que fazemos na Ethereum Mainnet. Você também aprenderá como implementar essa otimização. +Neste artigo, você aprenderá sobre [optimistic rollups](/developers/docs/scaling/optimistic-rollups), o custo das transações neles, e como essa estrutura de custos diferente exige que otimizemos para coisas diferentes do que na Rede Principal do Ethereum. +Você também aprende como implementar essa otimização. ### Divulgação completa {#full-disclosure} -Eu sou funcionário em tempo integral da [Optimism](https://www.optimism.io/), então os exemplos neste artigo serão executados na Optimism. No entanto, a técnica explicada aqui deve funcionar para outras rollups também. +Sou funcionário em tempo integral da [Optimism](https://www.optimism.io/), então os exemplos deste artigo serão executados na Optimism. +No entanto, a técnica explicada aqui deve funcionar tão bem para outros rollups. ### Terminologia {#terminology} -Quando se discute rollups, o termo 'camada 1' (L1) é usado para a Mainnet, a rede Ethereum de produção. O termo 'camada 2' (L2) é usado para a rollup ou qualquer outro sistema que depende do L1 para segurança, mas faz a maior parte de seu processamento fora da cadeia +Ao discutir rollups, o termo 'camada 1' (L1) é usado para a Rede Principal, a rede de produção da Ethereum. +O termo 'camada 2' (L2) é usado para o rollup ou qualquer outro sistema que dependa da L1 para segurança, mas que faça a maior parte de seu processamento fora da cadeia. ## Como podemos reduzir ainda mais o custo das transações L2? {#how-can-we-further-reduce-the-cost-of-L2-transactions} -[Optimistic rollups](/developers/docs/scaling/optimistic-rollups) tem que preservar um registro de cada transação histórica para que qualquer pessoa possa passar por elas e verificar se o estado atual está correto. A forma mais barata de obter dados na Ethereum Mainnet é escrevê-los como calldata. Esta solução foi escolhida por ambos [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) e [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups). +Os [Optimistic rollups](/developers/docs/scaling/optimistic-rollups) precisam preservar um registro de todas as transações históricas para que qualquer pessoa possa analisá-las e verificar se o estado atual está correto. +A forma mais barata de inserir dados na Rede Principal do Ethereum é gravá-los como calldata. +Esta solução foi escolhida tanto pela [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) quanto pela [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups). ### Custo das transações L2 {#cost-of-l2-transactions} O custo das transações L2 é composto por dois componentes: 1. Processamento L2, que geralmente é extremamente barato -2. Armazenamento L1, vinculado aos custos de gas da Mainnet +2. Armazenamento L1, que está atrelado aos custos de gás da Rede Principal -No momento em que escrevo isso, no Optimism, o custo do gas L2 é de 0,001 [Gwei](/developers/docs/gas/#pre-london). O custo do gas na L1 é de aproximadamente 40 gwei. [Você pode ver os preços atuais aqui](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m). +No momento em que escrevo isto, na Optimism o custo do gás L2 é de 0,001 [Gwei](/developers/docs/gas/#pre-london). +O custo do gás na L1, por outro lado, é de aproximadamente 40 gwei. +[Você pode ver os preços atuais aqui](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m). -Um byte de dado da chamada custa, ou 4 gas (se for zero), ou 16 gas (se for qualquer outro valor). Uma das operações mais caras no EVM é escrever no storage. O custo máximo de escrever uma palavra de 32 bytes para armazenamento na L2 é de 22100 gas. Atualmente, isso é 22.1 gwei. Portanto, se nós pudermos salvar um único byte zero de calldata, poderemos gravar cerca de 200 bytes no armazenamento e ainda sairemos ganhando. +Um byte de calldata custa 4 de gás (se for zero) ou 16 de gás (se for qualquer outro valor). +Uma das operações mais caras na EVM é gravar no armazenamento. +O custo máximo para gravar uma palavra de 32 bytes no armazenamento em L2 é de 22.100 de gás. Atualmente, isso é 22.1 gwei. +Portanto, se conseguirmos economizar um único byte zero de calldata, poderemos gravar cerca de 200 bytes no armazenamento e ainda sair ganhando. -### O ABI {#the-abi} +### A ABI {#the-abi} -A grande maioria das transações acessa um contrato de uma conta de propriedade externa. A maioria dos contratos é escrita em Solidity e interpreta seu campo de dados de acordo com a [interface binária do aplicativo (ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding). +A grande maioria das transações acessa um contrato de uma conta de propriedade externa. +A maioria dos contratos é escrita em Solidity e interpreta seu campo de dados de acordo com a [interface binária de aplicação (ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding). -No entanto, a ABI foi projetada para L1, em que um byte de dados da chamada custa aproximadamente o mesmo que quatro operações aritméticas, não para L2, em que um byte de dados da chamada custa mais de mil operações aritméticas. Por exemplo, [aqui está uma transação de transferência ERC-20](https://kovan-optimistic.etherscan.io/tx/0x7ce4c144ebfce157b4de99d8ad53a352ae91b57b3fa06d8a1c79439df6bfa998). Os dados da chamada são divididos da seguinte forma: +No entanto, a ABI foi projetada para a L1, onde um byte de calldata custa aproximadamente o mesmo que quatro operações aritméticas, e não para a L2, onde um byte de calldata custa mais de mil operações aritméticas. +O calldata é dividido da seguinte forma: -| Seção | Comprimento | Bytes | Bytes gastos | Gas gasto | Bytes necessários | Gas necessário | -| ------------------- | -----------:| -----:| ------------:| ---------:| -----------------:| --------------:| -| Seletor de função | 4 | 0-3 | 3 | 48 | 1 | 16 | -| Zeros | 12 | 4-15 | 12 | 48 | 0 | 0 | -| Endereço de destino | 20 | 16-35 | 0 | 0 | 20 | 320 | -| Quantidade | 32 | 16-35 | 17 | 64 | 15 | 240 | -| Total | 68 | | | 576 | | 576 | +| Seção | Comprimento | Bytes | Bytes desperdiçados | Gás desperdiçado | Bytes necessários | Gás necessário | +| ------------------- | ----------: | ----: | ------------------: | ---------------: | ----------------: | -------------: | +| Seletor de função | 4 | 0-3 | 3 | 48 | 1 | 16 | +| Zeros | 12 | 4-15 | 12 | 48 | 0 | 0 | +| Endereço de destino | 20 | 16-35 | 0 | 0 | 20 | 320 | +| Quantidade | 32 | 36-67 | 17 | 64 | 15 | 240 | +| Total | 68 | | | 160 | | 576 | Explicação: -- **Seletor de funções**: O contrato tem menos de 256 funções, portanto podemos distingui-las com um único byte. Esses bytes são tipicamente diferentes de zero e, portanto, [custam dezesseis gás](https://eips.ethereum.org/EIPS/eip-2028). -- **Zeros**: Esses bytes são sempre zero porque um endereço de vinte bytes não requer uma palavra de trinta e dois bytes para usá-lo. Bytes que possuem zero custam quatro gas ([consulte o yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf), Apêndice G, pág. 27, o valor para `G``txdatazero`). -- **Quantia**: Se nós assumirmos que neste contrato `decimais` são dezoito (o valor normal) e o valor máximo de tokens que nós transferimos será 1018, nós temos uma quantia máxima de 1036. 25615 > 1036, então quinze bytes são suficientes. +- **Seletor de função**: o contrato tem menos de 256 funções, então podemos distingui-las com um único byte. + Esses bytes normalmente não são zero e, portanto, [custam dezesseis de gás](https://eips.ethereum.org/EIPS/eip-2028). +- **Zeros**: esses bytes são sempre zero porque um endereço de vinte bytes não requer uma palavra de trinta e dois bytes para o conter. + Bytes que contêm zero custam quatro de gás ([consulte o yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf), Apêndice G, + p. 27, o valor para `G``txdatazero`). +- **Quantidade**: se assumirmos que neste contrato `decimals` é dezoito (o valor normal) e a quantidade máxima de tokens que transferimos será 1018, obteremos uma quantidade máxima de 1036. + 25615 > 1036, então quinze bytes são suficientes. -Um gasto de 160 gas na L1 é normalmente insignificante. Uma transação custa pelo menos [21.000 gas](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed), então um extra de 0,8% não importa. Entretanto, na L2, as coisas são diferentes. Quase o custo inteiro da transação é escrevendo-o na L1. Em adição ao calldata da transação, há 109 bytes de cabeçalho de transação (endereço de destino, assinatura, etc.). O custo total é portanto `109*16+576+160=2480`, e nós estamos desperdiçando cerca de 6,5% disso. +Um desperdício de 160 de gás na L1 é normalmente insignificante. Uma transação custa pelo menos [21.000 de gás](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed), então 0,8% a mais não importa. +Entretanto, na L2, as coisas são diferentes. Quase todo o custo da transação é para gravá-la na L1. +Além do calldata da transação, há 109 bytes de cabeçalho da transação (endereço de destino, assinatura etc.). +O custo total é, portanto, `109*16+576+160=2480`, e estamos desperdiçando cerca de 6,5% disso. ## Reduzindo custos quando você não controla o destino {#reducing-costs-when-you-dont-control-the-destination} -Assumindo que você não tem controle sobre o contrato de destino, você pode ainda usar uma solução similar a [esta](https://github.com/qbzzt/ethereum.org-20220330-shortABI). Vamos passar pelos arquivos relevantes. +Assumindo que você não tenha controle sobre o contrato de destino, você ainda pode usar uma solução semelhante a [esta](https://github.com/qbzzt/ethereum.org-20220330-shortABI). +Vamos rever os arquivos relevantes. ### Token.sol {#token-sol} -[Este é o contrato destino](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol). É um contrato ERC-20 padrão, com um recurso adicional. Esta função `faucet` permite qualquer usuário obter algum token para usar. Ele faria o contrato de produção ERC-20 inútil, mas ele facilita a vida quando um ERC-20 existe somente para facilitar o teste. +[Este é o contrato de destino](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol). +É um contrato padrão ERC-20, com um recurso adicional. +Esta função `faucet` permite que qualquer usuário obtenha alguns tokens para usar. +Isso tornaria um contrato de produção ERC-20 inútil, mas facilita as coisas quando um ERC-20 existe apenas para facilitar os testes. ```solidity /** - * @dev Gives the caller 1000 tokens to play with + * @dev Fornece ao chamador 1000 tokens para usar */ function faucet() external { _mint(msg.sender, 1000); } // function faucet ``` -[Você pode ver um exemplo deste contrato sendo implantado aqui](https://kovan-optimistic.etherscan.io/address/0x950c753c0edbde44a74d3793db738a318e9c8ce8). - ### CalldataInterpreter.sol {#calldatainterpreter-sol} -[Este é o contrato que transações devem chamar com calldata menor](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol). Vamos passar por ele linha a linha. +[Este é o contrato que as transações devem chamar com calldata mais curto](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol). +Vamos analisá-lo linha por linha. ```solidity //SPDX-License-Identifier: Unlicense @@ -89,7 +110,7 @@ pragma solidity ^0.8.0; import { OrisUselessToken } from "./Token.sol"; ``` -Nós precisamos da função do token para saber como chamá-lo. +Precisamos da função do token para saber como chamá-la. ```solidity contract CalldataInterpreter { @@ -97,13 +118,13 @@ contract CalldataInterpreter { OrisUselessToken public immutable token; ``` -O endereço do token para o qual nós somos um proxy. +O endereço do token para o qual somos um proxy. ```solidity /** - * @dev Specify the token address - * @param tokenAddr_ ERC-20 contract address + * @dev Especifique o endereço do token + * @param tokenAddr_ Endereço do contrato ERC-20 */ constructor( address tokenAddr_ @@ -112,14 +133,14 @@ O endereço do token para o qual nós somos um proxy. } // constructor ``` -O endereço do token é o único parâmetro que nós precisamos especificar. +O endereço do token é o único parâmetro que precisamos especificar. ```solidity function calldataVal(uint startByte, uint length) private pure returns (uint) { ``` -Ler um valor do calldata. +Leia um valor do calldata. ```solidity uint _retVal; @@ -131,7 +152,9 @@ Ler um valor do calldata. "calldataVal trying to read beyond calldatasize"); ``` -Nós iremos carregar uma simples palavra de 32-bytes (256-bit) para a memória e remover os bytes que não são parte do campo que nós queremos. Este algoritmo não funciona para valores maiores que 32 bytes, e claro, não podemos ler depois do fim do calldata. Na L1 pode ser necessário pular estes testes para economizar gas, mas na L2 o gas é extremamente barato, o que permite qualquer checagem de sanidade que possamos pensar. +Vamos carregar uma única palavra de 32 bytes (256 bits) para a memória e remover os bytes que não fazem parte do campo que queremos. +Este algoritmo não funciona para valores maiores que 32 bytes e, claro, não podemos ler além do final do calldata. +Na L1, pode ser necessário pular esses testes para economizar gás, mas na L2 o gás é extremamente barato, o que permite quaisquer verificações de sanidade que possamos imaginar. ```solidity assembly { @@ -139,16 +162,18 @@ Nós iremos carregar uma simples palavra de 32-bytes (256-bit) para a memória e } ``` -Nós poderiamos ter copiado os dados da chamada ao `fallback()` (veja abaixo), mas é mais fácil usar [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html), a linguagem de montagem da EVM. +Poderíamos ter copiado os dados da chamada para `fallback()` (veja abaixo), mas é mais fácil usar [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html), a linguagem assembly da EVM. -Aqui nós usamos [o opcode CALLDATALOAD](https://www.evm.codes/#35) para ler bytes `startByte` até `startByte+31` na pilha. Em geral, a sintaxe de um opcode em Yul é `(,...)`. +Aqui usamos [o opcode CALLDATALOAD](https://www.evm.codes/#35) para ler os bytes de `startByte` a `startByte+31` na pilha. +Em geral, a sintaxe de um opcode em Yul é `(,...)`. ```solidity _retVal = _retVal >> (256-length*8); ``` -Somente os bytes mais `length` significantes são parte do campo, então nós fazemos [right-shift](https://en.wikipedia.org/wiki/Logical_shift) para se livrar dos outros valores. Isto tem a vantagem adicional de mover o valor para a direita do campo, então é o valor por ele mesmo, ao invés do valor vezes 256alguma coisa. +Apenas os bytes de `comprimento` mais significativos fazem parte do campo, então nós [deslocamos para a direita](https://en.wikipedia.org/wiki/Logical_shift) para nos livrarmos dos outros valores. +Isso tem a vantagem adicional de mover o valor para a direita do campo, então é o valor em si, e não o valor vezes 256algo. ```solidity @@ -159,7 +184,8 @@ Somente os bytes mais `length` significantes são parte do campo, então nós fa fallback() external { ``` -Quando uma chamada a um contrato Solidity não encontra nenhuma das assinaturas de função, ela chama a função [the `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (assumindo que exista uma). No caso de `CalldataInterpreter`, _qualquer_ chamada chega aqui porque não há outras funções `external` ou `public`. +Quando uma chamada para um contrato Solidity não corresponde a nenhuma das assinaturas de função, ela chama [a função `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (supondo que haja uma). +No caso do `CalldataInterpreter`, _qualquer_ chamada chega aqui porque não há outras funções `external` ou `public`. ```solidity uint _func; @@ -167,17 +193,21 @@ Quando uma chamada a um contrato Solidity não encontra nenhuma das assinaturas _func = calldataVal(0, 1); ``` -Leia o primeiro byte do calldata, que nos conta a função. Há duas razões porque uma função não estaria disponível aqui: +Leia o primeiro byte do calldata, que nos diz a função. +Há duas razões pelas quais uma função não estaria disponível aqui: -1. Funções que são `pure` ou `view` não mudam seu estado e não custam gas (quando chamadas off-chain). Não faz sentido tentar reduzir seus custos de gas. -2. Funções que confiam em [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties). O valor de `msg.sender` será o endereço do `CalldataInterpreter`, não o chamador. +1. Funções que são `pure` ou `view` não alteram o estado e não custam gás (quando chamadas fora da cadeia). + Não faz sentido tentar reduzir seu custo de gás. +2. Funções que dependem de [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties). + O valor de `msg.sender` será o endereço do `CalldataInterpreter`, não o do chamador. -Infelizmente, [olhando as especificações do ERC-20](https://eips.ethereum.org/EIPS/eip-20), isto deixa apenas uma função, `transfer`. Isto nos deixa com somente duas funções: `transfer` (porque nós podemos chamar `transferFrom`) e `faucet` (porque nós podemos transferir os tokens de volta a quem quer tenha nos chamado). +Infelizmente, [olhando para as especificações do ERC-20](https://eips.ethereum.org/EIPS/eip-20), isso deixa apenas uma função, `transfer`. +Isso nos deixa com apenas duas funções: `transfer` (porque podemos chamar `transferFrom`) e `faucet` (porque podemos transferir os tokens de volta para quem nos chamou). ```solidity - // Call the state changing methods of token using - // information from the calldata + // Chame os métodos de alteração de estado do token usando + // informações do calldata // faucet if (_func == 1) { @@ -192,43 +222,46 @@ Uma chamada para `faucet()`, que não tem parâmetros. } ``` -Depois que nós chamamos `token.faucet()` nós obtivemos tokens. Entretanto, como o contrato proxy, nós não **precisamos** de tokens. O EOA (externally owned account) ou contrato que nos chamou o faz. Então nós transferimos todos nossos tokens para quem quer tenha nos chamado. +Depois que chamamos `token.faucet()`, nós recebemos tokens. No entanto, como o contrato de proxy, não **precisamos** de tokens. +A EOA (conta de propriedade externa) ou contrato que nos chamou precisa. +Então, transferimos todos os nossos tokens para quem nos chamou. ```solidity - // transfer (assume we have an allowance for it) + // transferir (assumir que temos uma permissão para isso) if (_func == 2) { ``` -Transferir tokens requer dois parâmetros: o endereço de destino e a quantidade. +A transferência de tokens requer dois parâmetros: o endereço de destino e a quantidade. ```solidity token.transferFrom( msg.sender, ``` -Nós apenas permitimos chamadores transferir tokens que eles possuam +Nós apenas permitimos que os chamadores transfiram tokens que eles possuem ```solidity address(uint160(calldataVal(1, 20))), ``` -O endereço de destino começa no byte 1 (o byte 0 é a função). Como um endereço, ele tem 20-bytes de comprimento. +O endereço de destino começa no byte #1 (o byte #0 é a função). +Como um endereço, ele tem 20 bytes de comprimento. ```solidity calldataVal(21, 2) ``` -Para esse contrato em particular nós assumimos que o número máximo de tokens que qualquer um poderia querer transferir cabe em dois bytes (menos que 65536). +Para este contrato em particular, assumimos que o número máximo de tokens que alguém gostaria de transferir cabe em dois bytes (menos de 65536). ```solidity ); } ``` -Em geral, uma transferência pega 35 bytes de calldata: +No geral, uma transferência leva 35 bytes de calldata: | Seção | Comprimento | Bytes | -| ------------------- | -----------:| -----:| +| ------------------- | ----------: | ----: | | Seletor de função | 1 | 0 | | Endereço de destino | 32 | 1-32 | | Quantidade | 2 | 33-34 | @@ -241,13 +274,14 @@ Em geral, uma transferência pega 35 bytes de calldata: ### test.js {#test-js} -[Este teste unitário JavaScript](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) nos mostra como usar este mecanismo (e como verificar que ele trabalha corretamente). Parto do princípio que você entendeu [chai](https://www.chaijs.com/) e [ethers](https://docs.ethers.io/v5/) e apenas explicar as partes que especificamente se aplicam ao contrato. +[Este teste de unidade JavaScript](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) nos mostra como usar este mecanismo (e como verificar se ele funciona corretamente). +Vou supor que você entende [chai](https://www.chaijs.com/) e [ethers](https://docs.ethers.io/v5/) e explicar apenas as partes que se aplicam especificamente ao contrato. ```js const { expect } = require("chai"); describe("CalldataInterpreter", function () { - it("Should let us use tokens", async function () { + it("Deve nos permitir usar tokens", async function () { const Token = await ethers.getContractFactory("OrisUselessToken") const token = await Token.deploy() await token.deployed() @@ -261,24 +295,27 @@ describe("CalldataInterpreter", function () { const signer = await ethers.getSigner() ``` -Nós começamos por implantar ambos contratos. +Começamos implantando ambos os contratos. ```javascript - // Get tokens to play with + // Obter tokens para usar const faucetTx = { ``` -Nós não podemos usar funções de alto nível que nós normalmente usamos (como `token.faucet()`) para criar transações, porque nós não seguimos o ABI. Ao invés disso, nós temos que construir a transação nós mesmos e enviá-la. +Não podemos usar as funções de alto nível que normalmente usaríamos (como `token.faucet()`) para criar transações, porque não seguimos a ABI. +Em vez disso, temos que construir a transação nós mesmos e depois enviá-la. ```javascript to: cdi.address, data: "0x01" ``` -Há dois parâmetros que nós precisamos fornecer para a transação: +Existem dois parâmetros que precisamos fornecer para a transação: -1. `to`, o endereço de destino. Isto é o contrato interpretador do calldata. -2. `data`, o calldata a enviar. No caso de uma chamada de faucet, o dado é um único byte, `0x01`. +1. `to`, o endereço de destino. + Este é o contrato interpretador de calldata. +2. `data`, o calldata a ser enviado. + No caso de uma chamada de faucet, os dados são um único byte, `0x01`. ```javascript @@ -286,26 +323,27 @@ Há dois parâmetros que nós precisamos fornecer para a transação: await (await signer.sendTransaction(faucetTx)).wait() ``` -Nós chamamos o método `sendTransaction` do [assinante](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction) porque nós já especificamos o destino (`faucetTx.to`) e nós precisamos que a transação seja assinada. +Chamamos o [método `sendTransaction` do assinante](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction) porque já especificamos o destino (`faucetTx.to`) e precisamos que a transação seja assinada. ```javascript -// Check the faucet provides the tokens correctly +// Verifique se o faucet fornece os tokens corretamente expect(await token.balanceOf(signer.address)).to.equal(1000) ``` -Aqui nós verificamos o saldo. Não há necessidade de economizar gas em funções `view`, então nós só as rodamos normalmente. +Aqui verificamos o saldo. +Não há necessidade de economizar gás em funções `view`, então apenas as executamos normalmente. ```javascript -// Give the CDI an allowance (approvals cannot be proxied) +// Dê ao CDI uma permissão (aprovações não podem ser intermediadas por proxy) const approveTX = await token.approve(cdi.address, 10000) await approveTX.wait() expect(await token.allowance(signer.address, cdi.address)).to.equal(10000) ``` -Dar ao intérprete calldata uma permissão para ser capaz de fazer transferências. +Dê ao interpretador de calldata uma permissão para poder fazer transferências. ```javascript -// Transfer tokens +// Transferir tokens const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d" const transferTx = { to: cdi.address, @@ -313,53 +351,50 @@ const transferTx = { } ``` -Criar uma transação de transferência. O primeiro byte é "0x02", seguido pelo endereço de destino, e finalmente a quantia (0x0100, que é 256 em decimal). +Crie uma transação de transferência. O primeiro byte é "0x02", seguido pelo endereço de destino e, finalmente, a quantidade (0x0100, que é 256 em decimal). ```javascript await (await signer.sendTransaction(transferTx)).wait() - // Check that we have 256 tokens less + // Verifique se temos 256 tokens a menos expect (await token.balanceOf(signer.address)).to.equal(1000-256) - // And that our destination got them + // E que nosso destino os recebeu expect (await token.balanceOf(destAddr)).to.equal(256) }) // it }) // describe ``` -### Exemplo {#example} - -Se você quiser ver estes arquivos em ação sem precisar rodá-los, siga estes links: - -1. [Implantação de `OrisUselessToken`](https://kovan-optimistic.etherscan.io/tx/1410744) no [endereço `0x950c753c0edbde44a74d3793db738a318e9c8ce8`](https://kovan-optimistic.etherscan.io/address/0x950c753c0edbde44a74d3793db738a318e9c8ce8). -2. [Implantação de `CalldataInterpreter`](https://kovan-optimistic.etherscan.io/tx/1410745) no [endereço `0x16617fea670aefe3b9051096c0eb4aeb4b3a5f55`](https://kovan-optimistic.etherscan.io/address/0x16617fea670aefe3b9051096c0eb4aeb4b3a5f55). -3. [Chamada para `faucet()`](https://kovan-optimistic.etherscan.io/tx/1410746). -4. [Chamada para `OrisUselessToken.approve()`](https://kovan-optimistic.etherscan.io/tx/1410747). Esta chamada tem de ir diretamente para o contrato do token porque o processamento confia no `msg.sender`. -5. [Chamada para `transfer()`](https://kovan-optimistic.etherscan.io/tx/1410748). - -## Reduzindo o custo quando você controla o contrato destino {#reducing-the-cost-when-you-do-control-the-destination-contract} +## Reduzindo o custo quando você controla o contrato de destino {#reducing-the-cost-when-you-do-control-the-destination-contract} -Se você realmente tem controle sobre o contrato destino, você pode criar funções que ignoram as checagens do `msg.sender` porque eles acreditam no intérprete do calldata. [Você pode ver um exemplo de como isto funciona aqui, no branch `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract). +Se você tiver controle sobre o contrato de destino, poderá criar funções que contornem as verificações do `msg.sender` porque elas confiam no interpretador de calldata. +[Você pode ver um exemplo de como isso funciona aqui, na ramificação `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract). -Se o contrato estiver respondendo somente para transações externas, nós poderíamos ter apenas um contrato. Entretanto, isso iria quebrar [a capacidade de composição](/developers/docs/smart-contracts/composability/). É bem melhor ter um contrato que responda a chamadas ERC-20 normais, e outro contrato que responda a transações com chamadas curtas de dados. +Se o contrato estivesse respondendo apenas a transações externas, poderíamos nos virar com apenas um contrato. +No entanto, isso quebraria a [componibilidade](/developers/docs/smart-contracts/composability/). +É muito melhor ter um contrato que responda a chamadas normais de ERC-20 e outro contrato que responda a transações com dados de chamada curtos. ### Token.sol {#token-sol-2} -Neste exemplo nós podemos modificar `Token.sol`. Isto nos deixa ter um número de funções que somente o proxy pode chamar. Eis aqui as novas partes: +Neste exemplo, podemos modificar `Token.sol`. +Isso nos permite ter várias funções que apenas o proxy pode chamar. +Aqui estão as novas partes: ```solidity - // The only address allowed to specify the CalldataInterpreter address + // O único endereço com permissão para especificar o endereço do CalldataInterpreter address owner; - // The CalldataInterpreter address + // O endereço do CalldataInterpreter address proxy = address(0); ``` -O contrato ERC-20 precisa saber a identidade do proxy autorizado. Entretanto, nós não podemos configurar esta variável no construtor, porque nós não sabemos o valor ainda. Este contrato é instanciado primeiro porque o proxy espera o endereço do token no seu construtor. +O contrato ERC-20 precisa saber a identidade do proxy autorizado. +No entanto, não podemos definir essa variável no construtor, porque ainda não sabemos o valor. +Este contrato é instanciado primeiro porque o proxy espera o endereço do token em seu construtor. ```solidity /** - * @dev Calls the ERC20 constructor. + * @dev Chama o construtor ERC20. */ constructor( ) ERC20("Oris useless token-2", "OUT-2") { @@ -367,47 +402,50 @@ O contrato ERC-20 precisa saber a identidade do proxy autorizado. Entretanto, n } ``` -O endereço do criador (chamado`owner`) é armazenado aqui porque este é o único endereço permitido para configurar o proxy. +O endereço do criador (chamado `owner`) é armazenado aqui porque esse é o único endereço com permissão para definir o proxy. ```solidity /** - * @dev set the address for the proxy (the CalldataInterpreter). - * Can only be called once by the owner + * @dev define o endereço para o proxy (o CalldataInterpreter). + * Só pode ser chamado uma vez pelo proprietário */ function setProxy(address _proxy) external { - require(msg.sender == owner, "Can only be called by owner"); - require(proxy == address(0), "Proxy is already set"); + require(msg.sender == owner, "Só pode ser chamado pelo proprietário"); + require(proxy == address(0), "O proxy já foi definido"); proxy = _proxy; } // function setProxy ``` -O proxy tem acesso privilegiado, porque ele pode ignorar checagens de segurança. Para garantir que nós podemos acreditar no proxy, nós somente deixamos `owner` chamar esta função, e somente uma vez. Uma vez que `proxy` tenha um valor real (não zero), este valor não pode mudar, então mesmo se o proprietário decide se tornar trapaceiro, ou caso o mnemônico seja revelado a ele, nós ainda estamos seguros. +O proxy tem acesso privilegiado, porque pode contornar as verificações de segurança. +Para garantir que possamos confiar no proxy, permitimos que apenas `owner` chame esta função, e apenas uma vez. +Uma vez que `proxy` tem um valor real (diferente de zero), esse valor não pode mudar, então mesmo que o proprietário decida se tornar malicioso, ou o mnemônico para ele seja revelado, ainda estamos seguros. ```solidity /** - * @dev Some functions may only be called by the proxy. + * @dev Algumas funções só podem ser chamadas pelo proxy. */ modifier onlyProxy { ``` -Isto é uma função [`modifier`](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm), ela modifica a maneira que outras funções trabalham. +Esta é uma [função `modifier`](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm), que modifica a forma como outras funções funcionam. ```solidity require(msg.sender == proxy); ``` -Primeiro, verifique que nós fomos chamados pelo proxy e ninguém mais. Se não, `revert`. +Primeiro, verifique se fomos chamados pelo proxy e por mais ninguém. +Se não, `reverta`. ```solidity _; } ``` -Neste caso, rode a função que nós modificamos. +Se sim, execute a função que modificamos. ```solidity - /* Functions that allow the proxy to actually proxy for accounts */ + /* Funções que permitem que o proxy realmente atue como proxy para as contas */ function transferProxy(address from, address to, uint256 amount) public virtual onlyProxy() returns (bool) @@ -436,17 +474,18 @@ Neste caso, rode a função que nós modificamos. } ``` -Há três operações que normalmente requerem que a mensagem venha direto da entidade transferindo tokens ou aprovando uma permissão. Aqui nós temos uma versão de proxy destas operações que: +Estas são três operações que normalmente exigem que a mensagem venha diretamente da entidade que transfere tokens ou aprova uma permissão. +Aqui temos uma versão proxy dessas operações que: -1. É modificada pelo `onlyProxy()`, de modo que ninguém mais tem permissão de controlá-los. -2. Pega o endereço que seria normalmente `msg.sender` como um parâmetro extra. +1. É modificada por `onlyProxy()` para que ninguém mais possa controlá-las. +2. Recebe o endereço que normalmente seria `msg.sender` como um parâmetro extra. ### CalldataInterpreter.sol {#calldatainterpreter-sol-2} -O interpretador calldata é praticamente idêntico ao acima, exceto que as funções com proxy recebem um parâmetro `msg.sender` e não há necessidade de permissão `transfer`. +O interpretador de calldata é quase idêntico ao anterior, exceto que as funções com proxy recebem um parâmetro `msg.sender` e não há necessidade de uma permissão para `transfer`. ```solidity - // transfer (no need for allowance) + // transferir (não é necessária permissão) if (_func == 2) { token.transferProxy( msg.sender, @@ -455,7 +494,7 @@ O interpretador calldata é praticamente idêntico ao acima, exceto que as funç ); } - // approve + // aprovar if (_func == 3) { token.approveProxy( msg.sender, @@ -464,7 +503,7 @@ O interpretador calldata é praticamente idêntico ao acima, exceto que as funç ); } - // transferFrom + // transferirDe if (_func == 4) { token.transferFromProxy( msg.sender, @@ -477,7 +516,7 @@ O interpretador calldata é praticamente idêntico ao acima, exceto que as funç ### Test.js {#test-js-2} -Há pequenas mudanças entre o código de teste anterior e este. +Existem algumas alterações entre o código de teste anterior e este. ```js const Cdi = await ethers.getContractFactory("CalldataInterpreter") @@ -486,21 +525,22 @@ await cdi.deployed() await token.setProxy(cdi.address) ``` -Nós precisamos contar ao contrato ERC-20 qual proxy acreditar +Precisamos dizer ao contrato ERC-20 em qual proxy confiar ```js console.log("CalldataInterpreter addr:", cdi.address) -// Need two signers to verify allowances +// Precisa de dois assinantes para verificar as permissões const signers = await ethers.getSigners() const signer = signers[0] const poorSigner = signers[1] ``` -Para checar `approve()` e `transferFrom()` nós precisamos de um segundo assinante. Nós o chamamos de `poorSigner` porque ele não pega nenhum de nossos tokens (ele precisa ter ETH, claro). +Para verificar `approve()` e `transferFrom()`, precisamos de um segundo assinante. +Nós o chamamos de `poorSigner` porque ele não recebe nenhum de nossos tokens (ele precisa ter ETH, é claro). ```js -// Transfer tokens +// Transferir tokens const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d" const transferTx = { to: cdi.address, @@ -509,10 +549,10 @@ const transferTx = { await (await signer.sendTransaction(transferTx)).wait() ``` -Como o contrato ERC-20 confia no proxy (`cdi`), nós não precisamos de uma permissão para confiar em transferências. +Como o contrato ERC-20 confia no proxy (`cdi`), não precisamos de uma permissão para retransmitir transferências. ```js -// approval and transferFrom +// aprovação e transferirDe const approveTx = { to: cdi.address, data: "0x03" + poorSigner.address.slice(2, 42) + "00FF", @@ -527,24 +567,19 @@ const transferFromTx = { } await (await poorSigner.sendTransaction(transferFromTx)).wait() -// Check the approve / transferFrom combo was done correctly +// Verifique se a combinação de aprovação / transferirDe foi feita corretamente expect(await token.balanceOf(destAddr2)).to.equal(255) ``` -Teste as duas novas funções. Note que `transferFromTx` requer dois parâmetros de endereço: o que deu a permissão e o recebedor. +Teste as duas novas funções. +Observe que `transferFromTx` requer dois parâmetros de endereço: o doador da permissão e o receptor. -### Exemplo {#example-2} - -Se você quiser ver estes arquivos em ação sem precisar rodá-los, siga estes links: +## Conclusão {#conclusion} -1. [Implantação de `OrisUselessToken-2`](https://kovan-optimistic.etherscan.io/tx/1475397) no endereço [`0xb47c1f550d8af70b339970c673bbdb2594011696`](https://kovan-optimistic.etherscan.io/address/0xb47c1f550d8af70b339970c673bbdb2594011696). -2. [Implantação de `CalldataInterpreter`](https://kovan-optimistic.etherscan.io/tx/1475400) no endereço [`0x0dccfd03e3aaba2f8c4ea4008487fd0380815892`](https://kovan-optimistic.etherscan.io/address/0x0dccfd03e3aaba2f8c4ea4008487fd0380815892). -3. [Chamada para `transfer()`](https://kovan-optimistic.etherscan.io/tx/1475402). -4. [Chamada para `faucet()`](https://kovan-optimistic.etherscan.io/tx/1475409). -5. [Chamada para `transferProxy()`](https://kovan-optimistic.etherscan.io/tx/1475416). -6. [Chamada para `approveProxy()`](https://kovan-optimistic.etherscan.io/tx/1475419). -7. [Chamada para `transferFromFProxy()`](https://kovan-optimistic.etherscan.io/tx/1475421). Note que esta chamada vem de um endereço diferente dos outros, `poorSigner` ao invés de `signer`. +Tanto a [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) quanto a [Arbitrum](https://developer.offchainlabs.com/docs/special_features) estão procurando maneiras de reduzir o tamanho do calldata escrito na L1 e, portanto, o custo das transações. +No entanto, como provedores de infraestrutura em busca de soluções genéricas, nossas habilidades são limitadas. +Como desenvolvedor de dapps, você tem conhecimento específico da aplicação, o que permite otimizar seu calldata muito melhor do que poderíamos em uma solução genérica. +Esperamos que este artigo o ajude a encontrar a solução ideal para suas necessidades. -## Conclusão {#conclusion} +[Veja aqui mais do meu trabalho](https://cryptodocguy.pro/). -Ambos [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) e [Arbitrum](https://developer.offchainlabs.com/docs/special_features) estão procurando por maneiras de reduzir o tamanho do calldata escrito no L1 e portanto o custo das transações. Entretanto, como provedores de infraestrutura procurando por soluções genéricas, nossas habilidades são limitadas. Como desenvolvedor dapp, você tem conhecimento específico de aplicações, o que te leva a otimizar seu calldata muito melhor do que nós poderíamos com uma solução genérica. Esperamos que este artigo ajude você a encontrar a solução ideal para as suas necessidades. diff --git a/public/content/translations/pt-br/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/pt-br/developers/tutorials/smart-contract-security-guidelines/index.md index 6053257ce85..344f34b77f0 100644 --- a/public/content/translations/pt-br/developers/tutorials/smart-contract-security-guidelines/index.md +++ b/public/content/translations/pt-br/developers/tutorials/smart-contract-security-guidelines/index.md @@ -1,21 +1,18 @@ --- -title: Diretrizes de segurança do contrato inteligente -description: Uma lista de verificações de diretrizes de segurança a considerar ao construir seu dapp +title: "Diretrizes de segurança do contrato inteligente" +description: "Uma lista de verificações de diretrizes de segurança a considerar ao construir seu dapp" author: "Trailofbits" -tags: - - "solidity" - - "contratos inteligentes" - - "segurança" +tags: [ "Solidity", "smart contracts", "segurança" ] skill: intermediate lang: pt-br published: 2020-09-06 -source: Construindo contratos seguros +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md --- Siga estas recomendações de alto nível para construir contratos inteligentes mais seguros. -## Padrões de design {#design-guidelines} +## Diretrizes de design {#design-guidelines} O design do contrato deve ser discutido antecipadamente, antes de escrever qualquer linha de código. @@ -23,40 +20,40 @@ O design do contrato deve ser discutido antecipadamente, antes de escrever qualq A documentação pode ser escrita em diferentes níveis, e deve ser atualizada durante a implementação dos contratos: -- **Uma descrição simples em inglês do sistema**, descrevendo o que os contratos fazem e qualquer suposição no código. -- **Esquemas e diagramas arquitetônicos**, incluindo as interações de contratos e a máquina de estado do sistema. [Impressoras do Slither](https://github.com/crytic/slither/wiki/Printer-documentation) podem ajudar a gerar esses esquemas. -- **Documentação de código Thorough**, o [formato Natspec](https://solidity.readthedocs.io/en/develop/natspec-format.html) pode ser usado para Solidity. +- **Uma descrição em inglês simples do sistema**, descrevendo o que os contratos fazem e quaisquer suposições sobre a base de código. +- **Esquemas e diagramas de arquitetura**, incluindo as interações de contratos e a máquina de estado do sistema. Os [impressores do Slither](https://github.com/crytic/slither/wiki/Printer-documentation) podem ajudar a gerar esses esquemas. +- **Documentação completa do código**, o [formato Natspec](https://docs.soliditylang.org/en/develop/natspec-format.html) pode ser usado para o Solidity. -### Computação on-chain vs off-chain {#on-chain-vs-off-chain-computation} +### Computação onchain vs. offchain {#onchain-vs-offchain-computation} -- **Mantenha o máximo de código que puder off-chain (fora da cadeia).** Mantenha a menor camada on-chain (dentro da cadeia). Pré-processe dados com código off-chain de tal forma que a verificação on-chain torne-se simples. Você precisa de uma lista ordenada? Ordene a lista off-chain, então apenas verifique a ordem on-chain. +- **Mantenha o máximo de código que puder offchain.** Mantenha a camada onchain pequena. Pré-processe dados com código offchain de forma que a verificação onchain seja simples. Você precisa de uma lista ordenada? Ordene a lista off-chain, então apenas verifique a ordem on-chain. -### Capacidade de Atualização {#upgradeability} +### Atualizabilidade {#upgradeability} -Nós discutimos as diferentes soluções de atualização em [nosso blog](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Faça ou não uma escolha deliberada para apoiar a capacidade de atualização antes de escrever qualquer código. A decisão irá influenciar como você estrutura nosso código. Em geral, recomendamos: +Discutimos as diferentes soluções de atualizabilidade em [nossa postagem no blog](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Faça ou não uma escolha deliberada para apoiar a capacidade de atualização antes de escrever qualquer código. A decisão influenciará como você estrutura seu código. Em geral, recomendamos: -- **Favorecer a [migração do contrato](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) sobre a atualização.** O sistema de migração tem muitas das mesmas vantagens do que ser atualizável, sem suas desvantagens. -- **Usando o padrão de separação de dados sobre o proxy delegatecallproxy.** Se o seu projeto tem uma separação de abstração clara, a atualizabilidade usando a separação de dados exigirá apenas alguns ajustes. O delegatecallproxy exige conhecimento de EVM e é altamente susceptível de erros. -- **Documentar o procedimento de migração/atualização antes da implantação.** Se você tiver que reagir sob o estresse sem quaisquer diretrizes, você cometerá erros. Escreva o procedimento a seguir com antecedência. Ele deve incluir: +- **Prefira a [migração de contrato](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) em vez da atualizabilidade.** Os sistemas de migração têm muitas das mesmas vantagens que os atualizáveis, sem as suas desvantagens. +- **Usando o padrão de separação de dados em vez do delegatecallproxy.** Se o seu projeto tem uma separação de abstração clara, a atualizabilidade usando a separação de dados necessitará de apenas alguns ajustes. O delegatecallproxy exige conhecimento de EVM e é altamente susceptível de erros. +- **Documente o procedimento de migração/atualização antes da implantação.** Se você tiver que reagir sob estresse sem quaisquer diretrizes, você cometerá erros. Escreva o procedimento a seguir com antecedência. Ele deve incluir: - As exigências que iniciam os novos contratos - Onde são armazenadas as chaves e como acessá-las - Como verificar a implantação de arquivos! Desenvolva e teste um script de pós-implantação. -## Orientações de implementação {#implementation-guidelines} +## Diretrizes de implementação {#implementation-guidelines} -**Esforço pela simplicidade.** Sempre use a solução mais simples que se encaixa em seu propósito. Qualquer membro da sua equipe deve ser capaz de entender a sua solução. +**Busque a simplicidade.** Sempre use a solução mais simples que se adeque ao seu propósito. Qualquer membro da sua equipe deve ser capaz de entender a sua solução. ### Composição de funções {#function-composition} A arquitetura da sua base de código deve facilitar a revisão do seu código. Evite escolhas arquitetônicas que diminuam a capacidade de raciocínio sobre sua exatidão. -- **Divida a lógica do seu sistema**, seja por meio de vários contratos ou agrupando funções semelhantes juntas (por exemplo, autenticação, aritmética, ...). -- **Escreva funções pequenas, com um propósito claro.** Isso facilitará uma revisão mais tranquila e permitirá o teste de componentes individuais. +- **Divida a lógica do seu sistema**, seja por meio de vários contratos ou agrupando funções semelhantes (por exemplo, autenticação, aritmética, ...). +- **Escreva funções pequenas, com um propósito claro.** Isso facilitará a revisão e permitirá o teste de componentes individuais. ### Herança {#inheritance} - **Mantenha a herança gerenciável.** A herança deve ser usada para dividir a lógica, no entanto, seu projeto deve visar minimizar a profundidade e a largura da árvore de herança. -- **Use a [impressora de herança de Slither](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) para verificar a hierarquia dos contratos.** A impressora de herança irá ajudá-lo a rever o tamanho da hierarquia. +- **Use o [impressor de herança](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) do Slither para verificar a hierarquia dos contratos.** O impressor de herança ajudará você a revisar o tamanho da hierarquia. ### Eventos {#events} @@ -64,31 +61,31 @@ A arquitetura da sua base de código deve facilitar a revisão do seu código. E ### Evite armadilhas conhecidas {#avoid-known-pitfalls} -- **Esteja ciente dos problemas de segurança mais comuns.** Há muitos recursos on-line para aprender sobre problemas comuns, como [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture o Ether](https://capturetheether.com/), ou [ contratos não tão inteligentes](https://github.com/crytic/not-so-smart-contracts/). -- **Esteja ciente das seções de avisos na [documentação Solidity](https://solidity.readthedocs.io/en/latest/)** As seções de avisos irão informá-lo sobre comportamentos não óbvios da linguagem. +- **Esteja ciente dos problemas de segurança mais comuns.** Existem muitos recursos online para aprender sobre problemas comuns, como [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/) ou [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/). +- **Esteja ciente das seções de avisos na [documentação do Solidity](https://docs.soliditylang.org/en/latest/).** As seções de avisos informarão sobre comportamentos não óbvios da linguagem. ### Dependências {#dependencies} -- **Use bibliotecas testadas.** A importação de código de bibliotecas testadas reduzirá a probabilidade de você escrever código com erros. Se você deseja escrever um contrato ERC20, use [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20). -- **Use um gerenciador de dependências; evite "copiar-e-colar" códigos.** Se você estiver contando com uma fonte externa, então você deve mantê-lo atualizado com a fonte original. +- **Use bibliotecas bem testadas.** Importar código de bibliotecas bem testadas reduzirá a probabilidade de você escrever código com bugs. Se você quiser escrever um contrato ERC20, use o [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20). +- **Use um gerenciador de dependências; evite copiar e colar código.** Se você depende de uma fonte externa, deve mantê-la atualizada com a fonte original. -### Teste e Validação {#testing-and-verification} +### Teste e verificação {#testing-and-verification} -- **Escreva testes unitários completos.** Um conjunto extenso de testes é crucial para construir softwares de alta qualidade. -- **Escreva propriedades e verificações personalizadas com [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) e [Manticore](https://github.com/trailofbits/manticore).** Ferramentas automatizadas ajudarão a garantir que o seu contrato é seguro. Revise o resto deste guia para aprender a escrever propriedades e verificações eficientes. -- **Use o [crytic.io](https://crytic.io/).** O Critic integra-se ao Github, fornece acesso a detectores privados do Slither e executa verificações de propriedade personalizadas pelo Echidna. +- **Escreva testes de unidade completos.** Um conjunto extenso de testes é crucial para construir um software de alta qualidade. +- **Escreva verificações e propriedades personalizadas para [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) e [Manticore](https://github.com/trailofbits/manticore).** Ferramentas automatizadas ajudarão a garantir que seu contrato seja seguro. Revise o resto deste guia para aprender a escrever propriedades e verificações eficientes. +- **Use o [crytic.io](https://crytic.io/).** O Crytic se integra ao GitHub, fornece acesso a detectores privados do Slither e executa verificações de propriedade personalizadas do Echidna. ### Solidity {#solidity} -- **Favoreça a Solidity 0.5 em vez de 0.4 e 0.6.** Em nossa opinião, a Solidity 0.5 é mais seguro e tem melhores práticas incorporadas que a 0.4. A Solidity 0.6 provou ser demasiado instável para produção e precisa de tempo para amadurecer. -- **Use um lançamento estável para compilar; use a versão mais recente para verificar se há avisos.** Verifique se o seu código não relatou problemas com a versão mais recente do compilador. No entanto, a Solidity tem um ciclo de lançamento rápido e tem um histórico de erros do compilador, então não recomendamos a versão mais recente para implantar (veja a [recomendação de versão solc do Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33)). -- **Não use montagem embutida.** A montagem requer experiência em EVM. Não escreva o código EVM se você não tiver _dominado_ o Yellow Paper da Ethereum. +- **Prefira o Solidity 0.5 ao 0.4 e 0.6.** Em nossa opinião, o Solidity 0.5 é mais seguro e tem práticas incorporadas melhores que o 0.4. A Solidity 0.6 provou ser demasiado instável para produção e precisa de tempo para amadurecer. +- **Use uma versão estável para compilar; use a versão mais recente para verificar se há avisos.** Verifique se seu código não tem problemas relatados com a versão mais recente do compilador. No entanto, o Solidity tem um ciclo de lançamento rápido e um histórico de bugs de compilador, portanto, não recomendamos a versão mais recente para implantação (veja a [recomendação de versão do solc do Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33)). +- **Não use assembly em linha.** O assembly requer experiência em EVM. Não escreva código EVM se você não tiver _dominado_ o yellow paper. -## Orientações de implantação {#deployment-guidelines} +## Diretrizes de implantação {#deployment-guidelines} Uma vez que o contrato tenha sido desenvolvido e implantado: -- **Monitore seus contratos.** Observe os acessos e esteja pronto para reagir em caso de comprometimento do contrato ou da carteira. -- **Adicione suas informações de contato em [contatos de segurança da blockchain](https://github.com/crytic/blockchain-security-contacts).** Essa lista ajuda a terceiros a entrar em contato com você caso uma falha de segurança seja descoberta. -- **Proteja as carteiras de usuários privilegiados.** Siga nossas [melhores práticas](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) se você armazenar chaves em carteiras físicas (hardware). -- **Tenha uma resposta ao plano de incidentes.** Considere que seus contratos inteligentes possam ser comprometidos. Mesmo que seus contratos estejam livres de erros, um invasor pode assumir o controle das chaves do proprietário do contrato. +- **Monitore seus contratos.** Observe os logs e esteja pronto para reagir em caso de comprometimento do contrato ou da carteira. +- **Adicione suas informações de contato em [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** Esta lista ajuda terceiros a entrarem em contato com você caso uma falha de segurança seja descoberta. +- **Proteja as carteiras de usuários privilegiados.** Siga nossas [melhores práticas](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) se você armazena chaves em carteiras de hardware. +- **Tenha um plano de resposta a incidentes.** Considere que seus contratos inteligentes podem ser comprometidos. Mesmo que seus contratos estejam livres de erros, um invasor pode assumir o controle das chaves do proprietário do contrato. diff --git a/public/content/translations/pt-br/developers/tutorials/stealth-addr/index.md b/public/content/translations/pt-br/developers/tutorials/stealth-addr/index.md new file mode 100644 index 00000000000..959feca5a6e --- /dev/null +++ b/public/content/translations/pt-br/developers/tutorials/stealth-addr/index.md @@ -0,0 +1,443 @@ +--- +title: "Usando endereços secretos" +description: "Endereços secretos permitem que os usuários transfiram ativos anonimamente. Após ler este artigo, você será capaz de: Explicar o que são endereços secretos e como eles funcionam, entender como usar endereços secretos de uma forma que preserve o anonimato e escrever uma aplicação web que use endereços secretos." +author: Ori Pomerantz +tags: + [ + "Endereço secreto", + "privacidade", + "criptografia", + "Rust", + "wasm" + ] +skill: intermediate +published: 2025-11-30 +lang: pt-br +sidebarDepth: 3 +--- + +Você é o Bill. Por razões que não vamos entrar em detalhes, você quer fazer uma doação para a campanha "Alice para Rainha do Mundo" e que a Alice saiba que você doou para que ela o recompense se ganhar. Infelizmente, a vitória dela não é garantida. Existe uma campanha concorrente, "Carol para Imperatriz do Sistema Solar". Se a Carol ganhar, e ela descobrir que você doou para a Alice, você terá problemas. Então você não pode simplesmente transferir 200 ETH da sua conta para a da Alice. + +O [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) tem a solução. Este ERC explica como usar [endereços secretos](https://nerolation.github.io/stealth-utils) para transferência anônima. + +**Aviso**: A criptografia por trás dos endereços secretos é, até onde sabemos, sólida. No entanto, existem potenciais ataques de canal lateral. [Abaixo](#go-wrong), você verá o que pode fazer para reduzir este risco. + +## Como os endereços secretos funcionam {#how} + +Este artigo tentará explicar os endereços secretos de duas maneiras. A primeira é [como usá-los](#how-use). Esta parte é suficiente para entender o resto do artigo. Depois, há [uma explicação da matemática por trás disso](#how-math). Se você estiver interessado em criptografia, leia esta parte também. + +### A versão simples (como usar endereços secretos) {#how-use} + +Alice cria duas chaves privadas e publica as chaves públicas correspondentes (que podem ser combinadas em um único meta-endereço de comprimento duplo). Bill também cria uma chave privada e publica a chave pública correspondente. + +Usando a chave pública de uma parte e a chave privada da outra, você pode derivar um segredo compartilhado conhecido apenas por Alice e Bill (ele não pode ser derivado apenas das chaves públicas). Usando este segredo compartilhado, Bill obtém o endereço secreto e pode enviar ativos para ele. + +Alice também obtém o endereço a partir do segredo compartilhado, mas como ela conhece as chaves privadas para as chaves públicas que publicou, ela também pode obter a chave privada que lhe permite sacar desse endereço. + +### A matemática (por que endereços secretos funcionam assim) {#how-math} + +Endereços secretos padrão usam [criptografia de curva elíptica (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor) para obter melhor desempenho com menos bits de chave, mantendo o mesmo nível de segurança. Mas, na maior parte, podemos ignorar isso e fingir que estamos usando aritmética regular. + +Existe um número que todos conhecem, _G_. Você pode multiplicar por _G_. Mas, devido à natureza da ECC, é praticamente impossível dividir por _G_. A forma como a criptografia de chave pública geralmente funciona no Ethereum é que você pode usar uma chave privada, _Ppriv_, para assinar transações que são então verificadas por uma chave pública, _Ppub = GPpriv_. + +Alice cria duas chaves privadas, _Kpriv_ e _Vpriv_. _Kpriv_ será usada para gastar dinheiro do endereço secreto, e _Vpriv_ para visualizar os endereços que pertencem a Alice. Alice então publica as chaves públicas: _Kpub = GKpriv_ e _Vpub = GVpriv_ + +Bill cria uma terceira chave privada, _Rpriv_, e publica _Rpub = GRpriv_ em um registro central (Bill também poderia tê-la enviado para Alice, mas assumimos que Carol está ouvindo). + +Bill calcula _RprivVpub = GRprivVpriv_, que ele espera que Alice também saiba (explicado abaixo). Este valor é chamado _S_, o segredo compartilhado. Isso dá a Bill uma chave pública, _Ppub = Kpub+G\*hash(S)_. A partir desta chave pública, ele pode calcular um endereço e enviar quaisquer recursos que ele queira para ele. No futuro, se Alice ganhar, Bill pode dizer a ela _Rpriv_ para provar que os recursos vieram dele. + +Alice calcula _RpubVpriv = GRprivVpriv_. Isso dá a ela o mesmo segredo compartilhado, _S_. Como ela conhece a chave privada, _Kpriv_, ela pode calcular _Ppriv = Kpriv+hash(S)_. Esta chave permite que ela acesse ativos no endereço que resulta de _Ppub = GPpriv = GKpriv+G\*hash(S) = Kpub+G\*hash(S)_. + +Temos uma chave de visualização separada para permitir que Alice subcontrate os Serviços de Campanha de Dominação Mundial de Dave. Alice está disposta a deixar Dave saber os endereços públicos e informá-la quando mais dinheiro estiver disponível, mas ela não quer que ele gaste o dinheiro da campanha dela. + +Como a visualização e o gasto usam chaves separadas, Alice pode dar a Dave _Vpriv_. Então Dave pode calcular _S = RpubVpriv = GRprivVpriv_ e dessa forma obter as chaves públicas (_Ppub = Kpub+G\*hash(S)_). Mas sem _Kpriv_ Dave não consegue obter a chave privada. + +Para resumir, estes são os valores conhecidos pelos diferentes participantes. + +| Alice | Publicado | Bill | Dave | | +| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ | +| G | G | G | G | | +| _Kpriv_ | — | — | — | | +| _Vpriv_ | — | — | _Vpriv_ | | +| _Kpub = GKpriv_ | _Kpub_ | _Kpub_ | _Kpub_ | | +| _Vpub = GVpriv_ | _Vpub_ | _Vpub_ | _Vpub_ | | +| — | — | _Rpriv_ | — | | +| _Rpub_ | _Rpub_ | _Rpub = GRpriv_ | _Rpub_ | | +| _S = RpubVpriv = GRprivVpriv_ | — | _S = RprivVpub = GRprivVpriv_ | _S = _RpubVpriv_ = GRprivVpriv_ | | +| _Ppub = Kpub+G\*hash(S)_ | — | _Ppub = Kpub+G\*hash(S)_ | _Ppub = Kpub+G\*hash(S)_ | | +| _Endereço=f(Ppub)_ | — | _Endereço=f(Ppub)_ | _Endereço=f(Ppub)_ | _Endereço=f(Ppub)_ | +| _Ppriv = Kpriv+hash(S)_ | — | — | — | | + +## Quando os endereços secretos dão errado {#go-wrong} + +_Não há segredos na cadeia de blocos_. Embora os endereços secretos possam fornecer privacidade, essa privacidade é suscetível à análise de tráfego. Para dar um exemplo trivial, imagine que Bill financia um endereço e imediatamente envia uma transação para publicar um valor _Rpub_. Sem o _Vpriv_ de Alice, não podemos ter certeza de que este é um endereço secreto, mas essa é a aposta mais segura. Em seguida, vemos outra transação que transfere todo o ETH desse endereço para o endereço do fundo de campanha de Alice. Podemos não ser capazes de provar, mas é provável que Bill tenha acabado de doar para a campanha de Alice. Carol certamente pensaria assim. + +É fácil para Bill separar a publicação de _Rpub_ do financiamento do endereço secreto (fazê-los em momentos diferentes, a partir de endereços diferentes). No entanto, isso não é suficiente. O padrão que Carol procura é que Bill financie um endereço e, em seguida, o fundo de campanha de Alice saca dele. + +Uma solução é a campanha de Alice não sacar o dinheiro diretamente, mas usá-lo para pagar um terceiro. Se a campanha de Alice envia 10 ETH para os Serviços de Campanha de Dominação Mundial de Dave, Carol só sabe que Bill doou para um dos clientes de Dave. Se Dave tiver clientes suficientes, Carol não seria capaz de saber se Bill doou para Alice, que compete com ela, ou para Adam, Albert ou Abigail, com quem Carol não se importa. Alice pode incluir um valor com hash no pagamento e, em seguida, fornecer a Dave a pré-imagem, para provar que foi sua doação. Alternativamente, como observado acima, se Alice der a Dave seu _Vpriv_, ele já saberá de quem veio o pagamento. + +O principal problema com essa solução é que ela exige que Alice se preocupe com o sigilo quando esse sigilo beneficia Bill. Alice pode querer manter sua reputação para que o amigo de Bill, Bob, também doe para ela. Mas também é possível que ela não se importe em expor Bill, porque então ele ficará com medo do que acontecerá se Carol vencer. Bill pode acabar dando ainda mais apoio a Alice. + +### Usando várias camadas secretas {#multi-layer} + +Em vez de confiar em Alice para preservar a privacidade de Bill, o próprio Bill pode fazê-lo. Ele pode gerar múltiplos meta-endereços para pessoas fictícias, Bob e Bella. Bill então envia ETH para Bob, e "Bob" (que na verdade é Bill) o envia para Bella. "Bella" (também Bill) o envia para Alice. + +Carol ainda pode fazer análise de tráfego e ver o pipeline Bill-para-Bob-para-Bella-para-Alice. No entanto, se "Bob" e "Bella" também usarem ETH para outros fins, não parecerá que Bill transferiu nada para Alice, mesmo que Alice saque imediatamente do endereço secreto para seu endereço de campanha conhecido. + +## Escrevendo uma aplicação de endereço secreto {#write-app} + +Este artigo explica uma aplicação de endereço secreto [disponível no GitHub](https://github.com/qbzzt/251022-stealth-addresses.git). + +### Ferramentas {#tools} + +Existe [uma biblioteca de endereço secreto em typescript](https://github.com/ScopeLift/stealth-address-sdk) que poderíamos usar. No entanto, operações criptográficas podem ser intensivas em CPU. Prefiro implementá-las em uma linguagem compilada, como [Rust](https://rust-lang.org/), e usar [WASM](https://webassembly.org/) para executar o código no navegador. + +Vamos usar [Vite](https://vite.dev/) e [React](https://react.dev/). Estas são ferramentas padrão da indústria; se você não estiver familiarizado com elas, pode usar [este tutorial](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Para usar o Vite, precisamos do Node. + +### Veja os endereços secretos em ação {#in-action} + +1. Instale as ferramentas necessárias: [Rust](https://rust-lang.org/tools/install/) e [Node](https://nodejs.org/en/download). + +2. Clone o repositório do GitHub. + + ```sh + git clone https://github.com/qbzzt/251022-stealth-addresses.git + cd 251022-stealth-addresses + ``` + +3. Instale os pré-requisitos e compile o código Rust. + + ```sh + cd src/rust-wasm + rustup target add wasm32-unknown-unknown + cargo install wasm-pack + wasm-pack build --target web + ``` + +4. Inicie o servidor web. + + ```sh + cd ../.. + npm install + npm run dev + ``` + +5. Acesse [a aplicação](http://localhost:5173/). Esta página da aplicação tem dois frames: um para a interface de usuário de Alice e outro para a de Bill. Os dois frames não se comunicam; eles estão na mesma página apenas por conveniência. + +6. Como Alice, clique em **Gerar um Meta-endereço Secreto**. Isso exibirá o novo endereço secreto e as chaves privadas correspondentes. Copie o meta-endereço secreto para a área de transferência. + +7. Como Bill, cole o novo meta-endereço secreto e clique em **Gerar um endereço**. Isso lhe dá o endereço para financiar Alice. + +8. Copie o endereço e a chave pública de Bill e cole-os na área "Chave privada para endereço gerado por Bill" da interface do usuário de Alice. Depois que esses campos forem preenchidos, você verá a chave privada para acessar os ativos nesse endereço. + +9. Você pode usar [uma calculadora online](https://iancoleman.net/ethereum-private-key-to-address/) para garantir que a chave privada corresponda ao endereço. + +### Como o programa funciona {#how-the-program-works} + +#### O componente WASM {#wasm} + +O código-fonte que compila para WASM é escrito em [Rust](https://rust-lang.org/). Você pode vê-lo em [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs). Este código é principalmente uma interface entre o código JavaScript e [a biblioteca `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses). + +**`Cargo.toml`** + +[`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) em Rust é análogo a [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) em JavaScript. Ele contém informações do pacote, declarações de dependência, etc. + +```toml +[package] +name = "rust-wasm" +version = "0.1.0" +edition = "2024" + +[dependencies] +eth-stealth-addresses = "0.1.0" +hex = "0.4.3" +wasm-bindgen = "0.2.104" +getrandom = { version = "0.2", features = ["js"] } +``` + +O pacote [`getrandom`](https://docs.rs/getrandom/latest/getrandom/) precisa gerar valores aleatórios. Isso não pode ser feito por meios puramente algorítmicos; requer acesso a um processo físico como fonte de entropia. Esta definição especifica que obteremos essa entropia perguntando ao navegador em que estamos executando. + +```toml +console_error_panic_hook = "0.1.7" +``` + +[Esta biblioteca](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) nos dá mensagens de erro mais significativas quando o código WASM entra em pânico e não pode continuar. + +```toml +[lib] +crate-type = ["cdylib", "rlib"] +``` + +O tipo de saída necessário para produzir código WASM. + +**`lib.rs`** + +Este é o código Rust real. + +```rust +use wasm_bindgen::prelude::*; +``` + +As definições para criar um pacote WASM a partir do Rust. Elas estão documentadas [aqui](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html). + +```rust +use eth_stealth_addresses::{ + generate_stealth_meta_address, + generate_stealth_address, + compute_stealth_key +}; +``` + +As funções que precisamos da [biblioteca `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses). + +```rust +use hex::{decode,encode}; +``` + +Rust normalmente usa [arrays](https://doc.rust-lang.org/std/primitive.array.html) de bytes (`[u8; ]`) para valores. Mas em JavaScript, normalmente usamos strings hexadecimais. [A biblioteca `hex`](https://docs.rs/hex/latest/hex/) traduz para nós de uma representação para a outra. + +```rust +#[wasm_bindgen] +``` + +Gere bindings WASM para poder chamar esta função a partir do JavaScript. + +```rust +pub fn wasm_generate_stealth_meta_address() -> String { +``` + +A maneira mais fácil de retornar um objeto com vários campos é retornar uma string JSON. + +```rust + let (address, spend_private_key, view_private_key) = + generate_stealth_meta_address(); +``` + +A [`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) retorna três campos: + +- O meta-endereço (_Kpub_ e _Vpub_) +- A chave privada de visualização (_Vpriv_) +- A chave privada de gastos (_Kpriv_) + +A sintaxe de [tupla](https://doc.rust-lang.org/std/primitive.tuple.html) nos permite separar esses valores novamente. + +```rust + format!("{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}", + encode(address), + encode(view_private_key), + encode(spend_private_key) + ) +} +``` + +Use a macro [`format!`](https://doc.rust-lang.org/std/fmt/index.html) para gerar a string codificada em JSON. Use [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html) para alterar os arrays para strings hexadecimais. + +```rust +fn str_to_array(s: &str) -> Option<[u8; N]> { +``` + +Esta função transforma uma string hexadecimal (fornecida pelo JavaScript) em um array de bytes. Nós a usamos para analisar valores fornecidos pelo código JavaScript. Esta função é complicada por causa de como o Rust lida com arrays e vetores. + +A expressão `` é chamada de [genérica](https://doc.rust-lang.org/book/ch10-01-syntax.html). `N` é um parâmetro que controla o comprimento do array retornado. A função é na verdade chamada `str_to_array::`, onde `n` é o comprimento do array. + +O valor de retorno é `Option<[u8; N]>`, o que significa que o array retornado é [opcional](https://doc.rust-lang.org/std/option/). Este é um padrão típico em Rust para funções que podem falhar. + +Por exemplo, se chamarmos `str_to_array::10("bad060a7")`, a função deveria retornar um array de dez valores, mas a entrada tem apenas quatro bytes. A função precisa falhar, e ela faz isso retornando `None`. O valor de retorno para `str_to_array::4("bad060a7")` seria `Some<[0xba, 0xd0, 0x60, 0xa7]>`. + +```rust + // decode returns Result, _> + let vec = decode(s).ok()?; +``` + +A função [`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) retorna um `Result, FromHexError>`. O tipo [`Result`](https://doc.rust-lang.org/std/result/) pode conter um resultado bem-sucedido (`Ok(value)`) ou um erro (`Err(error)`). + +O método `.ok()` transforma o `Result` em um `Option`, cujo valor é o valor de `Ok()` se for bem-sucedido, ou `None` se não for. Finalmente, o [operador de ponto de interrogação](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) aborta as funções atuais e retorna um `None` se o `Option` estiver vazio. Caso contrário, ele desempacota o valor e o retorna (neste caso, para atribuir um valor a `vec`). + +Este parece ser um método estranhamente complicado para lidar com erros, mas `Result` e `Option` garantem que todos os erros sejam tratados, de uma forma ou de outra. + +```rust + if vec.len() != N { return None; } +``` + +Se o número de bytes estiver incorreto, isso é uma falha e retornamos `None`. + +```rust + // try_into consome vec e tenta fazer [u8; N] + let array: [u8; N] = vec.try_into().ok()?; +``` + +Rust tem dois tipos de array. [Arrays](https://doc.rust-lang.org/std/primitive.array.html) têm um tamanho fixo. [Vetores](https://doc.rust-lang.org/std/vec/index.html) podem crescer e encolher. `hex::decode` retorna um vetor, mas a biblioteca `eth_stealth_addresses` quer receber arrays. [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) converte um valor em outro tipo, por exemplo, um vetor em um array. + +```rust + Some(array) +} +``` + +Rust não exige que você use a palavra-chave [`return`](https://doc.rust-lang.org/std/keyword.return.html) ao retornar um valor no final de uma função. + +```rust +#[wasm_bindgen] +pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option { +``` + +Esta função recebe um meta-endereço público, que inclui tanto _Vpub_ quanto _Kpub_. Ele retorna o endereço secreto, a chave pública para publicar (_Rpub_) e um valor de varredura de um byte que acelera a identificação de quais endereços publicados podem pertencer a Alice. + +O valor de varredura faz parte do segredo compartilhado (_S = GRprivVpriv_). Este valor está disponível para Alice, e verificá-lo é muito mais rápido do que verificar se _f(Kpub+G\*hash(S))_ é igual ao endereço publicado. + +```rust + let (address, r_pub, scan) = + generate_stealth_address(&str_to_array::<66>(stealth_address)?); +``` + +Usamos a função [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html) da biblioteca. + +```rust + format!("{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}", + encode(address), + encode(r_pub), + encode(&[scan]) + ).into() +} +``` + +Prepare a string de saída codificada em JSON. + +```rust +#[wasm_bindgen] +pub fn wasm_compute_stealth_key( + address: &str, + bill_pub_key: &str, + view_private_key: &str, + spend_private_key: &str +) -> Option { + . + . + . +} +``` + +Esta função usa a função [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) da biblioteca para calcular a chave privada para sacar do endereço (_Rpriv_). Este cálculo requer estes valores: + +- O endereço (_Endereço=f(Ppub)_) +- A chave pública gerada por Bill (_Rpub_) +- A chave privada de visualização (_Vpriv_) +- A chave privada de gastos (_Kpriv_) + +```rust +#[wasm_bindgen(start)] +``` + +[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) especifica que a função é executada quando o código WASM é inicializado. + +```rust +pub fn main() { + console_error_panic_hook::set_once(); +} +``` + +Este código especifica que a saída de pânico seja enviada para o console JavaScript. Para vê-lo em ação, use a aplicação e dê a Bill um meta-endereço inválido (apenas mude um dígito hexadecimal). Você verá este erro no console do JavaScript: + +``` +rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9: +assertion `left == right` failed + left: 0 + right: 1 +``` + +Seguido por um rastreamento de pilha. Em seguida, dê a Bill o meta-endereço válido e a Alice um endereço inválido ou uma chave pública inválida. Você verá este erro: + +``` +rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9: +keys do not generate stealth address +``` + +Novamente, seguido por um rastreamento de pilha. + +#### A interface do usuário {#ui} + +A interface do usuário é escrita usando [React](https://react.dev/) e servida por [Vite](https://vite.dev/). Você pode aprender sobre eles usando [este tutorial](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Não há necessidade de [WAGMI](https://wagmi.sh/) aqui, porque não interagimos diretamente com uma cadeia de blocos ou uma carteira. + +A única parte não óbvia da interface do usuário é a conectividade WASM. Funciona assim. + +**`vite.config.js`** + +Este arquivo contém [a configuração do Vite](https://vite.dev/config/). + +```js +import { defineConfig } from 'vite' +import react from '@vitejs/plugin-react' +import wasm from "vite-plugin-wasm"; + +// https://vite.dev/config/ +export default defineConfig({ + plugins: [react(), wasm()], +}) +``` + +Precisamos de dois plugins Vite: [react](https://www.npmjs.com/package/@vitejs/plugin-react) e [wasm](https://github.com/Menci/vite-plugin-wasm#readme). + +**`App.jsx`** + +Este arquivo é o componente principal da aplicação. É um contêiner que inclui dois componentes: `Alice` e `Bill`, as interfaces de usuário para esses usuários. A parte relevante para o WASM é o código de inicialização. + +```jsx +import init from './rust-wasm/pkg/rust_wasm.js' +``` + +Quando usamos [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/), ele cria dois arquivos que usamos aqui: um arquivo wasm com o código real (aqui, `src/rust-wasm/pkg/rust_wasm_bg.wasm`) e um arquivo JavaScript com as definições para usá-lo (aqui, `src/rust_wasm/pkg/rust_wasm.js`). A exportação padrão desse arquivo JavaScript é um código que precisa ser executado para iniciar o WASM. + +```jsx +function App() { + . + . + . + useEffect(() => { + const loadWasm = async () => { + try { + await init(); + setWasmReady(true) + } catch (err) { + console.error('Error loading wasm:', err) + alert("Wasm error: " + err) + } + } + + loadWasm() + }, [] + ) +``` + +O [hook `useEffect`](https://react.dev/reference/react/useEffect) permite que você especifique uma função que é executada quando as variáveis de estado mudam. Aqui, a lista de variáveis de estado está vazia (`[]`), então esta função é executada apenas uma vez quando a página carrega. + +A função de efeito deve retornar imediatamente. Para usar código assíncrono, como o `init` do WASM (que precisa carregar o arquivo `.wasm` e, portanto, leva tempo), definimos uma função interna [`async`](https://en.wikipedia.org/wiki/Async/await) e a executamos sem um `await`. + +**`Bill.jsx`** + +Esta é a interface de usuário para Bill. Ele tem uma única ação, criar um endereço com base no meta-endereço secreto fornecido por Alice. + +```jsx +import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js' +``` + +Além da exportação padrão, o código JavaScript gerado pelo `wasm-pack` exporta uma função para cada função no código WASM. + +```jsx +