Sui: Why Do We Need Another Layer 1?

Key Takeaways

• We have now reached an era where it is extremely difficult for Layer 1 blockchains to gain PMF(product market fit)simply by creating new narratives with existing technologies. Only fundamentally different technologies can justify the existence of a new Layer 1.

• In this respect, the Sui Network is very noteworthy. It has innovative features in consensus, mempool, and even in its programming language.

• Particularly, functions like zkSend and zkLogin seem to showcase how blockchains for the mass should evolve. Sui, by introducing these technologies at the forefront of the market, might just justify its existence as a new Layer 1.

Blockchain is inherently built on an open-source ecosystem, and due to the nature of open-source, products can be easily replicated. This leads to a situation where, if a certain sector or industry is deemed promising, numerous people enter the market, launching similar products and competing. This is likely why we witnessed a surge of Layer 1 blockchains entering the market in 2021 and 2022. Now, this phenomenon has shifted to Layer 2, with countless Layer 2 chains emerging. Does this mean that building a Layer 1 blockchain is no longer significant? Certainly, creating a new Layer 1 blockchain is very challenging and costly, and we are no longer in an era where mass-produced Layer 1 blockchains can gain attention as before. However, I still believe there are opportunities for Layer 1 blockchains in the market, assuming they offer technological differentiation.

I feel that the blockchain infrastructure sector is now facing a crucial phase. No market has ever sustained a continuous coexistence of numerous infrastructures. Ultimately, blockchain will also likely see ongoing competition among a few major infrastructures (although innovative infrastructures may occasionally disrupt the landscape). From this perspective, upcoming Layer 1 blockchains must continuously prove how they differ from existing ones and why they can coexist with other Layer 1 blockchains.

As someone who believes Layer 1 blockchains, especially integrated blockchains, will hold significant market share in this industry, I'm particularly interested in this cycle's Layer 1 blockchains with technological distinctions. Interestingly, many of these have quite innovative designs. One such blockchain I'd like to introduce is the Sui Blockchain.

In this article, we'll discuss the Sui Network, providing an overview and exploring its unique aspects as a Layer 1 blockchain.

1. A Trite but Important Discussion: The Origins of Sui

1.1 Introducing the Sui (or Mysten Labs) Co-founders: Not So Trite After All

It's well-known that Sui originated from the blockchain team Diem (formerly Libra) and the Novi wallet at Meta (formerly Facebook). While this may seem like a trite fact, many are unaware of the specific roles and contributions these individuals made in the Diem and Novi teams. Let's delve into the backgrounds of Sui's co-founders, what they did at Meta, and their experiences prior to that.

source: Mysten Labs 

Currently, the Sui Network is divided into two entities: the Sui Foundation and Mysten Labs, the developer of the Sui Network. All of the founders of the Sui Network are part of Mysten Labs. Let's take a closer look at each of them, starting from the top left. Evan Cheng, the CEO of Mysten Labs, worked at Apple for over a decade before joining Meta. At Apple, he led the LLVM (Low-Level Virtual Machine, a modular compiler project initiated by Chris Lattner at the University of Illinois but extensively developed and researched at Apple) backend team. LLVM is known for making iOS apps run faster. Evan's work on LLVM earned him the ACM Software System Award in 2013, which he shared with Chris Lattner.

Adeniyi Abiodun, the CPO, served as a senior software engineer at J.P. Morgan and HSBC and was involved in blockchain design at Oracle. He oversaw products at VMware before leading product development at Meta.

Sam Blackshear, the CTO, is famous for creating Move, Sui's programming language, during his tenure as a Principal Engineer at Meta. He also significantly contributed to the Diem project, including involvement in the Libra Blockchain paper. At Sui, Sam is not only contributing in terms of programming language but also overseeing blockchain architecture.

George Danezis, the Chief Scientist, has been a professor of Security and Privacy Engineering at the prestigious UCL in the UK for ten years and is a fellow at the Alan Turing Institute. I first became aware of George Danezis in 2022 when he published the Narwhal and Tusk consensus paper. He is also a co-author of another brand-new consensus algorithm, Mysticeti, making him a familiar figure to me, as I have a keen interest in the consensus design of integrated blockchains.

Konstantinos Kryptos Chalkias, the Chief Cryptographer, is renowned in cryptography. He led cryptography at Meta and previously at R3. He is a co-author of Sui's seamless onboarding framework, zkLogin. Konstantinos is also involved in features like zkSend that Sui is actively promoting. When asked about the use of ZK technology in integrated blockchains, I often refer to Konstantinos's papers and results.

Thus, each co-founder of Sui has achieved significant results in their respective fields and continues to publish various works. As a researcher interested in integrated blockchains, I am closely following their periodic outcomes.

1.2 Why Did Sui Launch its Own Layer 1 Blockchain?

Most of the Sui team are former Meta blockchain developers. This article won't delve into why they left Meta to establish Mysten Labs, as it's been covered extensively elsewhere. Instead, I will focus on the technical justification. Sui is an integrated blockchain like Solana, Sei, Aptos, and Monad. As mentioned earlier, the market is experiencing fatigue over new Layer 1 blockchains (and likely still is). Despite this, why did Sui Network launch its own Layer 1 blockchain?

“The utility of a smart contract platform is proportional to the amount of interesting shared state a program running on that platform can access atomically.”

• Sam Blackshear(CTO of Mysten Labs)

Sam believes that the usability of blockchain, particularly smart contract platforms, depends on how seamlessly different applications can interact. Layer 2 rollups and ecosystems based on multi-chain systems have isolated and independent states, sacrificing some aspect of the 'usability' Sam refers to. The usability of smart contract platforms increases when various applications organically and seamlessly communicate, leading to interesting outcomes.

In essence, Sui aims to enable seamless interaction between applications while being cost-effective, scalable, and secure. While this is easier said than done, achieving it would validate Sui's existence as an independent blockchain. Has Sui proven this yet? I think more time is needed, but as a reason for developing an independent Layer 1 blockchain, it's convincing. Truly confident in their technology, it's more efficient and valuable for them to design all aspects independently rather than relying on existing ecosystems or chains.

In a market where skepticism towards new Layer 1s is rampant, technological differentiation is key to gaining attention. Sui might leverage Meta's reputation and its prominent investors for some market visibility, but the crucial factor is proving sustainability through technological differentiation. So, does Sui's technology have enough distinction to prove sustainability? I believe it does. Let's explore Sui's technology in more detail.

2. Sui's Infrastructure and Design

Sui is a constantly evolving Layer 1 chain. For instance, it currently uses Narwhal and Bullshark as its mempool protocol and consensus engine, but plans to introduce a new consensus, Mysticeti, soon. Therefore, I will explain both the existing and future consensus engines to cover Sui's present and future.

2.1 Different Starting from Consensus: Separation of Mempool and Consensus

The consensus and mempool protocols of Sui were not solely developed by Mysten Labs; instead, their legacy can be traced back to the time these builders were designing the Diem blockchain at Meta. Narwhal, the mempool protocol applied in Sui, and Bullshark, the consensus engine, are both so intricately developed that each has its own academic paper. To aid understanding, let's explain each of these protocols.

2.1.1 Efficient Mempool Protocol: Narwhal

First, let's discuss Narwhal. Narwhal is a mempool protocol that drastically improves the efficiency of sharing transactions in the mempool among validators in a blockchain network. It's important to note that Narwhal is not a consensus engine in itself and cannot function independently; rather, it's meant to be used in conjunction with an existing consensus engine. This is evident from the fact that when Narwhal was first introduced, it wasn't only about Narwhal but also about Tusk, a consensus engine that synergizes well with Narwhal. What then is the purpose of a standalone mempool protocol like Narwhal, and what problem does it aim to solve?

Problems with Traditional Mempools

To understand Narwhal, it's necessary to first comprehend what a mempool is. A mempool, short for memory pool, is a collection of unverified transactions at the nodes. However, the critical point is that while blockchains share states in a database, mempools are local to each validator, meaning the data in them also needs to be shared and verified before being included in a block for final consensus. Traditional blockchains face a double transmission issue, where validators broadcast all transactions to other validators for verification and then package the verified transactions into blocks for further propagation. The issue isn't the double transmission per se, but the added load it places on the consensus process. If the data in the local mempools of validators are correct, there shouldn't be a need to exchange every transaction data among validators.

How Narwhal Simplifies This

What if we simplify this process by not exchanging all transaction data among validators and just ensuring that the data in each validator's local mempool is consistent? In other words, instead of including transaction data in the consensus process like traditional blockchains, handle the mempool independently and base the consensus on metadata (block headers and hashes). This is a brief explanation of what Narwhal does. However, to understand Narwhal's approach to simplifying the traditional mempool data propagation process in detail, we need to delve deeper.

Workers and Primaries

To understand Narwhal's structure, it's essential to first comprehend the roles of two key entities: workers and primaries. Within a validator, there can be multiple worker machines(Currently, in Sui, it is not possible to run multiple worker machines, but since it may be possible to operate multiple workers in the future, I will explain based on the premise of multiple worker machines.), and each of these workers propagates different transaction data, allowing the transaction propagation process to be handled in parallel. On the other hand, there is only one primary per validator.

Workers are responsible for receiving transaction data from clients, batching and hashing the data, and broadcasting them to workers of other validators. A worker additionally forwards the hashes of its batches to the local primary who makes a list of the batches and includes them in a block.

The blocks created in this manner are then transmitted to other validators through a leader validator, who also manages the process of the validators signing the block. If the signatures reach a quorum of 2f+1 (where f represents the maximum number of faulty or malicious nodes tolerated by the network), a certificate is issued. While Narwhal is separate from the consensus engine, it's important to note that the quorum standard depends on the consensus engine used with Narwhal. The leader then propagates this certificate to other validators, allowing them to include it in the next round's block. Once the leader verifies that 2f+1 validators have accumulated the certificate, they proceed to the next round. The block for the next round comprises information about the block producer, signatures, a list of transactions, and a list of certificates. The structure of the block indicates that the certificate list refers to certificates from previous rounds.

These certificates essentially prove that the validators have the same data, allowing them to synchronize the data they hold. Narwhal improves blockchain speed in two ways: 1) Unlike traditional mempool protocols that communicated transactions on a per-transaction basis, Narwhal does so at the block level containing batches of transactions, making it much more efficient. 2) Since transaction ordering is completely separate from Narwhal, the consensus engine (like Bullshark, Tusk, or HotStuff, which will be explained later) can order and reach consensus on transactions while Narwhal propagates and guarantees the transaction data. This division of labor results in faster consensus than traditional systems.

2.1.2 What About Consensus?: The Introduction of Bullshark

While Narwhal handles the propagation of transaction data, Bullshark is responsible for ordering the transactions. Like Narwhal, Bullshark is also based on a DAG (Directed Acyclic Graph) structure. To understand Bullshark, it's necessary to grasp the concept of a DAG.

A DAG is a graph that is directed and does not have cycles. It consists of vertices and edges that connect these vertices, forming a structure where each vertex indirectly or directly verifies others. These vertices and edges have a specific order, known as the causal order. If all validators participating in the consensus have a DAG with the same direction and values, it's said that they have reached the same total order. Essentially, Bullshark is a methodology on how (honest) validators can efficiently reach this total order. However, this is not an easy task. Validators each hold a local DAG, and often these DAGs are not identical (since Bullshark is fundamentally an asynchronous DAG approach). So, how does Bullshark ensure that validators reach the same total order?

Bullshark is a round-based DAG BFT (Byzantine Fault Tolerant) consensus protocol. In this system, each vertex in the DAG corresponds to a round, and vertices called "anchors," which are owned by a leader, exist in every even-numbered round. During odd-numbered rounds, votes are cast for the anchors of the even-numbered rounds (thus, odd rounds involve anchors, and even rounds involve voting for these anchors). In the depicted structure, anchors are represented by vertices colored in green (A1 and A2), while the vertices with green borders represent those forming the causal order of the anchor (for example, the A2 anchor references vertices from party 1, party 2, party 3 in Round 1).

An anchor is essentially the leader's vertex, and for an anchor to be confirmed, it is not sufficient just to be an anchor vertex. According to Bullshark's Commit Rule, the anchor must receive at least f+1 votes from the subsequent round, where f represents the number of faulty or malicious nodes, as previously explained in the context of Narwhal.

In the given example, with 4 participating nodes (N=4) and assuming 1 faulty node (f=1), according to Bullshark's commit rule, an anchor is confirmed by receiving a minimum of f+1 votes, meaning 2 votes are required for confirmation. Anchor A2, having received 3 votes, is confirmed (and thus crowned), while Anchor A1, with only 1 vote, remains unconfirmed. One might wonder whether to skip placing A1 in favor of A2. The answer is No. As mentioned earlier, Bullshark fundamentally operates on an asynchronous DAG, so from another node's perspective, A1 might have received more than 2 votes. Therefore, even if a particular node sees that A1 has not received f+1 votes, it's still correct to initially place A1 before A2 in the DAG and proceed with its construction.

Does this mean Bullshark should place all anchors as long as they exist? The answer is also No. For an anchor to be preferentially placed, it's important not only whether it receives votes, but also whether the next round's anchor is connected to it by at least one path. If, in our example, there is no guaranteed path between A2 and A1, it's acceptable to skip A1.

In summary, Bullshark is a round-based DAG, with anchor vertices in even rounds and votes for these anchors in odd rounds. An anchor must be 'confirmed' to be included in the DAG, which requires receiving more than f+1 votes in the odd rounds. However, even if an anchor hasn't received f+1 votes immediately, it's still placed in the DAG because from someone else's perspective, it might have received sufficient votes. But if an anchor has no connections with other anchors, it's excluded from the DAG. This ensures that all honest validators eventually have the same DAG value (known as reliable broadcast).

We've looked at how Bullshark progresses through the rounds of the DAG. How does Bullshark ensure scalability? Like Narwhal, Bullshark separates data propagation and DAG progression in the consensus process (in fact, Bullshark was developed based on Narwhal's open-source codebase). This means that while the DAG construction proceeds on its own, data propagation follows the network's speed. Even if DAG construction is slow, each vertex in the DAG can contain more metadata to progress the rounds, ensuring the network's scalability is not compromised.

Bullshark's approach enhances the scalability of the consensus mechanism. Validators don't need extensive communication to reach a total order, allowing them to efficiently reach consensus.

2.1.3 Summary of Narwhal & Bullshark Process
To summarize what we have discussed, lets break down the transaction lifecycle when network implements Narwhal/Bullshark:

1. Transactions are collected by workers who batch and hash and broadcast them

2. The hashes of the batches are then send to the primary

3. The primary puts these hashes in a block and proposed the block to other primaries

4. Primaries check that they got the batches and sign

5. The source primary collects 2f+1 signatures and generates a certificate

6. When 2f+1 certificates for a round exist (different primaries) we advance a round

7. At that point network might achieve consensus (it is not happening always)

8. If we suceed then all transactions in these batches are totally ordered. This is when network gets settlement finality

9. After ordering the transactions are forwarded for local execution (this is internal to the validator)

10. After execution the validator send an execution result message to the clients. When 2f+1 validators do that the client witnesses the settlement finality

11. Concurrently to 9 and 10 validators also checkpoint what they execute for posteriority. Most of the current apps wait for the checkpoint instead of step 10 because it is easier to handle

Through this efficient consensus method (Bullshark) and mempool strategy (Narwhal), Sui has achieved about 125,000 TPS, albeit with approximately 2 seconds of latency for 50 entities.

2.1.4 Unsatisfied with Bullshark, Enter Mysticeti

The combination of Bullshark and Narwhal I previously introduced has been the primary reason Sui Network could efficiently handle numerous transactions so far. However, there's always room for a better alternative. Currently, Sui is preparing for a consensus upgrade with a new engine named Mysticeti. Like Bullshark, Mysticeti is based on a DAG consensus, but it has several differences from Bullshark, which I will focus on today.

Significantly Reduced Latency

As I briefly mentioned earlier, despite its fast consensus, Bullshark experiences notable latency. According to the Mysticeti paper, Bullshark recorded an average of 60-80k TPS but also had latency issues, ranging from 8 to 10 seconds. While scalability was achieved, latency remained a problem. Mysticeti can be seen as an attempt to reduce this latency. In fact, with Mysticeti, a dramatic improvement is achieved, reaching 50,000 TPS while reducing latency to 0.5 seconds.

Signed Block Instead of Certified Block

Unlike Bullshark and other DAG-based systems that create consensus through Certified Blocks (blocks signed by more than 2f+1 validators), Mysticeti reaches consensus through Signed Blocks (blocks signed only by the single validator, i.e., the creator of the block). This is possible because Mysticeti uses the Universal Commit Rule. Simply put, instead of validators signing each block one by one, the network decides whether to commit or skip blocks based on the signed block alone. This allows Sui Network to significantly lower latency compared to Bullshark and also minimizes CPU usage needed for operations due to this efficiency.

Implicit Certificate

Many people might express concerns here. Despite there being clear reasons why DAG-based consensus models have used Certified Blocks in consensus, Mysticeti only uses Signed Blocks for committing operations. It is not an easy task to safely reach network consensus using Signed Blocks. While this approach may reduce network latency, Signed Blocks are considered to have a lower level of block verification compared to Certified Blocks, which inevitably raises security concerns, especially in comparison to networks like Bulshark that reach consensus using Certified Blocks.

So, is Sui adopting Mysticeti  despite these concerns? The answer is "no." How can the network safely reach consensus with just Signed Blocks without security issues? To understand this, one must grasp the concept of the Implicit Certificate. What is an Implicit Certificate and how does it differ from the certificates used in Bulshark?

In Bulshark, the system inherently has certificates that need to be created and propagated. In contrast, in Mysticeti, if a number of validators set by the consensus agree (sign), the transaction itself is considered "certified" and consensus is reached.

This means that in Mysticeti, even if every transaction doesn’t have a certificate, as long as the block receives support from a predetermined number of validators (and the block contains references to blocks from previous rounds held by these validators), it can be committed to the network. Thanks to the Logical Clock, it's possible to ensure that blocks are committed in the correct order, which greatly assists in maintaining the protocol's integrity.

Wen Mysticeti

Mysticeti is expected to upgrade the Sui consensus engine sometime in the first half of this year. It will be interesting to see if Sui can maintain stability while drastically reducing network latency with the introduction of Mysticeti.

2.2 Sui's Unique Tokenomics

Sui is renowned among blockchains for its highly unique tokenomics. Before delving into the details of Sui's tokenomics, let's first explore some concepts that are unique to Sui's economic model.

2.2.1 Storage Fund

The Storage Fund is one of the most intriguing features I encountered while studying Sui's tokenomics. It's a model that I believe could be a reference for other Layer 1 blockchains in the future. Firstly, as time progresses, the amount of storage required by nodes in a blockchain significantly increases. This is a given, as full nodes need to maintain all blocks from the genesis block to the current block, meaning their required storage capacity will inevitably grow over time. Therefore, for a blockchain to be sustainably maintained over a long period, there needs to be an economic incentive capable of handling extensive storage requirements, even as time passes. Sui has created the Storage Fund with the aim of providing appropriate storage rewards to nodes participating in the network at any given time in the future.

Soruce: Sui Document

So, where does the money in the Storage Fund come from? It can be considered as coming from the users who are currently paying transaction fees on Sui. When users pay transaction fees, the cost is composed of divided into execution cost and storage costs. The storage cost is then sent to the Storage Fund. Additionally, the Sui tokens in the Storage Fund are included when calculating the total staking amount in Sui's Proof of Stake (PoS) mechanism, and proportionate staking rewards are earned. Over time, this increases the size of the Storage Fund (until it's distributed to validators in the future), enabling sustainable storage management.

A particularly interesting feature I found while studying the Storage Fund is the “deletion option.” This feature refunds a portion of the storagetransaction fees originally spent to create certain on-chain data from the Storage Fund when a user deletes that data. It's fascinating because it incentivizes users to voluntarily delete useless data. However, it's important to clarify that the deletion option does not contradict blockchain's core value of immutability. The option is not for deleting past transactions but for removing no longer meaningful data (like NFT metadata, used tickets, or data related to concluded auctions). In other words, the blockchain's core value of immutability remains unaffected by the deletion option.

2.2.2 Transaction Fee Calculation Method

How are transaction fees determined in the Sui network? Surprisingly, the answer is "they continuously change." Epoch-by-epoch, Sui validators conduct a sort of survey. During this, validators individually set the minimum amount they are willing to accept for processing transactions. The reference cost is then based on the value at the lower 66.67% percentile of these minimum values. Importantly, this is not just a simple 66.67% percentile but is weighted by the amount of Sui tokens staked on each validator. The reason for using the 66.67% mark is to base it on a price most validators find acceptable.

Another interesting aspect is that at the end of each epoch, validators monitor the performance of other validators in the network. Performance is assessed based on various metrics (like response time) and rewards are adjusted accordingly (validators who submit a higher minimum transaction fee or fail to process transactions receive lesser rewards and vice versa). Validators then submit their opinions on the performance of others at the end of each epoch, which influences the distribution of staking rewards. This method of calculating transaction fees in Sui is quite user-friendly as it encourages validators to offer lower transaction fees.

2.3 Move on Sui

source: Sui

When exploring what sets Sui apart from other blockchains, it's impossible to overlook its programming language. I'm talking about Move, especially Move on Sui. Sui is notably unique for its adaptation of Move. Sam Blackshear, a co-founder and CTO of Mysten Labs & Sui, is renowned for creating this programming language during his time at Meta. Move is a programming language designed specifically for blockchains, focusing on security and network stability. Sui has made modifications to Move, so before discussing Move on Sui (the version of Move used in Sui), let's first take a look at Move itself.

2.3.1 Resource-Oriented Programming Language(I also worded this resource oriented because I want to differentiate Move on Sui from original Move(account based) but if you still think that object oriented is better way to say this, more than happy to change it)

In Move, resources are treated as first-class values (a first-class object is an entity that supports all the operations typically available to other objects in the language, indicating the highest level of flexibility in programming languages). In the Move language, resources can be stored and sent in various forms, but strict rules prevent the duplication, disposal, or unauthorized movement of these resources in storage. Essentially, resources are freely usable within the constraints related to stability. Examples of resources in Move include cryptographic assets, smart contract state values, NFTs, and on-chain voting rights (a feature not available in Solidity).

2.3.2 Data Abstraction

Data abstraction, simply put, is about hiding the complex details of how something operates, enabling its functionality without requiring the user to understand its inner workings. Data abstraction is a key feature in Move, where resources and other data types are encapsulated within modules, abstracting away complex tasks related to managing these resources (like how they should be stored, modified, or managed). This abstraction is a significant advantage from both a user and developer perspective.

Data abstraction also allows control over access to resources. It specifies what actions are permitted on what resources and under which conditions. This feature is incredibly useful for application builders, especially from a security perspective.

2.3.3 Static Verification

Static verification involves detecting errors or vulnerabilities in code before it is executed by the program. This is possible because Move assigns types to expressions, functions, and variables, and defines clear rules on how these types can be used and combined.

Move also introduces a borrow checker to ensure data doesn't get mutated unintentionally and to prevent references to data from outliving the data itself.

Lastly, the ability to perform formal verification to validate the logic of contracts is another significant advantage.

2.4.4 Move on Sui: What Are the Differences?(If there are any more differences that team wants to point out, I am more than happy to learn from you guys!)

While Move itself is a robust programming language, the original Move, based on an account-based model, had limitations for the Sui team. Originally designed for the permissioned blockchain Diem, it needed to be reimagined for the permissionless blockchain Sui, leading to the development of Move on Sui. Move on Sui differs from the original Move in several ways:

Object-Oriented Model

Unlike the original Move, where data was stored globally by addresses or type names, Move on Sui stores data by the object's ID. In Move on Sui, each object is assigned a unique ID, independent of blockchain addresses. For instance, an object “CoolAsset” would have a unique ID like “AssetID123”, and this ID is stored in the global storage, referencing the object. This means developers don’t have to write complex logic to transfer assets, as the global storage contains the object ID, not the owner’s data.

Transaction Parallelization

In the original Move, transaction parallelization is not the default due to its account-based model (in which transactions that alter state values are closely tied to account-related data, increasing the likelihood of issues). However, in Move on Sui's object-oriented model, each object is independently affected, so changes to one object don't impact another. For example, two transactions altering different objects can be processed in parallel without issues.

3. Killer Features on Sui: Why Sui?

So far, we've looked at the design and structural differences of Sui. However, the real distinguishing features that users experience lie in the features I will cover next. What if Sui supports native social logins in a self-custodial manner? Or what if users could send assets via QR codes or links? Lastly, what if Sui inherently includes the ability to sponsor transactions for users without Sui tokens? Amazingly, Sui possesses all three functionalities. Let's explore each feature and understand why Sui stands out functionally from other Layer 1 blockchains.

3.1 zkLogin

zkLogin is essentially an onboarding framework that provides a user interface (UI) experience comparable to the login or sign-up process of Web 2.0 services. However, unlike traditional Web 2.0, where third parties manage the user data, zkLogin enables users to fully own their data. How does Sui achieve this balance of convenience and self-custody (Self Custodial) of data? To understand the approach of zkLogin, it's essential to have a preliminary understanding of OAuth 2.0 and Zero Knowledge Proofs. So, let's briefly explore these two concepts.

3.1.1 OAuth 2.0

Many of you might find the term unfamiliar, but those reading this article have likely used the OAuth 2.0 method when logging into the Four Pillars website. OAuth 2.0, short for Open Authorization 2.0, is an open standard protocol for identity verification. In simple terms, it's a protocol that allows resource owners (users) to delegate access to their resources to third parties. It wouldn't be an exaggeration to say that most of the convenient login features we use today are based on the OAuth 2.0 protocol. The participants in OAuth are as follows:

• Resource Server: This can be seen as the server holding the resources. Companies like Facebook, Google, Twitter, which we use for easy login, mainly fall into this category.

• Resource Owner: The owner of the resources, essentially the user who is using the service.

• Authorization Server: This server manages access rights to resources and is also responsible for creating Access Tokens.

• Business Client: The entity that wants to access information from the Resource Server. Four Pillars can also be considered a Client.

To elaborate further, the client goes through about three steps to receive the resource: First, it must obtain authentication approval from the Resource Owner (user), then present this approval to the Authorization Server, which in turn provides an Access Token. This Access Token is then given to the Resource Server to obtain the resource.

Sui's zkLogin, as a core feature of "easy login," also utilizes OAuth 2.0. Therefore, any Resource Server that is compatible with OAuth 2.0 can potentially support zkLogin.

3.1.2 Zero Knowledge Proofs

However, if zkLogin had only used OAuth 2.0, it wouldn't have the prefix 'zk'. The unique aspect of Sui's zkLogin compared to standard easy login features is its use of Zero-Knowledge Proofs (ZKP). ZKP is a cryptographic protocol that allows a prover to demonstrate knowledge of certain information to a verifier without revealing the information itself. In other words, with ZKP, you can prove that you know something without actually disclosing the information.

ZKP works by enabling provers to demonstrate knowledge of specific information to verifiers without disclosing the information itself. Therefore, it has applications in authentication, identity verification, and privacy protection. Sui's zkLogin is an apt example of an application using ZKP. It leverages ZKP to prevent third parties from linking Sui addresses with their OAuth identifiers, offering an easy login method while keeping data completely under the user's control (with ZKP technology, even information providers like Google or Facebook cannot know that the information they provide is linked to a specific Sui address).

3.1.3 How Does zkLogin Work?

To understand zkLogin, it's important to know a few key terms:

1. JWT Token: Stands for JSON Web Token, divided into a header, payload, and signature. It's a token used for granting authorization in communications between clients and servers.

2. Salt: In cryptography, salt is a random string added to data, passwords, or passphrases before undergoing a hashing process. It ensures that even if the same password is used, the resulting hash will be different, commonly used for password protection in storage.

3. OpenID Provider (OP): These entities act as Resource Servers in OAuth 2.0. Currently, Facebook, Google, Twitch, Slack, and Apple are providers that support zkLogin.

4. Application Frontend: Refers to applications or services, like wallets, that support zkLogin.

5. Salt Backup Service: A backend service that returns the salt value to users.

6. ZK Proving Service: Based on JWT token, JWT randomness, user salt value, and max-epoch, this service creates a Zero-Knowledge Proof (ZKP). Creating a ZKP is resource-intensive, so Mysten Labs can also generate ZK Proofs on behalf of users.

7. eph_sk, eph_pk: These are key pairs (Private Key and Public Key) needed to generate temporary signatures. The signing mechanism is similar to standard transaction signatures but is temporary as they expire with the OAuth session.

   1. zkLogin uses these temporary key pairs to allow users to generate new keys if they lose theirs, protecting their assets.

8. iss (issuer): Represents the entity that issued the JWT token.

9. aud (audience): Identifies the entity receiving the JWT token.

10. sub (subject): Identifies the user subject of the JWT.

With these key terms understood, let's explore the process of zkLogin and how it enables users to access the Sui blockchain:

1. Users first log in to an OP, obtaining a JWT token containing a nonce value. They generate a temporary key pair (eph_sk, eph_pk), adding the public key to the nonce along with the expiry times and Jwt_randomness. After completing the OAuth login, users can find the JWT token in the application's redirection link.

2. The JWT token is then sent to the Salt Backup Service by the Application Frontend. The Salt Service validates the JWT token and returns the unique salt value for the user, based on the iss, aud, and sub, back to the Application Frontend.

3. The user sends the JWT token, salt value, temporary public key, jwt randomness, and strings (iss, aud, sub) to the ZK Proving Service, which then generates a ZKP based on this information.

4. The application calculates the user's address based on these strings (independent if the JWT token is valid).

5. Transactions are signed using the temporary private key, creating an ephemeral signature.

6. Finally, the user submits the ephemeral signature, ZKP, and other input values to the Sui blockchain.

It's important to highlight a particular aspect of zkLogin, namely that it creates separate OAuth credentials for each application and zkLogin-compatible wallet. Simply put, when you onboard onto the Sui blockchain using zkLogin to use a specific application, a separate address and account are assigned for each application (and this includes wallets as well. For example, even if you log into different wallets using the same Google account, different accounts are assigned). This approach is taken to provide an independent user experience for each app. Let's illustrate this with an example:

• steve@4pillars.io + Sui Wallet = account 1

• steve@4pillars.io + a different Sui wallet but zkLogin compatible = account 2

• steve@4pillars.io + game or DeFi app = account 3

Now, the question is, if someone uses the Google account steve@4pillars.io to log in via zkLogin and uses a Sui wallet to access games or DeFi applications, will different accounts be assigned for each game and DeFi app? The answer is "No." As I just explained, in this context, wallets are also considered applications. Therefore, if you log into the Sui wallet using zkLogin and use various applications on Sui, it's still considered one application in terms of OAuth credentials. However, if you accessed games or DeFi applications directly without going through another wallet, then indeed, separate accounts would be assigned for each application.

Readers of this article might think that zkLogin is too complex a feature, but naturally, the processes I mentioned above are all omitted on the user's end, and handled by the applications, so there's no need to worry. The reason I explained the process of zkLogin is to show how it can securely protect user data and easily onboard to the Synergy network in a non-custodial manner. Since it's about the wallet, which is one of the most important features in blockchain, a detailed explanation is necessary so that people can use it with confidence.

3.1.4 How zkLogin Differs from Other Social Logins

While other social logins (bringing Web2 authentication to Web3) may seem similar to zkLogin, they differ in that they 1) rely on third parties (for Web2 identity verification or managing private keys) and 2) require disclosing personal information for JWT token verification or conducting expensive on-chain ZKP verification.

zkLogin, being native to Sui, means that transactions created via zkLogin are easily compatible with other transactions on the Sui blockchain (like the upcoming Sponsored Transaction feature).

Additionally, the use of ephemeral keys means third parties don't need to continuously manage private keys (these keys expire along with the ZKP). Finally, only the ZKP and ephemeral signature need to be submitted on-chain, meaning other information doesn't have to be disclosed. This marks a clear distinction from traditional social logins. For a more detailed explanation of zkLogin, refer to Four Pillars' article on zkLogin.

3.2 zkSend

source: Mysten Labs Blog
zkSend is a simple technology that allows for the easy transfer of Sui tokens. Normally, sending tokens to someone involves 1) deciding the amount of tokens and 2) entering the recipient's address. Even with domain names, remembering or carrying around addresses is inconvenient. A wrong input could mean permanently losing assets. Wouldn't it be great if you could send assets without having to enter the recipient's address?

This is where zkSend comes in. The sender only needs to enter the amount of assets to be sent and then generates a link or QR code to send to the recipient. The recipient, after receiving it, can easily log in using zkLogin, as explained earlier, and receive the assets.

3.2.1 zkLogin + zkSend = UI/UX on Another Level

Combining zkLogin and zkSend, as I explained above, creates an experience where “even those without a Sui wallet can create one in just 10 seconds and receive Sui via a QR code or link.” First, the recipient gets a link or QR code via zkSend, then creates a Sui wallet instantly through zkLogin using their Google or Twitch account, and immediately receives the Sui tokens. Imagine someone without a wallet creating one and receiving Sui in a self-custodial wallet instead of a centralized exchange, all in just 10 seconds. Sui has already implemented all these functionalities. From an application builder's perspective, this infrastructure can be incredibly versatile, and the main reason I'm writing this article about Sui is due to the innovation of zkLogin and zkSend. Those interested in trying out zkSend can experience sending and receiving Sui tokens directly through this link.

3.3 Sponsored Transaction

Source: Sui Blog

We've delved into Sui's zkLogin and zkSend, innovative features that address the traditional inconveniences of blockchain wallets. Yet, another major challenge remains: transaction fees. Sui's approach to simplifying transaction fees is intriguing.

The core idea is to eliminate the cause of the problem. If transaction fees are a user interface issue, why not enable fee-less transactions? This concept gave birth to Sponsored Transactions. Using Sui's programming language, Move, application developers can now partially or fully cover the transaction fees for their users. Sponsored Transactions come into play in several scenarios:

1. Subsidizing User-Initiated Transactions: Users generate a GasLessTransactionData Object for the developer's approval. The developer then signs a TransactionData Object with the fee, which the user also signs, allowing the transaction to proceed.

2. Direct Fee Transfers from Developers to Users: Developers pre-authorize and cover the transaction costs, sending a ready-to-use TransactionData Object to users. This method is ideal for promotions or attracting new users. It's noteworthy that even those without Sui tokens or blockchain expertise can participate, thanks to zkLogin.

3. Providing GasData to Users: GasData, akin to a blank cheque, defines a transaction cost budget. Users can transact freely within this limit, with the developer handling the signing and processing.

Sui's innovative structure allows users to engage in blockchain transactions without fretting over costs. If these features – zkLogin, zkSend, and Sponsored Transactions – gain traction, they could seamlessly integrate many into the Web3 world. Envision a scenario where users can send and receive assets without knowing addresses or owning wallets, all fee-free. This aligns perfectly with what application developers have been striving for

4. Looking Ahead

We have explored various aspects of Sui. In my research on different blockchains, it is rare to write an article referencing as many papers as I did for Sui. This underscores how technically intensive and innovative Sui blockchain is. As I mentioned earlier, to create a new Layer 1, it really needs to be novel. Merely forking existing chains and adding new narratives might not be enough to stay competitive. Sui is continuously trying new things in various areas and evolving. This isn't just about consensus design or architecture but also about improving user interfaces and fostering a developer-friendly environment.

Technologies like zkLogin and zkSend were quite shocking even to someone like me who has researched blockchain for a long time. They send a vital message about blockchain mass adoption: to truly get the public using blockchain, innovation is needed not just in speed and low fees but also in how wallets operate, how assets are transferred, and simplifying transaction costs.

I foresee covering Sui frequently on Four Pillars in the future. Even as I write this article, the Sui team is making incredible attempts, such as sending transactions without an internet connection, and as a researcher, it's my duty to delve into how these feats are achieved. What new features will Sui introduce next? Let's all keep a keen eye on Sui's developments together.

Thanks to Kate for designing the graphics for this article.