1/x

Estamos orgulhosos de apresentar nossa @SuiNetwork : Mysticeti, uma análise aprofundada do novo paradigma de consenso.

$Sui = A Primeira Execução Paralela + Consenso Relâmpago

e o crescimento rápido da $Sui tem sido sustentado por uma infraestrutura tecnológica robusta.
______
Vamos explorar por que Mysticeti é tão cativante.

Parabéns : equipe $Sui @EmanAbio @0xAmoghGupta @weiduong @EvanWeb3 @theharrisonkim e outros

Parabéns : Chefe da pesquisa ContributionDAO e outros

______
É longo, mas vocês deveriam ter um tempo para ler e se inspirar nesta pesquisa
______

Mysticeti

Em julho, a $Sui anunciou uma mudança do uso de Narwhal e Bullshark como seu protocolo de consenso para Mysticeti[1]. Neste artigo, farei o meu melhor para simplificar o documento do Mysticeti e explicar como o Mysticeti funciona e por que foi escolhido, da minha perspectiva, preservando as ideias centrais.

Recapitulando Narwhal e Bullshark

Para entender a necessidade do Mysticeti, vamos primeiro revisar o Narwhal e o Bullshark. Se você está familiarizado com esses protocolos, sinta-se à vontade para pular adiante. Para mais detalhes, veja as referências [2], [3] e [4].
Narwhal e Bullshark são protocolos de consenso baseados em DAG certificados, projetados para aumentar a capacidade do sistema ao separar a disseminação de dados da lógica de consenso. Narwhal atua como a camada de mempool, gerenciando o fluxo de dados, enquanto Bullshark lida com o consenso. Os validadores interpretam seu DAG local construído pelo Narwhal sem comunicação adicional, o que significa que o consenso tem zero sobrecarga de comunicação, melhorando a eficiência.

Em um nível alto, o Narwhal funciona como um mempool que permite que cada validador transmita mensagens e construa uma visão local do DAG. Durante a rodada r, cada validador transmite seu bloco (vértice) para outros validadores. Os principais elementos dentro de cada bloco são os seguintes:

1. Uma lista de transações,
2. 2f+1 certificados da rodada r-1,
3. A assinatura do validador.

Ao receber um bloco de outro validador, cada validador verifica a validade do bloco, assina e o envia de volta ao remetente original. Uma vez que um validador coleta assinaturas de 2f+1 validadores distintos, ele pode criar um certificado para seu bloco e compartilhá-lo com os outros. Quando um validador recebe um certificado, ele adiciona o bloco correspondente (vértice) ao seu DAG local.
Um validador avança para a rodada r+1 após receber 2f+1 certificados. A estrutura resultante forma um DAG porque cada bloco referencia 2f+1 blocos da rodada anterior, criando links que se baseiam em rodadas anteriores.

Figura 1: Estrutura de DAG Baseada em Rodadas no Narwhal

Agora que temos um DAG, podemos interpretá-lo usando o Bullshark. No Bullshark, um validador tenta comprometer blocos a cada duas rodadas. Pegando como exemplo o [4], um bloco líder é selecionado em cada rodada par para ser usado no processo de compromisso. Por exemplo, os blocos do Validador 4 (L2) e do Validador 1 (L4) são escolhidos como blocos líderes nas rodadas 2 e 4, respectivamente.

Figura 2: L2 e L4 são líderes nas rodadas 2 e 4, respectivamente, e estão coloridos em verde.

Na rodada ímpar seguinte, os blocos votam no líder da rodada anterior, com referências servindo como votos. Por exemplo, o bloco líder L2 da rodada 2 recebe um voto, já que apenas um bloco na rodada 3 o referencia. De acordo com a regra de compromisso direto, se um líder recebe mais de f+1 votos, ele e sua história causal podem ser comprometidos. Assim, L4 pode ser comprometido diretamente porque recebe 2 votos, enquanto L2 não pode.

Figura 3: Regra de compromisso direto no Bullshark