Resumindo o avanço na MonadBFT Ontem, a Category Labs divulgou o artigo MonadBFT, descrevendo o mecanismo de consenso que alimentará a Monad na mainnet. MonadBFT é um desenvolvimento significativo na pesquisa de consenso, uma vez que é a primeira vez que o Pipelined HotStuff se torna resistente à falsificação da cauda. A bifurcação da cauda ocorre quando uma ranhura perdida faz com que a proposta anterior seja descartada e reextraída. É um problema grave em formulações anteriores do Pipelined HotStuff, uma vez que abre ataques MEV multibloco que desestabilizam o consenso. Aliviar este problema é um grande negócio porque nos dá todos os benefícios do Pipelined HotStuff - blocos frequentes, baixa latência, grandes conjuntos de validadores - evitando a maior desvantagem. MonadBFT também oferece um enorme upgrade para finalidade. Apresenta uma finalidade especulativa de slot único (500 ms) e uma finalidade rígida de dois slots (1s). "Finalidade especulativa" significa "finalidade que só será revertida em caso de equívoco (dupla assinatura) pela maioria dos validadores". O equívoco é uma ofensa grave na maioria dos sistemas blockchain e é comumente penalizado com cortes; Quanto maior a pena por equívoco, mais próximo se pode pensar em "finalidade especulativa" da finalidade. A finalidade especulativa de um slot é um enorme desbloqueio para aplicativos de alto desempenho, que podem exibir com confiança o estado atualizado do mundo imediatamente após o próximo bloco ser recebido. Essas propriedades tornam o MonadBFT um grande avanço no consenso e um complemento digno de outras melhorias de composição no Monad, incluindo Execução Assíncrona, Execução Paralela Otimista e MonadDb. O resto deste artigo serve como um resumo de como as sucessivas melhorias no HotStuff se construíram umas sobre as outras, a fim de explicar o problema que o MonadBFT resolve. Resumindo: 1. O HotStuff nos dá complexidade de comunicação linear para que possamos ter grandes conjuntos de validadores, mas não é muito eficiente 2. Pipelined HotStuff nos dá eficiência e baixa latência de propor blocos a cada slot, mas sofre com o problema de garfos de cauda 3. MonadBFT dá-nos resistência tail-fork e finalidade especulativa de um slot --- HotStuff: A complexidade da comunicação linear permite grandes contagens de nós Os algoritmos do HotStuff completam-se ao longo de várias rondas 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 cada um envia 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 bloco - 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 do final, o bloqueio não é finalizado e é descartado; As transações desse bloco terão de ser reincluídas no bloco seguinte. O protocolo HotStuff original não tem pipelining e tem 3 rodadas de comunicação antes da finalização; O mesmo validador desempenha o papel de líder para cada rodada. --- Pipelined HotStuff: Um novo bloco a cada slot aumenta a eficiência Pipelining é o que todos 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, na tubulação colocamos a carga 1 no secador 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 roupa (não comece na carga 2 até que a carga 1 esteja completamente concluída), enquanto o Pipelined HotStuff está fazendo o comportamento intuitivo de progredir várias cargas de lavanderia de forma escalonada. No Pipelined HotStuff escalonamos propostas, de modo que há um novo bloco proposto a cada rodada, com o novo bloco pegando carona em cima da mensagem carregando o QC do bloco anterior. As propostas em bloco avançam para a finalização ao longo de várias rodadas. Os benefícios da tubulação são significativos. O pipelining aumenta a densidade de propostas de blocos, uma vez que uma proposta de bloco é feita em cada slot, o que aumenta a taxa de transferência e reduz o tempo até a finalização. No entanto, há uma grande desvantagem da tubulação, que é melhor ilustrada com um exemplo. Suponha que os líderes dos blocos N, N+1 e N+2 são Alice, Bob e Charlie. Se Bob perder sua vaga, então a proposta de Alice também será invalidada, porque a mensagem de Bob carrega sua proposta e um QC 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 este comportamento como "tail-forking", e pode ser pensado como uma mini-reorganização de profundidade 1. A possibilidade de furar a cauda tem consequências significativas, porque a perda de slots não é necessariamente por acidente. Se houver uma oportunidade de extrair valor reminerando 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 reminerar o bloco de Alice. Esta tem sido uma desvantagem significativa dos protocolos Pipelined HotStuff (alguns dos quais estão na mainnet hoje). --- MonadBFT muda isso MonadBFT é o primeiro protocolo a permitir pipelining enquanto torna o algoritmo de garfo de cauda resistente. Essa resistência ao garfo de 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, sob MonadBFT, se Bob perder seu slot, então o procedimento de fallback tem validadores se comunicando uns aos outros com atestados assinados informando se viram o bloco de Alice. Se a supermaioria atesta o bloqueio de Alice, então Charlie é forçado a propor novamente o bloqueio de Alice. Se Charlie deseja propor um bloco diferente, então ele deve fornecer um atestado assinado da maioria dos validadores atestando que não viu o bloco de Alice a tempo. No caso típico em que Charlie volta a propor o bloco de Alice, ele então começa a propor seu bloco na rodada seguinte. O resultado são duas propriedades importantes: resistência à bifurcação da cauda e finalidade especulativa de um único slot. Já falamos sobre a resistência à bifurcação, mas vamos entender o impacto na finalidade. Como antes, assuma que os líderes dos blocos N, N+1 e N+2 são 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. Porquê? Porque se você finalizar assim que vir a proposta do Bob, é possível que o Bob esteja mexendo com você APENAS encaminhando sua proposta para você, e ele realmente planeja não enviar sua proposta para todos os outros, perdendo assim seu slot. Mas na MonadBFT, assim que você vê a proposta de Bob, você pode finalizar "especulativamente" a proposta de Alice porque a proposta de Bob inclui um QC sobre a proposta de Alice, o que é 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 supermaioria 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 equivocarem e assinarem dizendo que não viram a mensagem de Alice. Esta falha é facilmente demonstrável - nós assinamos mensagens conflitantes deles. Se a sanção por equívoco é substancial - e deveria ser - esta finalidade "especulativa" não é, na verdade, tão especulativa assim. --- Conclusões O MonadBFT é um desenvolvimento extremamente empolgante para o consenso, e é um complemento digno de 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, veja a postagem e o artigo do blog vinculados no próximo tweet.