1/x

We are proud to present our @SuiNetwork : Mysticeti, a deep dive into the new paradigm of consensus.

$Sui = The First Parallel Execution + Lightning Fast Consensus

and $Sui's rapid growth has been underpinned by robust technological infrastructure.
______
Let's explore why Mysticeti is so captivating.

Kudos : $Sui team @EmanAbio @0xAmoghGupta @weiduong @EvanWeb3 @theharrisonkim and others

Kudos : Head of ContributionDAO research and others

______
It's so long but you guys should have a time to read it for getting inspirations from this research
______

Mysticeti

In July, $Sui announced a shift from using Narwhal and Bullshark as their consensus protocol to Mysticeti[1]. In this article, I will do my best to simplify the Mysticeti paper and explain how Mysticeti works and why it was chosen from my perspective, while preserving the core ideas.

Narwhal and Bullshark Recap

To understand the need for Mysticeti, let’s first review Narwhal and Bullshark. If you’re familiar with these protocols, feel free to skip ahead. For more details, see references [2], [3], and [4].
Narwhal and Bullshark are certified DAG-based consensus protocols designed to boost system throughput by separating data dissemination from consensus logic. Narwhal acts as the mempool layer, managing data flow, while Bullshark handles consensus. Validators interpret their local DAG constructed by Narwhal without additional communication, meaning the consensus has zero communication overhead, improving efficiency.

At a high level, Narwhal functions as a mempool that allows each validator to broadcast messages and build a local view of the DAG. During round r, each validator broadcasts its block (vertex) to other validators. The main elements within each block are as follows:

1. A list of transactions,
2. 2f+1 certificates from round r-1,
3. The validator’s signature.

Upon receiving a block from another validator, each validator verifies the block’s validity, signs it, and sends it back to the original sender. Once a validator collects signatures from 2f+1 distinct validators, they can create a certificate for their block and share it with others. When a validator receives a certificate, they add the corresponding block (vertex) to their local DAG.
A validator moves to round r+1 after receiving 2f+1 certificates. The resulting structure forms a DAG because each block references 2f+1 blocks from the previous round, creating links that build on prior rounds.

Figure 1: Round-Based DAG Structure in Narwhal

Now that we have a DAG, we can interpret it using Bullshark. In Bullshark, a validator attempts to commit blocks every two rounds. Borrowing from the example in [4], a leader block is selected in each even round to be used for the commit process. For instance, the blocks of Validator 4 (L2) and Validator 1 (L4) are chosen as leader blocks in rounds 2 and 4, respectively.

Figure 2: L2 and L4 are leaders at round 2 and 4, respectively, and are colored in green.

In the following odd round, blocks cast votes for the leader in the previous round, with references serving as votes. For example, the leader block L2 from round 2 receives one vote since only one block in round 3 references it. According to the direct commit rule, if a leader receives more than f+1 votes, it and its causal history can be committed. Thus, L4 can be directly committed because it receives 2 votes, whereas L2 cannot.

Figure 3: Direct commit rule in Bullshark