Resultados da Colaboração: Albatross

Um algoritmo de consenso otimista

A Equipe Nimiq tem o prazer de apresentar o Albatross, que é resultado da colaboração de pesquisa com a Trinkler Software. Albatross é um algoritmo de consenso do tipo Proof-of-Stake, capaz de alcançar desempenho próximo ao máximo alcançado em teoria por algoritmos Proof-of-Stake single-chain. Por mais que uma descrição técnica do protocolo já tenha sido divulgada, essa publicação traz uma visão geral, com conteúdo mais leve e de fácil entendimento.

É importante enfatizar que o Albatross é um algoritmo de consenso, e nada a mais. Ou seja, ele não define as funcionalidades criadas sobre ele, sendo apenas um dos blocos fundamentais do protocolo de uma blockchain. Enquanto a Nimiq avalia a utilização do Albatross na próxima geração do seu protocolo, ainda não foi tomada nenhuma decisão. Mais detalhes sobre nossos planos para o Albatross estão disponíveis no final dessa publicação.

O que é Proof-of-Stake?

Em um algoritmo baseado em Proof-of-Stake, o node elegível para adicionar o próximo bloco na blockchain tem chances de ser escolhido proporcionais a sua participação (stake) no sistema. Isso faz com que a produção de blocos seja muito mais barata quando comparadas com algoritmos baseados em Proof-of-Work (PoW). Tentativas de fraude são punidas com o corte do stake do node que as cometeu, reduzindo e/ou redistribuindo esse valor.

As três maiores vantagens do PoS sobre o PoW são:

• redução drástica na redução do consumo de energia: não é necessário realizar os cálculos, que gastam grandes quantidades de energia, para proteger a blockchain;
• redução do risco de centralização: especificamente, economias de escala são problemas bem menores em algoritmos baseados em PoS;
• o equivalente ao ataque dos 51% é bem mais inviável: nodes fraudulentos perdem o seu stake, enquanto que o hardware utilizado no PoW não é descartado.

O que “algoritmo de consenso otimista” quer dizer?

Descrevemos o Albatross, nosso novo algoritmo de consenso, como sendo um algoritmo otimista. Esse termo não quer dizer que sacrificamos qualquer mecanismo de segurança, mas sim que nos baseamos em algoritmos do tipo Byzantine-fault-tolerant (BFT) especulativos.

Algoritmos BFT clássicos proporcionam o consenso em sistemas distribuídos levando em consideração um número limitado de agentes maliciosos (bizantinos). Um dos exemplos mais eminentes desse tipo de algoritmo é o PBFT, que, por exemplo, é empregado no core da criptomoeda Tendermint.

Algoritmos BFT especulativos são uma evolução dos algoritmos BFT padrão. Eles proporcionam ganhos significativos de performance, no caso em que não há agentes maliciosos. E é isso que representa a parte otimista do algoritmo. Quando há agentes bizantinos presentes, tentando cometer fraudes contra o protocolo, os outros nodes podem ativar seu modo mais lento, porém mais conservador, garantindo o mesmo nível de segurança de um protocolo BFT padrão.

O Protocolo do Albatross

No Albatross, os nodes responsáveis por gerar novos blocos são chamados de validadores (validators). Qualquer node que tiver stakes no sistema pode se voluntariar para ser um validador, necessitando apenas depositar seu stake como garantia, que pode ser reduzido em causa de fraude.

A produção de blocos no Albatross é dividida em épocas (epochs). Como mostrado na figura a seguir, cada época consiste de um número constante de micro blocos (quatro micro blocos são usados no exemplo abaixo) seguido por um macro bloco. Micro blocos armazenam as transações e são produzidos por um único node escolhido aleatoriamente do grupo de validadores. Mesmo que qualquer node possa se voluntariar a ser um validador, o grupo de validadores de uma época (os validadores ativos) é escolhido pelo macro bloco da época anterior.

No nosso exemplo, o bloco de número 0 determina quem são os validadores ativos v_0,…,v_k para a época, do bloco 1 ao bloco 5.

Para ser capaz de selecionar o node que vai produzir o próximo bloco a partir da lista de validadores, cada bloco possui um beacon randômico, representados acima por r_i. O gerador do bloco usa uma Função Aleatória Verificável (Verifiable Random Function, VRF) para produzir o próximo valor aleatório r_i a partir do valor anterior r_{i-1}. Todos os outros participantes podem então verificar com exatidão o valor do próximo valor aleatório.

Dados os beacons aleatórios de cada bloco, cada participante do Albatross pode determinar quem será o próximo node v_{σ(r)} a gerar um bloco, a partir da lista de validadores ativos.

Assim, a produção de micro blocos se torna tão simples quanto um gerador inserir uma transação em um bloco, assinando criptograficamente o bloco, e propagando o bloco para a rede.

A produção dos macro blocos é um pouco mais elaborada, mas acontecem com menos frequência. Macro blocos são construídos usando o protocolo PBFT clássico. Para tanto, o node escolhido para gerar o bloco — ou melhor, para propor o bloco — produz o próximo valor aleatório, que servirá para determinar a lista dos validadores ativos para a próxima época. A lista de validadores é formada a partir de todos os voluntários ponderados pelos seus stakes e beacons aleatórios. O node então propaga a proposta do novo bloco, e todos os outros validadores ativos votam em duas rodadas. Macro blocos não contêm nenhuma transação.

Não há a ideia de tempo alvo entre blocos, fazendo com que os blocos possam ser produzidos tão rapidamente quanto a rede permitir.

A explicação acima cobre somente os casos ideais, mas o protocolo garante a segurança mesmo que até 1/3 dos validadores sejam agentes bizantinos. Estes agentes, no entanto, podem reduzir a velocidade da rede temporariamente, colocando a produção de blocos em um modo conservador. Agentes bizantinos podem ativar dois mecanismos: (1) forks, que fazem com que o gerador do próximo bloco tenha que escolher entre dois blocos conflitantes, e permitem que os validadores reduzam o stake do validador malicioso; e (2) atrasos, o que permite que outro validador produza o bloco no lugar do agente malicioso.

Uma explicação mais detalhada desses casos se encontram no artigo técnico.

Consistência vs Disponibilidade

Um balanceamento crucial a ser considerado no projeto de um protocolo como esse é aquele entre consistência e disponibilidade. A consistência descreve a propriedade que faz com que todos os participantes do protocolo concordem com o valor mais recente. Disponibilidade descreve a propriedade em que os participantes não podem ser impedidos de saber qual é o valor mais recente de forma correta, independente do que aconteça.

O Teorema CAP diz que, havendo um particionamento de rede, ambas as propriedades citadas acima não podem ser alcançadas ao mesmo tempo.

O Bitcoin, por exemplo, dá preferência à disponibilidade sobre a consistência. Em caso de uma divisão da rede, ambas as sub-redes podem continuar funcionando, mesmo contendo possíveis transações conflitantes (um gasto duplo, por exemplo). Se a rede se recuperar do particionamento, apenas uma das versões será aceita.

Já o Albatross dá preferência à consistência sobre a disponibilidade. Em caso de particionamento da rede, apenas uma das partições continua funcionando ou nenhuma (dependendo do tamanho do particionamento). Porém, nunca haverá uma versão incorreta do estado mais recente. Após a recuperação do particionamento, o protocolo volta ao seu funcionamento normal.

Próximos passos

Agora que a descrição técnica do Albatross foi publicada, e o protocolo foi apresentado pelo Reto Trinkler, representando a Katallassos, na EthCC’19 em Paris, esses serão os próximos passos:

Começamos a desenvolver um simulador para o protocolo do Albatross, para avaliar sua performance em redes de larga escala. No momento, o simulador compreende apenas o protocolo base, não levando em consideração otimizações e a presença de agentes bizantinos. Planejamos estender este simulador, a fim de entender melhor como o Albatross se comportaria em funcionamento no mundo real.

Enquanto isso, também estamos procurando possíveis otimizações para o Albatross. Essas otimizações incluem a utilização do Handel, que é um protocolo para agregação rápida multi-assinatura. Entre outras melhorias, também estamos considerando a aplicação de Funções de Atraso Verificáveis (Verifiable Delay Functions) para reduzir a comunicação em casos em que os geradores de blocos parem de responder.

Enfim, quando os prerrequisitos demonstrarem os resultados esperados, avaliaremos mais a fundo a viabilidade de integrar o Albatross a Nimiq. Este passo pode incluir também detalhes quanto a recompensas por bloco, HTLC, contratos de vesting, e staking pools (equivalente das mining pools). Só então criaremos uma rede de testes utilizando o Albatross.

O Albatross pode trazer um aumento drástico no desempenho da Nimiq, cortando significativamente o consumo de energia. Mesmo que a implementação traga resultados positivos para o core da Nimiq, todas as suas implicações devem ser avaliadas minuciosamente.

A Equipe Nimiq tem como prioridade prover uma transição suave para um possível futuro onde a Nimiq não dependa de um algoritmo PoW, o qual acreditamos que trará benefícios para todos.

AVISO: nenhuma declaração aqui apresentada deve ser tomada como endossamento ou recomendação para aquisição de Nimiq ou qualquer outra criptomoeda ou investimento de qualquer natureza. Nenhuma informação ou opinião contida no texto acima constitui solicitações ou ofertas de compra ou venda de títulos ou instrumentos financeiros, ou ainda prover algum tipo de conselho ou serviço sobre investimentos, partindo dos criadores ou participantes do projeto.