Resumindo o avanço no MonadBFT Ontem, a Category Labs divulgou o artigo do MonadBFT, descrevendo o mecanismo de consenso que alimentará o Monad na rede principal. MonadBFT é um desenvolvimento significativo na pesquisa de consenso, pois é a primeira vez que o Pipelined HotStuff se torna resistente ao tail-forking. A bifurcação final ocorre quando um slot perdido faz com que a proposta anterior seja descartada e minerada novamente. É um problema grave em formulações anteriores do HotStuff em pipeline, pois abre ataques MEV multibloco que desestabilizam o consenso. Aliviar esse problema é um grande negócio porque nos dá todos os benefícios do Pipelined HotStuff - bloqueios frequentes, baixa latência, grandes conjuntos de validadores - evitando a maior desvantagem. O MonadBFT também oferece uma grande atualização para finalidade. Possui finalidade especulativa de slot único (500 ms) e finalidade rígida de dois slots (1s). "Finalidade especulativa" significa "finalidade que será revertida apenas em caso de equívoco (assinatura dupla) pela maioria dos validadores". O equívoco é uma ofensa grave na maioria dos sistemas blockchain e é comumente penalizado com cortes; Quanto maior a penalidade por equívoco, mais próximo você pode pensar em "finalidade especulativa" da finalidade. A finalidade especulativa de um slot é um grande desbloqueio para aplicativos de alto desempenho, que podem exibir com confiança o estado atualizado do mundo imediatamente após o recebimento do próximo bloco. Essas propriedades tornam o MonadBFT um grande avanço no consenso e um complemento valioso para outras melhorias compostas no Monad, incluindo Execução Assíncrona, Execução Paralela Otimista e MonadDb. O restante deste artigo serve como um resumo de como as sucessivas melhorias no HotStuff se basearam umas nas outras, a fim de explicar o problema que o MonadBFT resolve. Para resumir: 1. O HotStuff nos dá complexidade de comunicação linear para que possamos ter grandes conjuntos de validadores, mas não é muito eficiente 2. O HotStuff em pipeline nos dá eficiência e baixa latência ao propor blocos a cada slot, mas sofre com o problema dos forks de cauda 3. MonadBFT nos dá resistência ao garfo traseiro e finalidade especulativa de um slot --- HotStuff: A complexidade da comunicação linear permite grandes contagens de nós Os algoritmos HotStuff são concluídos ao longo de várias rodadas de comunicação, que geralmente assumem a forma de comunicação "fan out, fan in" diretamente dos líderes para os validadores de volta aos líderes. Cada rodada começa com o líder enviando uma mensagem diretamente para outros validadores, que enviam de volta uma mensagem assinada atestando ter recebido a mensagem. Desde que uma supermaioria (2/3) dos validadores envie de volta um atestado, cada rodada termina com o líder agregando os atestados assinados em um Certificado de Quórum (QC), que serve como prova de que a supermaioria atestou a mensagem anterior. Os algoritmos do HotStuff têm várias rodadas de comunicação como esta. - A primeira mensagem do líder é uma proposta de bloqueio - A segunda mensagem é o QC para essa proposta de bloco - A terceira mensagem é um QC sobre o QC anterior (ou seja, um QC-on-QC) - e assim por diante Se o procedimento for interrompido a qualquer momento antes da finalidade, o bloco não será finalizado e será descartado; As transações desse bloco terão que ser reincluídas no próximo bloco. O protocolo HotStuff original não tem pipelining e tem 3 rodadas de comunicação antes da finalidade; O mesmo validador desempenha o papel de líder para cada rodada. --- HotStuff em pipeline: Um novo bloco a cada slot aumenta a eficiência Pipelining é o que todos nós fazemos intuitivamente quando temos duas cargas de roupa para completar. Em vez de esperar que a carga 1 termine o ciclo completo antes de iniciar a carga 2, no pipelining colocamos a carga 1 na secadora ao mesmo tempo em que a carga 2 vai para a lavadora. Você pode pensar no HotStuff original como aquela abordagem ingênua para lavar a roupa (não comece na carga 2 até que a carga 1 esteja completamente pronta), enquanto o Pipelined HotStuff está fazendo o comportamento intuitivo de progredir várias cargas de roupa de forma escalonada. No Pipelined HotStuff, escalonamos as propostas, de modo que haja um novo bloco proposto a cada rodada, com o novo bloco pegando carona em cima da mensagem que carrega o QC do bloco anterior. As propostas de blocos marcham em direção à finalidade ao longo de várias rodadas. Os benefícios do pipelining são significativos. O pipelining aumenta a densidade das propostas de bloco, uma vez que uma proposta de bloco é feita em cada slot, o que aumenta a taxa de transferência e reduz o tempo de finalização. No entanto, há uma grande desvantagem do pipelining, que é melhor ilustrada com um exemplo. Suponha que os líderes dos blocos N, N+1 e N+2 sejam Alice, Bob e Charlie. Se Bob perder seu slot, a proposta de Alice também será invalidada, porque a mensagem de Bob carrega sua proposta e um controle de qualidade para a proposta de Alice. Quando isso acontece, Charlie acaba sendo chamado para produzir um bloco como se a proposta de Alice nunca tivesse existido. Referimo-nos a esse comportamento como "bifurcação da cauda" e pode ser pensado como uma mini-reorganização da profundidade 1. A possibilidade de bifurcação traseira tem consequências significativas, porque os slots perdidos não são necessariamente por acidente. Se houver uma oportunidade de extrair valor minerando novamente o bloco de Alice enquanto reordena ou omite algumas das transações, então Bob e Charlie podem conspirar para que Bob perca intencionalmente seu slot, desencadeando uma oportunidade para Charlie minerar novamente o bloco de Alice. Essa tem sido uma desvantagem significativa dos protocolos HotStuff em Pipeline (alguns dos quais estão na rede principal hoje). --- MonadBFT muda isso O MonadBFT é o primeiro protocolo a habilitar o pipelining enquanto torna o algoritmo resistente ao garfo traseiro. Essa resistência ao fork da cauda vem do procedimento de fallback quando Bob perde seu slot, o que permite que os validadores reúnam seu conhecimento coletivo da proposta de Alice e seu nível de consenso dentro do conjunto de validadores. Em particular, no MonadBFT, se Bob perder seu slot, o procedimento de fallback fará com que os validadores se comuniquem entre si com atestados assinados informando se viram o bloco de Alice. Se a supermaioria atesta o bloqueio de Alice, Charlie é forçado a propor novamente o bloqueio de Alice. Se Charlie deseja propor um bloco diferente, ele deve fornecer um atestado assinado pela maioria dos validadores atestando que não viu o bloco de Alice a tempo. No caso típico em que Charlie propõe novamente o bloqueio de Alice, ele então propõe seu bloqueio na rodada subsequente. O resultado são duas propriedades importantes: resistência à bifurcação traseira e finalidade especulativa de slot único. Já falamos sobre a resistência à bifurcação, mas vamos entender o impacto na finalidade. Como antes, suponha que os líderes dos blocos N, N+1 e N+2 sejam Alice, Bob e Charlie. Em Pipelined 2-Phase HotStuff - ou seja, antes do MonadBFT - como um validador (ou um nó completo), você não pode finalizar a proposta de bloco de Alice até ver a proposta de bloco de Charlie. Por que? Porque se você finalizar assim que vir a proposta de Bob, é possível que Bob esteja mexendo com você APENAS encaminhando sua proposta para você, e ele realmente planeja deixar de enviar sua proposta para todos os outros, perdendo assim seu slot. Mas no MonadBFT, assim que você vê a proposta de Bob, você pode "especular" finalizar a proposta de Alice porque a proposta de Bob inclui um QC na proposta de Alice, o que é a prova de que 2/3 da rede atestou a proposta de Alice. Mesmo que Bob esteja mexendo com você APENAS encaminhando sua proposta para você, e vai acabar perdendo seu slot, você sabe que uma grande maioria da rede viu a proposta de Alice e, quando eles participarem do procedimento de fallback, assinarão a proposta de Alice novamente. A única maneira de o bloqueio de Alice não ser finalizado é se os validadores se equivocarem e assinarem dizendo que não viram a mensagem de Alice. Essa falha é facilmente provável - assinamos mensagens conflitantes deles. Se a penalidade por equívoco é substancial - e deveria ser - essa finalidade "especulativa" não é realmente tão especulativa. --- Conclusões O MonadBFT é um desenvolvimento extremamente empolgante para o consenso e é um complemento valioso para outras melhorias compostas no Monad, incluindo Execução Assíncrona, Execução Paralela Otimista e MonadDb. Parabéns a @MohammadMJalal1 e @KushalBabel por este avanço significativo. O MonadBFT será implementado em breve no Monad Testnet, que atualmente implementa o Pipelined 2-Phase HotStuff. Para ler mais, consulte a postagem do blog e o artigo vinculados no próximo tweet.