It’s the latency, you stupid! Changes that Mysticeti will bring.

1. Background

Sui Network, which introduced the groundbreaking concept of an “Object-Centric Move Programming Language,” has made a significant impact in the market and has now been over a year since it launched its mainnet. Sui has achieved remarkable growth in the past year, as evidenced by its ranking as the third among Layer 1 blockchains in terms of daily active users.

Why has Sui grown so rapidly? In my view, their technical innovations have attracted many builders and users. While Sui’s unique Move language brought tremendous innovation by changing the traditional account-based storage model to an object-centric one, what intrigued me the most as an infrastructure researcher was Sui’s consensus protocol.

Having seen numerous blockchains built on the Cosmos SDK (not to criticize or denounce them, but from an infrastructure researcher’s perspective, it does get monotonous), encountering a consensus protocol built from scratch was profoundly impactful. Notably, Sui’s consensus model stands out for two key reasons: 1) it was one of the first attempts to separate mempool from the consensus, and 2) it addressed the issues inherent to DAGs in a practical way, effectively solving the problem of scalability.

But what does it mean to have solved the “scalability” issue? Let’s take a closer look at Sui’s consensus and mempool model.

In Sui's mempool protocol, Narwhal, there are entities called workers and primaries. In this article, let's focus more on the workers.

As shown in the diagram, workers are responsible for batching transaction data received from clients and then transmitting the hash of these batches to the workers and primaries of other validators. Essentially, workers handle the reception of transactions from clients. An interesting aspect of Narwhal is that validators can add as many worker machines as needed.

To explain more simply, in Sui, which uses Narwhal as its mempool protocol, validators can add worker machines according to the real-time demand on the network. This theoretically eliminates the problem of transaction throughput. If there is a sudden surge in transactions, validators can add more worker machines to process them. Conversely, if transaction demand decreases, they can reduce the number of worker machines to optimize costs. Therefore, in Sui, the scalability issue is virtually non-existent.

So, is Sui the perfect blockchain? Of course not. While scalability is important when discussing blockchain speed, the metric that actually affects the user interface and experience (UI/UX) is latency. If scalability concerns "how many transactions can be processed," latency deals with "how quickly transactions can be finalized." Hence, the latency is what users directly experience, and this issue cannot be resolved with the worker machine structure of Narwhal.

Where should the latency problem be addressed? It needs to be resolved at the consensus level. Let's examine Sui's consensus protocol up to now.

Until now, Sui has been using the Bullshark consensus. Although Bullshark is considered a significant advancement over traditional Byzantine Fault Tolerant (BFT) systems, its limitations are clear. According to the Mysticeti paper, the Bullshark consensus can process an average of 60,000 to 80,000 transactions per second, but it has a critical drawback of latency that can reach up to 10 seconds in the worst case. Ultimately, to overcome this, a change at the consensus level was necessary, leading to the forthcoming announcement of Mysticeti.

(The above graph shows the trend of changes in the median network latency due to the transition in consensus from Bullshark to Mysticeti. It is very impressive that while Bullshark resulted in approximately 2 seconds of latency, changing the consensus to Mysticeti reduced this to about 0.39 seconds.)

Mysticeti focuses on addressing three inefficiencies found in Bullshark, as outlined in the Mysticeti paper. The identified issues with Bullshark are as follows:

First, Bullshark introduces latency during the transaction certification process. Validators need to propagate blocks, obtain signatures, and re-propagate certificates, resulting in higher latency compared to existing consensus protocols. Second, Bullshark commits blocks based on the start and end of a wave, causing latency because blocks cannot be committed until the wave finishes. Here, a wave refers to the combined propose, vote, and certify rounds. Lastly, for a block to be certified in Bullshark, it must receive signatures from a majority of validators. This not only consumes CPU resources but also places a heavy burden on validators, especially those lagging in synchronization, thereby increasing latency.

Ultimately, all three issues lead to increased latency, and Mysticeti was developed to address these problems. So, how does Mysticeti solve these issues?

Firstly, Mysticeti reduces the latency in block certification and commitment processes through the use of Implicit Certificates. An Implicit Certificate means that the DAG inherently contains the certificate, eliminating the need for additional certificate issuance. Thus, blocks can be committed based on the embedded certificate without sending extra messages, leading to fewer message delays compared to Bullshark. While Bullshark experiences six message delays (commitment occurs over two rounds, each comprising propose, vote, and certify processes), Mysticeti only has three message delays (since it doesn't require separate certificates, only the block needs to be sent. Therefore, each round incurs one message delay, and commitment occurs over approximately three rounds).

Moreover, Mysticeti uses pipelining, allowing new waves to start before the previous ones finish. This differs from Bullshark, where blocks cannot be committed until the current wave completes, contributing to Mysticeti's reduced latency.

Lastly, Mysticeti employs a Universal Commit Rule, enabling multiple leaders to commit their blocks within a single round. Blocks can be committed or skipped based on their signatures alone, without requiring a majority of validators to sign off on each block, allowing network commitment without excessive validator overhead.

Through these solutions, Sui can maintain the number of validators while still processing large volumes of transactions, achieving a significant reduction in latency to under 0.5 seconds. Until now, it was believed that throughput and low latency couldn't be achieved simultaneously. Mysticeti’s accomplishment of both is remarkable.

2. Takeaway

Sui is a fascinating project in many aspects. From consensus to programming language, they haven't relied on anything they didn't create themselves. Yet, what impresses me the most is their relentless pursuit of improvement and development in their blockchain.

I believed that blockchain technology had stagnated since Tendermint. While this indicates the significant technological advancements brought by Tendermint, it also suggests that despite its areas needing improvement, no one stepped forward to address these issues. In an open-source market, investing massive capital and manpower into infrastructure improvements may seem inefficient because it’s uncertain whether the innovator will benefit from the market(because anyone can emulate the innovation from day1).

In this context, Sui continues to research new consensus methods. Mysticeti, the latest introduction, represents the pinnacle of this research. While blockchains like Sei have reduced latency to below 0.5 seconds, they only have 40 validators, which is somewhat limiting. However, Sui has achieved a latency of under 0.5 seconds while maintaining its existing number of 150 validators through Mysticeti, which is remarkable.

I describe "network scalability" as the "ceiling of imagination." The worst development environment is one where developers must consider network scalability limitations while creating something. In this context, the achievements of the Mysticeti upgrade lay the foundation for more diverse applications within the Sui ecosystem. Projects demanding immense network scalability, like Spam or Mine, have already been created on Sui. I look forward to seeing even more creative and groundbreaking applications implemented on Sui in the future.

Moreover, I hope the Sui team does not cease their research efforts. Such research benefits not only the Sui network but also the blockchain industry as a whole. I hope this virtuous cycle continues.

3. Resource

Related Articles, News, Tweets etc. :

• Mysticeti Explained by Arun - https://x.com/Kloshy/status/1814344750021128302

• Sui: Why Do We Need Another Layer 1? - https://4pillars.io/en/articles/sui-network/public

• MYSTICETI: Reaching the Latency Limits with Uncertified DAGs - https://arxiv.org/pdf/2310.14821