O que é o protocolo de consenso HotStuff e como funciona?

O que é o protocolo de consenso HotStuff?

O HotStuff é um protocolo de consenso BFT que permite que um grupo fixo de validadores chegue a acordo sobre uma única ordem definitiva de transações ou outras instruções, mesmo que uma parte desse grupo cometa falhas ou envie mensagens enganadoras de forma intencional.

BFT significa Byzantine Fault Tolerance. Isto significa que o protocolo é resistente a validadores que falham, não respondem, mentem ou enviam mensagens diferentes a participantes diferentes. O HotStuff garante que os validadores que funcionam corretamente continuam a seguir a mesma versão da blockchain ou do registo partilhado.

O HotStuff funciona com um grupo de validadores conhecido. Assim, o protocolo não determina por si próprio quem pode tornar-se validador, como o staking é estruturado, nem como uma rede de criptomoedas aberta seleciona participantes. Essas regras estão fora do âmbito do HotStuff. O protocolo foca-se na questão: como é que este grupo de validadores alcança acordo de forma segura?

O modelo original parte do princípio de um grupo de validadores com n = 3f + 1 participantes. Aqui, n é o número total de validadores e f é o número máximo de validadores que se podem comportar de forma incorreta ou maliciosa. Em termos simples: enquanto menos de um terço dos validadores for pouco fiável, o sistema continua a funcionar corretamente. Com 4 validadores, no máximo 1 pode ser pouco fiável. Os outros 3 validadores ainda assim podem, em conjunto, tomar uma decisão segura. Com 7 validadores, no máximo 2 validadores podem ser pouco fiáveis. Para uma decisão válida, pelo menos 5 validadores têm de estar de acordo. Para este efeito, o HotStuff utiliza um quorum certificate, muitas vezes abreviado como QC. Um QC é uma prova criptográfica compacta de que um número suficiente de validadores votou na mesma proposta. Um quórum é a quantidade mínima de apoio necessária para tomar uma decisão. No modelo original, esse quórum é composto por n − f, ou seja, 2f + 1, votos.

Com 4 validadores, isso corresponde a 3 votos. Com 7 validadores, isso corresponde a 5 votos. Este limiar elevado evita que um pequeno grupo de validadores pouco fiáveis consiga, por si só, fazer aprovar um bloco em conflito.

O HotStuff foi concebido para uma rede parcialmente síncrona. Isto significa que as mensagens podem sofrer atrasos significativos temporariamente, mas que a rede deve, eventualmente, voltar a estabilizar o suficiente para entregar mensagens atempadamente. A segurança mantém-se, mesmo durante grandes atrasos. O progresso, como a finalização de novos blocos, só é garantido quando a rede está suficientemente estável.

Pontos principais

• O HotStuff é um protocolo de consenso BFT para um grupo fixo de validadores.
• Os validadores registam em conjunto uma ordem de transações ou instruções.
• Um quorum certificate prova, de forma criptográfica, que um número suficiente de validadores apoia a mesma proposta.
• O modelo original tolera menos de um terço de validadores Bizantinos.
• O HotStuff mantém a segurança com atrasos na rede, mas precisa de uma rede estável para progredir.

Como funciona o protocolo de consenso HotStuff?

O HotStuff funciona em rondas sucessivas em que um líder temporário coordena uma proposta e os validadores votam sobre a mesma. Uma ronda deste tipo chama-se view. O líder não é um produtor de blocos permanente, mas apenas desempenha um papel de coordenação durante essa view específica.

Na variante original Basic HotStuff, são necessárias três fases de votação antes de uma decisão se tornar definitiva: prepare, pre-commit e commit. Cada fase dá aos validadores uma certeza adicional de que não pode ser concluída uma proposta em conflito.

Uma forma prática posterior, o Chained HotStuff, permite que estas fases se sobreponham ao longo de blocos sucessivos. Assim, um novo bloco pode, em simultâneo, fornecer prova do progresso de blocos anteriores. As regras de base sobre votação, quóruns e segurança mantêm-se as mesmas.

Que papel desempenham os validadores e o líder?

Os validadores verificam se a proposta do líder é segura antes de votarem. Entre outros aspetos, verificam se a proposta se baseia nos blocos anteriores corretos e se respeita as regras de segurança do protocolo. Se for esse o caso, enviam um voto assinado digitalmente ao líder.

O líder recolhe os votos. Assim que o líder tenha votos suficientes, agrega-os num único QC. Em vez de reenviar constantemente todos os votos individuais, o líder pode, portanto, divulgar uma prova compacta que mostra que um quórum concordou.

Os validadores utilizam também um lock, isto é, um bloqueio. Um lock é uma regra que impede que um validador apoie mais tarde, sem mais, um ramo em conflito. Um validador vota normalmente apenas numa proposta que estende o ramo bloqueado. É possível uma exceção quando um QC de uma view superior demonstrar, de acordo com as regras de segurança, que uma continuação é segura.

Quando uma view não faz progresso, por exemplo porque o líder está offline, os validadores mudam para uma nova view. Nessa altura, enviam uma mensagem new-view ao próximo líder. Esta contém o prepareQC mais alto conhecido, isto é, a prova mais forte de que dispõem naquele momento.

O novo líder escolhe o QC mais alto recebido como highQC. Este é o ponto de partida para uma nova proposta segura. Uma rotação previamente conhecida pode determinar quem é o próximo líder. Um pacemaker, um mecanismo com time-outs, garante que os validadores não ficam à espera indefinidamente de um líder que não funciona.

Como decorre o processo de consenso?

No Basic HotStuff, a tomada de decisão decorre passo a passo através de três fases de votação. A descrição seguinte mostra como uma proposta vai do início até uma decisão definitiva.

1. O novo líder recolhe informação. Numa mudança de view, o novo líder recebe mensagens new-view de um quórum de validadores. O líder escolhe o QC mais alto indicado nessas mensagens. Isto evita que o líder faça uma proposta que entre em conflito com um bloco anteriormente continuado de forma segura.

2. O líder faz uma proposta. O líder constrói um novo bloco com base no ramo justificado pelo highQC e envia-o a todos os validadores. A proposta inclui, portanto, também a prova de que esta é a via de continuação segura.

3. Os validadores verificam e votam na fase prepare. Cada validador verifica se o bloco cumpre as regras de segurança. Se a proposta as cumprir, o validador envia um voto prepare de volta ao líder.

4. O líder forma provas para prepare e pre-commit. Após 2f + 1 votos prepare, o líder cria um prepareQC e divulga-o para a fase pre-commit. Depois disso, os validadores recolhem votos novamente. Com mais 2f + 1 votos, o líder forma um precommitQC.

5. Os validadores bloqueiam e fazem commit da proposta. Os validadores estabelecem um lock com base no precommitQC e votam na fase commit. O líder agrega depois 2f + 1 votos commit num commitQC. Uma mensagem decide subsequente torna a proposta executável e definitiva.

Exemplo: Suponha que um grupo é composto por 4 validadores. Um líder propõe um bloco. Pelo menos 3 validadores têm de votar em cada fase exigida antes de o líder poder formar um QC. Assim, um validador defeituoso não pode forçar o processo a tornar definitivo um bloco diferente.

O Chained HotStuff torna este método mais eficiente ao combinar fases de blocos diferentes. De acordo com a three-chain commit rule, o bloco mais antigo numa sequência torna-se definitivo quando três blocos consecutivos, segundo as regras do protocolo, estão ligados entre si através de QCs válidos. Essa cadeia fornece a prova de commit para o bloco relevante mais antigo.

Como lida o HotStuff com falhas Bizantinas?

O HotStuff limita o impacto de falhas Bizantinas ao combinar um limiar de votação elevado, votos assinados, locks e regras claras para mudanças de view. Um validador Bizantino é um validador que se comporta de forma imprevisível ou maliciosa, por exemplo ao mentir, não responder ou enviar propostas diferentes a validadores diferentes.

O limite de falhas é inferior a um terço dos validadores num grupo não ponderado. Com n = 3f + 1 participantes, no máximo f validadores podem ser Bizantinos. Um QC exige 2f + 1 votos, o que é igual a n − f.

A consequência importante é que dois quóruns têm sempre sobreposição. Com 7 validadores, por exemplo, são necessários 5 votos para um QC. Dois grupos de 5 votos têm de ter, no mínimo, 3 validadores em comum. Como, no máximo, 2 validadores podem ser Bizantinos, existe sempre pelo menos um validador correto nessa sobreposição.

Um validador correto não vota duas vezes em propostas conflituantes na mesma fase e view. Por isso, não podem existir dois QCs conflituantes para a mesma fase e view. Além disso, os locks e a regra safeNode, a verificação de que uma nova proposta se baseia de forma segura em provas conhecidas, garantem que os validadores não mudam mais tarde, sem mais, para um ramo em conflito.

Isto protege a safety. Safety significa aqui que dois blocos conflituantes não podem ambos tornar-se definitivos por validadores que funcionam corretamente. Perante incerteza, a rede prefere esperar em vez de tornar definitivas duas histórias diferentes.

Liveness diz respeito ao progresso: a capacidade de tornar novos blocos definitivos. O HotStuff não promete esse progresso durante uma partição prolongada da rede ou atrasos grandes persistentes. Assim que a rede voltar a estar suficientemente estável e um líder correto liderar a mesma view durante tempo suficiente, os validadores podem voltar a formar quóruns e prosseguir.

Em variantes de proof-of-stake, este limite é frequentemente expresso em peso de voto em vez de apenas no número de validadores. Nesse caso, nem todos os validadores contam de forma igual. As garantias de segurança e progresso apenas se aplicam enquanto menos de um terço do peso de voto relevante for Bizantino.

Para que é utilizado o protocolo de consenso HotStuff?

O HotStuff é utilizado para permitir que um grupo de servidores ou validadores registe uma única ordem definitiva de instruções. Isto chama-se state machine replication: vários computadores executam as mesmas instruções na mesma ordem, para manterem o mesmo resultado e o mesmo registo partilhado.

Numa blockchain, esta tarefa pode consistir em ordenar e finalizar blocos com transações. Depois de os validadores fixarem a ordem, outras partes da rede podem executar as transações e atualizar o ledger. O HotStuff, por si só, determina sobretudo a ordem e a finalidade das decisões.

O DiemBFT era uma família de consenso baseada no HotStuff para a histórica blockchain Diem. Esta família de protocolos ordenava e finalizava transações dentro de um grupo de validadores configurável.

A Aptos utiliza o AptosBFT, um protocolo de consenso BFT baseado no Jolteon. O protocolo funciona com poder de voto ponderado por stake e pode aplicar seleção de líder baseada em reputação, em que o comportamento e o desempenho dos validadores influenciam a escolha de líderes. Nesse contexto, o peso de voto dos validadores pode diferir com base no stake.

A Flow utiliza a família de consenso HotStuff e migrou em janeiro de 2023 para o Jolteon. O Jolteon é uma variante otimizada do HotStuff. Assim, estes sistemas não utilizam necessariamente a especificação original do HotStuff exatamente tal como foi concebida; detalhes como a seleção do líder e o processamento podem variar.

Quais são as vantagens do HotStuff?

O HotStuff tem como vantagem importante o facto de organizar de forma mais eficiente a comunicação entre validadores do que protocolos em que todos têm de comunicar continuamente com todos os outros validadores.

• Provas compactas: O líder agrega os votos dos validadores com threshold signatures num único QC. Threshold signatures são assinaturas digitais agregadas que provam que um número suficiente de validadores votou. Assim, um validador não precisa de receber constantemente todos os votos individuais para verificar o quórum.

• Comunicação linear com um líder correto: No modelo original, a carga de comunicação e de autenticação por líder correto cresce, aproximadamente, com o número de validadores, em vez de crescer muito mais rapidamente. Isto não diz automaticamente quantas transações uma blockchain completa consegue processar, porque a execução, o armazenamento, o hardware e a propagação de transações também podem ser limitativos.

• Mudanças de líder mais eficientes: O HotStuff foi concebido para exigir menos comunicação do que o PBFT, mesmo em caso de falha do líder. Isto é importante quando um líder falha ou não divulga uma proposta utilizável.

• Pipelining no Chained HotStuff: Novas propostas podem contribuir para a finalização de blocos anteriores. Assim, a rede não precisa de concluir cada fase totalmente de forma isolada antes de iniciar uma proposta seguinte.

• Finalidade determinística: Um bloco em commit é definitivo dentro das suposições de segurança. Finalidade determinística significa que validadores que funcionam corretamente não podem mais tarde aceitar também um bloco conflituante como definitivo.

O HotStuff tem ainda optimistic responsiveness. Depois de a rede se tornar estável, um líder correto não precisa de esperar sempre por um atraso máximo de rede predefinido se as mensagens necessárias já tiverem sido recebidas antes. Isto pode melhorar o progresso em condições de rede favoráveis.

Quais são as limitações do HotStuff?

O HotStuff não oferece proteção ilimitada nem progresso garantido em todas as circunstâncias. O funcionamento depende de suposições claras sobre validadores, comunicação na rede e a implementação escolhida.

• Limites à tolerância a falhas: A análise formal de segurança aplica-se quando menos de um terço dos validadores ou do peso de voto é Bizantino. Com uma fração maior pouco fiável, as garantias de segurança e progresso ficam fora do modelo.

• Sem progresso numa partição persistente: A safety mantém-se com atrasos de rede ilimitados, mas o HotStuff não torna, de forma garantida, novos blocos definitivos enquanto a rede permanecer dividida ou instável por um período prolongado.

• Dependência do líder: Um líder fraco, que sofreu crash ou que está inacessível pode fazer falhar uma view. O pacemaker e a rotação de líderes ajudam a rede a recuperar quando a suposição de sincronia voltar a aplicar-se, mas primeiro causam atraso adicional.

• Grupo fixo de validadores como ponto de partida: O protocolo original parte de um grupo de validadores conhecido, autenticado e de threshold signatures. O HotStuff não determina por si próprio como uma rede aberta escolhe validadores, distribui stake ou pune o mau comportamento económico.

• Várias fases para finalidade: O Basic HotStuff precisa de três fases de votação antes de uma proposta ser definitiva. O Chained HotStuff aumenta o débito através de pipelining, mas o tempo até à finalidade dos primeiros blocos e o comportamento em mudanças de líder continuam a depender de atrasos de rede, time-outs e da implementação.

Assim, o líder reduz a quantidade de comunicação entre participantes, mas também se torna um importante ponto temporário de coordenação. Esse líder tem de recolher votos de quórum a tempo e divulgar novas provas.

Como se compara o HotStuff com outros protocolos de consenso?

O HotStuff pertence à família de protocolos BFT baseados em líder, mas difere na forma como organiza a votação, os quóruns e as mudanças de líder. Não existe uma hierarquia direta: os protocolos fazem escolhas diferentes sobre grupos de validadores, condições de rede e finalidade.

Em comparação com o PBFT, o HotStuff foi concebido para reduzir a comunicação durante o progresso normal e numa mudança de view. Na comparação original, a complexidade de autenticadores do HotStuff com um líder correto e em caso de falha do líder cresce de forma linear com o número de validadores. No PBFT, essa carga cresce mais rapidamente na mesma comparação. A complexidade de autenticadores refere-se especificamente à quantidade de informação de autenticação a processar dentro do protocolo, e não diretamente a transações por segundo ou latência para utilizadores.

O Tendermint e o Casper partilham com o HotStuff a abordagem BFT com líderes temporários, quóruns e finalidade. Na comparação original, as variantes de Tendermint e Casper da época tinham uma carga de comunicação mais elevada. Otimizações técnicas, como threshold signatures, podem alterar estes custos em implementações específicas.

O HotStuff difere claramente do consenso de Nakamoto, como o Bitcoin. O HotStuff funciona com um grupo de validadores conhecido e pode finalizar decisões em commit de forma determinística dentro do limite de falhas. O Bitcoin utiliza um modelo permissionless de proof-of-work em que os participantes podem aderir livremente e em que a finalidade é probabilística. Isto significa que a probabilidade de reversão diminui à medida que mais blocos se seguem, em vez de um único momento fornecer finalidade absoluta dentro das regras do protocolo.

Em comparação com protocolos BFT totalmente assíncronos, o HotStuff opta por sincronia parcial. Assim, o protocolo pode fazer progresso de forma responsiva após a estabilização da rede, mas não promete liveness durante uma partição persistente da rede.

Variantes posteriores baseiam-se nas ideias do HotStuff. O DiemBFTv4 ajusta a abordagem com um steady-state commit em dois passos, enquanto a Flow utiliza o Jolteon como variante otimizada do HotStuff. Estes derivados podem ter propriedades diferentes do protocolo original.

Considerações finais

O HotStuff é um protocolo de consenso BFT que ajuda um grupo fixo de validadores a registar, de forma segura, uma única ordem de transações ou instruções. O líder temporário recolhe votos, enquanto os quorum certificates demonstram que um número suficiente de validadores analisou e apoiou a mesma proposta.

A combinação de limiares de votação elevados, assinaturas digitais, locks e mudanças de view evita que um pequeno grupo de validadores Bizantinos consiga tornar definitivos dois blocos conflituantes. O HotStuff mantém-se seguro durante grandes atrasos de rede, mas só pode garantir progresso quando a rede voltar a estar suficientemente estável e um líder correto permanecer ativo.

A agregação eficiente de votos e a possibilidade de pipelining tornam o HotStuff uma base importante para variantes BFT modernas. Ao mesmo tempo, continua a ser essencial compreender que o HotStuff não é um modelo de consenso totalmente aberto nem um sistema económico: a seleção de validadores, o stake e os incentivos são geridos pela blockchain ou pela implementação em seu redor.