Escrito por: Stanislav Kozlovski

O que é um sistema distribuído e por que é tão complicado?

Com a expansão tecnológica cada vez maior do mundo, os sistemas distribuídos estão se tornando cada vez mais difundidos. Eles são um vasto e complexo campo de estudo em ciência da computação.

Este artigo tem como objetivo apresentar a você os sistemas distribuídos de maneira básica, dando uma ideia das diferentes categorias desses sistemas, sem mergulhar profundamente nos detalhes.

O que é um sistema distribuído?

Em sua definição mais simples, um sistema distribuído é um grupo de computadores trabalhando juntos de modo a parecer como um único computador para o usuário final.

Essas máquinas possuem um estado compartilhado, operam de maneira concorrente e podem falhar independentemente sem afetar o tempo de atividade de todo o sistema.

Proponho que trabalhemos gradualmente através de um exemplo de distribuição de um sistema para que você possa ter uma melhor compreensão de tudo isso.

Vamos usar um banco de dados como exemplo! Bancos de dados tradicionais são armazenados no sistema de arquivos de uma única máquina. Sempre que você deseja buscar/inserir informações nele, você se comunica diretamente com aquela máquina.

Para distribuir esse sistema de banco de dados, precisaríamos fazer com que esse banco de dados fosse executado em várias máquinas ao mesmo tempo. O usuário deve ser capaz de se comunicar com qualquer máquina que ele escolha e não deve ser capaz de perceber que não está falando com uma única máquina – se ele insere um registro no nó nº 1, o nó nº 3 deve ser capaz de retornar esse registro.

Por que distribuir um sistema?

Os sistemas são sempre distribuídos por necessidade. A verdade é que gerenciar sistemas distribuídos é um tópico complexo, repleto de armadilhas e desafios. É uma dor de cabeça implantar, manter e depurar sistemas distribuídos. Então, por que seguir por esse caminho afinal?

O que um sistema distribuído possibilita é a escalabilidade horizontal. Voltando ao nosso exemplo anterior do servidor de banco de dados único, a única maneira de lidar com mais tráfego seria atualizar o hardware em que o banco de dados está sendo executado. Isso é chamado de escalonamento vertical.

O escalonamento vertical é válido até certo ponto, mas, após um determinado ponto, você verá que mesmo o melhor hardware não é suficiente para lidar com volume suficiente de tráfego, sem mencionar o fato de que é impraticável para hospedar.

O escalonamento horizontal, por sua vez, significa simplesmente adicionar mais computadores em vez de atualizar o hardware de um único computador.

É significativamente mais barato do que o escalonamento vertical após um certo limite, mas esse não é o principal motivo de preferência.

O escalonamento vertical só pode melhorar o desempenho até as capacidades do hardware mais recente. Essas capacidades acabam sendo insuficientes para empresas tecnológicas com cargas de trabalho moderadas a grandes.

A melhor coisa sobre o escalonamento horizontal é que não há limite para o quanto você pode escalar – sempre que o desempenho se degrada, basta adicionar outra máquina, potencialmente até o infinito.

A facilidade de escalonamento não é o único benefício que você obtém com sistemas distribuídos. Tolerância a falhas e baixa latência também são igualmente importantes.

Tolerância a falhas – um cluster de dez máquinas em dois data centers é intrinsecamente mais tolerante a falhas do que uma única máquina. Mesmo que um data center pegue fogo, sua aplicação ainda funcionaria.

Baixa latência – o tempo para um pacote de rede viajar pelo mundo é fisicamente limitado pela velocidade da luz. Por exemplo, o tempo mais curto possível para o tempo de ida e volta de uma solicitação (ou seja, ir e voltar) em um cabo de fibra óptica entre Nova York e Sydney é de 160 ms (texto em inglês). Sistemas distribuídos permitem que você tenha um nó em ambas as cidades, permitindo que o tráfego atinja o nó mais próximo.

No entanto, para que um sistema distribuído funcione, é necessário que o software em execução nessas máquinas seja projetado especificamente para ser executado em vários computadores ao mesmo tempo e que lide com os problemas que surgem com isso. Isso acaba sendo uma tarefa complicada.

Escalonando nosso banco de dados

Imagine que nossa aplicação para a web se tornou extremamente popular. Imagine também que nosso banco de dados começou a receber o dobro de consultas por segundo do que ele pode lidar. Essa aplicação começaria imediatamente a perder desempenho e isso seria percebido por nossos usuários.

Vamos trabalhar juntos e fazer com que nosso banco de dados aumente sua capacidade para atender essas altas demandas.

Em uma aplicação para a web típica, geralmente se lê informações com muito mais frequência do que se insere novas informações ou se modifica as antigas.

Existe uma maneira de aumentar o desempenho de leitura e é chamada de estratégia primary-replica replication (replicação entre mestre-escravo). Você cria dois servidores de banco de dados que sincronizam com o servidor principal. A pegadinha é que você só pode fazer leituras dessas novas instâncias.

Sempre que você inserir ou modificar informações, você se comunica com o banco de dados principal. Ele, por sua vez, informa as réplicas assincronamente sobre a mudança e elas também a salvam.

Parabéns, agora você pode executar três vezes mais consultas de leitura! Não é ótimo?

Armadilha

Peguei vocês! Perdemos imediatamente o "C" nas garantias ACID (texto em inglês) de nosso banco de dados relacional, a Consistência.

Perceba que, agora, existe a possibilidade de inserirmos um novo registro no banco de dados e, imediatamente após, realizarmos uma consulta de leitura para esse registro e não obtermos nenhuma resposta de volta, como se ele não existisse!

A propagação de novas informações do primário para a réplica não acontece instantaneamente. Na verdade, existe uma janela de tempo em que você pode obter informações desatualizadas. Se não fosse assim, o desempenho da gravação seria prejudicado, pois teria que aguardar sincronamente a propagação dos dados.

Sistemas distribuídos envolvem algumas escolhas e renúncias (trade-offs em inglês). Essa questão em particular é algo com que você terá que conviver se quiser escalar adequadamente.

Continuando a Escalonar

Utilizando a abordagem do banco de dados replicado, podemos escalonar horizontalmente nosso tráfego de leitura até certo ponto. Isso é ótimo, mas encontramos um obstáculo em relação ao nosso tráfego de escrita — ele ainda está todo em um único servidor!

Não temos muitas opções aqui. Simplesmente precisamos dividir nosso tráfego de escrita entre vários servidores, já que um não é capaz de lidar com isso.

Uma maneira é adotar uma estratégia de replicação multi-primária (texto em inglês). Nesse caso, em vez de réplicas as quais você só pode ler, você tem vários nós primários que suportam leitura e escrita. Infelizmente, isso se torna complicado rapidamente, pois você agora tem a capacidade de criar conflitos (por exemplo, inserir dois registros com o mesmo ID – texto em inglês).

Vamos adotar outra técnica chamada fragmentação (também chamada de particionamento – texto em inglês).

Com a fragmentação, você divide o seu servidor em vários servidores menores, chamados de fragmentos (shards, em inglês) Esses fragmentos contêm registros diferentes — você cria uma regra para determinar que tipo de registros é armazenado em cada fragmento. É muito importante criar a regra de tal maneira que os dados sejam distribuídos de modo uniforme.

Uma abordagem possível para isso é definir intervalos de acordo com alguma informação sobre um registro (por exemplo, usuários com nomes de A a D).

Essa abordagem de fragmentação deve ser escolhida com muito cuidado, pois a carga nem sempre é igual com base em colunas arbitrárias. (por exemplo, mais pessoas têm nomes que começam com C em vez de Z). Um único fragmento que recebe mais solicitações do que outros é chamado de hot spot (ponto de acesso) e deve ser evitado. Depois de divididos, a nova fragmentação dos dados torna-se incrivelmente cara e pode causar um significativo tempo de indisponibilidade, como foi o infame caso das 11 horas de indisponibilidade do Foursquare (texto em inglês).

Para manter nosso exemplo simples, suponha que nosso client (a aplicação em Rails) saiba qual banco de dados usar para cada registro. Também vale ressaltar que existem muitas estratégias para o particionamento e esse é um exemplo simples para ilustrar o conceito.

No momento, já obtivemos bastante sucesso – podemos aumentar nosso tráfego de gravação N vezes, onde N é o número de fragmentos. Isso praticamente nos deixa quase sem limites – imagine o nível de granularidade que podemos ter com essa divisão.

Armadilha

Tudo na Engenharia de Software é mais ou menos escolhas e renúncias (trade-offs em inglês), e isso não é uma exceção. O particionamento não é uma tarefa simples e é melhor evitá-lo até que seja realmente necessário (texto em inglês).

Agora, tornamos as consultas por chaves diferentes das chaves particionadas incrivelmente ineficientes (elas precisam passar por todos os fragmentos). As consultas de SQL JOIN são ainda piores e complexas, tornam-se praticamente inutilizáveis.

Decentralizado x distribuído

Antes de prosseguirmos, gostaria de fazer uma distinção entre esses dois termos.

Embora as palavras soem semelhantes e possam ser concluídas como significando o mesmo logicamente, suas diferenças têm um impacto tecnológico e político significativo.

Descentralizado ainda é distribuído no sentido técnico, mas todo o sistema descentralizado não é de propriedade de um único ator. Nenhuma empresa pode possuir um sistema descentralizado. Caso contrário, ele deixaria de ser descentralizado.

Isso significa que a maioria dos sistemas que discutiremos hoje pode ser considerada como sistemas centralizados distribuídos – e é isso que eles foram projetados para ser.

Se você pensar a respeito, é mais difícil criar um sistema descentralizado porque é preciso lidar com a situação em que alguns dos participantes são mal-intencionados. Isso não ocorre com sistemas distribuídos normais, pois você sabe que é o proprietário de todos os nós.

Observação: essa definição tem sido bastante debatida (texto em inglês) e pode ser confundida com outras (peer-to-peer, federado). Em literatura mais antiga, também foi definida de maneira diferente (texto em inglês). Independentemente disso, o que forneci como definição é o que considero ser o mais amplamente utilizado agora, especialmente após a popularização dos termos blockchain e criptomoedas.

Categorias de sistemas distribuídos

Agora vamos explorar algumas categorias de sistemas distribuídos e listar seus maiores usos conhecidos publicamente. Tenha em mente que a maioria dos números apresentados está desatualizada e, provavelmente, é significativamente maior no momento em que você está lendo isso.

Armazenamento distribuídos de dados

Os armazenamentos distribuídos de dados são mais amplamente utilizados e reconhecidos como bancos de dados distribuídos. A maioria dos bancos de dados distribuídos são NoSQL (texto em inglês), ou seja, bancos de dados não relacionais, limitados à semântica chave-valor. Eles oferecem desempenho e escalabilidade incríveis, mas isso ocorre às custas da consistência ou disponibilidade.

Escala conhecida – a Apple é conhecida por utilizar 75.000 nós do Apache Cassandra, armazenando mais de 10 petabytes de dados (texto em inglês).

Não podemos entrar em discussões sobre armazenamento distribuído de dados sem primeiro introduzir o Teorema CAP.

Teorema CAP

Comprovado pela primeira vez em 2002 (texto em inglês), o Teorema CAP (sigla em inglês para Consistency, Availability e Partition Tolerance) estabelece que um sistema de armazenamento de dados distribuído não pode simultaneamente manter consistência, estar sempre disponível e ser tolerante a partições.

Algumas definições rápidas:

• Consistência — o que você lê e escreve sequencialmente é o que é esperado (lembre-se da situação complicada com a replicação do banco de dados mencionada alguns parágrafos atrás?).
• Disponibilidade — o sistema como um todo não falha — todo nó não defeituoso sempre retorna uma resposta.
• Tolerância a partições — o sistema continua a funcionar e manter suas garantias de consistência/disponibilidade apesar das partições na rede (texto em inglês).

Na realidade, a tolerância a partições deve ser uma premissa para qualquer armazenamento de dados distribuído. Conforme mencionado em vários lugares, como citado neste ótimo artigo (texto em inglês), não é possível ter consistência e disponibilidade sem tolerância a partições.

Reflexão: se você tiver dois nós que aceitam informações e a conexão entre eles for interrompida, como ambos poderão estar disponíveis e fornecer consistência ao mesmo tempo? Eles não têm conhecimento do que o outro nó está fazendo, podendo assim ficar off-line (indisponíveis) ou operar com informações desatualizadas (inconsistentes).

No final, você precisa escolher se deseja que seu sistema seja fortemente consistente ou altamente disponível em caso de uma partição de rede.

A prática mostra que a maioria das aplicações valoriza mais a disponibilidade. Você nem sempre precisa necessariamente de uma consistência forte. Mesmo assim, essa compensação não é necessariamente feita porque você precisa da garantia de 100% de disponibilidade, mas sim porque a latência da rede pode ser um problema quando é necessário sincronizar máquinas para obter uma consistência forte. Esses e outros fatores fazem com que as aplicações normalmente optem por soluções que ofereçam alta disponibilidade.

Esses bancos de dados se contentam com o modelo de consistência mais fraco – consistência eventual (explicação de consistência forte versus consistência eventual – texto em inglês). Esse modelo garante que se nenhuma nova atualização for feita em um determinado item, eventualmente todos os acessos a esse item retornarão o último valor atualizado.

Esses sistemas fornecem propriedades BASE (em oposição ao ACID dos bancos de dados tradicionais):

• Basically Available — basicamente disponível — o sistema sempre retorna uma resposta
• Soft state — estado suave — o sistema pode mudar com o tempo, mesmo durante períodos sem entrada (devido a eventual consistência)
• Eventual consistency — consistência eventual — na ausência de entrada, os dados se espalharão para todos os nós, mais cedo ou mais tarde — tornando-se assim consistentes

Exemplos de tais bancos de dados distribuídos disponíveis — Cassandra, Riak, Voldemort (texto em inglês)

Claro, existem outros armazenamentos de dados que preferem consistência mais forte — HBase, Couchbase, Redis, Zookeeper (texto em inglês)

O teorema CAP é digno de vários artigos por si só – alguns sobre como você pode ajustar as propriedades CAP de um sistema dependendo de como o client se comporta (texto em inglês) e outros sobre como ele não é compreendido corretamente (texto em inglês).

Cassandra

Cassandra, como mencionado acima, é um banco de dados No-SQL distribuído que prefere as propriedades do AP fora do CAP, estabelecendo-se com consistência eventual. Devo admitir que isso pode ser um pouco enganador, já que o Cassandra é altamente configurável — você também pode fazer com que ele forneça uma consistência forte em detrimento da disponibilidade, mas esse não é seu caso de uso comum.

Cassandra utiliza hashing consistente (texto em inglês) para determinar quais nós do seu cluster devem gerenciar os dados que você está passando. Você define um fator de replicação, que basicamente indica para quantos nós você deseja replicar seus dados.

Ao ler, você lerá apenas desses nós.

Cassandra é altamente escalável, proporcionando uma taxa de transferência de escrita absurdamente alta.

Mesmo que esse diagrama possa ser tendencioso e pareça que compara Cassandra a bancos de dados configurados para fornecer consistência forte (caso contrário, não consigo ver por que o MongoDB diminuiria o desempenho quando atualizado de 4 para 8 nós), isso ainda deve mostrar o que é configurado corretamente até o cluster Cassandra é capaz.

Independentemente disso, no trade-off de sistemas distribuídos que permite escalabilidade horizontal e rendimento incrivelmente alto, o Cassandra não fornece alguns recursos fundamentais dos bancos de dados ACID – ou seja, transações.

Consenso

As transações de banco de dados são difíceis de implementar em sistemas distribuídos, pois exigem que cada nó concorde sobre a ação correta a ser tomada (abortar ou confirmar). Isso é conhecido como consenso e é um problema fundamental em sistemas distribuídos.

Alcançar o tipo de acordo necessário para o problema de "confirmação de transação" é simples se os processos participantes e a rede forem completamente confiáveis. No entanto, os sistemas reais estão sujeitos a uma série de falhas possíveis, como falhas de processos, particionamento de rede e mensagens perdidas, distorcidas ou duplicadas.

Isto levanta um problema: provou-se ser impossível (texto em inglês) garantir que um consenso correto seja alcançado dentro de um prazo limitado em uma rede não confiável.

Na prática, porém, existem algoritmos que chegam rapidamente a um consenso em uma rede não confiável. Na verdade, Cassandra fornece transações leves por meio do uso do algoritmo Paxos para consenso distribuído.

Computação distribuída

A computação distribuída é a chave para o fluxo de processamento de Big Data que temos visto nos últimos anos. É a técnica de dividir uma tarefa enorme (por exemplo, agregar 100 bilhões de registos), que nenhum computador é capaz de executar praticamente por si só, em muitas tarefas mais pequenas, cada uma das quais pode caber numa única máquina comum. Você divide sua enorme tarefa em muitas tarefas menores, executa-as em muitas máquinas em paralelo, agrega os dados adequadamente e resolve seu problema inicial. Essa abordagem novamente permite escalar horizontalmente – quando você tem uma tarefa maior, basta incluir mais nós no cálculo.

Folding@Home  160 mil máquinas ativas em 2012 (texto em inglês)

Um dos primeiros inovadores neste espaço foi o Google, que devido à necessidade de suas grandes quantidades de dados teve que inventar um novo paradigma para computação distribuída – MapReduce. Eles publicaram um artigo sobre isso em 2004 (texto em inglês) e a comunidade de código aberto mais tarde criou o Apache Hadoop (texto em inglês) baseado nele.

MapReduce

MapReduce pode ser definido simplesmente como duas etapas – mapear os dados (Map) e reduzi-los a algo significativo (Reduce).

Vamos ver um exemplo novamente:

Digamos que somos a Medium (Plataforma de publicação de artigos) e armazenamos nossas enormes informações em um banco de dados secundário distribuído para fins de armazenamento. Queremos buscar dados que representem o número de palmas enviadas todos os dias durante o mês de abril de 2017 (um ano antes da edição original deste artigo).

Este exemplo é o mais curto, claro e simples possível, mas imagine que estamos trabalhando com muitos dados (por exemplo, analisando bilhões de aplausos). Obviamente, não armazenaremos todas essas informações em uma máquina e não analisaremos tudo isso em apenas uma máquina. Também não consultaremos o banco de dados de produção, mas algum banco de dados de "armazém" construído especificamente para trabalhos off-line de baixa prioridade.

Cada trabalho Map é um nó separado que transforma o máximo de dados possível. Cada trabalho percorre todos os dados em um determinado nó de armazenamento e os mapeia para uma tupla simples da data e do número um. Em seguida, são realizadas três etapas intermediárias (das quais ninguém fala) – Shuffle, Sort e Partition. Elas basicamente organizam ainda mais os dados e os excluem para o trabalho de redução apropriado. Como estamos lidando com Big Data, separamos cada trabalho de Reduce para funcionar apenas em uma única data.

Esse é um bom paradigma e surpreendentemente permite que você faça muitas coisas com ele — você pode encadear vários trabalhos MapReduce, por exemplo.

Melhores técnicas

O MapReduce é um tanto legado nos dias de hoje e traz alguns problemas consigo. Por trabalhar em lotes (jobs), surge um problema onde, se o seu job falhar, você precisa reiniciar tudo do zero. Um job de 2 horas falhando pode realmente retardar todo o seu pipeline de processamento de dados e você definitivamente não quer isso, especialmente nas horas de pico.

Outra questão é o tempo que você espera até receber os resultados. Em sistemas analíticos em tempo real (onde todos têm big data e, portanto, usam computação distribuída), é importante que os seus dados mais recentes estejam o mais novos possível e certamente não sejam de algumas horas atrás.

Como resultado, surgiram outras arquiteturas (texto em inglês) que abordam esses problemas. Nomeadamente, a arquitetura Lambda (uma mistura de processamento em lote e processamento em fluxo – texto em inglês) e a arquitetura Kappa (apenas processamento em fluxo – texto em inglês). Esses avanços no campo trouxeram novas ferramentas que os possibilitam — Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Sistemas de arquivos distribuídos

Os sistemas de arquivos distribuídos podem ser considerados como armazenamentos de dados distribuídos. São a mesma coisa como conceito — armazenar e acessar uma grande quantidade de dados em um cluster de máquinas, todas aparecendo como uma só. Eles geralmente andam de mãos dadas com a Computação Distribuída.

Escala conhecida – O Yahoo é conhecido por executar o HDFS em mais de 42.000 nós para armazenamento de 600 Petabytes de dados, lá em 2011

A diferença é que os sistemas de arquivos distribuídos permitem que os arquivos sejam acessados usando as mesmas interfaces e semânticas que os arquivos locais, e não por meio de uma API personalizada como a Cassandra Query Language (CQL).

HDFS

O Hadoop Distributed File System (HDFS) é o sistema de arquivos distribuídos usado para computação distribuída através do framework Hadoop. Com ampla adoção, é utilizado para armazenar e replicar grandes arquivos (de GB ou TB em tamanho) em muitas máquinas.

Sua arquitetura consiste principalmente em NameNodes e DataNodes. Os NameNodes são responsáveis por manter o metadata sobre o cluster, como qual nó contém quais blocos de arquivos. Eles atuam como coordenadores da rede, determinando onde é melhor armazenar e replicar arquivos, além de monitorar a saúde do sistema. Os DataNodes simplesmente armazenam arquivos e executam comandos como replicar um arquivo, escrever um novo entre outros.

Não surpreendentemente, o HDFS é melhor utilizado com o Hadoop para computação, pois fornece consciência de dados para os jobs de computação. Esses jobs são então executados nos nós que armazenam os dados. Isso aproveita a localidade dos dados — otimizando as computações e reduzindo a quantidade de tráfego na rede.

IPFS

O Interplanetary File System (IPFS – texto em inglês), sistema de arquivos interplanetário, é um novo e empolgante protocolo de rede peer-to-peer para um sistema de arquivos distribuídos. Aproveitando a tecnologia Blockchain (texto em inglês), ele possui uma arquitetura completamente descentralizada, sem um único proprietário ou ponto de falha.

O IPFS oferece um sistema de nomes (semelhante ao DNS) chamado IPNS e permite que os usuários acessem facilmente informações. Ele armazena arquivos por meio de versionamento histórico, semelhante ao que o Git (texto em inglês) faz. Isso permite o acesso a todos os estados anteriores de um arquivo.

Ainda está passando por um desenvolvimento intenso (versão 0.4 no momento desta edição), mas já viu projetos interessados em construir sobre ele (FileCoin, texto em inglês).

Messageria distribuída

Sistemas de mensageria fornecem um local central para armazenamento e propagação de mensagens/eventos dentro do seu sistema geral. Eles permitem que você desacople a lógica de sua aplicação de falar diretamente com seus outros sistemas.

Escala conhecida – o cluster Kafka do LinkedIn processou 1 trilhão de mensagens por dia, com picos de 4,5 milhões de mensagens por segundo (texto em inglês).

Simplificando, uma plataforma de mensagens funciona da seguinte maneira:

Uma mensagem é transmitida a partir da aplicação que a potencialmente cria (chamada de produtor), entra na plataforma e é lida por potencialmente múltiplas aplicações que têm interesse nela (chamadas de consumidores).

Se você precisa salvar um determinado evento em vários lugares (por exemplo, criação de usuário no banco de dados, data warehouse, serviço de envio de e-mails e qualquer outra coisa que você possa imaginar), uma plataforma de mensageria é a maneira mais limpa de disseminar essa mensagem.

Os consumidores podem tanto extrair informações dos brokers (modelo pull) quanto ter os brokers enviando informações diretamente para os consumidores (modelo push).

Existem algumas plataformas de mensagens populares e de alta qualidade:

RabbitMQ (texto em inglês) — broker de mensagens que permite um controle mais detalhado das trajetórias das mensagens através de regras de roteamento e outras configurações facilmente ajustáveis. Pode ser chamado de broker inteligente, pois possui muita lógica embutida e acompanha rigorosamente as mensagens que passam por ele. Oferece configurações tanto para AP quanto para CP do teorema CAP. Utiliza um modelo push para notificar os consumidores.

Kafka (texto em inglês) — broker de mensagens (e uma plataforma completa) que é um pouco mais de baixo nível, pois não acompanha quais mensagens foram lidas e não permite uma lógica de roteamento complexa. Isso ajuda a alcançar um desempenho incrível. Na minha opinião, esse é o maior prospecto nesse espaço, com desenvolvimento ativo da comunidade de código aberto e suporte da equipe Confluent (texto em inglês). O Kafka, indiscutivelmente, é o mais amplamente utilizado pelas principais empresas de tecnologia. Escrevi uma introdução detalhada sobre isso, onde explico em detalhes todas as suas vantagens (texto em inglês).

Apache ActiveMQ (texto em inglês) — o mais antigo do grupo, datando de 2004. Usa a API JMS, o que significa que é voltado para aplicativos Java EE. Foi reescrito como ActiveMQ Artemis (texto em inglês), que oferece um desempenho excepcional comparável ao Kafka.

Amazon SQS (texto em inglês) — um serviço de mensageria fornecido pela AWS. Permite que você integre rapidamente com aplicações existentes e elimina a necessidade de lidar com sua própria infraestrutura, o que pode ser um grande benefício, já que sistemas como o Kafka são notoriamente difíceis de configurar. A Amazon também oferece dois serviços semelhantes — SNS (texto em inglês) e MQ (texto em inglês), este último é basicamente o ActiveMQ, mas gerenciado pela Amazon.

Aplicações distribuídas

Se você agrupar 5 servidores de Rails atrás de um único balanceador de carga, todos conectados a um banco de dados, poderia chamar isso de aplicação distribuída? Lembre-se da minha definição lá em cima:

Um sistema distribuído é um grupo de computadores trabalhando juntos para parecer como se fosse um único computador para o usuário final. Essas máquinas têm um estado compartilhado, operam de maneira concorrente e podem falhar independentemente sem afetar o tempo de atividade do sistema como um todo.

Se você considerar o banco de dados como um estado compartilhado, poderia argumentar que isso pode ser classificado como um sistema distribuído — mas você estaria errado, pois você ignorou a parte "trabalhando juntos" da definição.

Um sistema é distribuído apenas se os nós se comunicarem entre si para coordenar suas ações.

Portanto, algo como uma aplicação que executa seu código de back-end em uma rede peer-to-peer (texto em inglês) pode ser melhor classificado como uma aplicação distribuída. Independentemente disso, toda essa classificação desnecessária não serve para nada além de ilustrar como somos detalhistas sobre agrupar coisas juntas.

Escala conhecida – Por exemplo, o enxame BitTorrent de 193.000 nós para um episódio de Game of Thrones, em abril de 2014.

Máquina virtual com Erlang

Erlang é uma linguagem funcional que possui ótimas semânticas para concorrência, distribuição e tolerância a falhas. A própria máquina virtual com Erlang lida com a distribuição de uma aplicação do Erlang.

Seu modelo funciona tendo muitos processos leves (texto em inglês) e isolados, todos com a capacidade de se comunicar entre si por meio de um sistema integrado de passagem de mensagens. Isso é chamado de Modelo de Ator (texto em inglês) e as bibliotecas Erlang OTP podem ser consideradas como um framework de atores distribuídos (similar ao Akka para a JVM).

O modelo é o que ajuda a alcançar uma ótima concorrência de maneira bastante simples — os processos são distribuídos pelos núcleos disponíveis do sistema que os executa. Uma vez que isso é indistinguível de um ambiente de rede (exceto pela capacidade de descartar mensagens), a máquina virtual do Erlang pode se conectar a outras máquinas virtuais do Erlang em execução no mesmo data center ou até mesmo em outro continente. Esse conjunto de máquinas virtuais executa uma única aplicação e lida com falhas de máquina por meio de takeover (outro nó é escalonado para executar).

De fato, a camada distribuída da linguagem foi adicionada para fornecer tolerância a falhas. Software em execução em uma única máquina está sempre em risco de ter essa única máquina falhando e tirando sua aplicação do ar. O software em execução em muitos nós permite um manuseio mais fácil de falhas de hardware, desde que a aplicação tenha sido construída com isso em mente.

BitTorrent

O BitTorrent é um dos protocolos mais amplamente utilizados para transferir arquivos grandes pela web por meio de torrents. A ideia principal é facilitar a transferência de arquivos entre diferentes pares na rede sem precisar passar por um servidor central.

Usando um client do BitTorrent, você se conecta a vários computadores ao redor do mundo para baixar um arquivo. Quando você abre um arquivo .torrent, você se conecta a um chamado tracker (rastreador), que é uma máquina que age como coordenador. Ele ajuda na descoberta de pares, mostrando os nós na rede que têm o arquivo que você deseja.

Você tem as noções de dois tipos de usuário, um leecher e um seeder. Um leecher é o usuário que está baixando um arquivo e um seeder é o usuário que está enviando esse arquivo.

O interessante sobre redes peer-to-peer é que você, como usuário comum, tem a capacidade de se juntar e contribuir para a rede.

O BitTorrent e seus precursores (Gnutella, Napster – textos em inglês) permitem que você hospede arquivos voluntariamente e os envie para outros usuários que os desejam. A razão pela qual o BitTorrent é tão popular é que ele foi o primeiro de seu tipo a fornecer incentivos para contribuir com a rede. O problema do Freeriding, onde um usuário apenas baixava arquivos sem contribuir com uploads, era um desafio para os protocolos de compartilhamento de arquivos anteriores.

O BitTorrent resolveu o freeriding até certo ponto, fazendo com que os seeders enviassem mais para aqueles que fornecem as melhores taxas de download. Ele funciona incentivando você a fazer upload enquanto baixa um arquivo. Infelizmente, depois que você termina, nada o obriga a permanecer ativo na rede. Isso causa uma falta de seeders na rede que têm o arquivo completo e, como o protocolo depende fortemente de tais usuários, soluções como rastreadores privados (texto em inglês) surgiram. Rastreadores privados exigem que você seja membro de uma comunidade (geralmente apenas por convite) para participar da rede distribuída.

Após avanços na área, torrents sem rastreadores foram inventados. Essa foi uma atualização para o protocolo BitTorrent que não dependia de rastreadores centralizados para reunir metadados e encontrar pares, mas usava novos algoritmos. Um exemplo disso é o Kademlia (Mainline DHT) (textos em inglês), uma tabela de hash distribuída (DHT) que permite encontrar pares através de outros pares. Na prática, cada usuário desempenha as funções de um rastreador.

Registros distribuídos

Um registro distribuído pode ser pensado como um banco de dados imutável, de apenas anexação, que é replicado, sincronizado e compartilhado entre todos os nós na rede distribuída.

Escala conhecida – a Rede Ethereum teve um pico de 1,3 milhão de transações por dia em 4 de janeiro de 2018

Eles aproveitam o padrão de Event Sourcing (texto em inglês), permitindo que você reconstrua o estado do registro em qualquer momento de sua história.

Blockchain

A tecnologia Blockchain é atualmente usada para os registros distribuídos e, na verdade, marcou seu início. Essa mais recente e revolucionária inovação no espaço distribuído possibilitou a criação do primeiro protocolo de pagamento verdadeiramente distribuído – o Bitcoin.

Blockchain é um registro distribuído que carrega uma lista ordenada de todas as transações que já ocorreram em sua rede. As transações são agrupadas e armazenadas em blocos. O blockchain inteiro é essencialmente uma lista encadeada (texto em inglês) de blocos (daí o nome). Esses blocos são computacionalmente caros de serem criados e estão intimamente ligados entre si por meio de criptografia.

Dito de maneira simples, cada bloco contém um hash especial (que começa com uma quantidade X de zeros) do conteúdo do bloco atual (na forma de uma Árvore de Merkle) mais o hash do bloco anterior. Esse hash requer muita potência de CPU para ser produzido porque a única maneira de obtê-lo é através de força bruta.

Os miners (mineradores) são os nós que tentam calcular o hash (via força bruta). Os miners competem entre si para ver quem consegue encontrar uma string aleatória (chamada de nonce) que, quando combinada com o conteúdo, produz o hash mencionado anteriormente. Uma vez que alguém encontre o nonce correto, ele o transmite para toda a rede. Essa string é então verificada por cada nó individualmente e aceita em sua cadeia.

Isso se traduz em um sistema onde é absurdamente caro modificar o blockchain e absurdamente fácil verificar se ele não foi adulterado.

É caro alterar o conteúdo de um bloco porque isso produziria um hash diferente. Lembre-se de que o hash de cada bloco subsequente depende dele. Se você mudasse uma transação no primeiro bloco da imagem acima, você mudaria a Raiz de Merkle. Isso, por sua vez, mudaria o hash do bloco (provavelmente sem os zeros iniciais necessários) — isso mudaria o hash do bloco nº 2 e assim por diante. Isso significa que você precisaria forçar um novo nonce para cada bloco após aquele que você acabou de modificar.

A rede sempre confia e replica a cadeia válida mais longa. Para trapacear o sistema e eventualmente produzir uma cadeia mais longa, você precisaria de mais de 50% do poder total de processamento da CPU usado por todos os nós.

O blockchain pode ser pensado como um mecanismo distribuído para o consenso emergente. O consenso não é alcançado explicitamente — não há eleição ou momento fixo em que o consenso ocorre. Em vez disso, o consenso é um produto emergente da interação assíncrona de milhares de nós independentes, todos seguindo regras de protocolo.

Essa inovação sem precedentes recentemente se tornou um boom no espaço tecnológico, com pessoas prevendo que marcará a criação da Web 3.0 (texto em inglês). É definitivamente o espaço mais emocionante no mundo da engenharia de software no momento, repleto de problemas extremamente desafiadores e interessantes esperando para serem resolvidos.

Bitcoin

O que os protocolos de pagamento distribuídos anteriores não tinham era uma maneira de prevenir de maneira prática o problema de gasto duplo (texto em inglês) em tempo real e de maneira distribuída. Pesquisas produziram propostas interessantes[1], mas o Bitcoin foi o primeiro a implementar uma solução prática com vantagens claras sobre os outros.

O problema de gasto duplo afirma que um ator (por exemplo, Bob) não pode gastar seu único recurso em dois lugares. Se Bob tem $1, ele não deveria poder entregá-lo tanto para Alice quanto para Zack — é apenas um recurso, não pode ser duplicado. Acontece que é realmente difícil alcançar verdadeiramente essa garantia em um sistema distribuído. Existem algumas abordagens de mitigação interessantes (texto em inglês) anteriores ao blockchain, mas elas não resolvem completamente o problema de maneira prática.

O problema de gasto duplo é facilmente resolvido pelo Bitcoin, pois apenas um bloco é adicionado à cadeia de cada vez. O gasto duplo é impossível dentro de um único bloco, portanto, mesmo que dois blocos sejam criados ao mesmo tempo — apenas um virá a fazer parte da cadeia mais longa eventualmente.

O Bitcoin depende da dificuldade de acumular poder de processamento da CPU.

Enquanto em um sistema de votação um atacante só precisa adicionar nós à rede (o que é fácil, já que o acesso gratuito à rede é uma meta de projeto), em um esquema baseado em poder de CPU, um atacante enfrenta uma limitação física: obter acesso a hardware cada vez mais poderoso.

Essa também é a razão pela qual grupos maliciosos de nós precisam controlar mais de 50% do poder computacional da rede para realmente realizar qualquer ataque bem-sucedido. Menos do que isso, e o restante da rede criará um blockchain mais longo mais rapidamente.

Ethereum

Ethereum pode ser considerado como uma plataforma de software baseada em blockchain programável. Ele tem sua própria criptomoeda (Ether), que alimenta a implementação de contratos inteligentes em seu blockchain.

Contratos inteligentes são um pedaço de código armazenado como uma única transação no blockchain do Ethereum. Para executar o código, tudo o que você precisa fazer é emitir uma transação com um contrato inteligente como seu destino. Isso, por sua vez, faz com que os nós mineradores executem o código e quaisquer mudanças que ele incorra. O código é executado dentro da Máquina Virtual Ethereum.

Solidity, a linguagem de programação nativa do Ethereum, é o que é usado para escrever contratos inteligentes. É uma linguagem de programação completa de Turing que interage diretamente com o blockchain do Ethereum, permitindo que você consulte o estado, como saldos ou outros resultados de contratos inteligentes. Para evitar loops infinitos, executar o código requer uma certa quantidade de Ether.

Como o blockchain pode ser interpretado como uma série de mudanças de estado, muitas aplicações distribuídas (DApps; texto em inglês) foram construídas em cima do Ethereum e plataformas similares.

Outros usos de registros distribuídos

Prova de Existência (texto em inglês) — um serviço para armazenar de maneira anônima e segura a prova de que um determinado documento digital existia em algum momento no tempo. Útil para garantir a integridade do documento, propriedade e registro de data e hora.

Organizações autônomas descentralizadas (DAO; texto em inglês) — organizações que utilizam blockchain como meio de alcançar consenso sobre as proposições de melhoria da organização. Exemplos são o sistema de governança da Dash e o projeto SmartCash (textos em inglês).

Autenticação descentralizada — armazene sua identidade no blockchain, permitindo que você use logins únicos em todos os lugares (single sign-on; SSO). Exemplos são Sovrin e Civic (textos em inglês).

Há muitos, muitos outros. A tecnologia de registro distribuído realmente abriu possibilidades infinitas. Alguns, provavelmente, estão sendo inventados enquanto falamos!

Resumo

No curto espaço deste artigo, conseguimos definir o que é um sistema distribuído, por que você usaria um e passamos brevemente por cada categoria. Algumas coisas importantes para lembrar são:

• Sistemas distribuídos são complexos
• São escolhidos pela necessidade de escala e preço
• São mais difíceis de trabalhar
• Teorema CAP — escolha entre Consistência e Disponibilidade
• Eles têm 6 categorias — armazenamento de dados, computação, sistemas de arquivos, sistemas de mensagens, registros, aplicações

Para ser sincero, mal arranhamos a superfície dos sistemas distribuídos. Não tive a chance de abordar minuciosamente e explicar problemas fundamentais como consenso, estratégias de replicação, ordenação de eventos e tempo, tolerância a falhas, transmissão de mensagens pela rede e outros (textos em inglês).

Atenção

Deixe-me compartilhar com você um aviso final:

Você deve evitar os sistemas distribuídos o máximo possível. A sobrecarga de complexidade que eles trazem consigo não vale o esforço se você puder evitar o problema resolvendo-o de uma maneira diferente ou por meio de alguma outra solução criativa.

[1]
Combate ao duplo gasto usando sistemas P2P cooperativos (texto em inglês), 25 a 27 de junho de 2007 — uma solução proposta na qual cada 'moeda' pode expirar e é atribuído um testemunho (validador) a ela ao ser gasta.

Bitgold (texto em inglês), dezembro de 2005 — uma visão geral de alto nível de um protocolo extremamente semelhante ao do Bitcoin. Diz-se que ele é o precursor do Bitcoin.

Leituras adicionais sobre sistemas distribuídos:

Designing Data-Intensive Applications, Martin Kleppmann — um ótimo livro que aborda tudo sobre sistemas distribuídos e muito mais (em inglês).

Especialização em computação em nuvem, Universidade de Illinois, Coursera — uma série de cursos (6) que aborda conceitos de sistemas distribuídos e suas aplicações.

Jepsen — blog que explica muitas tecnologias distribuídas (ElasticSearch, Redis, MongoDB etc).

Obrigado por dedicar seu tempo para ler este longo artigo (mais de 6.700 palavras)!

Se, por acaso, você achou este artigo informativo ou considerou que ele proporcionou valor a você, por favor, considere compartilhá-lo com um amigo que possa se beneficiar de uma introdução a esse maravilhoso campo de estudo.

Sobre Stanislav Kozlovski

O autor, atualmente, trabalha na Confluent. Confluent é uma empresa de Big Data fundada pelos próprios criadores do Apache Kafka! Ele se diz imensamente grato pela oportunidade que lhe deram – atualmente, ele trabalha no próprio Kafka, o que considera incrível! Na Confluent, eles ajudam a moldar todo o ecossistema Kafka de código aberto, incluindo uma nova oferta gerenciada de nuvem Kafka como serviço.

A Confluent contrata para vários cargos (especialmente SRE/Engenheiros de Software) na Europa e nos EUA! Se você estiver interessado em trabalhar no próprio Kafka, em busca de novas oportunidades ou simplesmente curioso – envie para o autor uma mensagem no Twitter e ele se oferece a compartilhar todas as grandes vantagens de se trabalhar por lá.

Introdução

Com a Web 3.0 e a blockchain se tornando mais comuns a cada dia, você sabe o que é blockchain? Você conhece suas vantagens técnicas e seus casos de uso?

O objetivo deste tutorial é introduzir a tecnologia de blockchain a partir de uma perspectiva técnica, construindo uma a partir do zero.

Esqueça tudo o que você já ouviu sobre blockchain nas redes sociais. Agora, você construirá um sistema de blockchain do zero para entender realmente as entradas e saídas dessa tecnologia distribuída peer-to-peer.

Depois disso, decida sobre seu futuro e suas vantagens. Alerta de spoiler: você vai se apaixonar pelo software de programação de blockchain.

Como?

Você seguirá a história de um desenvolvedor de software que está procurando revolucionar seu bar local, através da implementação da tecnologia de blockchain para seu sistema de pagamento.

Embora a blockchain tenha vários casos de uso inegáveis, no momento, a aplicação número um são os pagamentos. Isto ocorre porque os bancos ainda estão funcionando em uma infraestrutura ineficiente, com 40 anos de idade, alimentada por arquivos CSV e FTP.

A história vem com muitos fatos engraçados e intrigantes sobre o ecossistema geral da blockchain e diferentes protocolos, como Bitcoin, Ethereum e XRP.

O que você vai criar, aprender e fazer neste tutorial?

• Você vai configurar um projeto na linguagem Go em sua máquina local sem qualquer experiência prévia com GoLang
• Você gerará e distribuirá seus primeiros tokens (ativos digitais) de blockchain.
• Você desenvolverá um banco de dados controlado pela CLI em Go a partir do zero
• Você descobrirá como poucos usuários possuem direitos em suas aplicações favoritas
• Você descobrirá a principal proposta de valor da blockchain
• Você tornará seu BD imutável usando uma função de hash criptográfico segura

Por isso, vamos começar a nossa história.

⭐ Conheça o protagonista, Andrej.

Andrej é dono de um bar à noite e desenvolvedor de software de dia em uma pequena cidade eslovaca chamada Bardejov.

Andrej está cansado de:

• Programação de aplicações sólidas e à moda antiga com PHP/Java/Javascript
• Esquecer quanto dinheiro seus amigos e clientes lhe devem por todos os shots de vodka não pagos de sexta-feira à noite
• Passar tempo coletando e contando moedas, devolvendo troco e geralmente tocando cédulas expostas à COVID-19
• Fazer a manutenção de diferentes fichas plásticas para pebolim, dardos, bilhar e pôquer

Andrej adoraria:

• Ter um histórico auditável perfeito das atividades e vendas do bar para tornar seu bar compatível com as normas fiscais
• Transformar seu bar em um ambiente autônomo, eficiente, descentralizado e seguro, no qual seus clientes possam confiar e apenas se divertir

Seu objetivo é escrever um programa simples e manter todos os saldos de seus clientes de modo virtual.

Andrej compartilha suas ideias aqui:

"Cada novo cliente me dará dinheiro, e eu creditarei para eles uma quantidade equivalente dos meus tokens (moedas/moeda criptográfica)". Os tokens representarão uma unidade monetária dentro e fora do bar.

As pessoas usarão os tokens para todas as funcionalidades do bar, desde pagar bebidas, pedir emprestado e emprestar a seus amigos, até jogar tênis de mesa, pôquer e pebolim.

Ter um bar administrado por meio de tokens gerará um valor imenso para meus clientes. Ao contrário da minha concorrência e de outros bares nesta rua, onde os clientes só gastam dinheiro e conseguem uma ressaca em troca, os clientes que tiverem fichas do meu bar terão direito de acionistas.

Semelhante a possuir uma grande parte das ações de uma empresa, como a Apple ou a Microsoft, os clientes que possuem esses tokens de bar poderão decidir como o bar funcionará através de votação e decisão sobre:

• preços das bebidas
• horário de funcionamento
• novas funcionalidades (TV, jukebox...)
• design interior e exterior
• alocação de lucros
• etc.

Ah, isso será um sonho para programação!

Chamarei os tokens de: tokens do bar das blockchain, ou TBB!"

Agora que Andrej compartilhou seu sonho, vamos começar.

Sumário

• Requisitos
• Configurar o projeto
• 01 | O banco de dados MVP
• 02 | Alterando o estado global do BD
• 03 | Evento monolítico x transação
• 04 | Os seres humanos são gananciosos
• 05 | Por que precisamos da blockchain
• 06 | O hash imutável
• Próximos passos

Requisitos

Vamos nos aprofundar em nosso tutorial. Recomendo mais de 2 anos de experiência em programação em Java/PHP/Javascript ou outra linguagem similar à Go.

Se você quiser ter uma boa introdução rápida para começar, aqui está um curso gratuito (em inglês) que ajudará você.

Você também pode completar as 17 aulas oficiais de Um tour por Go para se familiarizar com a sintaxe do idioma e conceitos básicos (cerca de 20 minutos).

Por que Go?

Porque, assim como a blockchain, é uma tecnologia fantástica para toda a sua carreira de programação. Go é uma linguagem da moda e desenvolvedores de Go são mais bem pagos do que a média das posições em Java/PHP/Javascript.

Go é otimizado para a arquitetura de CPUs multi-core. Você pode gerar milhares de threads leves (rotinas do Go) sem problemas. É extremamente prático para software paralelos e simultâneos, tais como redes de blockchain.

Ao escrever seu software em Go, você atinge um nível semelhante ao do C++ em termos de desempenho, desde o início, sem se matar por ter esquecido de liberar a memória.

Go também compila para binário, o que o torna muito portátil.

Configurar o projeto

Este artigo tem um repositório dedicado e de código aberto no Github, com o código-fonte completo para que você possa compilar o código e executar o programa em sua própria máquina local.

Se você ficar preso em qualquer capítulo ou em uma linha de código em particular, crie uma issue no Github do repositório descrevendo seu problema e eu o ajudarei o quanto antes!

Visite o repositório no Github e siga as instruções de instalação.

01 | O banco de dados MVP

✍ git checkout c1_genesis_json

Andrej dominou os bancos de dados relacionais em SQL nos anos 90. Ele sabe como fazer modelos de dados avançados e como otimizar as consultas em SQL.

Chegou a hora de Andrej alcançar a inovação e começar a criar software para a web 3.0.

Por sorte, após ler o livro "The Lean Startup" na semana passada, Andrej percebe que ainda não deveria projetar demais a solução. Assim, ele escolhe um arquivo JSON simples, mas eficaz, para ser o banco de dados e o produto viável mínimo, ou MVP (do inglês, minimum viable product), do bar.

No início, havia um banco de dados centralizado primitivo.

Resumo:

A blockchain é um banco de dados.

Usuário 1, Andrej

Segunda-feira, 18 de março.

Andrej gera 1 milhão de tokens de utilidade.

No mundo da blockchain, os tokens são unidades dentro do banco de dados da blockchain. Seu valor real em espécie flutua com base em sua demanda e popularidade.

Cada blockchain tem um arquivo "Genesis". O arquivo "Genesis" é usado para distribuir os primeiros tokens aos participantes iniciais da blockchain.

Tudo começa com um simples genesis.json de teste.

Andrej cria o arquivo ./database/genesis.json, onde ele define que o banco de dados do bar da blockchain terá 1 milhão de tokens e que todas elas pertencerão a Andrej:

{
  "genesis_horario": "2019-03-18T00:00:00.000000000Z",
  "chain_id": "the-blockchain-bar-ledger",
  "saldo": {
      "andrej": 1000000
  }
}

Os tokens precisam ter uma "utilidade" real, ou seja, um caso de uso. Os usuários devem ser capazes de pagar com eles a partir do primeiro dia!

Andrej deve estar em conformidade com as regulamentações da lei. É ilegal a emissão de valores não registrados. Por outro lado, os tokens de utilidade estão em conformidade, então ele imprime e cola imediatamente um novo cartaz com os preços na porta do bar.

Andrej atribui um valor monetário inicial a seus tokens para poder trocá-los por euro, dólar ou outra moeda.

1 token TBB = 1€

| Item                      	 | Preco   |
| ------------------------------ | ------- |
| Dose de vodka                	 | 1   TBB |
| Suco de laranja           	 | 5   TBB |
| Hamburguer                	 | 2   TBB |
| Garrafa de vodka Crystal Head  | 950 TBB |

Andrej também decide que deve receber 100 tokens por dia para manter o banco de dados e por ter tido uma ideia tão brilhante e disruptiva.

Fatos interessantes

A primeira genesis Ether (ETH) sobre a blockchain Ethereum foi criada e distribuída aos primeiros investidores e desenvolvedores da mesma maneira que o token de utilidade de Andrej.

Em 2017, durante um boom das ofertas iniciais de moedas (do inglês, Initial Coin Offers, ou ICO) na rede de blockchain Ethereum, os fundadores do projeto escreveram e apresentaram whitepapers aos investidores. Um whitepaper é um documento técnico que esboça uma questão complexa e uma possível solução, destinada a educar e esclarecer sobre um assunto específico. No mundo da blockchain, um whitepaper serve para delinear as especificações de como essa blockchain em particular será e se comportará uma vez desenvolvida.

Os projetos de blockchain aumentaram entre 10 e 300 milhões de euros por ideia de whitepaper.

Em troca de dinheiro (o "financiamento" das ICOs), os nomes dos investidores seriam incluídos nos "balanços de genesis" iniciais, semelhante ao que Andrej fez. As esperanças dos investidores em uma ICO estão no fato de que as moedas de genesis subam de valor e que as equipes entreguem a blockchain delineada.

Naturalmente, nem todas as ideias de whitepaper se concretizam. Investimentos massivos perdidos por ideias pouco claras ou incompletas são a razão pela qual a blockchain recebeu cobertura negativa na mídia através dessas ICOs e para alguns ainda a considerarem uma modinha. A tecnologia da blockchain subjacente, porém, é fantástica e útil, como você aprenderá mais neste artigo. Ela tem sido abusada por alguns maus atores.

Resumo:

A blockchain é um banco de dados.

O fornecimento de tokens, o balanço inicial do usuário e as configurações globais da blockchain são definidas em um arquivo genesis.

02 | Alterando o estado global do BD

✍ git checkout c2_db_changes_txt

Festa chata

Segunda-feira, 25 de Março.

Após uma semana de trabalho, as instalações do bar estão prontas para aceitar os tokens. Infelizmente, ninguém aparece. Então, Andrej pede três doses de vodka para si mesmo e escreve as mudanças no banco de dados em um pedaço de papel:

andrej-3;   // 3 doses de vodka
andrej+3;   // tecnicamente comprando de seu próprio bar
andrej+700; // Recompensa por uma semana de trabalho (7x100 por dia)

Para evitar recalcular o estado mais recente do saldo de cada cliente, Andrej cria um arquivo ./database/state.json, que armazena os saldos em um formato agregado.

Novo estado do BD:

{
  "saldo": {
      "andrej": 1000700
  }
}

Bônus para BabaYaga

Terça-feira, 26 de Março.

Para trazer o público até seu bar, Andrej anuncia um bônus exclusivo de 100% para todos que adquirirem os tokens TBB nas próximas 24 horas.

Ele recebe sua primeira cliente, chamada BabaYaga. BabaYaga pré-compra mil euros em tokens e, para comemorar, gasta imediatamente 1 TBB para uma dose de vodka. Ela tem um problema com a bebida.

Transações do BD escritas em um pedaço de papel:

andrej-2000;   // transfererência para BabaYaga
babayaga+2000; // pré-compra com 100% bônus
babayaga-1;
andrej+1;
andrej+100;    // 1 dia de sol nascendo

Novo estado do BD:

{
  "saldo": {
      "andrej": 998801,
      "babayaga": 1999
  }
}

Fatos interessantes

Os projetos de ICO (ofertas iniciais de moedas, baseadas em whitepaper) de blockhain frequentemente distribuem os tokens de genesis com diferentes bônus, dependendo de quantos deles você compra e de você ter feito isso rapidamente. As equipes oferecem, em média, 10-40% de bônus aos "participantes" iniciais.

A palavra "investidor" é evitada, de modo que os reguladores legais não considerarão os tokens como um valor não registrado. Os projetos argumentariam que seu produto principal, tokens de blockchain, funcionam como "milhas de vôo ou pontos de fidelidade".

Os "participantes", mais tarde, fazem até 1.000% de seu investimento vendendo ao público através de um intercâmbio vários meses depois.

Resumo:

A blockchain é um banco de dados.

O fornecimento de tokens, o balanço inicial do usuário e as configurações globais da blockchain, você define em um arquivo Genesis.

Os balanços de Genesis indicam qual era o estado original da blockchain e nunca são atualizados depois.

As mudanças de estado do banco de dados são chamadas de transações (TX).

03 | Evento monolítico x transação

✍ git checkout c3_state_blockchain_component

Os desenvolvedores acostumados à arquitetura de fornecimento de eventos devem ter reconhecido imediatamente os princípios familiares por trás das transações. Eles estão corretos.

As transações das blockchain representam uma série de eventos. O banco de dados é um estado final agregado, calculado após a repetição de todas as transações em uma sequência específica

Andrej programando

Terça-feira à noite, 26 de março.

É uma noite relaxante de terça-feira para Andrej. Comemorando seu primeiro cliente, ele decide jogar Starcraft e limpar sua máquina de desenvolvimento local, removendo algumas fotos antigas.

Infelizmente, ele pressionou prematuramente a tecla Enter ao digitar um comando de comando de remoção no terminal, sudo rm -rf /. Xiiii!

Todos os seus arquivos, incluindo os arquivos genesis.json e state.json do bar, desapareceram.

Andrej, sendo um desenvolvedor sênior, gritou repetidamente algumas palavras bem alto por alguns segundos, mas não entrou em pânico!

Embora ele não tivesse um back-up, ele tinha algo melhor – um pedaço de papel com todas as transações do banco de dados. A única coisa que ele precisa fazer é reproduzir todas as transações uma a uma e o estado de seu banco de dados será recuperado.

Impressionado com as vantagens da arquitetura baseada em eventos, ele decide ampliar sua solução de banco de dados MVP. Cada atividade do bar, como a compra individual de bebidas, DEVE ser registrada dentro do banco de dados da blockchain.

Cada consumidor será representado no BD utilizando uma estrutura de conta:

type Conta string

Cada Transação (TX – uma mudança de banco de dados) terá os quatro atributos seguintes: de, para, valor e dados.

O atributo de dados com um valor possível (recompensa) captura o bônus de Andrej por inventar a blockchain e aumenta artificialmente a oferta total inicial de tokens TBB (inflação).

type Tx struct {
   De  Account `json:"de"`
   Para    Account `json:"para"`
   Valor uint    `json:"valor"`
   Dado  string  `json:"dado"`
}

func (t Tx) IsReward() bool {
   return t.Dado == "recompensa"
}

O BD de Genesis permanecerá com um arquivo JSON:

{
  "genesis_horario": "2019-03-18T00:00:00.000000000Z",
  "chain_id": "the-blockchain-bar-ledger",
  "saldo": {
      "andrej": 1000000
  }
}

Todas as transações, previamente escritas em um pedaço de papel, serão armazenadas em um banco de dados local de arquivos de texto chamado tx.db, serializado em formato JSON e separado por caracteres de quebra de linha:

{"de":"andrej","para":"andrej","valor":3,"dado":""}
{"de":"andrej","para":"andrej","valor":700,"dado":"recompensa"}
{"de":"andrej","para":"babayaga","valor":2000,"dado":""}
{"de":"andrej","para":"andrej","valor":100,"dado":"recompensa"}
{"de":"babayaga","para":"andrej","valor":1,"dado":""}

O componente mais crucial do banco de dados, que encapsula toda a lógica comercial será o Estado:

type Estado struct {
   Saldos   map[Conta]uint
   txMempool []Tx

   dbFile *os.File
}

A estrutura do Estado saberá sobre todos os saldos de usuários, quem transferiu os tokens TBB para quem e quantos foram transferidos.

É construído através da leitura do saldo inicial de usuários do arquivo genesis.json:

func NewStateFromDisk() (*Estado, error) {
   // Obter o diretorio de trabalho atual
   cwd, err := os.Getwd()
   if err != nil {
      return nil, err
   }

   genFilePath := filepath.Join(cwd, "database", "genesis.json")
   gen, err := loadGenesis(genFilePath)
   if err != nil {
      return nil, err
   }

   saldo := make(map[Conta]uint)
   for conta, saldo := range gen.Saldos {
      saldos[conta] = saldo
   }

Em seguida, os balanços do Estado de genesis são atualizados através da reprodução sequencial de todos os eventos do banco de dados do tx.db:

   txDbFilePath := filepath.Join(cwd, "database", "tx.db")
   f, err := os.OpenFile(txDbFilePath, os.O_APPEND|os.O_RDWR, 0600)
   if err != nil {
      return nil, err
   }

   scanner := bufio.NewScanner(f)
   estado := &Estado{saldos, make([]Tx, 0), f}

   // Iterar sobre cada linha do arquivo tx.db
   for scanner.Scan() {
      if err := scanner.Err(); err != nil {
         return nil, err
      }

      // Converter TX codificado pelo JSON em um objeto (estrutura)
      var tx Tx
      json.Unmarshal(scanner.Bytes(), &tx)

      // Reconstruir o Estado (saldos de usuários),
      // como uma série de eventos
      if err := estado.apply(tx); err != nil {
         return nil, err
      }
   }

   return estado, nil
}

O componente Estado é responsável por:

• Adicionar novas transações ao Mempool
• Validar as transações contra o Estado atual (saldo suficiente do remetente)
• Mudar o estado
• Salvar transações persistentes em disco
• Calcular os saldos de contas através da repetição de todas as transações desde Genesis em uma seqüência

Adicionar novas transações ao Mempool:

func (s *Estado) Add(tx Tx) error {
   if err := s.apply(tx); err != nil {
      return err
   }

   s.txMempool = append(s.txMempool, tx)

   return nil
}

Persistir as transações em disco:

func (s *Estado) Persist() error {
   // Faça uma cópia do mempool porque o s.txMempool será modificado
   // no laço abaixo
   mempool := make([]Tx, len(s.txMempool))
   copy(mempool, s.txMempool)

   for i := 0; i < len(mempool); i++ {
      txJson, err := json.Marshal(mempool[i])
      if err != nil {
         return err
      }

      if _, err = s.dbFile.Write(append(txJson, '\n')); err != nil {
         return err
      }

      // Remover o TX escrito em um arquivo do mempool
      s.txMempool = s.txMempool[1:]
   }

   return nil
}

Mudar, validar o estado:

func (s *Estado) apply(tx Tx) error {
   if tx.IsReward() {
      s.Saldos[tx.To] += tx.Valor
      return nil
   }

   if tx.Valor > s.Saldos[tx.De] {
      return fmt.Errorf("saldo insuficiente")
   }

   s.Saldos[tx.De] -= tx.Valor
   s.Saldos[tx.Para] += tx.Valor

   return nil
}

Construir uma interface de linha de comando (CLI)

Terça-feira à noite, 26 de março.

Andrej quer ter uma maneira conveniente de adicionar novas transações ao seu banco de dados e listar os últimos saldos de seus clientes. Como os programas Go compilam para binário, ele faz uma CLI para seu programa.

A maneira mais fácil de desenvolver programas baseados em CLI em Go é usando a biblioteca de terceiros github.com/spf13/cobra.

Andrej inicializa o gerenciador de dependências de Go para seu projeto, chamado go modules:

✍ cd $GOPATH/src/github.com/web3coach/the-blockchain-way-of-programming-newsletter-edition

✍ go mod init github.com/web3coach/the-blockchain-way-of-programming-newsletter-edition

O comando Go modules buscará automaticamente qualquer biblioteca a que você se referir dentro de seus arquivos Go.

Andrej cria um diretório chamado cmd, com um subdiretório tbb:

✍mkdir -p ./cmd/tbb

Dentro, ele cria um arquivo main.go, servindo como o ponto de entrada da CLI do programa:

package main

import (
    "github.com/spf13/cobra"
    "os"
    "fmt"
)

func main() {
    var tbbCmd = &cobra.Command{
        Use:   "tbb",
        Short: "The Blockchain Bar CLI",
        Run: func(cmd *cobra.Command, args []string) {
        },
    }
    
    err := tbbCmd.Execute()
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

Os programas Go são compilados usando o comando install:

✍ go install ./cmd/tbb/...

go: finding github.com/spf13/cobra v1.0.0
go: downloading github.com/spf13/cobra v1.0.0
go: extracting github.com/spf13/cobra v1.0.0

O Go detectará as bibliotecas ausentes e as buscará automaticamente antes de compilar o programa. Dependendo de seu $GOPATH, o programa resultante será salvo na pasta $GOPATH/bin.

✍echo $GOPATH

/home/web3coach/go

✍which tbb

/home/web3coach/go/bin/tbb

Você pode executar o tbb de seu terminal agora, mas ele não fará nada porque a função Run dentro do arquivo main.go está vazia.

A primeira coisa que Andrej precisa é de suporte de versão para seu programa tbb da CLI.

Ao lado do arquivo main.go, ele cria um comando version.go:

package main

import (
    "fmt"
    "github.com/spf13/cobra"
)

const Major = "0"
const Minor = "1"
const Fix = "0"
const Verbal = "Adicionar TX e listar saldos"

var versionCmd = &cobra.Command{
    Use:   "versão",
    Short: "Descreve a versão.",
    Run: func(cmd *cobra.Command, args []string) {
        fmt.Printf("Versão: %s.%s.%s-beta %s", Major, Minor, Fix, Verbal)
    },
}

Ele compila o programa e o executa:
✍ go install ./cmd/tbb/...
✍ tbb version

Versão: 0.1.0-beta Adicionar TX e listar saldos

Perfeito.

De modo idêntico ao arquivo version.go, ele cria um arquivo balance.go:

func saldosCmd() *cobra.Command {
    var saldosCmd = &cobra.Command{
        Use:   "saldos",
        Short: "Interage com saldos (lista...).",
        PreRunE: func(cmd *cobra.Command, args []string) error {
            return incorrectUsageErr()
        },
        Run: func(cmd *cobra.Command, args []string) {
        },
    }

    saldosCmd.AddCommand(saldosListaCmd)

    return saldosCmd
}

O comando saldos será responsável por carregar o último estado do BD e imprimi-lo para a saída padrão:

var saldosListaCmd = &cobra.Command{
    Use:   "list",
    Short: "Lista todos os saldos.",
    Run: func(cmd *cobra.Command, args []string) {
        estado, err := database.NewStateFromDisk()
        if err != nil {
            fmt.Fprintln(os.Stderr, err)
            os.Exit(1)
        }
        defer estado.Close()

        fmt.Println("Saldos das contas:")
        fmt.Println("__________________")
        fmt.Println("")
        for conta, saldo := range estado.Saldos {
            fmt.Println(fmt.Sprintf("%s: %d", conta, saldo))
        }
    },
}

Andrej verifica se o comando funciona como esperado. Ele deve imprimir os saldos exatos definidos no arquivo Genesis porque o arquivo tx.db ainda está vazio.

✍ go install ./cmd/tbb/...

✍ tbb saldos list

Saldos das contas:
__________________
andrej: 1000000

Funciona bem! Agora, ele só precisa de um comando para registrar a atividade do bar.

Andrej cria o comando ./cmd/tbb/tx.go:

func txCmd() *cobra.Command {
    var txsCmd = &cobra.Command{
        Use:   "tx",
        Short: "Interage com as txs (adicionar...).",
        PreRunE: func(cmd *cobra.Command, args []string) error {
            return incorrectUsageErr()
        },
        Run: func(cmd *cobra.Command, args []string) {
        },
    }

    txsCmd.AddCommand(txAddCmd())

    return txsCmd
}

O comando tbb tx add utiliza a função Estado.Adicionar(tx) para a persistência dos eventos do bar no sistema de arquivos:

func txAddCmd() *cobra.Command {
    var cmd = &cobra.Command{
        Use:   "add",
        Short: "Adiciona novo TX ao banco de dados.",
        Run: func(cmd *cobra.Command, args []string) {
            de, _ := cmd.Flags().GetString(flagDe)
            para, _ := cmd.Flags().GetString(flagPara)
            valor, _ := cmd.Flags().GetUint(flagValor)

            deConta := database.NewAccount(de)
            paraConta := database.NewAccount(para)
            
            tx := database.NewTx(deConta, paraConta, valor, "")

            estado, err := database.NewStateFromDisk()
            if err != nil {
                fmt.Fprintln(os.Stderr, err)
                os.Exit(1)
            }
            
            // Deferir ao final da execução dessa função
            // A executação da seguinte declaração (fechar o arquivo DB com todos os TXs)
            defer estado.Close()
            
            // Adicionar o TX a um array em memória (pool)
            err = estado.Add(tx)
            if err != nil {
                fmt.Fprintln(os.Stderr, err)
                os.Exit(1)
            }
            
            // Limpa os TXs do mempool para o disco
            err = estado.Persist()
            if err != nil {
                fmt.Fprintln(os.Stderr, err)
                os.Exit(1)
            }

            fmt.Println("TX adicionada com sucesso ao ledger.")
        },
    }

O comando tbb tx add tem 3 flags obrigatórias: --de, --para e --valor.

cmd.Flags().String(flagDe, "", "De que conta enviar os tokens")
cmd.MarkFlagRequired(flagDe)

cmd.Flags().String(flagPara, "", "Para que conta enviar os tokens")
cmd.MarkFlagRequired(flagPara)

cmd.Flags().Uint(flagValor, 0, "Quantos tokens enviar")
cmd.MarkFlagRequired(flagValor)

return cmd

A CLI está feita!

Andrej migra todas as transações do papel para o novo BD:

✍ tbb tx add --de=andrej --para=andrej --valor=3

✍tbb tx add --de=andrej --para=andrej --valor=700

✍tbb tx add --de=babayaga --para=andrej --valor=2000

✍tbb tx add --de=andrej --para=andrej --valor=100 --dado=recompensa

✍tbb tx add --de=babayaga --para=andrej --valor=1

Leia todos os TXs a partir do disco e calcule o estado mais recente:

✍ tbb saldos list

Saldos das contas:
__________________
andrej: 998801
babayaga: 1999

Dados do bar restaurados com sucesso! Ufa! Que noite!

Sobre a biblioteca Cobra CLI

O bom da biblioteca Cobra para a programação da CLI está nas características adicionais que ela traz consigo. Por exemplo, agora, você pode executar o comando tbb help e imprimirá todos os subcomandos registrados na TBB com instruções sobre como usá-los.

 tbb help

The Blockchain Bar CLI

Usage:
  tbb [flags]
  tbb [command]

Available Commands:
  balances    Interage com balanços (list...).
  help        Ajuda sobre qualquer comando
  tx          Interage com txs (add...).
  version     Descreve a versão.

Flags:
  -h, --help   ajuda para tbb

Use "tbb [comando] --help" para mais informações sobre um comando.

Fatos interessantes

A perda acidental de dados dos clientes é normal no mundo corporativo nos dias de hoje. A blockchain corrige isso descentralizando o armazenamento de dados.

Há um truque que Andrej introduziu no programa ao pular a verificação de saldos para os TX marcados como "recompensas". Bitcoin e Ethereum funcionam da mesma forma. O saldo da Conta que minerou um bloco aumenta do nada como um assunto de inflação total de fornecimento dos tokens, que afeta toda a cadeia. O fornecimento total de bitcoins é limitado a 21M BTC. Você aprenderá mais sobre "mineração" e "blocos" posteriormente.

Os componentes State (estado) e Mempool não são exclusivos deste programa. Andrej escolheu os nomes e designs para combinar com um modelo simplificado da go-Ethereum, para que você tenha uma ideia do código fonte central do Ethereum.

Resumo:

A blockchain é um banco de dados.

O fornecimento de tokens, os balanços iniciais dos usuários e as configurações globais da blockchain são definidos em um arquivo Genesis.

Os balanços de Genesis indicam qual era o estado original da blockchain e nunca são atualizados depois.

As mudanças de estado do banco de dados são chamadas Transações (TX).

As transações são eventos ao estilo antigo, que representam ações dentro do sistema.

⚒ Código de estudo

Commit: 5d4b0b

Vamos falar sobre a ganância.

04 | Os humanos são gananciosos

✍ git checkout c4_caesar_transfer

A ganância típica dos negócios

Quarta-feira, 27 de março.

BabaYaga investiu um pouco demais. Ela esqueceu que o pagamento do aluguel do apartamento estava chegando e, agora, não tem o dinheiro. BabaYaga chama o proprietário de seu apartamento, César.

BabaYaga: Ei, César, sinto muito, mas não tenho dinheiro para pagar o aluguel este mês...

Caesar: Por que não?

BabaYaga: O ICO do Blockchain Bar ofereceu um bônus enorme e eu comprei 2000 tokens no valor de apenas mil euros. Foi um grande negócio!

César: Do que você está falando? O que é um ICO? O que são tokens? Você pode me pagar de algum outro modo?

BabaYaga: Ah, outra vez, não. Eu posso dar mil tokens TBB, que valem mil euros, e você pode usá-los no bar para pagar suas bebidas! Deixe-me ligar para o dono do bar, Andrej, e fazer a transferência!

César: Muito bem... eu vou aceitar.

Andrej realiza a transferência, mas decide cobrar mais 50 tokens de TBB por ter de fazer os procedimentos. Ele não quer, MAS os acionistas do bar que investiram nele há alguns anos estão forçando-o a gerar lucro o mais rápido possível.

BabaYaga não vai ter problemas com esta taxa relativamente pequena, muito provavelmente, diz Andrej a si mesmo. No final, somente ele tem o acesso ao BD.

// Pagamento do aluguel

✍tbb tx add --de=babayaga --para=cesar --valor=1000

// Cobrança de taxa oculta

✍ tbb tx add --de=babayaga --para=andrej --valor=50

// Nova recompensa por mais um dia de manutenção do BD

✍ tbb tx add --de=andrej --para=andrej --valor=100 --dado=recompensa

Fatos interessantes

O caso de uso número um da blockchain é o bancário. Muitos projetos de blockchain visam otimizar o câmbio nacional e internacional de dinheiro através de diferentes canais de moedas (XRP).

Outros projetos enfocam a liberdade e a identidade própria (SSI, do inglês, Self-sovereign identity) – um movimento digital que reconhece que um indivíduo deve possuir e controlar sua identidade e dinheiro sem as autoridades administrativas intervenientes ou outros intermediários centralizados. A SSI permite que as pessoas interajam no mundo digital com a mesma liberdade e capacidade de confiança que interagem no mundo off-line. (Bitcoin / Ethereum)

Aqui estão alguns fatos interessantes que explicam o porquê de a blockchain ser um ajuste perfeito para substituir a infraestrutura bancária atual de seu banco.

O bom dos tokens é sua fungibilidade - ou seja, sua capacidade de serem comercializados, com cada unidade sendo tão utilizável quanto a próxima. A realização de uma transferência de conta para conta pode ser feita simplesmente mudando o estado do banco de dados. As moedas criptográficas são negociáveis 24 horas por dia, 7 dias por semana.

Você não pode negociar ações diretamente. Você precisa passar por um corretor que participa de uma porcentagem da transação total como taxa (1-3% a 7% do lucro médio anual).

Uma transferência bancária internacional leva entre 3-10 dias úteis e pode custar até 5% do valor transferido! Se você estiver enviando $10.000, poderá ter que pagar até $500. A tecnologia por trás disso nos últimos 40 anos? FTP + arquivos CSV.

Você acha que o mercado de ações é justo? Os bancos, índices e ações são altamente centralizados e controlados por governos e grupos privados de Wall Street. O mercado livre? Wall Street controla o quanto os preços podem saltar/cair em um único dia.

Como exemplo, Wall Street suspendeu a negociação do "Índice S&P 500" após uma queda de 7% para proteger seus investidores e fundos especulativos de perder dinheiro das pessoas que venderam suas ações durante março de 2020, após as notícias da COVID. Posteriormente, o FED imprimiu trilhões de dólares para eles mesmos para apoiar o preço das ações. Se você é um desenvolvedor que gosta de economizar dinheiro e evitar dívidas, suas economias acabarão perdendo valor de um dia para o outro por uma porcentagem ainda desconhecida.

Muitos países estão entrando em rendimentos negativos, um território inexplorado com consequências desconhecidas. O que isto significa? Em breve você terá que pagar ao banco para manter suas economias. Inflação no seu melhor. Você está sendo obrigado a gastar seu dinheiro para apoiar um sistema que você não controla.

⚒ Código de estudo

Commit: 00d6ed

05 | Por que precisamos da blockchain

✍ git checkout c5_broken_trust

BabaYaga busca justiça

Quinta-feira, 28 de março.

BabaYaga entra no bar para seu aniversário.

BabaYaga: Ei, Andrej! Hoje é meu aniversário! Traga-me sua garrafa mais cara!

Andrej: Feliz aniversário! Aqui está: Vodka Crystal Head. Mas você precisa comprar um token TBB adicional. A garrafa custa 950 tokens, e seu saldo é de 949.

BabaYaga: O quê?! Meu saldo deveria ser de 999 TBB!

Andrej: A transferência de fundos para César que você solicitou na semana passada custou 50 tokens.

BabaYaga: Isto é inaceitável! Eu nunca concordaria com uma taxa tão alta. Você não pode fazer isto, Andrej. Confiei em seu sistema, mas você é tão pouco confiável quanto qualquer outro proprietário de empresa. As coisas devem mudar!

Andrej: Muito bem, veja. Você é minha cliente mais fiel e eu não queria cobrar de você, mas meus acionistas me obrigaram.

Deixe-me reprogramar meu sistema e torná-lo completamente transparente e descentralizado. Afinal, se todos fossem capazes de interagir com o bar sem passar por mim, isso melhoraria significativamente a eficiência do bar e equilibraria o nível de confiança!

• Pedir bebidas levaria segundos ao invés de minutos
• Os clientes que esqueceram suas carteiras em casa poderiam pedir emprestado ou emprestar tokens um ao outro
• Eu não teria que me preocupar em perder os dados dos clientes (novamente), pois todos teriam uma cópia dos mesmos
• O banco de dados seria imutável, portanto, uma vez que todos estivessem de acordo sobre um estado específico, ninguém mais poderia mudá-lo ou modificar maliciosamente a história. A imutabilidade também ajudaria nas auditorias fiscais anuais!
• Se os acionistas quisessem introduzir novas taxas ou aumentar as taxas atuais, todos os envolvidos no sistema de blockchain notariam e teriam que concordar com ele. Os usuários e proprietários de empresas teriam até mesmo que se engajar em algum sistema de governança descentralizada em conjunto, baseado na votação, provavelmente. Em caso de desacordo, os usuários se afastam com todos os seus dados!

BabaYaga: Bem, certamente soa bem, mas será que isso é mesmo possível?

Andrej: Sim, eu acho que sim. Com um pouco de hashing, listas vinculadas, estrutura de dados imutável, replicação distribuída e criptografia assimétrica!

BabaYaga: Não faço ideia do que você acabou de dizer, mas vá em frente e faça suas nerdices, Andrej!

Fatos interessantes

Os mineradores Bitcoin e Ethereum também recebem recompensas a cada 15 minutos, aproximadamente, por executar os servidores da blockchain (os nós) e validar as transações.

A cada 15 minutos, um minerador de Bitcoins recebe 12,5 BTC ($100 mil no momento em que este artigo foi escrito) para cobrir o custo de seus servidores + obter algum lucro.

A rede das Bitcoins consome tanta eletricidade quanto o país inteiro da Áustria. Ela é responsável por 0,29% do consumo anual de eletricidade mundial.

Anualmente, ela consome 76,84 TWh, produzindo 36,50 Mt de rastro de carbono de CO2 (Nova Zelândia). Fonte.

Por quê? Você aprenderá mais tarde onde você programará um algoritmo de mineração de Bitcoin a partir do zero!

Observação: nosso algoritmo consumirá um pouco menos de eletricidade🙂

Resumo:

O software, quando não é de código aberto, dá acesso centralizado aos dados privados, o que permite que apenas um punhado de pessoas tenha muito poder. Os usuários não têm escolha, e os acionistas estão no negócio para ganhar dinheiro.

Os desenvolvedores da blockchain visam desenvolver protocolos onde os empresários e usuários das aplicações se sinergizem em uma relação transparente e auditável. As especificações do sistema da blockchain devem ser bem definidas desde o início e só devem mudar se seus usuários o apoiarem.

A blockchain é um banco de dados. O fornecimento de tokens, os saldos iniciais de usuários e as configurações globais da blockchain são definidos em um arquivo Genesis. Os balanços Genesis indicam qual era o estado original da blockchain e nunca são atualizados posteriormente.

As mudanças de estado do banco de dados são chamadas Transações (TX). Transações são eventos à moda antiga que representam ações dentro do sistema.

⚒ Código de estudo

Commit: 642045

06 | O hash imutável

✍ git checkout c6_immutable_hash

A dificuldade técnica começa com esta seção! Os conceitos só vão ficar mais desafiadores mas, ao mesmo tempo, muito empolgantes. Apertem os cintos 😀

Como programar um banco de dados imutável?

Sexta-feira, 29 de março.

Se Andrej quer descobrir como programar um BD imutável, ele tem que entender porque outros sistemas de banco de dados são mutáveis por padrão.

Ele decide analisar uma tabela poderosa do BD do MySQL:

| id | nome     | saldo   |
| -- | -------- | ------- |
| 1  | Andrej   | 998951  |
| 2  | BabaYaga | 949     | 
| 3  | Caesar   | 1000    |

No BD MySQL, qualquer pessoa com acesso e uma razão suficientemente boa pode realizar uma atualização de tabela como, por exemplo:

UPDATE saldo_usuario SET saldo = saldo + 100 WHERE id > 1

A atualização de valores através de diferentes linhas é possível porque as linhas da tabela são independentes, mutáveis e o estado mais recente não é aparente.

Qual é a última mudança no BD? A última coluna mudou? Qual é a última linha inserida? Como Andrej pode saber qual linha foi apagada recentemente? Se as linhas e o estado da tabela estivessem firmemente unidos, dependentes, a atualização da linha 1 geraria uma tabela completamente nova e diferente. Andrej conseguiria sua imutabilidade.

Como você pode saber se algum byte em um banco de dados mudou?

Imutabilidade via funções de hash

Hashing é o processo de tomar uma string de entrada de comprimento arbitrário e produzir uma string de hash de comprimento fixo. Qualquer mudança na entrada, resultará em um hash novo e diferente.

package main

import (
	"crypto/sha256"
	"fmt"
)

func main() {
	saldosHash := sha256.Sum256([]byte("| 1 | Andrej | 99895 |"))
	fmt.Printf("%x\n", saldosHash)
	// Output: 6a04bd8e2...f70a3902374f21e089ae7cc3b200751
	
	// Mudar o saldo de 99895 -> 99896
	
	saldosHashDiff := sha256.Sum256([]byte("| 1 | Andrej | 99896 |"))
	fmt.Printf("%x\n", saldosHashDiff)
	// Saída: d04279207...ec6d280f6c7b3e2285758030292d5e1
}

Experimente: https://play.golang.org/p/FTPUa7IhOCE

Andrej também requer algum nível de segurança para seu banco de dados. Por isso, ele decide por uma função de hash criptográfico com as seguintes propriedades:

• é determinista – a mesma mensagem resulta sempre no mesmo hash
• é rápida para calcular o valor de hash para qualquer mensagem dada
• é inviável gerar uma mensagem a partir de seu valor hash, exceto tentando todas as mensagens possíveis
• uma pequena mudança em uma mensagem deve mudar o valor de hash tão extensivamente que o novo valor de hash pareça não estar relacionado com o antigo valor de hash
• é inviável (texto em inglês) encontrar duas mensagens diferentes com o mesmo valor de hash

Implementando o hashing do conteúdo do BD

Sábado à noite, 30 de março.

Andrej modifica a função Persist() para devolver um novo hash de conteúdo, Snapshot, toda vez que uma nova transação é persistida.

type Snapshot [32]byte

O Snapshot é produzido por esta nova função de hashing seguro sha256:

func (s *Estado) doSnapshot() error {
   // Lê novamente todo o arquivo desde o primeiro byte
   _, err := s.dbFile.Seek(0, 0)
   if err != nil {
      return err
   }

   txsData, err := ioutil.ReadAll(s.dbFile)
   if err != nil {
      return err
   }
   s.snapshot = sha256.Sum256(txsData)

   return nil
}

A função doSnapshot() é chamada pela função Persist() modificada. Quando uma nova transação é escrita no arquivo tx.db, Persist() faz o hash de todo o conteúdo do arquivo e retorna seu hash uma "impressão digital" de 32 bytes.

A partir deste momento, todos podem se referir com 100% de confiança e segurança a qualquer estado particular do banco de dados (conjunto de dados) com um hash específico.

⚓Hora da prática

1/4 Execute o comando da lista de saldos e verifique se os balanços estão de acordo.

✍ tbb saldos list

Saldos das contas em 7d4a360f465d...

| id | nome     | saldo   |
| -- | -------- | ------- |
| 1  | Andrej   | 999251  |
| 2  | BabaYaga | 949     | 
| 3  | Cesar    | 1000    |

2/4 Remova as 2 últimas filas de ./database/tx.db e verifique novamente os saldos.

✍ tbb saldos list

Saldos das contas 841770dcd3...

| id | nome     | saldo   |
| -- | -------- | ------- |
| 1  | Andrej   | 999051  |
| 2  | BabaYaga | 949     | 
| 3  | Cesar    | 1000    |

3/4 Recompense Andrej pelos últimos 2 dias (de 28 a 30 de março):

Transação de recompensa 1:

✍ tbb tx add --de=andrej --para=andrej --valor=100 --dado=recompensa

Persisting new TX to disk:
       {"de":"andrej","para":"andrej","valor":100,"dado":"recompensa"}
       
New DB Snapshot: ff2470c7043f5a34169b5dd38921ba6825b03b3facb83e426
TX persistida com sucesso no ledger.

Transação de recompensa 2:

✍ tbb tx add --de=andrej --para=andrej --valor=100 --dado=recompensa

Persisting new TX to disk:
       {"from":"andrej","to":"andrej","value":100,"data":"reward"}
       
New DB Snapshot: 7d4a360f468b837b662816bcdc52c1869f99327d53ab4a9ca
TX persistida com sucesso no ledger.

4/4 Execute o comando da lista de saldos de tbb e garanta que os balanços e o hash do snapshot sejam os mesmos do início.

✍ tbb saldos list

Saldos das contas em 7d4a360f465d...

| id | nome     | saldo   |
| -- | -------- | ------- |
| 1  | Andrej   | 999251  |
| 2  | BabaYaga | 949     | 
| 3  | Cesar    | 1000    |

Pronto!

Como a função criptográfica de hash sha256 produz a mesma saída (dadas as mesmas entradas, a tx.db atual e 2x tbb tx add), se você seguir os passos exatos em seu próprio computador, você gerará exatamente o mesmo estado e hashes do banco de dados!

Resumo:

O software fechado com acesso centralizado aos dados privados coloca apenas algumas poucas pessoas na posição de poder. Os usuários não têm escolha, e os acionistas estão no negócio para ganhar dinheiro.

Os desenvolvedores da blockchain visam desenvolver protocolos onde os empresários e usuários das aplicações se sinergizem em uma relação transparente e auditável. As especificações da blockchain devem ser bem definidas desde o início e só devem mudar se seus usuários o apoiarem.

A blockchain é um banco de dados imutável. O fornecimento de tokens, os saldos iniciais de usuários e as configurações globais da blockchain que você define em um arquivo Genesis. Os balanços Genesis indicam qual era o estado original da blockchain e nunca são atualizados depois.

As mudanças de estado do banco de dados são chamadas Transações (TX). Transações são eventos à moda antiga que representam ações dentro do sistema.

O conteúdo do banco de dados é passado por uma função de hash criptográfico segura. Os participantes da blockchain usam o hash resultante para referenciar um estado específico do banco de dados.

⚒ Código de estudo

Commit: b99e51

⭐Próximos passos

Você terminou os primeiros capítulos! Parabéns!

█▒▒▒▒▒▒▒▒▒ 10%

Este, porém, foi apenas um aquecimento rápido. A blockchain é uma tecnologia muito desafiadora e extensa. Você precisaria de um livro inteiro explicando como construir o sistema completo e todos os seus componentes a partir do zero. Por isso, escrevi um.

Você pode continuar lendo o próximo capítulo gratuito no eBook com minha versão da newsletter "The Blockchain Way of Programming".

07 | O Modelo de programação da blockchain

• Melhorando o desempenho de um BD imutável
• Batch + Hash + Lista vinculadas ⇒ Blocos
• Migrando de TX.db para BLOCKS.db

Aprendizagem: você redesenha e refatora seu banco de dados MVP e o transforma em uma arquitetura de blockchain.

Continuação do tutorial: https://web3.coach#book

Obrigado por leitura!

Se você é um desenvolvedor interessado no desenvolvimento de blockchains, deve saber algo sobre NFTs, ou tokens não fungíveis. Portanto, neste artigo, aprenderemos sobre a engenharia por trás deles para que você possa começar a construir o seu próprio blockchain.

No final do projeto, você terá sua própria carteira Ethereum, com um novo NFT dentro dela. Este tutorial é amigável para iniciantes e não requer nenhum conhecimento prévio da rede Ethereum ou de contratos inteligentes (em inglês, smart contracts).

O que é um NFT?

NFT significa token não fungível. Esta citação da ethereum.org explica bem:

NFTs são tokens que podemos usar para representar a propriedade de itens exclusivos. Eles nos permitem tokenizar coisas como arte, colecionáveis e até imóveis. Eles só podem ter um proprietário oficial de cada vez e são protegidos pelo blockchain Ethereum – ninguém pode modificar o registro de propriedade ou copiar/colar um novo NFT para fazê-lo existir.

O que é um NFT padrão ou ERC-721?

O ERC-721 é o padrão NFT mais comum. Se o seu contrato inteligente implementar determinados métodos de API padronizados, ele poderá ser chamado de contrato de token não fungível ERC-721.
Esses métodos são especificados no EIP-721. Projetos de código aberto, como o OpenZeppelin, simplificaram o processo de desenvolvimento ao implementar os padrões ERC mais comuns como uma biblioteca reutilizável.

O que é cunhar um NFT?

Ao cunhar um NFT, você publica um token exclusivo em um blockchain. Este token é uma instância do seu contrato inteligente.

Cada token tem um tokenURI exclusivo, que contém metadados de seu ativo em um arquivo JSON em conformidade com determinado esquema. Os metadados são onde você armazena informações sobre seu NFT, como nome, imagem, descrição e outros atributos.

Um exemplo de arquivo JSON para o "ERC721 Metadata Schema" se parece com este:

{
	"attributes": [
		{
			"trait_type": "Shape",
			"value": "Circle"
		},
		{
			"trait_type": "Mood",
			"value": "Sad"
		}
	],
	"description": "A sad circle.",
	"image": "https://i.imgur.com/Qkw9N0A.jpeg",
	"name": "Sad Circle"
}

Como armazeno os metadados do meu NFT?

Existem três maneiras principais de armazenar os metadados de um NFT.

Primeiro, você pode armazenar as informações on-chain (em cadeia). Em outras palavras, você pode estender seu ERC-721 e armazenar os metadados no blockchain, o que pode ser caro.

O segundo método é usar IPFS. A terceira maneira é simplesmente fazer com que sua API retorne o arquivo JSON.

O primeiro e o segundo métodos geralmente são os preferidos, pois você não pode modificar o arquivo JSON subjacente. Para o escopo deste projeto, optaremos pelo terceiro método.

Para um bom tutorial sobre como usar NFTs com IPFS, leia  este artigo da equipe Alchemy.

O que vamos construir

Neste tutorial, criaremos e cunharemos nosso próprio NFT. O tutorial é simples para iniciantes e não requer nenhum conhecimento prévio da rede Ethereum ou de contratos inteligentes. Ainda assim, ter uma boa compreensão desses conceitos ajudará você a entender o que está acontecendo nos bastidores.

Em um próximo tutorial, construiremos um aplicativo em React para a web totalmente funcional, onde você poderá exibir e vender seus NFTs.

Se você está apenas começando com o desenvolvimento de dApps, comece lendo os tópicos principais e assista a este curso incrível de Patrick Collins.

Este projeto foi escrito intencionalmente com código de fácil compreensão e não é adequado para uso em produção.

Pré-requisitos

Metamask

Precisamos de um endereço Ethereum para interagir com nosso contrato inteligente. Usaremos o Metamask como nossa carteira. É uma carteira virtual gratuita que gerencia seus endereços Ethereum. Vamos precisar dele para enviar e receber transações (leia mais sobre isso aqui). Por exemplo, cunhar um NFT é uma transação.

Faça o download da extensão do Chrome e do aplicativo para dispositivos móveis. Precisaremos de ambos, pois a extensão do Chrome não exibe seus NFTs.

Certifique-se de alterar a rede para "Ropsten Test Network" para fins de desenvolvimento. Você precisará de algum Eth para cobrir as taxas de implantação e cunhagem de seu NFT. Vá para o Ropsten Ethereum Faucet e digite seu endereço. Você logo deverá ver alguns Eth de teste em sua conta do Metamask.

Alchemy

Para interagir com a rede Ethereum, você precisará estar conectado a um Ethereum Node.

Executar seu próprio Node e manter a infraestrutura é um projeto à parte. Felizmente, existem provedores do tipo node-as-a-service que hospedam a infraestrutura para você. Existem muitas opções, como Infura, BlockDaemon e Moralis. Usaremos a Alchemy como nosso provedor de nodes.

Vá até o site deles, crie uma conta, escolha Ethereum como sua rede e crie seu aplicativo. Escolha Ropsten como sua rede.

No seu painel, clique em "ver detalhes" no seu aplicativo e, em seguida, clique em "ver chave". Salve sua chave http em algum lugar, pois precisaremos disso mais tarde.

NodeJS/NPM

Usaremos NodeJS para o projeto. Se você não o tiver instalado, siga este tutorial simples do freeCodeCamp (texto em inglês).

Inicialize o projeto

No seu terminal, execute este comando para criar um novo diretório para seu projeto:

mkdir nft-project
cd nft-project

Agora, vamos criar outro diretório, ethereum/, dentro de nft-project/ e inicializá-lo com o Hardhat. O Hardhat é uma ferramenta de desenvolvimento que facilita a implantação e o teste do seu software Ethereum.

mkdir ethereum
cd ethereum
npm init

Responda as perguntas como quiser. Em seguida, execute esses comandos para criar um projeto Hardhat:

npm install --save-dev hardhat
npx hardhat

Você verá este prompt:

888    888                      888 888               888
888    888                      888 888               888
888    888                      888 888               888
8888888888  8888b.  888d888 .d88888 88888b.   8888b.  888888
888    888     "88b 888P"  d88" 888 888 "88b     "88b 888
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.8

? What do you want to do? …
  Create a sample project
❯ Create an empty hardhat.config.js
  Quit

Selecione Create an empty hardhat.config.js. Isso gerará um arquivo vazio hardhat.config.js que atualizaremos posteriormente.

Para a aplicação da web, usaremos o Next.js para inicializar uma aplicação da web totalmente funcional. Volte para o diretório raiz nft-project/ e inicialize um boilerplate do Next.js app, chamado web:

cd ..
mkdir web
cd web
npx create-next-app@latest

Seu projeto, agora, tem esta aparência:

nft-project/
	ethereum/
	web/

Ótimo! Estamos prontos para entrar na parte da programação de verdade.

Como definir nossas variáveis .env

Você se lembra da chave de Alchemy que pegamos em nosso projeto de teste anterior? Nós a usaremos junto com as chaves públicas e privadas da nossa conta Metamask para interagir com o blockchain.

Execute os comandos a seguir, crie um arquivo chamado.env  dentro do seu diretório ethereum/, e instale o dotenv. Vamos usá-los mais tarde.

cd ..
cd ethereum
touch .env
npm install dotenv --save

Para o seu arquivo .env,  coloque a chave que você exportou do Alchemy e siga estas instruções para pegar a chave privada do seu Metamask.

Aqui está seu arquivo .env :

DEV_API_URL = YOUR_ALCHEMY_KEY
PRIVATE_KEY = YOUR_METAMASK_PRIVATE_KEY
PUBLIC_KEY = YOUR_METAMASK_ADDRESS

O Smart Contract para NFT

Na pasta ethereum/ crie mais dois diretórios: contracts e scripts. Um projeto hardhat simples contém essas pastas.

• contracts/ contém os arquivos de origem de seus contratos
• scripts/ contém os scripts para implantar e cunhar nossos NFTs

mkdir contracts
mkdir scripts

Então, instale o OpenZeppelin. O OpenZeppelin Contract é uma biblioteca de código aberto com código reutilizável pré-testado para facilitar o desenvolvimento dos Smart Contracts (contratos inteligentes).

npm install @openzeppelin/contracts

Por fim, escreveremos o Smart Contract para o nosso NFT. Navegue até o diretório de contratos e crie um arquivo intitulado EmotionalShapes.sol.  Você pode nomear seus NFTs como achar melhor.

A extensão .sol  refere-se à linguagem Solidity, que usaremos para programar nosso Smart Contract. Escreveremos apenas 14 linhas de código com o Solidity. Então, não se preocupe se você ainda não viu isso antes.
Comece com este artigo para saber mais sobre as linguagens de Smart Contract. Você também pode pular diretamente para esta ficha informativa do Solidity, que contém a sintaxe principal.

cd contracts
touch EmotionalShapes.sol

Este é o nosso Smart Contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

contract EmotionalShapes is ERC721 {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIdCounter;

    constructor() ERC721("EmotionalShapes", "ESS") {}

    function _baseURI() internal pure override returns (string memory) {
        return "YOUR_API_URL/api/erc721/";
    }

    function mint(address to)
        public returns (uint256)
    {
        require(_tokenIdCounter.current() < 3); 
        _tokenIdCounter.increment();
        _safeMint(to, _tokenIdCounter.current());

        return _tokenIdCounter.current();
    }
}

Vamos passar pelo código e entender o que está acontecendo.

1. Na parte superior do arquivo, especificamos qual módulo do OpenZeppelin importar. Precisamos do contrato ERC721, pois é a 'base' do nosso Smart Contract. Ele já implementou todos os métodos especificados no EIP-721 para que possamos usá-lo com segurança.
2. Um contador é útil para gerar ids incrementais para nossos NFTs. Nós nomeamos a variável _tokenIdCounter
3. No construtor, inicializamos nosso ERC721 com seu nome e seu símbolo. Eu escolhi EmotionalShapes e ESS.
4. Substituímos a função padrão baseURI, retornando a nossa. Vamos começar a construir isso logo após. Em resumo, é o URL que será adicionado como 'prefixo' a todos os nossos tokenURIs. No exemplo acima, os metadados de nossos NFTs ficarão em um arquivo JSON em URL_DA_SUA_API/api/erc721/1.  
5. Implementamos a função 'mint'. É a função que permite publicar uma instância desse Smart Contract no blockchain. Eu exigi que a variável _tokenIdCounter fosse menor que 3, pois criarei apenas três instâncias do meu NFT. Você pode remover isso se quiser cunhar mais.
6. Finalmente, dentro da função mint, incrementamos a variável _tokenIdCounter em 1. Então, nosso id será 1, seguido de 2, depois de 3. Então, chamamos a função fornecida pelo OpenZeppelin _safeMint para publicar o token.

Não se preocupe se você se sentir perdido. Você pode participar de um workshop liderado por voluntários do freeCodeCamp, onde convidamos desenvolvedores de níveis de habilidade semelhantes para construir coisas juntos, incluindo esse projeto de NFT.

Os eventos são gratuitos e remotos, então você pode tirar qualquer dúvida diretamente. Você pode se registrar aqui. As vagas são limitadas, então você será convidado para os próximos eventos disponíveis.

Como criar os metadados para nosso NFT

Como mencionado anteriormente, existem três maneiras principais de armazenar seu tokenURI. Construiremos um endpoint de API simples que resolve as informações do nosso NFT como JSON.

Nosso projeto do Next.js nos oferece uma maneira prática de desenvolver rotas de API. Vá para a pasta web/, encontre a pasta api/ dentro da pasta pages/  e faça nossa rota dinâmica [id].js em uma pasta erc721/  (leia mais sobre roteamento  aqui):

// web/pages/api/erc721/[id].js

const metadata = {
  1: {
    attributes: [
      {
        trait_type: "Shape",
        value: "Circle",
      },
      {
        trait_type: "Mood",
        value: "Sad",
      },
    ],
    description: "A sad circle.",
    image: "https://i.imgur.com/Qkw9N0A.jpeg",
    name: "Sad Circle",
  },
  2: {
    attributes: [
      {
        trait_type: "Shape",
        value: "Rectangle",
      },
      {
        trait_type: "Mood",
        value: "Angry",
      },
    ],
    description: "An angry rectangle.",
    image: "https://i.imgur.com/SMneO6k.jpeg",
    name: "Angry Rectangle",
  },
  3: {
    attributes: [
      {
        trait_type: "Shape",
        value: "Triangle",
      },
      {
        trait_type: "Mood",
        value: "Bored",
      },
    ],
    description: "An bored triangle.",
    image: "https://i.imgur.com/hMVRFoJ.jpeg",
    name: "Bored Triangle",
  },
};

export default function handler(req, res) {
  res.status(200).json(metadata[req.query.id] || {});
}

Para fins deste projeto, tornei o código o mais fácil de entender possível. Isso definitivamente não é adequado para produção (por favor, não use um URL do Imgur para o seu NFT). Certifique-se de definir os metadados para todos os NFTs que você pretende cunhar.

Agora, vá para o diretório da web e inicie seu aplicativo Next.js com este comando:

npm run dev

Sua aplicação deve ser executada no localhost:3000. Para garantir que nosso endpoint funcione, vá para http://localhost:3000/api/erc721/1 e ele deve ser resolvido com um objeto JSON dos metadados do seu primeiro NFT.

Como expor os metadados para nosso NFT

Como nossa aplicação está hospedada localmente, outras aplicações não podem acessá-la. Usando uma ferramenta como o ngrok, podemos expor nosso host local a um URL acessível publicamente.

1. Vá para ngrok.com e complete o processo de registro
2. Descompacte o pacote baixado
3. No seu terminal, certifique-se que você executou o comando cd na pasta que você descomprimiu seu pacote do ngrok
4. Siga as instruções do painel de controle e execute

./ngrok authtoken SEU_TOKEN_DE_AUTENTICACAO

5.  Então, execute este comando para criar um túnel para sua aplicação da web, hospedada em localhost:3000

./ngrok http 3000

6.  Você está quase lá! Em seu terminal, você deverá ver algo como isto:

ngrok by @inconshreveable                                                                            (Ctrl+C to quit)
                                                                                                                     
Session Status                online                                                                                 
Account                       YOUR_ACCOUNT (Plan: Free)                                                                       
Version                       2.3.40                                                                                 
Region                        United States (us)                                                                     
Web Interface                 http://127.0.0.1:4040                                                                  
Forwarding                    http://SEU_ENDERECO_DO_NGROK -> http://localhost:3000                             
Forwarding                    https://SEU_ENDERECO_DO_NGROK -> http://localhost:3000                             

Vá para  SEU_ENDERECO_DO_NGROK/api/erc721/1 para ter certeza que o endpoint funciona corretamente.

Como fazer o deploy de nosso NFT

Agora que fizemos todo o trabalho de base (ufa), vamos voltar para nossa pasta e  ethereum/ e nos preparar para implantar nosso  NFT.

Mude a função _baseURI no seu arquivo ethreum/contracts/NOME_DO_SEU_NFT.sol para retornar ao seu endereço do ngrok.

// ethereum/conrtacts/EmotionalShapes.sol

contract EmotionalShapes is ERC721 {
...
	function _baseURI() internal pure override returns (string memory) {
		return "https://SEU_ENDERECO_DO_NGROK/api/erc721/";
	}
...
}

Para fazer o deploy do nosso NFT, precisamos primeiro compilá-lo usando Hardhat. Para que o processo seja mais fácil, instalaremos o ethers.js.

npm install @nomiclabs/hardhat-ethers --save-dev

Vamos atualizar nosso hardhat.config.js:

require("dotenv").config();
require("@nomiclabs/hardhat-ethers");

module.exports = {
  solidity: "0.8.0",
  defaultNetwork: "ropsten",
  networks: {
    hardhat: {},
    ropsten: {
      url: process.env.DEV_API_URL,
      accounts: [`0x${process.env.PRIVATE_KEY}`],
    },
  },
};

Para saber mais sobre a configuração do arquivo hardhat dê uma olhada na sua  documentação. Configuramos a rede ropsten com nosso URL do Alchemy e fornecemos a chave privada de sua conta do metamask.

Finalmente, execute:

npx hardhat compile

Isto permite que o hardhat gere dois arquivos por contrato compilado. Devemos ver uma pasta recém-criada artifacts/, que contém seus contratos compilados na pasta contracts/. Para saber mais sobre como isso funciona, leia este tutorial da equipe do Hardhat.

Agora, vamos escrever um script para finalmente implantar nosso NFT na rede de teste. Na pasta scripts/ , crie um arquivo chamado deploy.js.

// ethereum/scripts/deploy.js

async function main() {
  const EmotionalShapes = await ethers.getContractFactory("EmotionalShapes");
  const emotionalShapes = await EmotionalShapes.deploy();

  console.log("EmotionalShapes deployed:", emotionalShapes.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

Este código é  inspirado pelo tutorial de deploy do hardhat.

Uma ContractFactory em ethers.js é uma abstração usada para implantar novos contratos inteligentes, então EmotionalShapes aqui é uma factory para instâncias do nosso contrato de token. Invocar deploy() na ContractFactory iniciará o deploy e retornará uma Promise que então é resolvida para Contract. Este é o objeto que possui um método para cada uma de suas funções de contrato inteligente.

Como visualizar o NFT no blockchain

Execute o script de deploy:

node ./scripts/deploy.js

Você deverá ver em seu terminal EmotionalShapes deployed: UM_ENDERECO. Este é o endereço onde seu Smart Contract está implantado na rede de teste ropsten.

Se você for para https://ropsten.etherscan.io/address/UM_ENDERECO, você deve ver seu NFT recém-implantado. Sim! Você conseguiu!

Se você estiver confuso em algum ponto do tutorial ou se sentindo perdido, novamente, pode participar de nossos workshops ao vivo, onde construiremos este projeto juntos em uma chamada de Zoom.

Como cunhar seu NFT

Agora que você fez o deploy do seu NFT, é hora de cunhá-lo para você! Crie um novo arquivo chamado mint.js na sua pasta scripts/.Usaremos o ethers.js para nos auxiliar.

Comece adicionando o pacote ethers.js :

npm install --save ethers

Em seguida, preencha o arquivo mint.js :

require("dotenv").config();
const { ethers } = require("ethers");

const contract = require("../artifacts/contracts/EmotionalShapes.sol/EmotionalShapes.json");
const contractInterface = contract.abi;

// https://docs.ethers.io/v5/api/providers
const provider = ethers.getDefaultProvider("ropsten", {
  alchemy: process.env.DEV_API_URL,
});

// https://docs.ethers.io/v5/api/signer/#Wallet
const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

//https://docs.ethers.io/v5/api/contract/contract
const emotionalShapes = new ethers.Contract(
  YOUR_NFT_ADDRESS,
  contractInterface,
  wallet
);

const main = () => {
  emotionalShapes
    .mint(process.env.PUBLIC_KEY)
    .then((transaction) => console.log(transaction))
    .catch((e) => console.log("something went wrong", e));
};

main();

Eu deixei comentários para onde você pode encontrar mais informações sobre os diferentes métodos. Primeiro, pegamos a interface do contrato (ABI). Na ethereum.org, vemos que:

Uma interface binária de aplicativo, ou ABI, é a maneira padrão de interagir com contratos no ecossistema Ethereum, tanto de fora do blockchain quanto para interações contrato a contrato.

Sua ABI define como os outros interagem com seu contrato. Então, criamos nosso provedor com Alchemy (lembre-se dos node-as-a-service). Por fim, inicializamos nossa carteira com nossa chave privada.

A função  main() executa o método mint no Smart Contract que acabamos de implementar. O método mint recebe apenas um parâmetro, to, que indica o receptor do token. Como estamos cunhando para nós mesmos, colocamos o endereço público da nossa conta Metamask.

Se tudo correr bem, você deverá ver a transação registrada em seu terminal. Pegue a propriedade hash vá para https://ropsten.etherscan.io/tx/SEU_HASH. Você deve ver a transação de cunhagem lá!

Como visualizar o NFT em sua carteira Metamask

Você precisa começar baixando a versão móvel do Metamask. Em seguida, faça login na sua conta.

Você deve ver uma guia de NFTs junto com um botão Add NFT. Clique no botão e insira o endereço do seu Smart Contract junto com os ids que você cunhou. Se você seguiu o tutorial, você deve começar com um id de 1.

Conclusão

Parabéns! Você acabou de cunhar seu próprio NFT. Na próxima parte do projeto, construiremos o aplicativo em React para o front-end que interaja com nosso contrato. O objetivo final é construir um aplicativo da web totalmente funcional onde você possa vender seus próprios NFTs.

Por fim, você pode  participar de nossos workshops ao vivo com voluntários do freeCodeCamp, onde construiremos este projeto junto com outros.

Os eventos são gratuitos para todos em qualquer lugar do mundo e os convites são enviados por ordem de chegada. Se você gostaria de liderar os workshops, envie uma mensagem no Twitter, adoraríamos contar com você! Também organizamos outros tipos de eventos como feiras de contratação e encontros sociais.

Gostaria de saber o que você quer criar. Os NFTs ainda estão em seus estágios iniciais e novas ideias são mais do que bem-vindas. Mal posso esperar para ver que ideia maluca você tem!

Neste artigo, eu vou mostrar para você como fazer um NFT sem nenhuma habilidade em engenharia de software. Depois, vamos aprender como fazer NFTs customizáveis ilimitados com o Brownie, Python e o Chainlink (todos os links em inglês). Então, veremos como renderizar e vender nossa criação no Marketplace de NFTs da OpenSea.

Se estiver procurando por um tutorial que use o Truffle, JavaScript e alguns personagens medievais legais, dê uma olhada em como Construir, Implantar e Vender seu NFT aqui (em inglês).

O que é um NFT?

NFTs (do inglês non-fungible tokens, ou  "tokens não fungíveis") podem ser resumidos em uma palavra: "únicos".  Eles são contratos inteligentes implantados em uma blockchain que representam algo único.

ERC20 x ERC721

NFTs são tokens padrão de blockchain, similares ao ERC20 (em inglês), como AAVE, SNC e LINK (tecnicamente, um ERC677). ERC20s são tokens "fungíveis" o que significa que são "substituíveis" ou "intercambiáveis".

Por exemplo, a nota de dez reais vai valer R$ 10,00, não importando qual nota você use, desde que ela seja uma nota de dez reais. O código na nota pode até ser diferente, mas as notas são intercambiáveis e elas vão valer dez reais independentemente de outras coisas.

NFTs, por outro lado, são "não fungíveis". Eles seguem seu próprio padrão de token, o ERC721. Por exemplo, a Mona Lisa é "não fungível". Mesmo que alguém faça uma cópia dela, sempre vai haver apenas uma Mona Lisa. Se a Mona Lisa tivesse sido criada em uma blockchain, ela seria um NFT.

Para que serve um NFT?

NFTs agregam valor para os criadores, artistas, designers de jogos e outros por terem um histórico permanente de implantação armazenado on-chain.

Você sempre saberá quem criou o NFT, quem o comprou, de onde ele veio e mais, o que dá a eles muito valor, mais do que arte tradicional. Na arte tradicional, pode ser bem difícil discernir o que é falso, enquanto um histórico on-chain é facilmente rastreável.

Como os contratos inteligentes e os NFTs são 100% programáveis, NFTs podem também ter royalties e qualquer outra funcionalidade embutida. Recompensar os artistas sempre foi um problema, dado que um trabalho artístico geralmente é apresentado sem nenhuma atribuição, como ouvir uma música no parque.

Mais e mais artistas e engenheiros estão aproveitando desse valor agregado, porque finalmente é uma boa maneira de recompensar os artistas por seu trabalho. Mais que isso, os NFTs são maneiras divertidas de botar para quebrar com sua criatividade e se tornar um colecionador em um mundo digital.

O valor dos NFTs

Os NFTs percorreram um longo caminho e continuamos vendo recordes de vendas de NFTs, como "Everydays: The First 5.000 Days" sendo vendido por US$ 69,3 milhões.

Então, existe um grande valor aqui, além de ser divertido, dinâmico e uma forma engajadora de criar arte em um mundo digital e aprender sobre criação de um contrato inteligente. Agora, eu vou ensinar a você tudo o que precisa saber sobre criar NFTs.

Como criar um NFT

O que não vamos ensinar

A maneira mais fácil de fazer um NFT é ir a uma plataforma, como a Opensea, a Rarible ou a Mintible, e seguir o seu passo a passo para a implantação na plataforma escolhida.

Você pode seguir por esse caminho. No entanto, você pode acabar ligado à plataforma de alguma forma e ficará preso na funcionalidade que a plataforma tiver. Desse modo, você não poderá alcançar a personalização ilimitada nem utilizar realmente qualquer uma das vantagens que os NFTs têm. Mas se você for um engenheiro de software principiante, ou se não for muito técnico, esse caminho servirá para você.

Se você procura se tornar um engenheiro de software melhor, aprender um pouco sobre Solidity e ter o poder de criar algo com criatividade ilimitada, siga com a leitura!

Se você é novo com Solidity, não se preocupe. Também passaremos pelo básico.

Como criar um NFT com customização Ilimitada

Vamos começar com o NFT Brownie Mix. Esse é um repositório em desenvolvimento com muito código boilerplate.

Pré-requisitos

Precisaremos de alguns programas instalados antes de começar

• Python
• Nodejs e npm
• Metamask

Se você não está familiarizado com o Metamask, você pode seguir esse tutorial (em inglês) para configurá-lo.

Rinkeby Testnet ETH e LINK

Estaremos trabalhando também com o Rinkeby Ethereum Testnet para realizar a implantação dos nossos contratos em uma blockchain real, de graça!

Testnets são formas excelentes de testar como os contratos se comportam no mundo real.

Precisaremos do Rinkeby ETH e do Rinkeby LINK, que conseguimos gratuitamente nos links da documentação do Chainlink (em inglês)

Também precisaremos adicionar o token do Rinkeby LINK na nossa metamask, o que podemos fazer seguindo a documentação de como conseguir o LINK (em inglês).

Se você continuar confuso, você pode usar este vídeo como guia (em inglês), apenas certifique-se de usar o Rinkerby ao invés do Ropsten.

Quando trabalhamos com uma plataforma de contratos inteligentes, como a Ethereum, precisamos pagar um pouco de ETH. Quando retiramos dados off-chain precisamos pagar com um pouco de LINK. Por este motivo, nós precisamos dos testnets Link e ETH.

Maravilha, agora vamos mergulhar. Este é o NFT que vamos implantar na OpenSea.

Começando

git clone https://github.com/PatrickAlphaC/nft-mix
cd nft-mix

Ótimo! Agora, precisamos instalar o ganache-cli e o eth-brownie.

pip install eth-brownie
npm install -g ganache-cli

Então, podemos configurar nossas variáveis de ambiente (em inglês). Se você não é familiarizado com variáveis de ambiente, pode apenas adicioná-las no seu arquivo .env e executar:

source .env

Deve existir um arquivo .env no repositório que você acabou de clonar com as variáveis de ambiente comentadas. Retire-as dos comentários para usá-las!

Você vai precisar de um WEB3_INFURA_PROJECT_ID e de uma PRIVATE_KEY. O WEB3_INFURA_PROJECT_ID pode ser encontrado ao se cadastrar com uma conta gratuita no Infura. Assim, teremos uma maneira de enviar as transações para a blockchain.

Também vamos precisar de uma private key, que você consegue pegar em sua Metamask. Clique nos 3 pontinhos, vá em Account Details e depois em Export Private Key. NÃO compartilhe essa chave com ninguém se você colocar dinheiro de verdade nela!

export PRIVATE_KEY=YOUR_KEY_HERE
export WEB3_INFURA_PROJECT_ID=YOUR_PROJECT_ID_HERE

Agora, podemos implantar nosso contrato NFT e criar nosso primeiro colecionável com os dois comandos a seguir.

brownie run scripts/simple_collectible/deploy_simple.py --network rinkeby
brownie run scripts/simple_collectible/create_collectible.py --network rinkeby

O primeiro script implanta nosso contrato NFT na blockchain da Rinkerby, e o segundo cria nosso colecionável.

Você acabou de implantar seu primeiro contrato inteligente!

Por enquanto, ele não faz muita coisa, mas não se preocupe – vou mostrar para você como renderizá-lo na OpenSea na parte avançada desse tutorial. Mas, antes, vamos olhar para o padrão de token ERC721.

O padrão de token ERC721

Vamos dar uma olhada no contrato que acabamos de implantar no arquivo SimpleCollectible.sol.

// SPDX-License-Identifier: MIT
pragma solidity 0.6.6;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract SimpleCollectible is ERC721 {
    uint256 public tokenCounter;
    constructor () public ERC721 ("Dogie", "DOG"){
        tokenCounter = 0;
    }

    function createCollectible(string memory tokenURI) public returns (uint256) {
        uint256 newItemId = tokenCounter;
        _safeMint(msg.sender, newItemId);
        _setTokenURI(newItemId, tokenURI);
        tokenCounter = tokenCounter + 1;
        return newItemId;
    }

}

Estamos usando o pacote OpenZeppelin (em inglês) para o token ERC721. Esse pacote que importamos nos permite usar todas as funções típicas de um token ERC721. Isso define todas as funcionalidades que nossos tokens vão ter, como transfer, que move tokens para novos usuários, safeMint que cria novos tokens e mais.

Você pode encontrar todas as funções que são fornecidas ao nosso contrato lendo o Contrato de Token ERC721 OpenZeppelin. Nosso contrato herda essas funções nessa linha:

contract SimpleCollectible is ERC721 {

É assim que a Solidity trabalha com herança. Quando nós implantamos um contrato, o constructor é automaticamente chamado e recebe alguns parâmetros.

constructor () public ERC721 ("Dogie", "DOG"){
        tokenCounter = 0;
    }

Também usamos o construtor do ERC721 no nosso construtor. Temos que dar a ele um nome e um símbolo. No nosso caso, é "Dogie"e "DOG". Isso significa que todos os NFTS criados serão do tipo Dogie/DOG.

É como todos os Pokémons nas cartas de pokémons. Eles no final são pokémons, ou todo jogador de baseball nas cartas colecionáveis (trading cards) continuam jogadores de baseball. Cada jogador é único, mas eles continuam sendo jogadores de baseball. Nós estamos apenas usando o tipo DOG.

Nós temos um tokenCounter no topo que conta quantos NFTs já criamos daquele tipo. Cada novo token ganha um tokenId baseado no tokenCounter atual.

Atualmente, nós podemos criar um NFT com a função createCollectible. É ela que chamamos no nosso script create_collectible.py.

function createCollectible(string memory tokenURI) public returns (uint256) {
        uint256 newItemId = tokenCounter;
        _safeMint(msg.sender, newItemId);
        _setTokenURI(newItemId, tokenURI);
        tokenCounter = tokenCounter + 1;
        return newItemId;
    }

A função _safeMint cria o novo NFT e o atribui a quem chamou createdCollectible, também conhecido comomsg.sender, com um newItemId derivado de tokenCounter. É assim que podemos acompanhar quem é proprietário de quê, verificando o proprietário do tokenId.

Você vai perceber que também chamamos a função _setTokenURI. Vamos conversar sobre ela.

O que são metadados de NFT e tokenURI?

Quando os contratos inteligentes estavam sendo criados e os NFTs estavam sendo criados, as pessoas rapidamente perceberam que é beeeeeem caro implantar muitos dados na blockchain. Imagens pequenas de um KB podem facilmente custar mais de 1 milhão de dólares para guardar (em inglês).

Isso é claramente um problema para os NFTs, já que, ao ser o proprietário de arte criativa, você tem que guardar essa informação em algum lugar. Eles também queriam uma maneira mais leve de guardar os atributos sobre NFTs – e é aqui que  os metadados e o tokenURI entram em ação.

TokenURI

O tokenURI em um NFT é um identificador único da "aparência" daquele token. Um URI pode ser uma chamada HTTPS para uma API, um hash IPFS, ou qualquer outra coisa exclusiva.

Eles seguem um padrão de mostrar os metadados que têm essa aparência:

{
    "name": "name",
    "description": "description",
    "image": "https://ipfs.io/ipfs/QmTgqnhFBMkfT9s8PHKcdXBn1f5bG3Q5hmBaR4U6hoTvb1?filename=Chainlink_Elf.png",
    "attributes": [
        {
            "trait_type": "trait",
            "value": 100
        }
    ]
}

Eles mostram como um NFT é e seus atributos. O atributo image aponta para outro URI da aparência do NFT. Isso facilita para as plataformas de NFT como a Opensea, Rarible e Mintable renderizar NFTs nas suas plataformas, já que todos estão esperando receber esses metadados.

Metadados off-chain x metadados on-chain

Agora, você pode estar pensando "Peraí... se os metadados não estão on-chain, significa que o meu NFT pode sumir em algum momento"? E você não poderia estar mais correto.

Você também estaria correto em pensar que metadados off-chain significam que você não pode usá-los para que seus contratos inteligentes interajam um com o outro.

Esse é o motivo pelo qual nós queremos focar nos metadados on-chain, para que assim possamos programar nossos NFTs para interagir uns com os outros.

No entanto, ainda precisamos da parte da imagem (image) dos metadados off-chain, pois não temos uma maneira otimizada de armazenar imagens grandes on-chain. Mas não se preocupe. Podemos fazer isso gratuitamente em uma rede descentralizada ainda usando IPFS.

Aqui está um exemplo de um imageURI do IPFS que mostra o Chainlink Elf criado no tutorial Dungeons and Dragons (em inglês).

Não definimos um tokenURI para o NFT simplesmente porque queríamos apenas mostrar um exemplo básico.
Vamos pular para o NFT avançado agora, para que possamos ver alguns dos recursos incríveis que podemos fazer com metadados on-chain, para que o NFT seja renderizado na Opensea, e colocar nosso Dogie no ar!

Se você quiser um vídeo para refrescar sua memória sobre o que acabamos de ver na seção anterior, acompanhe esse vídeo sobre a implantação de um NFT simples.

NFTs dinâmicos e avançados

NFTs dinâmicos são NFTs que podem mudar com o tempo ou ter funcionalidades on-chain que podem ser usadas para interagir umas com as outras. Esses são as NFTs que tem customizações ilimitadas. Assim, podemos criar jogos inteiros, mundos ou algum tipo de arte interativa.
Vamos nos aprofundar na parte avançada desse tutorial.

Início rápido avançado

Certifique-se de ter as testnets ETH e LINK, bem como o suficiente na sua metamask, e então execute o comando a seguir:

brownie run scripts/advanced_collectible/deploy_advanced.py --network rinkeby
brownie run scripts/advanced_collectible/create_collectible.py --network rinkeby

Nosso collectible aqui é uma reprodução de raças de cachorros aleatória retornada do Chainlink VRF (em inglês). Chainlink VRF é uma maneira de obter números aleatórios comprováveis e, portanto, realmente em falta em nossos NFTs. Em seguida, vamos criar seus metadados.

brownie run scripts/advanced_collectible/create_metadata.py --network rinkeby

Podemos, então, como opção, fazer upload desses dados para o IPFS para que possamos ter um tokenURI. Eu vou mostrar para você como fazer isso mais tarde. Por enquanto, vamos usar apenas o tokenURI de exemplo de:

https://ipfs.io/ipfs/Qmd9MCGtdVz2miNumBHDbvj8bigSgTwnr4SbyH6DNnpWdt?filename=1-PUG.json

Se você fizer o download do IPFS Companion no seu navegador, poderá usar aquele URL para ver o que o URI retorna. Ficará parecido com isso:

{
    "name": "PUG",
    "description": "An adorable PUG pup!",
    "image": "https://ipfs.io/ipfs/QmSsYRx3LpDAb1GZQm7zZ1AuHZjfbPkD6J7s9r41xu1mf8?filename=pug.png",
    "attributes": [
        {
            "trait_type": "cuteness",
            "value": 100
        }
    ]
}

Então, podemos executar nosso script set_tokenuri.py:

brownie run scripts/advanced_collectible/set_tokenuri.py --network rinkeby

Teremos, então, uma saída como esta:

Running 'scripts/advanced_collectible/set_tokenuri.py::main'...
Working on rinkeby
Transaction sent: 0x8a83a446c306d6255952880c0ca35fa420248a84ba7484c3798d8bbad421f88e
  Gas price: 1.0 gwei   Gas limit: 44601   Nonce: 354
  AdvancedCollectible.setTokenURI confirmed - Block: 8331653   Gas used: 40547 (90.91%)

Awesome! You can view your NFT at https://testnets.opensea.io/assets/0x679c5f9adC630663a6e63Fa27153B215fe021b34/0
Please give up to 20 minutes, and hit the "refresh metadata" button

E podemos clicar no link que nos foi dado para ver como ficou no Opensea! Talvez você tenha que clicar no botão refresh metadata e esperar alguns minutos.

As raças aleatórias

Vamos falar sobre o que acabamos de fazer. Aqui está nossa AdvancedCollectible.sol:

pragma solidity 0.6.6;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@chainlink/contracts/src/v0.6/VRFConsumerBase.sol";

contract AdvancedCollectible is ERC721, VRFConsumerBase {
    uint256 public tokenCounter;
    enum Breed{PUG, SHIBA_INU, BRENARD}
    // add other things
    mapping(bytes32 => address) public requestIdToSender;
    mapping(bytes32 => string) public requestIdToTokenURI;
    mapping(uint256 => Breed) public tokenIdToBreed;
    mapping(bytes32 => uint256) public requestIdToTokenId;
    event requestedCollectible(bytes32 indexed requestId); 


    bytes32 internal keyHash;
    uint256 internal fee;
    uint256 public randomResult;
    constructor(address _VRFCoordinator, address _LinkToken, bytes32 _keyhash)
    public 
    VRFConsumerBase(_VRFCoordinator, _LinkToken)
    ERC721("Dogie", "DOG")
    {
        tokenCounter = 0;
        keyHash = _keyhash;
        fee = 0.1 * 10 ** 18;
    }

    function createCollectible(string memory tokenURI, uint256 userProvidedSeed) 
        public returns (bytes32){
            bytes32 requestId = requestRandomness(keyHash, fee, userProvidedSeed);
            requestIdToSender[requestId] = msg.sender;
            requestIdToTokenURI[requestId] = tokenURI;
            emit requestedCollectible(requestId);
    }

    function fulfillRandomness(bytes32 requestId, uint256 randomNumber) internal override {
        address dogOwner = requestIdToSender[requestId];
        string memory tokenURI = requestIdToTokenURI[requestId];
        uint256 newItemId = tokenCounter;
        _safeMint(dogOwner, newItemId);
        _setTokenURI(newItemId, tokenURI);
        Breed breed = Breed(randomNumber % 3); 
        tokenIdToBreed[newItemId] = breed;
        requestIdToTokenId[requestId] = newItemId;
        tokenCounter = tokenCounter + 1;
    }

    function setTokenURI(uint256 tokenId, string memory _tokenURI) public {
        require(
            _isApprovedOrOwner(_msgSender(), tokenId),
            "ERC721: transfer caller is not owner nor approved"
        );
        _setTokenURI(tokenId, _tokenURI);
    }
}

Usamos o Chainlink VRF para criar uma raça aleatória de uma lista de PUG, SHIBA_INU, BERNARD. Quando chamamos a createCollectible desta vez, na verdade ,iniciamos uma solicitação para o nó Chainlink VRF off-chain e retornamos com um número aleatório para criar o NFT com uma dessas 3 raças.

Usar aleatoriedade verdadeira em seus NFTs é uma ótima maneira de criar escassez verdadeira e usar um número aleatório do oráculo Chainlink significa que seu número é comprovadamente aleatório, não podendo ser influenciado pelos mineradores.

Você pode aprender mais sobre isso na documentação do Chainlink VRF(em inglês).

O nó Chainlink responde chamando a função fulfillRandomness e cria o collectible com base no número aleatório. Ainda temos que chamar _setTokenURI para dar ao nosso NFT a aparência que ele precisa.

Nós não demos nossos atributos do NFT aqui, mas os atributos são uma ótima maneira de fazer com que nossos NFTs batalhem e interajam. Você pode ver um ótimo exemplo de NFTs com atributos neste exemplo de Dungeons and Dragons (em inglês).

Metadados do IPFS

Estamos usando o IPFS para guardar dois arquivos:

1. A imagem do NFT (a imagem do pug)
2. O arquivo tokenURI (o arquivo JSON que também inclui o link da imagem)

Nós usamos o IPFS por ser uma plataforma grátis e descentralizada. Também podemos adicionar nossos tokenURIs e imagens no IPFS fazendo download do IPFS desktop (em inglês), clicando no botão import.

Agora, podemos compartilhar o URI clicando nos três pontos ao lado do arquivo que queremos compartilhar, clicando em share link e copiando o link fornecido. Podemos adicionar esse link no nosso arquivo set_tokenuri.py para mudar o URI do token que queremos usar.

Persistência

No entanto, se o tokenURI estiver apenas em nosso node, isso significa que, quando nosso node estiver inativo, ninguém mais poderá visualizá-lo. Então, queremos que outros façam o pin do nosso NFT. Podemos usar um serviço que realiza o pin como o Pinata para ajudar a manter nossos dados ativos mesmo quando nosso node no IPFS estiver inativo.

Imagino que, no futuro, mais e mais metadados serão armazenados em IPFS e plataformas de armazenamento serão descentralizadas. Servidores centralizados podem ficar inativos, e isso significaria que a arte dos NFTs nesses servidores seria perdida para sempre. Certifique-se de verificar onde está localizado o tokenURI do NFT que você usa!
Também espero que mais pessoas usem plataformas dStorage como Filecoin, pois usar um serviço de pinning também não é tão descentralizado quanto deveria ser.

Indo além

Se você quiser ver um passo a passo em vídeo do NFT avançado que acabamos de fazer, assista ao vídeo sobre NFT avançado.

Agora, você tem as habilidades para criar NFTs lindos, divertidos, personalizados e interativos e renderizá-los em um marketplace.

NFTs são maneiras divertidas e poderosas de compensar os artistas com precisão por todo o trabalho duro que eles fazem. Boa sorte e lembre-se de se divertir!