De A a Z Sobre o Consenso na Blockchain

Sumário

1 . O que é consenso e por que isso importa?
‎ ‎ ‎ ‎ 1.1 Em que concordamos?
‎ ‎ ‎ ‎ 1.2 Como chegamos a um acordo?
2 . Proposta de bloco
3 . Acordos de Bloco
4 . Consenso de Nakamoto
5 . Consenso Clássico
6 . Qual Algoritmo De Consenso Eu Preciso?
‎ ‎ ‎ ‎ 6.1 Quão importante é a finalização?
‎ ‎ ‎ ‎ 6.2 Quão rápido seu aplicativo precisa ser?
‎ ‎ ‎ ‎ 6.3 Quão “descentralizado” você precisa que seu aplicativo seja?
‎ ‎ ‎ ‎ 6.4 Tudo bem se o sistema parar?
7 . Conclusão

Coautoria de Julian Koh e Cheryl Sew Hoy

O consenso na Blockchain foi um dos subcampos sobre blockchains mais discutidos ao longo de 2017 e 2018. Vimos várias empresas tentando competir com a Ethereum construindo novas plataformas de contratos inteligentes do zero, onde o principal diferenciador/inovação era o algoritmo de consenso subjacente a essas blockchains.
Tentar entender esses algoritmos e ser capaz de compará-los criticamente foi um trabalho em tempo integral para muitos investidores em criptomoedas - eles não são de forma alguma simples de entender. Tem havido muitos esforços para desmistificar esses “algoritmos de consenso” mágicos, mas muitos deles ainda acabam sendo técnicos demais para a maioria das pessoas. Alguns conceitos como sincronia, segurança/ provas de vivacidade e resultados de impossibilidade são fundamentais para ver o quadro completo, mas, na minha opinião, não são particularmente importantes para a maioria das pessoas entender completamente. Esta postagem do blog se concentrará diretamente em algoritmos de consenso no mundo blockchain, sem muita menção ao campo maior (e supercomplexo!) de Sistemas Distribuídos. Haverá também alguns acenos de mãos sobre conceitos técnicos por uma questão de simplicidade e compreensão.

Ao final deste post, você será capaz de entender as diferenças entre Proof-of-Work e Proof-of-Stake, o que significa “BFT” e, mais importante, quais são os principais trade-offs ao considerar qual blockchain escolher para construir uma aplicação em cima dela.

O que é consenso e por que isso importa?

Uma blockchain é, simplesmente, um banco de dados público onde os usuários concordam com o que é correto. Bitcoin é um banco de dados público de todas as transações que já aconteceram, preservando a integridade do sistema monetário. Há duas perguntas principais que precisamos fazer para entender como isso funciona:

1. Em que concordamos?
2. Como chegamos a um acordo?

A gente precisa que alguém proponha alguma coisa, aí tem um jeito para todo mundo escolher até que haja algum tipo de acordo. No caso de blockchains, precisamos que alguém proponha um bloco, e precisamos que os demais nós aceitem esse bloco.

Um exemplo simples disso seria o seguinte:

4 amigos tentam agendar um horário mútuo para colocar o papo em dia

Quatro pessoas tentam agendar um horário mútuo para conversar. Cada pessoa propõe seus horários disponíveis (espaços brancos vazios). Como podemos ver, existem 2 espaços mutuamente disponíveis: 14h e 18h.

Como eles chegam a um acordo? Antes de proporem seus horários disponíveis, eles podem concordar com uma regra específica - todos devem escolher o horário mais próximo disponível mutuamente. Nesse caso, isso significa que todos se reunirão às 14h em vez das 18h —- então eles chegaram a um consenso.

Usando essa estrutura, podemos estender esta analogia à blockchain do Bitcoin:

1. Em que concordamos?

   Concordamos com blocos de dados, que contêm transações Bitcoin válidas. No Bitcoin, qualquer pessoa pode propor blocos, desde que primeiro resolva um quebra-cabeça computacional difícil (Proof-of-Work).

2. Como chegamos a um acordo?

   Concordamos em aceitar blocos que estendem a cadeia mais longa. Por exemplo, se houver cadeia A de comprimento 100 e cadeia B de comprimento 200, se você receber um bloco 101 na cadeia A e um bloco 201 na cadeia B, você deve aceitar o bloco 201. Algumas pessoas podem propor um bloco em uma cadeia mais curta porque eles não estão cientes da cadeia mais longa, mas a “regra da cadeia mais longa” garante que todos eventualmente concordem com a mesma coisa quando os blocos forem propagados por toda a rede.

Essa estrutura sustenta todos os algoritmos de consenso. Alguns algoritmos podem usar uma maneira diferente de propor blocos, e alguns algoritmos podem usar uma maneira diferente de concordar com os blocos.

Proposta de bloco

A maior questão que precisamos pensar em relação à proposta de bloco é quem pode propor blocos. Se alguém puder propor um bloco a qualquer momento, será difícil chegar a um acordo porque é como se as pessoas estivessem conversando a um só tempo, sem parar. Tem que haver alguma maneira de selecionar as pessoas de forma que todos possam ouvir uma proposta de cada vez. A maneira mais ingênua de fazer isso é fazer com que o protocolo selecione aleatoriamente uma pessoa para cada novo bloco. No entanto, na internet, uma pessoa pode fingir ser cem pessoas executando cem instâncias do mesmo programa. Portanto, precisamos criar alguma forma de escassez (“Resistência Sybil”), para que o jogo não possa ser manipulado por um único hacker disfarçado de cem pessoas. Isso é exatamente o que Proof-of-Work e Proof-of-Stake oferecem a você —- uma maneira de os computadores serem limitados por algum recurso.

Proof-of-Work se comporta da seguinte forma: para obter o direito de propor um bloco, você deve primeiro concluir uma tarefa computacionalmente intensiva. Uma situação análoga seria fazer um computador jogar uma moeda virtual até obter cara 100 vezes seguidas. Isso é computacionalmente intensivo e não há como alguém se disfarçar de cem pessoas, porque ele é fisicamente limitado pela quantidade de energia que seu computador possui.

No entanto, ao empregar esse mecanismo de “Resistência Sybil”, as pessoas criaram fazendas de servidores com milhares de computadores para que possam superar a concorrência e obter o direito de propor blocos. Essas fazendas de servidores custam uma quantidade exorbitante de eletricidade, portanto, estão geograficamente concentradas em países ou zonas que têm o acesso mais barato à eletricidade. Então, o que significa para a descentralização quando a maioria dos mineradores de Bitcoin estão baseados na China? Essa centralização geográfica representa uma ameaça real à longevidade do sistema, pois o governo chinês poderia facilmente regulamentar essas mineradoras.

Fazenda de Mineração de Bitcoin

Por outro lado, o Proof-of-Stake usa um mecanismo radicalmente diferente de “Resistência Sybil”. Já que custa dinheiro comprar esses computadores de mineração de Bitcoin e custa dinheiro para alimentá-los, por que não usamos o dinheiro como uma forma de selecionar os proponentes de blocos e pular todo esse processo computacional intensivo? Proof-of-Stake é a ideia de selecionar os proponentes de blocos com base em quanto dinheiro eles têm no sistema —- ou na proporção de moedas que possuem no sistema. No Proof-of-Work, quanto mais computadores você tiver, maiores serão suas chances de ser selecionado para propor o próximo bloco. No Proof-of-Stake, quanto mais moedas você possuir, maiores serão suas chances.

Observe que não falamos sobre nenhum acordo sobre blocos. Há um equívoco comum de que Proof-of-Work e Proof-of-Stake são algoritmos de consenso. Eles não são. Eles são apenas maneiras de selecionar proponentes de blocos, restringindo algum recurso escasso.

Acordos de Bloco

É aqui que as coisas ficam interessantes e a maior parte da inovação aconteceu nos últimos anos. Depois que alguém propõe um bloco, como chegamos a um acordo? Esta tem sido uma questão que os cientistas da computação vêm tentando resolver desde os anos 80 para construir clusters de computadores que podem sincronizar mesmo se alguns travarem ocasionalmente. Nos anos 90, esses cientistas da computação começaram a pensar em um problema ainda mais difícil —– e se um hacker pudesse controlar alguns desses computadores? Eles foram capazes de construir sistemas robustos o suficiente para garantir que todos os computadores não corrompidos ainda pudessem chegar a um acordo? Esta propriedade foi apelidada de “Byzantine Fault Tolerance” (BFT), baseada no problema chamado de Problema dos Generais Bizantinos. Os sistemas BFT eram um tópico de estudo de nicho porque a maioria dos sistemas não precisava desse nível de robustez, uma vez que o cluster de computadores geralmente pertencia a uma única corporação. Até a chegada das blockchains.

Em blockchains, qualquer pessoa pode rodar um nó (um computador no cluster) e enviar mensagens ou dados para outros nós. Este é um ambiente realmente contraditório, já que atores mal-intencionados podem fingir ser honestos. Por exemplo, e se um computador corrompido em um cluster de 10 estivesse enviando aos outros 9 computadores informações conflitantes?

Computador malicioso envia informações conflitantes para diferentes computadores honestos

Como bons computadores não são capazes de diferenciar o bom do ruim, esse problema se torna extremamente difícil de resolver. Houve 2 grandes famílias de abordagens para resolver este problema, Consenso de Nakamoto e Consenso Clássico.

Consenso de Nakamoto

O Consenso Nakamoto é o que é usado no Bitcoin e na maioria dos sistemas Proof-of-Work, iniciado por Satoshi Nakamoto. É a regra única: “quando você vir uma proposta de bloco com mais proof-of-work, aceite-a”. Normalmente, o bloco com o número de bloco mais alto terá a maior prova de trabalho feita nele.

O que isso significa é que você nunca tem 100% de certeza se um bloco que vê é “correto”. Por exemplo, o bloco mais alto que você viu é o bloco 99. Você pode receber um bloco A na altura 100, então você o aceita.

De repente, você recebe um bloco B na altura 103 que possui um bloco diferente na altura 100. Pelas regras de consenso, você precisará “reverter” o bloco A que você aceitava anteriormente, e agora aceitar esse novo histórico de blocos.

Nesse sistema, um atacante que tenha mais de 50% do poder de computação geral do sistema será capaz de construir consistentemente a cadeia mais longa e, portanto, pode criar quaisquer blocos que desejar. Através deste exemplo, podemos ver que essas regras ajudam a alinhar as pessoas para que cheguem a um acordo sobre qual cadeia é a aceita.

Consenso Clássico

Antes do Consenso de Nakamoto ser inventado em 2009, os cientistas da computação tinham uma solução diferente para esse problema, que possui um conjunto diferente de propriedades. O primeiro algoritmo de consenso tolerante a falhas bizantinas foi um algoritmo chamado Tolerância prática a falhas bizantinas (eu sei, que nome). Ele funciona com um conjunto de participantes fazendo várias rodadas de votação até que alguma porcentagem dos eleitores chegue a um acordo.

Alguém é selecionado para propor um bloco, com base em algo como Proof-of-Stake. Ele envia o bloco para os outros participantes conhecidos. Os outros participantes votam.

Como a maioria dos participantes vota sim naquele bloco, todos no sistema aceitarão esse bloco como correto. O uso desse tipo de consenso requer um conjunto conhecido de eleitores, mas uma vez que eles votem para aprovar o bloco, o bloco se torna final. Portanto, não existe a reversão de blocos. Se houver desacordos, o sistema pára.

Este algoritmo PBFT foi adaptado para funcionar com blockchains, sendo o algoritmo BFT mais proeminente para blockchains o Tendermint Core. O Tendermint Core foi o primeiro algoritmo de consenso em blockchains que não usou o Consenso de Nakamoto, mas foi construído com base em mais de 20 anos de pesquisa em ciência da computação. A principal limitação dos algoritmos BFT é que eles geralmente são restritos a um grupo bastante pequeno de eleitores, uma vez que todos os eleitores precisam ser conhecidos de antemão. Torna-se extremamente difícil ter 100.000 pessoas constantemente se comunicando umas com as outras para chegar a um acordo. A Cosmos rodou o que provavelmente é o maior sistema público de BFT até agora em sua rede de teste Game of Stakes com mais de 200 validadores participando.

Existem outras variantes do Consenso de Nakamoto, como GHOST (novo algoritmo de pontuação, não apenas cadeia mais longa), e também existem outras variantes do consenso BFT, como Casper-BFT e Thunderella. Esses algoritmos de consenso realmente diferem apenas na maneira como os blocos são propostos ou na quantidade de comunicação que as pessoas precisam fazer para chegar a um acordo - na maioria das vezes, eles têm trade-offs (compensações) semelhantes a outros algoritmos em cada família respectiva. Existem também formas mais recentes de consenso, como Avalanche, que não se encaixam em nenhuma das categorias.

Trade-offs (Compensações) do Consenso Clássico/Nakamoto da Apresentação Avalanche G por un Sirer

Qual Algoritmo De Consenso Eu Preciso?

Dependendo do tipo de aplicação que você deseja construir, essas são questões orientadoras na seleção de qual algoritmo de consenso e, por sua vez, em qual plataforma de contrato inteligente construir.

1. Quão importante é a finalização?

   A finalização é extremamente importante para algumas aplicações e nem tanto para outras. Se você está construindo um novo sistema de pagamento para pequenos micropagamentos, ter uma transação revertida não é o fim do mundo. Da mesma forma, se você estiver construindo uma rede social descentralizada, ter 100% de garantia de que uma atualização de status será realizada imediatamente não é uma propriedade particularmente importante. Por outro lado, se você estiver construindo uma troca descentralizada, a finalidade é absolutamente crucial para a experiência do usuário. Ter negociações revertidas é pior do que não ter uma negociação acontecendo. Para se ter uma referência, o Bitcoin tem aproximadamente 1 hora de finalização, o Ethereum tem aproximadamente 6 minutos de finalização e o Tendermint Core tem uma finalização de 1 segundo.

2. Quão rápido seu aplicativo precisa ser?

   Se você está construindo um jogo, é razoável esperar 15 segundos (ou mais!) antes de cada ação? Por causa dos tempos de bloco do Ethereum, os jogos construídos nele acabam tendo uma experiência de usuário ruim devido à vazão do Ethereum. No entanto, um aplicativo que transfere a propriedade de um certificado de habitação pode ser perfeitamente adequado para ser executado no Ethereum. Usar o Cosmos SDK para criar aplicativos permite que um desenvolvedor use o Tendermint Core pronto para uso, que tem tempos de bloco curtos e alto rendimento, até 10.000 transações por segundo. Você pode fazer isso definindo um número máximo de validadores para seu aplicativo — reduzindo a sobrecarga de comunicação necessária e acelerando o aplicativo.

3. Quão “descentralizado” você precisa que seu aplicativo seja?

   Alguns aplicativos, como jogos, podem não exigir resistência significativa à censura, que é um subproduto da descentralização. Realmente importa se, em teoria, os validadores poderiam criar cartéis e bloquear/reverter transações em seu jogo para lucrar para si mesmos? Se não importa, blockchains como o EOS podem ser adequados para o seu caso de uso devido a transações rápidas e sem taxas. No entanto, algumas aplicações, como um banco autônomo, serão mais robustas quanto mais descentralizadas forem. Embora o Ethereum seja considerado descentralizado, há proponentes que afirmam que os pools de mineração no Ethereum são um ponto significativo de centralização para a plataforma e, na realidade, existem apenas 11 validadores (pools de mineração).
   Um dos grandes benefícios de construir sua própria blockchain, em vez de construir em uma plataforma de contrato inteligente, é que você pode personalizar a forma como a validação é feita para seu aplicativo. No entanto, é difícil construir sua própria blockchain, portanto, o Cosmos SDK é útil nesse sentido, facilitando a construção de sua própria blockchain e personalizando o nível de descentralização que seu aplicativo precisa.

4. Tudo bem se o sistema parar?

   Se você estiver criando um aplicativo como um serviço descentralizado de compartilhamento de viagens, pode ser prioridade n.º 1 garantir que o serviço seja executado 24 horas, 7 dias por semana, mesmo se houver erros ocasionais na contabilidade (por exemplo, transações sendo revertidas). Uma das propriedades do Tendermint Core é que, se houver divergências entre os validadores da rede, a rede optará por parar em vez de fazer transações incorretas. Algumas aplicações, como trocas descentralizadas, exigem correção a todo custo —- é muito melhor ter uma troca descentralizada que faça uma pausa se houver problemas, em vez de fazer negócios que serão revertidos.

Conclusão

Não existe um único algoritmo de consenso “melhor” —– cada um vem com seu próprio conjunto de trade-offs (compensações). No entanto, ao entender o processo de consenso (proposta e acordo) e ter uma estrutura para pensar sobre qual algoritmo de consenso seu aplicativo pode precisar, você poderá tomar uma decisão muito mais informada sobre a escolha de sua blockchain preferida. Claro, existem outras considerações, como ferramentas de desenvolvedor, comunidade e assim por diante, mas isso é assunto para outra postagem no blog.

Os principais tópicos de TL;DR desta postagem do blog são os seguintes:

1. Proof-of-work e Proof-of-stake não são algoritmos de consenso. Eles são “Mecanismos de Resistência Sybil” que ajudam você a escolher um proponente de bloco.
2. As duas principais famílias de consenso são o Consenso de Nakamoto e o Consenso Clássico. Esses algoritmos são usados para chegar a um acordo sobre blocos em uma blockchain.
3. Existem trade-offs (compensações) específicas para cada algoritmo de consenso. Escolha com base no caso de uso do aplicativo.
4. Fatores a considerar:
   • Finalização
   • Velocidade
   • Descentralização
   • Vivacidade

Deixe-nos saber o que você pensa sobre este post e o que você gostaria que escrevêssemos a seguir.

Esse artigo é uma tradução feita por @bananlabs. Você pode encontrar o artigo original aqui

---

Abrace a oportunidade de elevar sua jornada de desenvolvimento para um nível superior. Consenso na Blockchain é apenas o começo; os builds incríveis da WEB3DEV representam a chave de entrada para o emocionante cenário web3. 🚀🧑‍💻

Não perca tempo, 👉inscreva-se👈 agora mesmo e comece a desbravar o universo Blockchain!
 
Seja também WEB3DEV!