A Arquitetura de um aplicativo da Web 3.0

Este artigo é uma tradução do original, escrito por Preethi Kasireddy. A tradução foi feita por Fatima Lima.

A arquitetura dos aplicativos da Web 3.0 (ou "DApps") é completamente diferente da arquitetura dos aplicativos da Web 2.0.

Tomemos o Medium, por exemplo, um site simples que permite que os usuários publiquem seus próprios conteúdos e interajam com o conteúdo de outras pessoas.
Como um aplicativo da web 2.0, pode parecer simples, mas tem muita coisa na arquitetura do Medium para tornar tudo isso possível:

Primeiro, é necessário ter um local para armazenar os dados essenciais, como usuários, postagens, tags, comentários, curtidas etc. Isso requer um banco de dados constantemente atualizado.

Segundo, o código back-end (escrito numa linguagem como Node.js, Java, ou Python) deve definir a lógica de negócios do Medium. Por exemplo, o que acontece quando um novo usuário se inscreve, publica um novo artigo ou comenta no artigo de uma outra pessoa?

Terceiro, o código front-end (normalmente escrito em JavaScript, HTML e CSS) deve definir a lógica de interface do usuário do Medium. Por exemplo, com o que o site se parece e o que acontece quando o usuário interage com cada elemento da página?

Juntando tudo isso, quando você escreve um artigo no Medium, você interage com o seu front-end, que conversa com o seu back-end, que conversa com o seu banco de dados. Todo esse código é hospedado em servidores centralizados e enviados para os usuários por meio de um navegador de internet. Esse é um bom resumo de alto nível, de como a maioria dos aplicativos da Web 2.0 funcionam hoje.

Mas, tudo isso está mudando.

A tecnologia Blockchain desbloqueou uma nova e empolgante direção para aplicativos da Web 3.0. Neste artigo, vamos focar no que a blockchain do Ethereum traz para a mesa.

O que torna a Web 3.0 diferente?

Diferentemente dos aplicativos da Web 2.0, como o Medium, a Web 3.0 elimina o intermediário. Não há banco de dados centralizado que armazena o estado do aplicativo, e não há servidor de web centralizado onde resida a lógica back-end.

Ao invés disso, você pode aproveitar a blockchain para criar apps numa máquina de estado descentralizada que é mantida por nós (nodes) anônimos na internet.

Por “máquina de estado”, quero dizer uma máquina que mantém um determinado estado de programa e futuros estados permitidos nessa máquina. As Blockchains são máquinas de estado que são instanciadas com algum estado inicial e possuem regras muito rígidas (isto é, consenso) que definem como o estado pode fazer transição.

Melhor ainda, nenhuma entidade controla essa máquina de estado descentralizada - ela é mantida coletivamente por todos na rede.

E quanto a um servidor back-end? Ao invés de como o back-end do Medium era controlado, na Web 3.0 você pode escrever smart contract que definem a lógica dos seus aplicativos e implantá-los na máquina de estado descentralizada. Isso significa que qualquer pessoa que queira criar um aplicativo na blockchain implanta seu código nessa máquina de estado compartilhada.

E o front-end? Ele praticamente permanece o mesmo, com algumas exceções, que abordaremos mais à frente.

Eis aqui a arquitetura:

Um Olhar Mais Atento

Agora vamos mergulhar um pouco mais profundo no que torna isso possível

1) Blockchain

A blockchain do Ethereum é muitas vezes apresentada como um “computador do mundo”. Isso porque é uma máquina de estado determinístico, globalmente acessível mantida por rede ponto a ponto de nós. As mudanças de estado nessa máquina de estado são dirigidas pelas regras de consenso que os pares na rede seguem.

Assim, em outras palavras, é literalmente projetada para ser uma máquina de estado que qualquer pessoa no mundo possa acessar e também, para a qual possa escrever. Como resultado, essa máquina não é propriedade de uma única entidade - mas, de todos na rede.

Mais uma coisa a saber: os dados só podem ser escritos para a blockchain do Ethereum — os dados existentes nunca podem ser atualizados.

2) Smart Contracts

Um smart contract é um programa que executa a blockchain do Ethereum e define a lógica atrás das mudanças de estado que acontecem na blockchain. Os smart contracts são escritos em linguagens de alto nível, como a Solidity ou a Vyper.

Já que o código do smart contract é armazenado na blockchain do Ethereum, qualquer pessoa pode examinar a lógica do aplicativo de todos os smart contracts na rede.

3) Máquina Virtual do Ethereum (EVM)

A seguir, você tem a Máquina Virtual do Ethereum, que executa a lógica definida nos smart contracts e processa as mudanças de estado que acontecem nessa máquina de estado acessível globalmente.

A EVM não entende linguagens de alto nível como a Solidity e a Vyper, que são usadas para escrever smart contracts . Ao invés disso, você tem que compilar a linguagem de alto nível em bytecode, que é a que a EVM pode executar.

4) Front-end

Finalmente, temos o front-end. Como mencionamos anteriormente, ele define a lógica da interface do usuário, mas o front-end também se comunica com a lógica do aplicativo definida nos smart contracts .

A comunicação entre o front-end e os smart contrats é um pouco mais complicada do que aparece no diagrama acima. Vamos ver isso com mais atenção, a seguir.

Como o código front-end se comunica com os Smart Contrats no Ethereum?

Nós queremos que o nosso front-end se comunique com os nossos smart contracts de forma que eles possam chamar funções, mas vamos lembrar que o Ethereum é uma rede descentralizada. Todo nó na rede Ethereum mantém uma cópia de todos os estados na máquina de estado do Ethereum, incluindo o código e os dados associados a todo smart contracts .
Quando desejamos interagir com os dados e o código de uma blockchain, precisamos interagir com um desses nós. Isso porque qualquer nó pode transmitir uma solicitação para uma transação ser executada na EVM. Um minerador então, executará a transação e propagará a mudança de estado resultante para o resto da rede.

Existem duas maneiras de transmitir uma transação:

1. Configurar seu próprio nó que executa o software da blockchain do Ethereum

2. Usar nós fornecidos por serviços terceirizados, como Infura, Alchemy e Quicknode.

Se você utiliza serviço terceirizado, você não precisa lidar com todas as dores de cabeça provenientes de executar, você mesmo, um nó completo. Afinal, configurar um novo nó Ethereum no seu próprio servidor pode levar dias (há muitos dados para sincronizar — pode até ocupar mais largura de banda e armazenamento do que um laptop normal possa suportar).

Além disso, o custo do armazenamento da blockchain completa do Ethereum aumenta à medida que seu DApp aumenta e você precisa acrescentar mais nós para expandir sua infraestrutura. É por isso que, à medida que sua infraestrutura se torna mais complexa, você vai precisar de engenheiros de DevOps em tempo integral. Eles o ajudarão a manter a infraestrutura para assegurar tempo de atividade confiável e tempos de resposta rápidos.

Tudo isso para dizer que evitar essas dores de cabeça é o motivo pelo qual muitos DApps optam por usar serviços como Infura ou Alchemy para gerenciar, sua infraestrutura. Naturalmente, existe um perde-ganha, isso cria um estrangulamento centralizado, mas vamos deixar essa toca de coelho para um outro dia. ;)

Continuando, vamos falar sobre os provedores. Os nós com os quais você se conecta quando você precisa interagir com a blockchain (se você mesmo os configura ou usa os existentes de terceiros) são sempre chamados “provedores.”

Todo cliente Ethereum (ou seja, provedor) implementa uma especificação JSON-RPC. Isso assegura que haja um conjunto uniforme de métodos quando os aplicativos front-end querem interagir com a blockchain. Se você precisa de uma cartilha em JSON-RPC, é um protocolo de chamada de procedimento remoto (RPC) simplificado e sem estados, que define várias estruturas de dados e as regras para seu processamento. É independente de transporte, de forma que conceitos podem ser usados dentro do mesmo processo, em soquetes, em HTTP ou em vários ambientes de troca de mensagem. Ele utiliza o JSON (RFC 4627) como um formato de dados.

Uma vez que você se conecta com a blockchain por meio de um provedor, você pode ler o estado armazenado na blockchain. Mas, se você quiser escrever para o estado, ainda há mais uma coisa que você precisa fazer antes de poder submeter a transação para a blockchain— “assinar” a transação usando sua chave privada.

Por exemplo, imagine que temos um DApp que permite que os usuários leiam e publiquem postagens de blog para a blockchain. Você pode ter um botão no front-end que permite a qualquer pessoa consultar as postagens escritas por um usuário específico. (Lembre-se de que a leitura da blockchain não exige que um usuário assine uma transação.)

Entretanto, quando um usuário quer publicar um novo artigo na cadeia, nosso DApp solicita que o usuário “assine” a transação usando a chave privada — só depois o DApp retransmite a transação para a blockchain. Caso contrário, os nós não aceitariam a transação.

Essa “assinatura” de transações é onde a Metamask normalmente entra.

Metamask é uma ferramenta que torna mais fácil para os aplicativos lidarem com o gerenciamento de chaves e assinatura de transações. É muito simples. A Metamask armazena as chaves privadas do usuário no navegador e sempre que o front-end precisa da assinatura do usuário para a transação, ele chama a Metamask.

A Metamask também fornece uma conexão para a blockchain (como um “provedor”) uma vez que já tem uma conexão com os nós fornecidos pela Infura, pois precisa dele para assinar transações. Desse modo, a Metamask é tanto um provedor quanto uma signatária. 🤯

Armazenamento na Blockchain

Naturalmente, essa arquitetura faz sentido se você está criando um app em que todos os smart contracts e dados vivem inteiramente na blockchain Ethereum. Mas, todos que criaram apps na Ethereum sabem que armazenar tudo na blockchain é muito caro, muito rápido.

Tenha em mente que, com Ethereum, o usuário paga todas as vezes que acrescentam novos dados à blockchain. Isso porque acrescentar um estado à máquina de estado descentralizada aumenta os custos para os nós que estão mantendo aquela máquina de estado.

Pedir aos usuários que paguem mais para usar seu DApp toda vez que a sua transação exigir a adição de um novo estado não é a melhor experiência. Uma maneira de combater isso é usar uma solução de armazenamento off-chain descentralizada, como IPFS ou Swarm.

IPFS é um sistema de arquivo distribuído para armazenar e acessar dados. Então, ao invés de armazenar dados num banco de dados centralizado, o sistema IPFS distribui e armazena os dados numa rede ponto a ponto. Isso facilita a recuperação, quando necessário.

IPFS também possui uma camada de incentivo chamada de “Filecoin.” Essa camada incentiva os nós em todo o mundo a armazenar e recuperar esses dados. Você pode usar um provedor como o Infura (que te fornece um nó IPFS) ou Pinata (que te fornece um serviço fácil de usar em que você pode “fixar” seus arquivos ao IPFS e pegar o hash do IPFS e armazená-lo na blockchain).

O Swarm é semelhante por ser uma rede de armazenamento descentralizada, mas existe uma diferença marcante. Enquanto o Filecoin é um sistema separado, o sistema de incentivo do Swarm é integrado e aplicado por meio de smart contracts na blockchain do Ethereum a fim de armazenar e recuperar dados.

Então agora, com o IPFS ou o Swarm, nossa arquitetura de aplicativo se parece com isso:

Os leitores perspicazes podem também ter observado no diagrama que o código front-end não está armazenado na blockchain. Poderíamos hospedar esse código no AWS, como normalmente faríamos na Web 2.0, mas isso cria um estrangulamento centralizado para o seu DApp. E se o AWS cair? E se ele censurar seu aplicativo?

Essa é a razão pela qual, se você quer criar um aplicativo verdadeiramente descentralizado, você deve escolher hospedar seu front-end numa solução de armazenamento descentralizado, como o IPFS ou o Swarm.

Então agora a nossa arquitetura do aplicativo vai parecer mais assim:

Consultando a Blockchain

Até agora, falamos sobre como escrever para a blockchain assinando transações e depois enviando essas transações para a blockchain. Mas, e a leitura de dados dos smart contracts na blockchain? Existem duas maneiras principais de fazer isso:

1) Eventos de Smart Contracts

Você pode usar a biblioteca da Web3.js para consultar e ouvir os eventos do smart contract. Você pode ouvir eventos específicos e especificar um retorno de chamada sempre que o evento for disparado. Por exemplo, se você tem um smart contract que envia um fluxo contínuo de pagamento de uma pessoa A para uma pessoa B a cada bloco, então você pode emitir um evento sempre que um novo pagamento é feito para a pessoa B. Seu código front-end pode ouvir os eventos sendo disparados pelo smart contract e realizar ações específicas com base nele.

2) O Graph

A abordagem acima funciona, mas apresenta algumas limitações. Por exemplo, e se você implantar um smart contract e depois perceber que precisa de um evento emitido que não foi incluído inicialmente? Infelizmente, você deveria reimplantar um novo smart contract com esse evento e dados. Além disso, usar retornos de chamadas para lidar com várias lógicas de interface de usuário fica muito complexo muito rapidamente.

É aqui que entra “The Graph”.

The Graph é uma solução de indexação off-chain que facilita a consulta de dados na blockchain Ethereum. The Graph permite que você defina qual smart contract será indexado, quais eventos e chamadas de função serão ouvidas e como transformar eventos de entrada em entidades que sua lógica front-end (ou o que estiver usando a API) possa consumir. Ele usa GraphQL como uma linguagem de consulta, o que muitos engenheiros de front-end adoram devido à sua expressividade em comparação com as REST APIs tradicionais.

Indexando os dados da blockchain, The Graph nos permite consultar os dados on-chain em nossa lógica do aplicativo com baixa latência.

Agora, sua arquitetura do DApp parece com isso:

Estamos quase terminando, mas falta um tópico maior: dimensionamento.

Escalando Seu DApp

Como você já deve ter escutado,o Ethereum não escala — pelo menos, até agora...

Claramente, temos um problema aqui. Criar um DApp no Ethereum com altas taxas de gás e blocos cheios leva a uma UX muito ruim. Felizmente, existem algumas soluções em desenvolvimento.

Uma solução de escalabilidade popular é a Polygon, uma solução de escalabilidade L2. Ao invés de executar transações na blockchain principal, a Polygon possui “sidechains” que processam e executam transações. Uma sidechain é uma blockchain secundária que faz interface com a cadeia principal. De vez em quando, a sidechain envia uma agregação de seus blocos recentes de volta para a cadeia principal.

Outros exemplos de soluções L2 são Optimistic Rollups e zkRollups. A ideia aqui é parecida: Agrupamos transações off-chain usando um smart contract “rollup” e depois, periodicamente, alocamos essas transações na cadeia principal.

A ideia para levar para casa é: soluções L2 fazem a execução da transação (ou seja, a parte lenta) off-chain, apenas com dados da transação armazenados on-chain. Isso nos permite escalar a blockchain já que não temos que executar cada transação on-chain. Isso também torna as transações mais rápidas e mais baratas — e elas ainda podem se comunicar com a blockchain principal do Ethereum, quando necessário.

Colocando Tudo Junto

Se tudo isso estiver fazendo sua cabeça rodar, você não está sozinho. Juntar todas essas ferramentas é complexo e pode levar a uma experiência dolorosa para o desenvolvedor. Mas, não se preocupe — estamos começando a ver novos frameworks que realmente melhoram a experiência para os desenvolvedores.

Por exemplo, o Hardhat é um framework que torna mais fácil para os desenvolvedores do Ethereum criar, implantar e testar seus smart contracts. O Hardhat oferece a “Hardhat Network,” que pode ser usada por desenvolvedores para implantar seus smart contracts em uma rede local — sem ter que lidar com ambientes ao vivo. Melhor ainda, ele oferece um ótimo ecossistema de plugin que torna a vida dos desenvolvedores muito mais fácil. O Hardhat também fornece a funcionalidade console.log(), similar ao javascript, para fins de depuração.

Naturalmente, isso é apenas o começo. Espero que continuemos a ver melhores ferramentas para desenvolvedores no futuro.

Conclusão

A maioria das pessoas passa meses descobrindo como a cadeia de ferramentas funciona. Então, se você é um novo desenvolvedor de DApp, espero que esse artigo tenha te poupado algum tempo. É hora de começar a criar!
Se criar aplicativos Web 3.0 é algo de seu interesse, então se inscreva para nossa próxima corte do DappCamp, onde você vai aprender como criar e implantar seu primeiro Dapp no Ethereum.
Como sempre, se você tem algumas perguntas ou encontrou algum erro neste artigo, por favor me informe nos comentários! :)