1/x

Estamos orgullosos de presentar nuestro @SuiNetwork: Mysticeti, una profunda inmersión en el nuevo paradigma del consenso.

$Sui = La Primera Ejecución Paralela + Consenso Rápido como el Rayo

y el rápido crecimiento de $Sui ha sido respaldado por una infraestructura tecnológica robusta.
______
Exploremos por qué Mysticeti es tan cautivador.

Reconocimientos: equipo de $Sui @EmanAbio @0xAmoghGupta @weiduong @EvanWeb3 @theharrisonkim y otros.

Reconocimientos: Jefe de investigación de ContributionDAO y otros.

______
Es muy largo, pero ustedes deberían tomarse un tiempo para leerlo y obtener inspiración de esta investigación.
______

Mysticeti

En julio, $Sui anunció un cambio en el uso de Narwhal y Bullshark como su protocolo de consenso a Mysticeti[1]. En este artículo, haré todo lo posible para simplificar el documento de Mysticeti y explicar cómo funciona y por qué fue elegido desde mi perspectiva, mientras conservo las ideas centrales.

Resumen de Narwhal y Bullshark

Para entender la necesidad de Mysticeti, primero revisemos Narwhal y Bullshark. Si estás familiarizado con estos protocolos, siéntete libre de saltar. Para más detalles, consulta las referencias [2], [3] y [4].
Narwhal y Bullshark son protocolos de consenso basados en DAG certificados diseñados para aumentar el rendimiento del sistema al separar la difusión de datos de la lógica de consenso. Narwhal actúa como la capa de mempool, gestionando el flujo de datos, mientras que Bullshark se encarga del consenso. Los validadores interpretan su DAG local construido por Narwhal sin comunicación adicional, lo que significa que el consenso tiene cero sobrecarga de comunicación, mejorando la eficiencia.

A un alto nivel, Narwhal funciona como un mempool que permite a cada validador transmitir mensajes y construir una vista local del DAG. Durante la ronda r, cada validador transmite su bloque (vértice) a otros validadores. Los elementos principales dentro de cada bloque son los siguientes:

1. Una lista de transacciones,
2. 2f+1 certificados de la ronda r-1,
3. La firma del validador.

Al recibir un bloque de otro validador, cada validador verifica la validez del bloque, lo firma y lo envía de vuelta al remitente original. Una vez que un validador recoge firmas de 2f+1 validadores distintos, puede crear un certificado para su bloque y compartirlo con otros. Cuando un validador recibe un certificado, agrega el bloque correspondiente (vértice) a su DAG local.
Un validador pasa a la ronda r+1 después de recibir 2f+1 certificados. La estructura resultante forma un DAG porque cada bloque referencia 2f+1 bloques de la ronda anterior, creando enlaces que se basan en rondas previas.

Figura 1: Estructura de DAG Basada en Rondas en Narwhal

Ahora que tenemos un DAG, podemos interpretarlo usando Bullshark. En Bullshark, un validador intenta comprometer bloques cada dos rondas. Tomando prestado el ejemplo en [4], se selecciona un bloque líder en cada ronda par para ser utilizado en el proceso de compromiso. Por ejemplo, los bloques del Validador 4 (L2) y del Validador 1 (L4) son elegidos como bloques líderes en las rondas 2 y 4, respectivamente.

Figura 2: L2 y L4 son líderes en la ronda 2 y 4, respectivamente, y están coloreados de verde.

En la siguiente ronda impar, los bloques votan por el líder en la ronda anterior, con referencias que sirven como votos. Por ejemplo, el bloque líder L2 de la ronda 2 recibe un voto ya que solo un bloque en la ronda 3 lo referencia. Según la regla de compromiso directo, si un líder recibe más de f+1 votos, él y su historia causal pueden ser comprometidos. Por lo tanto, L4 puede ser comprometido directamente porque recibe 2 votos, mientras que L2 no puede.

Figura 3: Regla de Compromiso Directo en Bullshark