Como chegar a um acordo: Diferentes tipos de consenso para Blockchain

Existem muitos mais tipos de consenso para além da prova de trabalho e da prova de aposta. Apresentamos de seguida as alternativas mais importantes.

Em termos simples, uma cadeia de blocos é constituída por dados processados e registados por um grupo de computadores, que trabalham em conjunto para garantir a autenticidade e a segurança destas transacções de dados.

Mas como podemos garantir que estas transacções são, de facto, verificadas e seguras? As cadeias de blocos são, por natureza, descentralizadas e distribuídas, o que significa que não existe uma autoridade central para exercer a governação do sistema. Para garantir que as regras do protocolo estão a ser seguidas e evitar qualquer comportamento pouco ético, as cadeias de blocos aplicam vários algoritmos para alcançar o chamado consenso entre entidades sem confiança.

Definição rápida de consenso

O consenso pode ser definido como o acordo de um grupo de agentes sobre os seus estados comuns através da interação local.

No contexto da cadeia de blocos, o consenso é um procedimento em que os pares de uma rede de cadeia de blocos chegam a acordo sobre o estado atual dos dados na rede. São estes algoritmos de consenso que estabelecem a fiabilidade e a confiança nos sistemas Blockchain.

Embora o consenso seja bastante fácil de obter em redes centralizadas, em que uma autoridade governamental é de confiança para validar as transacções e salvaguardar os registos, é muito menos simples no caso dos sistemas descentralizados.

Consenso na cadeia de blocos

A cadeia de blocos funciona através da adição de blocos de dados e a essência do consenso é garantir que cada bloco adicionado à cadeia é a única versão da verdade acordada por todos os nós do sistema. Trata-se de uma caraterística fundamental da natureza descentralizada da cadeia de blocos.

As regras de base para o consenso na cadeia de blocos incluem:

• O objetivo de chegar a um acordo
• Colaboração, cooperação e direitos iguais para todos os nós/pares, e
• Participação obrigatória de cada nó no processo

Existem muitas abordagens diferentes para chegar a um consenso sobre os sistemas descentralizados. Aqui analisamos diferentes formas de chegar a acordo e formar um consenso.

Consenso de Nakamoto

A mãe de todos os consensos de cadeias de blocos, o protocolo de consenso Nakamoto foi concebido por Satoshi Nakamoto em 2009 como um novo meio de verificar a autenticidade de uma rede de cadeias de blocos e impedir a duplicação de gastos. É um algoritmo de consenso bizantino tolerante a falhas que funciona em conjunto com a prova de trabalho (PoW) para governar a cadeia de blocos Bitcoin.

A tolerância a falhas bizantinas (BFT) é uma condição em que um sistema distribuído pode permanecer tolerante a falhas na presença de actores maliciosos e de imperfeições na rede.

Enquanto o PoW se refere ao mecanismo criptográfico através do qual os mineiros competem entre si para resolver puzzles computacionais extremamente complexos (e dispendiosos) para ganhar o direito de validar um novo bloco e ganhar uma “recompensa de bloco”. Esta recompensa monetária incentiva os mineiros a seguirem as regras e a manterem-se honestos, enquanto os custos de participação servem como um desincentivo económico para que ataquem a rede Bitcoin, protegendo ainda mais a cadeia de blocos.

Através da combinação de BFT e PoW, Nakamoto procurou contornar alguns dos problemas inerentes ao BFT com a escalabilidade, ao mesmo tempo que dissuadia os maus actores. Ao criar uma medida padrão para a validade da blockchain – neste caso, a quantidade de recursos computacionais (ou “poder de hashing”) gastos nela – Nakamoto abriu uma nova direção para resolver o Problema dos Generais Bizantinos numa configuração sem permissões. Uma que levaria ao aparecimento de muitos novos algoritmos de consenso, incluindo a prova de participação (PoS), a prova de autoridade (PoA), a prova de reputação (PoR) e a prova de importância (PoI).

Prova de X

A ideia subjacente a este consenso de prova de algo (PoX) é utilizar alguns recursos escassos X onde os atacantes maliciosos não podem obter X facilmente. Deste modo, o sistema pode manter-se seguro de forma descentralizada e sem autorizações. É assim que funciona normalmente.

Para obter o privilégio de validar transacções e minerar novas moedas, os nós de uma rede PoX devem fornecer provas de que cumpriram com êxito X critérios. Muitas vezes, este processo implica algum tipo de sacrifício. Por exemplo, o poder e o esforço computacional no PoW, e as moedas apostadas no PoS. De diferentes formas, estes servem de incentivos para que os mineiros se mantenham honestos.

Em geral, a PoX pertence à classe de consenso Nakamoto. O consenso de Nakamoto adopta normalmente as seguintes opções de conceção:

• Tolerância a falhas bizantinas – as redes são capazes de continuar a funcionar mesmo que alguns nós falhem ou actuem de forma maliciosa
• Síncrono – as mensagens são entregues dentro de um período de tempo fixo
• Probabilística – os nós concordam com a probabilidade de o valor estar correto
• Baseado em líderes – os líderes são eleitos para validar as transacções

E, por conseguinte, pode alcançar as seguintes propriedades:

• Os pares podem entrar e sair quando quiserem
• Centra-se na vivacidade (ou seja, um par pode sempre produzir novos blocos) à custa da segurança (ou seja, a decisão tomada pode ser revertida)
• Autossustentável – os pares são incentivados a manter a rede

Existem demasiados protocolos PoX para os apresentar a todos. Os leitores interessados podem ler o nosso guia para principiantes sobre mecanismos de consenso para um resumo dos consensos PoX mais conhecidos atualmente.

Consenso clássico

O consenso clássico, por outro lado, alcança o consenso através da votação. Estes protocolos confirmam as transacções mais rapidamente do que os tipos de consenso Nakamoto discutidos acima, uma vez que o tamanho da rede de consenso é fixo e o progresso pode ser feito assim que os votos necessários são vistos.

Eis alguns exemplos importantes de consenso clássico:

Tolerância prática a falhas bizantinas (pBFT)

Introduzida no final dos anos 90 por Barbara Liskov e Miguel Castro, a tolerância prática a falhas bizantinas (pBFT) tem como objetivo resolver muitos dos problemas associados às soluções de tolerância a falhas bizantinas (BFT) acima mencionadas.

O pBFT utiliza uma máquina de estados trifásica e uma eleição em bloco para selecionar o líder. As três fases do pBFT são conhecidas como pré-preparação, preparação e autorização. No caso habitual, o consenso é obtido através da troca de mensagens entre os nós, o que implica uma transição progressiva para o seu estado local. Caso contrário, em caso de falha de um nó, será desencadeada uma “mudança de vista”, o que levará a uma nova seleção do líder de forma round-robin. O pBFT é capaz de lidar com menos de ⅓ das falhas bizantinas, o que pode ser visto como 3f+1= Total de nós onde f=quantidade de falhas bizantinas.

No entanto, tem algumas desvantagens:

• Liderança fraca – os nós podem rejeitar os pedidos do líder e propor a sua reeleição, mas são necessários serviços de autoridade para a seleção do líder.
• Tolerância a falhas bizantinas – 33% dos nós podem ser maliciosos.
• Baixa escalabilidade da rede – devido à elevada sobrecarga de comunicação e à latência de várias rondas de mensagens, o aumento do número de nós também aumentaria quadraticamente a complexidade do sistema.
• Taxa de transferência de transacções – até 50.000 tx por segundo com um tempo de confirmação de 1 segundo.
• Caso de utilização – cadeia de blocos de consórcios com um validador autorizado limitado.

Tolerância a falhas bizantinas delegadas (dBFT)

A tolerância a falhas bizantinas delegadas (dBFT) foi proposta pelo projeto NEO em 2014. Ao contrário do pBFT, que requer serviços de autoridade para selecionar o líder, o sistema de votação do dBFT permite a participação em larga escala, de forma semelhante à prova de participação delegada (DPoS).

O procedimento global de consenso é muito semelhante ao pBFT, diferindo apenas na forma como os votos são contados. No dBFT, o peso do voto é proporcional ao número de tokens que os participantes detinham no momento da votação. Os participantes podem delegar os seus tokens (votos) a representantes de confiança. Isto melhora o desempenho, mas também significa que pode tornar-se mais centralizado ao longo do tempo devido a esta camada extra de representação. Uma desvantagem deste método é que os delegados eleitos deixam de poder ser anónimos. Os delegados na blockchain NEO trabalham com identidades reais.

Acordo Bizantino Federado (FBA)

O acordo bizantino federado (FBA) é um algoritmo que suporta a adesão aberta, permitindo que os validadores adiram livremente à rede. É notável pelo seu elevado rendimento, escalabilidade e baixos custos de transação.

O FBA pode ser considerado um BFT sem permissões. No entanto, é necessário que uma transação seja assinada por um grupo específico de signatários. Num sistema FBA, os validadores podem escolher os outros validadores em que confiam e, a partir daí, formam o que se designa por fatia de quórum. Num sistema com muitos validadores, pode haver várias fatias de quorum e, com várias fatias de quorum, há uma sobreposição, com alguns nós a serem considerados fiáveis em várias fatias. Estas sobreposições juntam-se para formar o quórum global. Que é utilizado como método para chegar a um consenso na FBA. Os projectos notáveis que utilizam o FBA são o Ripple(XRP) e o Stellar(XLM).

Algumas vantagens do FBA são:

• Baixa barreira à entrada, uma vez que a adesão é aberta desde que se possa confiar e aderir a uma fatia de quórum.
• Qualquer pessoa pode entrar e sair em qualquer altura, sem que o sistema deixe de funcionar.

Jangada

Desenvolvido por Diego Ongaro e John Ousterhout em 2014, o Raft é baseado no protocolo Paxos e foi concebido para ser mais fácil de compreender e implementar. Em comparação com muitos outros algoritmos de consenso, o Raft tem uma maior dependência do líder. Os nós confiarão no líder quando os temporizadores aleatórios o elegerem, e este só será reeleito se o líder atual falhar.

Isto melhorou consideravelmente as coisas:

• Liderança forte – os nós não rejeitariam pedidos do líder, não haveria reeleição até o líder estar indisponível.
• Tolerante a falhas de colisão – 49% dos nós podem falhar ou ficar indisponíveis.
• Elevada escalabilidade da rede – A complexidade deste algoritmo de consenso é linearmente proporcional ao número de nós.

Exemplos:

Consenso sem líderes

O último tipo de consenso que vamos apresentar é uma nova direção emergente – o consenso sem líderes.

Tal como referido anteriormente, o consenso significa o acordo de um grupo de agentes sobre os seus estados comuns através da interação local.

Num problema de consenso sem líder, não é necessário um líder virtual, ao passo que num problema de consenso com líder e seguidor, é necessário um líder virtual que especifique o objetivo para todo o grupo. Mais especificamente, o consenso com um líder virtual estático é designado por problema de regulação do consenso e o consenso com um líder virtual dinâmico é designado por problema de seguimento do consenso.

Exemplos de projectos de consenso sem líder incluem Avalanche, IOTA e NKN. Apresentaremos aqui a Avalanche e a IOTA a um nível elevado.

Avalanche

O documento técnico da Avalanche foi publicado anonimamente em meados de maio de 2018 por uma equipa que se identificou apenas como Team Rocket. Mais tarde, a AVA Labs foi fundada para desenvolver o token Avalanche (AVA), e acredita-se que um grupo de cientistas informáticos da Universidade de Cornell (Emin Gün Sirer, Kevin Sekniqi, Ted Yin) está intimamente associado ao projeto.

A Team Rocket chamou ao protocolo de consenso uma “nova família de protocolos de consenso metaestável para as criptomoedas” e descreveu-o como “uma nova família de protocolos de tolerância a falhas bizantinas sem líder, construída sobre um mecanismo metaestável”.

O Avalanche utiliza a subamostragem aleatória repetida para votar e chegar a um consenso. Cada nó precisa de recolher amostras de um certo número de vizinhos para verificar os seus estados e ver se está de acordo com a maioria. Caso contrário, mudarão de Estado seguindo a maioria. O processo repetir-se-á uma e outra vez, pelo que, a longo prazo, toda a rede chegará a uma conclusão ubíqua.

A Avalanche afirma que o seu mecanismo de consenso pode atingir 1300 tps com uma latência de 4 segundos.

De acordo com a equipa, espera-se que a rede principal da Avalanche seja lançada em setembro de 2020.

IOTA

A IOTA foi fundada em 2015 por David Sonstebo, Sergey Ivancheglo, Dominik Schiener e Dr. Serguei Popov. A IOTA é uma das primeiras moedas a propor a utilização de um gráfico acíclico dirigido (DAG) como estrutura de dados subjacente a uma tecnologia de registo distribuído (DLT) em vez de uma cadeia de bloqueio.

A versão atual da IOTA utiliza um protocolo chamado Tangle. O Tangle tem as seguintes propriedades que são diferentes das da bitcoin:

• Utiliza uma estrutura de dados baseada em DAG para formar o gráfico de transacções em vez de agrupar as transacções em blocos encadeados.
• Elimina o papel dos mineiros e exige que o utilizador verifique duas transacções anteriores (não confirmadas) se pretender enviar novas transacções para a rede.
• O consenso/votação baseia-se em informações locais e não requer a interação com toda a rede. Em vez disso, é conseguido através de um processo de passeio aleatório ponderado denominado Cadeia de Markov de Monte-Carlo (MCMC)
• No entanto, o livro branco não especifica claramente como se pode chegar a um consenso num ambiente distribuído. Por conseguinte, até à data, a rede depende de um “coordenador” centralizado, o que foi amplamente criticado pela comunidade criptográfica.

Recentemente, a Fundação IOTA declarou o seu roteiro chamado “Coordicide” para renovar o protocolo e remover o coordenador. Foram propostos dois consensos: o consenso probabilístico rápido (FPC) e o consenso celular (CC). Ambas as soluções pertencem à classe dos consensos sem líderes.

Consenso e escalonamento da cadeia de blocos

E aqui tem, uma visão geral dos mecanismos de consenso mais utilizados. Como todas as partes que mantêm uma cadeia de blocos em movimento, podemos ver uma evolução distinta aqui também, desde o conceito original até versões mais rápidas e ágeis que ajudam a escalar cadeias de blocos para velocidades mais rápidas e redes maiores. Se quiser saber mais sobre as funções básicas da cadeia de blocos, consulte também os nossos artigos sobre cadeias laterais e como estas ajudam a construir muito mais do que apenas um sistema de pagamento na cadeia.