Before we dive in:

Do you like our Thesis Approach to understanding crypto and blockchain tech?

Then Subscribe to our Newsletter and we'll deliver a Thesis every week straight to your inbox:

Guaranteed spam-free:)

Speed Matters!

Speed is a critical factor in user experience, particularly for internet applications, as it directly influences users' perceptions and their subsequent adoption of these technologies.

Users generally perceive response times under 100 milliseconds as instantaneous, while delays exceeding 1 second can disrupt their flow. 

This perception significantly influences their overall experience and satisfaction. For instance, Google found that a delay of just 0.5 seconds in page load time can result in a 20% drop in traffic.

Similarly, in blockchain-based applications, transaction speed and confirmation times are crucial factors in user experience.

Blockchain applications often face challenges in achieving the rapid response times users have come to expect from traditional centralized systems.

That's why being fast is often a big buzzword in the blockchain space. 

But what does 'speed' actually mean?

What does ‘Speed’ in Blockchain Transactions mean?

Basically when we talk about speed, we're really talking about how quickly a transaction can be confirmed and its results known with certainty.

And Speed is one of the most misunderstood concepts in the blockchain space, often used as a marketing buzzword without clear context.

So when we are discussing how fast a blockchain is in confirming transactions, it's important to understand what specific metric is being referenced. Different interpretations of speed exist within the industry, leading to confusion when comparing systems.

When someone mentions a blockchain's speed, they might be referring to block time, transaction finality, or settlement finality, each of which has different implications.

Basically when we talk about speed, we're really talking about how quickly a transaction can be confirmed and its results known with certainty.

Block Time vs. Transaction Finality

Block time is a common metric used to indicate how quickly a blockchain can add new blocks to its chain.

For example, Ethereum has a block time of around 12-14 seconds, while Solana boasts a block time of approximately 400 milliseconds. However, block time alone does not guarantee that a transaction is final and irreversible. It merely indicates how often new blocks are created.

Transaction finality refers to the moment when a user submits a transaction and receives a promise that the transaction will eventually be executed. At this stage, the transaction has not yet been executed; you simply have a guarantee that it will be.

Therefore, neither block time nor transaction finality accurately represents the true speed at which blockchains process transactions.

Settlement Finality: The Gold Standard

Settlement finality is the gold standard for measuring transaction speed. It means that the transaction is confirmed, executed, and its results are known and irreversible.

This is particularly important for applications requiring immediate and irreversible results. Unlike block time or transaction finality, settlement finality provides a clear and definitive measure of transaction completion, making it the cleanest and most reasonable way to think about speed in blockchain systems.

Now the question is: How can you improve the speed of a system? What components can you adjust to achieve the maximum speed possible?

Ok, let’s go down this rabbit hole:)

How to Improve Blockchain Speed: Key Components to Adjust for Maximum Performance

To improve the speed of a blockchain system, developers can focus on two main areas: 

1. Consensus protocols and 

2. Lower-level implementation optimizations.

Here Consensus protocol refers to the high-level rules governing how validators agree on the blockchain's state, while lower-level implementations encompass the underlying technical optimizations that facilitate the protocol's operation.

Now the “lower-level optimizations” might include more efficient data structures, improved networking protocols, or optimized cryptographic operations. These lower-level optimizations can make a noticeable difference in throughput and overall system efficiency. 

However these optimizations often have less impact on transaction speed, as the system is not operating at its capacity limits.

Meaning, these optimizations might shave off milliseconds in processing time, but their impact is often negligible compared to other factors.

This is why consensus protocol is the most critical factor in determining transaction speed. It defines how validators in the network communicate and agree on the state of the blockchain.

The efficiency of the consensus protocol directly impacts transaction speed. In wide-area networks, each round of communication between validators can take approximately 150-200 milliseconds. This means that the number of communication rounds required by the consensus protocol has a significant impact on overall transaction speed.

Once you have implemented a consensus protocol that requires the least rounds of communication, then you can go on and implement the lower-level optimizations to squeeze out maximum efficiency out of the system.

In a bid to outpace the competition, core development teams of top layer 1 blockchains are frantically working to break through speed barriers and enhance efficiency.

Meanwhile one team appears to have cracked the code, launching their speed-optimized consensus protocol, just last week on 'Sui'

Yes, Sui has now swapped out its old 'Narwhal & Bullshark consensus protocol’ with the 'Mysticety consensus protocol'. A step that has dramatically decreased its settlement finality time, cementing Sui's position as a leader in the high-performance blockchain space.

To understand why Mysticeti has decreased its settlement finality time and what improvements it brings in terms of speed, you must first understand how transactions get processed on Sui.

For that, we need to:

1. Dig into the types of transactions on Sui and how they are processed differently.

2. Understand how the previous consensus protocol of Sui, the ‘Narwhal & Bullshark consensus protocol,’ works.

3. What improvements Mysticeti has introduced to decrease the latency to settlement finality to an impressive 390 ms.

So, let's take a look at each of these aspects one by one.

1. Types of Transactions on Sui

Transactions on the Sui blockchain are categorized into two main types: owned object transactions and shared object transactions.

1. Owned Object Transactions: These transactions involve objects owned by a single address. Examples of owned object transactions include coin balance transfers, certain NFT minting operations, and some in-game logic asset management creations. Since only one entity has control, these transactions can be processed independently without requiring consensus.

2. Shared Object Transactions: These transactions involve objects that multiple addresses can access and modify, such as a liquidity pool in a decentralized exchange. These transactions need to be sequenced before execution, requiring consensus to ensure the correct order and integrity of changes.

Here’s a Step-by-Step Journey of a Transaction from Submission to Execution

The processing of both transaction types follows a two-phase protocol.

In the first phase of owned object transactions, the user constructs and signs the transaction, then broadcasts it to the validators.

The validators perform validation without execution, promising to execute the transaction in the future when instructed. Once the user receives responses from a majority of validators (a quorum), they create a transaction certificate.

For owned object transactions, the second phase involves sending this certificate back to the validators. After execution and receipt of a quorum of responses, the user obtains an effects certificate, signifying that the transaction has been executed and its results are irreversibly on the chain.

Meaning, the transaction can be executed immediately without waiting for consensus.

This process typically requires two Round Trip Times (RTTs).

TLDR: RTT is the duration it takes for a signal to travel from a source to a destination and back.

In blockchain networks, RTT refers to the time required for a message to travel between nodes and receive a response, typically measured in milliseconds (ms). In wide-area networks, a single RTT usually ranges from 150 to 200 ms, though it can vary based on network conditions and distance.

Shared object transactions follow a similar first phase, but the second phase differs.

The validators must send the transaction certificate through the consensus process before execution. After sequencing, validators can execute the transaction. The user receives the effects certificate once a quorum of responses is obtained, confirming the transaction's on-chain status.

The consensus process is where the opportunity for latency improvement lies. 

Currently, the best-case scenario for the consensus process is approximately 4.5 RTTs. With the previous Narwhal and Bullshark consensus protocol, the entire path for shared object transactions took about 6.5 RTTs.

So, let's take a deeper look at the Narwhal & Bullshark consensus protocol and how Mysticeti is reducing the number of RTTs to make the consensus process faster.

2. Understanding Sui’s Narwhal & Bullshark Consensus Protocol

When discussing the Narwhal & Bullshark consensus protocol, it's important to understand the broader landscape of consensus mechanisms in the blockchain space.

There are consensus protocols with probabilistic finality (e.g. Bitcoin’s Nakamoto consensus protocol) and deterministic finality, aka fast finality (e.g. PBFT) 

Here, we are talking about fast finality and those consensus protocols with fast finality, which are further divided into linear and DAG-based protocols.

So let’s take a look at the linear and DAG-based protocols.

Linear Consensus Protocols

Linear protocols, such as PBFT (Practical Byzantine Fault Tolerance), Tendermint, and HotStuff, rely on a leader to coordinate the consensus process.

In these protocols, a designated leader node is responsible for gathering transactions, creating blocks, collecting votes or validations for those blocks, and then including them in the blockchain. This process is repeated continuously, forming a linear sequence of blocks, hence the term "linear-based."

The key advantage of linear protocols is their low latency in ideal conditions. The standard PBFT is achieving the latencies of two, three RTTs. This makes them suitable for certain applications.

However, linear-based protocols have several inherent limitations. For example, the leader node often becomes a bottleneck due to the disproportionate amount of work it must perform compared to other nodes in the network. This can limit the overall throughput of the system.

Also, these protocols require strong connectivity with the leader node. If the leader crashes or becomes unavailable, the network must elect and agree on a new leader, a process that can be complex and time-consuming, during which the network may be unable to process new transactions.

DAG-Based Consensus Protocols

DAG-based (Directed Acyclic Graph) protocols, such as the one used in Sui, take a different approach.

Instead of relying on a single leader, these protocols allow all nodes in the network to propose blocks concurrently. 

This leaderless design leads to full utilization of network bandwidth and resources, as the workload is distributed evenly across all nodes.

DAG-based protocols separate the process of transaction dissemination (building the DAG) from the commit logic (reading the DAG and finalizing transactions). This separation allows for continued block proposals even if there are issues with the commit process, maintaining high throughput.

However, this approach typically results in higher latency compared to linear protocols like PBFT.

So, let's take a look at how the Narwhal & Bullshark protocol works and what improvements Mysticeti has introduced to decrease the latency to settlement finality.

Here’s How Narwhal & Bullshark Consensus Protocol Works

Narwhal: This protocol handles the mempool, managing the collection and dissemination of transaction data.

It uses a DAG structure to organize transactions, allowing validators to independently process and store transaction batches.

This process involves three steps within each round:

1. Proposing a Block: Validators propose new blocks containing transactions.

2. Voting on the Block: The network votes on the proposed block. This involves sending network messages to gather votes.

3. Creating a Certified Block: Once enough votes are collected, a certificate or certified block is created and broadcasted to the network.

These steps require three network messages per round, resulting in approximately 1.5 RTTs per round.

Bullshark: Built on top of Narwhal's DAG, Bullshark handles the ordering of transactions. It ensures that transactions are ordered correctly without additional message exchanges between validators.

This protocol addresses common issues in DAG-based consensus systems, such as memory management and fairness, by implementing garbage collection and ensuring fair participation of all validators.

This process operates in two phases:

1. Leader Election: Every even round, a leader is elected to coordinate the commit process.

2. Voting for the Leader: In the odd rounds, the network votes for the leader. If there are enough links to the block from the previous round, the block can be committed.

In an optimal scenario, at least two rounds are needed to commit a block, which translates to about 3 RTTs.

So with Narwhal and Bullshark consensus protocol, which Sui initially used, typically results in a latency of 2 seconds for shared object transactions. (The latency for owned object transactions is approximately 250 milliseconds.)

It has been live and running on the Sui network for more than a year now without any glitches. 

Imagine being the fastest L1 already and pushing out an update to make your last record look small.

They have now come up with the Mysticeti consensus protocol, or Consensus 2.0, for Sui, which achieves a transaction latency of 390 milliseconds for shared object transactions, making Sui the fastest blockchain in the world.

So, let’s take a look at how they have achieved this feat.

Mysticeti: Reaching the Latency Limits with Uncertified DAGs

The fundamental question that spurred the creation of Mysticeti is: in what ways can the efficiency of the consensus process be optimized?

What if blocks could be optimistically sent to the network without the need for certification?

Basically this concept forms the foundation of Mysticeti. 

Mysticeti introduces the idea of optimistically propagating uncertified blocks within the network. 

Understanding Uncertified DAG

Unlike Narwhal, which constructs a certified DAG through a three-step process (propose, vote, certify) per round, Mysticeti builds an uncertified DAG.

Meaning, there is no notion of certification or counter-signatures from other nodes. Instead, each node simply creates a block and adds it to the DAG, referencing the previous block in the process.

This approach eliminates the need for explicit certification steps, reducing message delays per round from three to one, thereby significantly improving the overall speed of the consensus process. 

So, let's take a look at how all of this works in a step-by-step manner.

Step 1: Block Creation

In Mysticeti, each validator node in the system gathers transactions from users.  

Once enough transactions are collected or a timeout is reached, the node creates a block containing the transactions, the block author's name, and a round number that increments each time that node creates a block.

Step 2: DAG Structure Rules

Mysticeti’'s DAG structure is built using three simple rules:

2f+1 refers to a quorum size necessary to achieve consensus. Here, "f" represents the number of faulty or Byzantine nodes in the system, and "2f+1" represents the minimum number of nodes required to agree on a decision to ensure that the system remains fault-tolerant.

Rule 1: Adding Hash Links to a Quorum of Parents

When a node creates a block, it adds a quorum of hash links to blocks from the previous round. These blocks must be authored by a quorum of different committee members. This ensures that the node has a quorum size necessary to achieve consensus.

Rule 2: Every Node Waits and Links to Leaders

If a node is creating a block in a round with a leader in the previous round, it will wait to try to include that leader block as a parent. This helps to ensure that leader blocks are properly linked and included in the DAG structure.

Rule 3: All Nodes Run in Parallel

All nodes operate in parallel, creating blocks, including a quorum of parents if possible, linking to leader blocks, and propagating their blocks to other nodes.

Now that we've explored the construction of the uncertified DAG, how do validators in the system ensure that their proposed blocks are agreed upon and added to the DAG?

So let’s take a look at how that works!

Step 3: Interpreting the DAG

Validator nodes interpret the DAG structure locally to drive consensus, without relying on secondary messages like signatures or certificates.

There are two key patterns that nodes observe in the DAG:

1. Certificate Pattern: This pattern resembles a consensus certificate. Nodes validate blocks by linking them to previous blocks with enough confirmations from other nodes, ensuring that each new block has a certain level of trust before being accepted.

2. Blame Pattern: This pattern is used to handle faults. If a block is not sufficiently validated or there are missing links to it, it is marked with a blame pattern. This helps the protocol identify and skip faulty or malicious blocks, ensuring that the system can proceed even if some nodes or blocks are not behaving correctly.

Why These Patterns Matter

The key insight here is that nodes interpret the DAG structure locally, and determine whether a leader block should be committed or skipped without relying on external information. 

This approach enables a more efficient and scalable consensus mechanism, as nodes can make decisions based on their local view of the DAG.

Now let’s take a look at the core consensus process👇

Step 4: Consensus Process

The ultimate goal of the consensus process is for all honest nodes to output the same sequence of leader blocks. This sequence enables the sequencing of all blocks, ensuring a consistent and reliable ordering of transactions.

To achieve this goal, nodes follow a series of steps to interpret the DAG structure.

First, the DAG is organized into waves of 3 rounds each, labeled ‘Propose, Vote, and Certify’.

Each wave has a leader in the proposed round, which helps to facilitate the consensus process.

Round 1: Propose

• In this initial round, a leader is predetermined based on public parameters.

• This leader proposes a new block by collecting user transactions and signing the block.

• The proposed block includes links to a sufficient number of blocks from the previous rounds (2f + 1 links) to ensure consistency and reference to prior state.

Round 2: Voting

• In this round, validators (nodes) vote on the block proposed in the proposal round.

• Each validator checks the validity and integrity of the proposed block, ensuring it adheres to the protocol rules and includes the necessary links to previous blocks.

• Validators then cast their votes by creating their own blocks that include references to the leader’s proposed block.

• These vote messages are broadcasted to other validators in the network.

​​Round 3: Certify

• Vote Collection: Validators collect the vote messages for the block proposed in Round 1.

• Block Certification: If a block receives enough votes (typically 2f + 1 votes, where f is the number of tolerated Byzantine faults), it forms a certificate. This certification marks the block as valid and ready for potential commitment.

• Decision Making: Validators now decide whether the block should be committed or skipped.

To decide where to committed or skip a block, Mysticeti employs two main commit decision rules:

1. Direct Decision Rule: This rule is used to determine whether a leader should be committed or skipped. 

2. Indirect Decision Rule (for undecided blocks): This rule looks for a future committed leader.

The direct decision rule is applied first in the certification round.

• Certificate Pattern Check: Validators check if there are 2f + 1 certificate patterns for the proposed block. If this condition is met, the block is labeled as "to commit."

• Blame Pattern Check: If the certificate pattern condition is not met, validators check if there are 2f + 1 blame patterns (indicating that the block cannot be certified due to issues). If this condition is met, the block is labeled as "to skip."

This rule is used to quickly identify leaders that do not have the necessary support and skip them, allowing the system to move forward with the next leader.

When neither condition is met, If neither the certificate pattern nor the blame pattern conditions are met, the indirect decision rule is applied.

Indirect Decision Rule: This rule checks if there's a path from a future committed leader to the undecided block that passes through a certificate. If such a path exists, the block is committed. If not, it's skipped.

• Anchor Identification: Validators identify the anchor, which is the first leader block after the wave that is either labeled "to commit" or still undecided. An anchor in this context is like a reference point that helps validators make decisions about whether to commit or skip a block when the usual direct checks don't provide a clear answer.

• Certificate Pattern from Anchor: Validators check if there is a certificate pattern linking the anchor to the current block. If this condition is met, the block can be labeled as "to commit." If not, it is labeled as "to skip." 

Step 5: Determining Final Order of Blocks

Once the commit rule is run for these leader blocks, the final order of the blocks can be determined.

This is determined in a way that ensures not only low latency but also:

• Consistency: All nodes in the network agree on the same sequence of blocks.

• Reliability: The ordering of transactions is reliable and consistent.
  

  But this is not the end of the story.

Till now, you have seen how the  whole consensus process involves three rounds of waiting for a commit decision. But what if there was a way to cut down on this waiting time?

Here Mysticeti brings to the table some clever optimizations that can significantly cut down on this waiting time to enhance efficiency.

Introducing ‘Universal Commit Rule’ for Faster Consensus

The Universal Commit Rule is a mechanism that allows any block in the DAG to be committed as the leader, reducing the overall latency for reaching consensus.

Here’s a breakdown of its key components and how they contribute to faster consensus:

1. Pipelining

In traditional consensus processes, nodes wait for 3 rounds to make a commit decision.

Pipelining involves starting multiple waves of interpretation, each offset by one round. 

With pipelining Instead of waiting for one wave of ‘propose-vote-certify’ to complete before starting the next, pipelining initiates subsequent waves while the previous ones are still in progress. 

This reduces the waiting time for each round's leader to be committed, effectively tripling the rate at which blocks can be committed and creates a steady stream of chances to commit blocks. 

In fact, there's a chance to commit a leader block every single round. 

Then the multi-leader proposal feature further accelerates the process.

2. Multi-Leader Proposals

Mysticeti also introduces multi-leader proposals, which allow for multiple leaders to propose blocks within the same round.

This means that rather than having a single leader propose a block per round, the protocol allows multiple leaders (e.g., L1a, L1b, L1c) to make proposals simultaneously. These proposals are ranked and processed concurrently.

This increases the likelihood of at least one leader’s block being committed quickly, thus speeding up the overall process, especially in scenarios where network conditions are optimal,

It also enhances fault tolerance, as the failure of one leader does not stall the entire round.

Along with that the protocol increases the anchor points to provide more opportunities to apply the commit rule.

Increasing Anchor Points

Anchor points serve as reference points from which the protocol can evaluate and determine the status of blocks to be committed.

In traditional DAG-based protocols, there is typically a single leader or anchor point that is responsible for running the commit rule.

By increasing the number of anchor points, the protocol can evaluate and commit blocks from multiple starting points in the DAG. This ensures that even if some blocks are undecided, there are other blocks from which the commit process can continue.

This improves the resilience and efficiency of the consensus process, as it reduces the dependency on any single leader or anchor point. It also helps in maintaining high throughput under varying network conditions.

This is because the commit rule ensures that all nodes in the network agree on the same sequence of blocks, allowing for a consistent and reliable ordering of transactions.

I know, this has been an exhausting write-up. But if you reached this far, then now you get to see the tangible efficiency gains Mysticeti has brought to Sui.

Performance Showdown: Mysticeti vs. Narwhal & Bullshark

In terms of latency, Narwahl & Bullshark (Consensus 1.0) required approximately 6 message delays to commit under optimal networking conditions, with an estimated average latency of 4.5 Round Trip Times (RTTs). 

In contrast, Mysticeti (Consensus 2.0) achieves commits with just 3 message delays, theoretically reducing average latency to about 2 RTTs.

Benchmarking results show an approximately 80% reduction in average latencies compared to the Mainnet running Narwhal & Bullshark.

Meaning Mysticeti has now reduced the network latency to consensus to 0.39 seconds in comparison to 2 seconds with Narwahl & Bullshark.

From my personal point of view, such a groundbreaking protocol, which is very UX oriented, was expected to be delivered by @mystenlabs.

Until now, the blockchain space was never known for user-oriented features, but the brains at Mysten Labs are one of the most laser-focused teams when it comes to implementing features that give the best user experience, and with Mysticeti, users can now enjoy lightning-fast speeds on Sui.

And these user-experience-oriented features do not stop with Mysticeti.

If you want to know how they made accessing crypto as simple as sending an email with zkLogin, here’s an article that will tell you more about zkLogin 👇

OK, that was a long one 😇 

I hope you found it valuable,

until next week with another thesis driven deep dive,

Sooraj

Subscribe to our Newsletter and we'll deliver a Thesis every week straight to your inbox:

Guaranteed spam-free:)