While traditional Web 2.0 services have improved user experiences by simplifying complex processes, users have become accustomed to this convenience. In contrast, blockchain remains a complex technology.
One of the main reasons blockchain hasn't become a popular choice among the masses is the inherent difficulty of using blockchain wallets, compounded by the constant need to pay transaction fees.
In response, Sui introduces zkLogin, offering users a login experience similar to traditional Web 2.0 while preserving their data privacy. Furthermore, through Sponsored Transactions, Sui provides an infrastructure that allows users to engage in on-chain activities without having to pay transaction fees.
Simple can be harder than complex: you have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains. Steve Jobs(Co-Founder of Apple)
When thinking of User Experience (UX) today, the first company that comes to mind is Apple, founded by Steve Jobs. Jobs emphasized "simplicity" when creating products. While he was an extreme minimalist who stressed simplicity in every aspect of the company, from its decision-making structure to its product lineup, the most familiar manifestation of Jobs' simplicity philosophy is evident in Apple's product design and software. By reducing the number of buttons and allowing smartphones to be operated with just a few simple actions, Apple's "simplicity" ultimately won the hearts of the public, and this continues to be the case today.
The "The Bull" by Picasso introduced in the Apple college course.
Source: Drawpaintacademy
After Apple's success, countless IT companies admired and emulated Apple's philosophy. As a result, people are now accustomed to 'simplicity'. In other words, complexity in UI design is no longer tolerated in the market. It's an era where simplicity and clarity prevail. Yet, there is a technology that seemingly defies this trend: blockchain.
To initiate a transaction on a chain, one must pay a fee. This fee isn't in legal tender but in the native token of that particular network. Moreover, different blockchains require different accounts and wallets. Users must store their Seed Phrases and Private Keys somewhere secure on their computer or, even better, in a personal vault inaccessible to others. In an age where fingerprint and facial recognition (like FaceID) enable easy logins, such complexity seems anachronistic. No matter how interesting or innovative blockchain products may be, people will likely get frustrated and give up during the onboarding process.
Simplicity has now become an intrinsic part of human behavior. If it's not straightforward or intuitive, it can't gain widespread adoption. So, what must blockchain change? This article aims to explore the usability issues in blockchain and how Sui addresses and resolves these challenges.
Just as wallets in real life mark the beginning of all economic activities, in the realm of blockchain, wallets serve as the entry point for accessing the technology. Without a wallet, it's impossible to use blockchain. To put it bluntly, if blockchain wallets are cumbersome to use, potential users won't even step into the so-called 'world of blockchain.'
Regrettably, blockchain wallets are notoriously difficult to use. Even for someone like me, who has been active in the blockchain industry for a long time, the process of creating a wallet, generating Seed Phrases, Private and Public Keys, distinguishing among them, and safely storing them can be exceptionally tedious and inconvenient. Unless it's absolutely necessary, the mere act of creating a new wallet is off-putting. This is hardly surprising. Most contemporary login services utilize Single Sign On (SSO) - a technology that allows users to log in to multiple applications and websites with a single authentication - simplifying what was once a complex sign-up or login procedure.
Users accustomed to the convenience of SSO are unlikely to be willing to go through the hassle of storing Seed Phrases and various keys, let alone repeating the process each time they switch to a different mainnet. Users who are already acclimated to intuitive UIs would naturally have built a certain inertia against such complexities, and overcoming this inertia is no small feat. But is the issue with blockchain wallets solely a matter of usability? If only it were that simple. Let's enumerate the various challenges presented by blockchain wallets.
Blockchain wallets inherently adopt a Self-Custodial model. This means there's no fallback mechanism like in the Web 2.0 era to recover a lost password or private key. A story that frequently surfaced in the media, especially when Bitcoin prices soared, was about individuals who had stored substantial amounts of Bitcoin in their wallets but lost access due to misplaced wallets or lost private keys. According to Origin Stamp, as of 2022, an estimated 4 million Bitcoins have been lost. While lost credit cards can be reported and reissued, and online accounts can be recovered by contacting the service provider, blockchain wallets offer no such recourse. How many are willing to take on this risk to safeguard their assets? The potential threat of hacks leading to lost assets further deters people from using blockchain wallets.
This issue might be seen in a similar light to the usability problem mentioned earlier. For newcomers to blockchain wallets, concepts like Seed Phrases, Private and Public Keys, and their distinctions are foreign. They don't understand why these are constructed in long, complex combinations. They likely don't grasp how to send transactions or understand why they need to pay fees. Asking these uneducated users to engage with blockchain wallets is akin to asking a toddler who can't walk yet to drive a car.
Regulatory and guideline challenges, such as AML (Anti-Money Laundering) and KYC (Know Your Customer), exist. It's not straightforward to exchange real-world assets for crypto assets and vice versa. The potential misuse of crypto assets for money laundering and other crimes discourages direct use of blockchain wallets. Trust issues concerning wallet providers persist, given the plethora of wallets available. There's always the looming threat that the provider might have malicious intentions. Numerous other reasons exist for the reluctance in using blockchain wallets.
In conclusion, if wallets remain complex and insecure, there's a possibility that many users will continue to avoid directly using blockchain. Perhaps the dream of a blockchain-saturated world is unattainable without simplifying wallets. Yet even if the wallet issue is resolved, there remains another significant hurdle: transaction fees.
Let's assume blockchain wallets have evolved to the point where users can effortlessly create an account without the need to store Seed Phrases or Private Keys. Would this catalyze widespread blockchain adoption? Probably not. Even if everyone could possess a wallet, the unfamiliar barrier of transaction fees still exists. Imagine if posting on Facebook or playing many of today's popular games came with a fee. Such platforms would likely struggle to gain traction. On blockchain, virtually every action has a cost. What other concerns surround this aspect?
It's already inconvenient that every transaction is subject to a fee. But if these fees fluctuate in real-time, it becomes significantly harder for users. Humans inherently dislike unpredictability. If posting on Facebook costs $0.5 today but doubles tomorrow, even fee-accustomed users might abandon the platform. Moreover, because blockchain fees are denominated in tokens, it doubles the mental math for users, converting not just the fee but its equivalent in fiat currency, adding to the complexity.
Almost all blockchains involve a process where validators or nodes determine the sequence in which transactions are added to blocks. Naturally, transactions offering higher fees get processed faster. Users must weigh the unpredictability of when their transaction might be processed. While it's logical that higher-paying users receive prioritization, this dynamic can introduce significant inconveniences and financial implications.
In the end, for those accustomed to Web 2.0 services, two conditions must be met for seamless blockchain adoption: 1) the onboarding process must be remarkably smooth, and 2) the intricacies of using blockchain must be minimized. Sui aims to address these challenges with the introduction of two new features: zkLogin and Sponsored Transactions. Let's delve into these two solutions.
Source: Binance Feed
First, let's delve into zkLogin, an onboarding framework developed to address the challenges of smoothly integrating users onto the blockchain. In essence, zkLogin offers a user experience almost identical to the login or sign-up processes familiar to Web 2.0 users. However, while traditional Web 2.0 solutions often entrust user data to third parties, zkLogin ensures that users maintain complete ownership and control over their data. So, how did Sui manage to balance convenience with the principle of Self-Custodial data ownership? To understand the workings of zkLogin, a preliminary grasp of OAuth 2.0 and Zero Knowledge Proofs is essential. Let's briefly explore these two concepts.
Many might find these terms unfamiliar, but readers of this article likely used the OAuth 2.0 method when logging into the Four Pillars website. OAuth 2.0, which stands for Open Authorization 2.0, is an open standard protocol for authentication. Put simply, it's a protocol that allows resource owners (users) to delegate third-party access to their resources without sharing credentials. It wouldn't be an exaggeration to say that most of the "quick login" features we use today are based on the OAuth 2.0 protocol. The key players in the OAuth framework include:
Resource Server: Essentially, this is the server that holds the resources. It's primarily companies like Facebook, Google, and Twitter, which we often use for quick login features.
Resource Owner: The actual user or the entity that owns the resource or data.
Authorization Server: This server manages access permissions to resources. It's also responsible for generating Access Tokens.
Business Client: The entity aiming to access and retrieve information from the Resource Server. Populous, for example, can be viewed as a Client.
To elaborate on the above, the client undergoes roughly three stages to retrieve the resource. Initially, it needs authentication approval from the Resource Owner (user). Upon obtaining this, the client submits the approval to the Authorization Server, which in return provides an Access Token. This Access Token is then presented to the Resource Server to finally retrieve the desired resource.
Sui's zkLogin also emphasizes "quick login" as one of its core features and utilizes OAuth 2.0. This means that any OAuth 2.0 compatible Resource Server can support zkLogin.
However, if zkLogin solely employed OAuth 2.0, it wouldn't carry the "zk" prefix. The distinguishing feature of Sui's zkLogin compared to conventional quick login systems is its utilization of Zero Knowledge Proofs (ZKP). ZKP is a cryptographic protocol that allows a prover to show a verifier that they possess a particular piece of information without revealing the information itself. In other words, with ZKP, one can demonstrate knowledge of specific information without actually disclosing it.
ZKP (Zero-Knowledge Proof) operates in a manner that allows a prover to demonstrate to a verifier that they possess knowledge of specific information without revealing the information itself. This makes it suitable for various applications, including authentication, identity verification, and privacy protection. Sui's zkLogin is an exemplary application of ZKP. This is because zkLogin utilizes ZKP to prevent third parties from associating a Sui address with its corresponding OAuth identifier. While providing a highly streamlined login method, it ensures that data remains entirely under the user's ownership. Through the zero-knowledge proof technology, even information providers like Google and Facebook cannot discern the connection between the information they provide and a specific Sui address.
To initially understand zkLogin, we need to familiarize ourselves with several terms:
JWT Token: JWT Token stands for JSON Web Token, which is categorized into header, payload, and signature. It's a token used to grant permissions during communication between a client and a server.
Salt: Refers to a random string added to data, passwords, or passphrases when hashing through a one-way function. Even if two individuals use the same password, the salted string will differ, typically used to protect passwords in storage.
OpenID Provider (OP): These entities play the role of Resource Server in OAuth 2.0. Currently, providers supporting zkLogin include Facebook, Google, Twitch, Slack, and Apple.
Application Frontend: Refers to services or applications supporting zkLogin, like wallets.
Salt Backup Service: A backend service that returns the salt value to users.
ZK Proving Service: The ZKP is created based on the JWT token, JWT random value, user salt value, and max-epoch. Generating a ZK Proof is a resource-intensive task. While it's possible to create the ZK Proof directly, Mysten Labs can also produce the ZK Proof on behalf of builders.
eph_sk. eph_pk: These signify the KeyPair (combination of Private and Public Keys) needed to temporarily create a signature. The signature mechanism is akin to the regular transaction signature mechanism but is temporary due to the expiration of the OAuth session.
The reason zkLogin generates this ephemeral KeyPair is to protect user assets by enabling the creation of a new ephemeral key even if users lose their key.
iss (issuer): Represents the party that issued the JWT token.
aud (audience): Identifies the recipient of the JWT token.
sub (subject): Identifies the user who is the subject of the JWT.
Having established a foundational understanding of the key terms, let's delve into the process of zkLogin. How can users access the Sui blockchain via zkLogin?
Initially, users log in to the OP (OpenID Provider) and obtain a JWT token containing nonce. Importantly, users create an ephemeral KeyPair (eph_sk. eph_pk) and input the public key, along with expiry times and Jwt_randomness, into the nonce. After concluding OAuth login, the application's redirection link will contain the JWT token.
Then, the Application Frontend sends the JWT token to the Salt Backup Service. The service validates the JWT token and returns the user's unique salt value and JWT token to the Application Frontend based on the iss, aud, and sub strings.
The user forwards the JWT token, salt value,ephemeral public key, jwt randomness, and strings (iss, aud, sub) to the ZK Proving Service, which then crafts the ZKP.
The application calculates the user's address based on these strings (this operation can be standalone if the JWT token is valid).
The transaction is signed using an ephemeral private key to generate ephemeral signature.
Finally, the user submits the ephemeral signature, ZKP, and other input values to Sui.
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.
At first glance, other social logins(Web3Auth, DAuth, and Magic Wallet), which bridge Web 2.0 credentials to Web 3.0, may seem similar to zkLogin. However, they differ due to their 1) reliance on third parties (during Web 2.0 identity verification or while persistently managing the private key), and 2) the need to publicly expose personal data(since it has to rely on smart contracts)when proving JWT tokens or conduct costly on-chain ZKP.
zkLogin, being native to Sui, seamlessly integrates with other Sui blockchain transactions, such as Sponsored Transaction(which I will discuss later on this article).
Since it uses an ephemeral public key, there's no continuous need for third parties to manage the private key(The ephemeral key pair is used only until its expiration date, and the corresponding ZKP also expires when the key pair does.). The requirement to only submit ZKP and ephemeral signature on-chain means no additional information is exposed, marking a stark contrast from traditional social logins.
Thus far, we've explored Sui's zkLogin. While zkLogin seems capable of mitigating the inconveniences posed by blockchain wallets, that isn't the only pain point, as previously noted. Perhaps the transaction fees might be an even more significant inconvenience than wallets. How does Sui intend to tackle the complexity of transaction fees?
Source: Sui Blog
In truth, if something is problematic, the wisest solution often lies in eradicating the cause of that problem. If paying transaction fees in blockchain poses a user-interface problem, wouldn’t it be great if one could execute transactions without incurring those fees? This is where Sponsored Transactions come into play. Sui's programming language, Sui Move, allows application builders to cover part or all of the transaction fees that occur within their applications. Sponsored Transactions can be used in the following scenarios:
When covering the fees of transaction initiated by a user.
A user creates a GasLessTransactionData Object, which is sent to the builder for approval. The builder then crafts a TransactionData Object with the transaction fee, which, after being signed by the user, processes the transaction.
When builders directly transfer transaction fees to users.
Here, builders create a pre-authorized TransactionData Object (where the transaction cost is already covered) and send it directly to users via email or other messaging protocols, allowing users to initiate the transaction.
This type of transaction is especially handy for advertising or onboarding new users.
What's intriguing about this transaction type is that, combined with zkLogin, even users without any Sui tokens or those who've never used blockchain can have a Web3 experience.
When builders produce GasData to transfer to users.
Think of GasData as a blank check. Users who receive GasData (where transaction cost limits are predefined) don't need to know the exact transaction fee. Once they execute the transaction, the builder signs off, and the transaction is processed.
In this manner, Sui has structured a system where users can execute blockchain transactions without being aware of the transaction costs. As these features gain traction, there could come a time when many users utilize Web3 services without even realizing they're operating on a blockchain.
Adeniyi, the co-founder and CPO of Sui, asserted that following the success formula from Web2 could ensure triumph in Web3. If a Layer 1 blockchain is to become the core infrastructure of Web3, one must revisit the success stories of services like AWS. We use services built on AWS without directly paying AWS; it's the service providers that bear the AWS costs. While this may seem obvious, it’s not the case in the blockchain world.
Perhaps one of the primary reasons blockchain hasn't gone mainstream is that, at its core, it challenges human inertia.
In this regard, the initiatives of Sui with zkLogin and Sponsored Transactions could be signaling the direction that blockchain infrastructure services ought to take. It may not be too long before we're using application services without even realizing they're based on blockchain.
Thanks to Kate for designing the graphics for this article.
Dive into 'Narratives' that will be important in the next year
Sui
Optimism
