After our discussion with Alberto Sonnino from Mysten Labs in early 2024, we wanted to follow up on the current state of the ZK landscape in the Sui Ecosystem.

Below is the Q&A we had with Deepak Maram, researcher at Mysten Labs. 

TL;DR

• Adoption Growth: zkLogin adoption surged with Enoki, generating 1.6M+ ZK proofs (85% post-May 2024) for 4M+ transactions, enabling easier integration for wallets, DeFi, and NFTs.
• Asset Transfer UX: Stashed wallet simplifies transfers via links/QR codes without mnemonics, avoiding privacy risks of email-bound addresses.
• Expanding Use Cases: New zkLogin providers added; future work includes faster proof generation, flexible signature support, and efficient credential issuance.
• Broader ZK Efforts: Focus on private authentication, lightweight ZK light clients, and cryptographic optimizations via FastCrypto for scalability.

zkLogin

Q: zkLogin was deployed on Sui some time ago, which is very interesting from an adoption perspective. Did you notice any change in your adoption metrics? 

A: zkLogin has been steadily gaining traction since we launched it a year ago. In order to make zkLogin integration as simple as possible, our team at Mysten Labs has launched Enoki earlier this year, a SaaS service offering proof generation and salt management services (among other value-add services like sponsored transactions, human-readable names etc.). 

Enoki is being used by a wide range of partners like wallet providers, DeFi and NFT platforms. Thanks to Enoki, we have seen an uptick in zkLogin adoption – to date, our prover service has generated over 1.6 million unique Zero-Knowledge Proofs (over 85% of those have been generated after May 2024) that have been used to power upwards of 4 million zkLogin transactions. As a side note, this increased workload has put focus on the performance of our ZK prover (a pleasant problem to have!). 

Q: The tech used for zkLogin can also improve the UX of asset transfers (e.g., sending Sui tokens to someone’s email address). Is there any work on that front? 

Indeed, zkLogin significantly improves the UX of asset transfers. Showcasing this, we’ve recently launched Stashed, a web-based wallet that allows people to use Sui without having to install additional software (no need for an extension or a mobile app) or remember a new passphrase/mnemonic. Stashed allows users to send assets (money, NFTs, etc.) by creating and sharing either a link or a QR code with anyone. Internally, the assets are escrowed in a contract. Once the recipient creates a zkLogin account, they can receive the assets instantly. While directly sending to someone’s email address is also technically possible, we have not yet enabled it for privacy reasons as it creates a permanent binding between an email and an on-chain address. 

Stashed has successfully showcased the ease of transferring assets, as the recipient only needs a Google or Twitch account to receive any asset living on the Sui blockchain within seconds! We hope the UX improvements Stashed offers make it a great wallet for new users.

Q: Are there any other use cases that zkLogin unlocks and might hit mainnet soon? 

A: We have been constantly expanding the set of zkLogin providers supported. For example, we have recently launched zkLogin with Apple on mainnet and zkLogin with Kakao, Microsoft, Slack on devnet (which we hope will soon progress to mainnet). We have also onboarded many providers that have added OpenID support to their existing bespoke authentication systems. This is quite an interesting pattern as it allows providers to create blockchain wallets for their users automatically!

The popularity of Stashed has naturally led to discussions around ways to further improve its security, as web wallets have not traditionally been the most secure. One interesting proposal is using passkeys to store zkLogin’s ephemeral keys. This gives a glimpse into interesting possibilities that lay ahead as we try to push the boundaries of designing user-friendly wallets while still being secure.

Taking a slightly more long-term view, there are plenty of interesting directions to improve zkLogin. To name a few, we would like local proof generation (either with Groth16 or a newer proving system), more flexible proof generation (e.g., work for both RSA, ECDSA signatures without extra proving overhead), more efficient credential issuance algorithms (nudge issuers to switch to ZK-friendly algorithms). In a sense, “ZK for authentication” is quite unique compared to other ZK use cases as it requires blazing fast provers (has to finish in 2-3s for a smooth user experience) and small proof sizes (to post on-chain). 

Other ZK projects in Sui

Q: Besides zkLogin, are there any other ZK projects currently being developed on Sui that you are excited about? Can you share some details with us? 

A: Improving user authentication on all fronts has been a key focus area for us. We recently worked on a project to minimise the amount of information revealed about one’s authentication policies. A lot of potentially sensitive information can be gleaned from authentication policies, e.g., if your organization uses a 1-out-of-3 multisig, then it is clear that hacking one entity is enough to steal all the assets, or if you are using zkLogin with Google, then it is clear that hacking your Google account is enough to steal. 

Our key idea hinges on an interesting insight about Groth16: we prove that Groth16’s verification key does not reveal any information about the circuit. Therefore, we can encode arbitrarily complex policies into the circuit and use a hash of the corresponding verification key as the on-chain address! This allows us to realise authenticators that can encode arbitrary logic while keeping it private, e.g., hide whether using zkLogin or a mnemonic! We hope to release a paper with all the details soon.

More recently, we have also begun looking at ZK for light clients. The high-level goal is to allow making arbitrarily complex queries about the blockchain’s history and receive provable responses. The traditional approach to light clients has been to make validators commit to the entire state periodically. But this incurs significant overhead. We are looking into alternative light-weight approaches using Zero-Knowledge Proofs.

Q: Let’s talk about FastCrypto. What role does it play for the Sui roadmap, particularly concerning ZK projects? 

A: FastCrypto houses all the cryptography code necessary for Sui, including the necessary pieces for ZK projects like zkLogin. A deep dive into the myriad different optimizations (ZK or otherwise) we made in FastCrypto can be found in this recent paper. 

Productionizing zkLogin required improving and optimizing parts of various open-source cryptography libraries: more efficient Poseidon hashing (to speed up verification), optimized BLS, bug fixes in a trusted setup generating library, to name a few. More details are in the following blog. 

Beyond ZK in Sui 

Q: Recently, the KelpMe protocol, providing account recovery after key loss without backups, earned 1st prize in the Bybit/DMCC Global Hackathon. To solve this challenge, the Mysten Labs / Sui team had to design a novel fraud-proof system since a ZK-only solution was insufficient. Could you perhaps tell us more about why that is, give us some insights into this new fraud-proof system, and what sets it apart from prior constructions? 

A: KelpMe tries to solve the difficult problem of protecting users against key loss. As we all know, mnemonics are hard to use and easy to forget. Broadly speaking, KelpMe takes inspiration from two recent published works by us: Kelp (at FC’21) and interactive authentication (at CCS’24). 

The most common solution to protect against key loss is to use an OR wallet, but that also weakens the account’s security. For example, if we use k1 OR k2, where k1 is controlled by the user and k2 by a custodian, then the user is protected against key loss, but the custodian can easily take over the account.

In contrast, KelpMe strives to strike the fine balance of retaining self-custody while protecting against key loss! The main idea is to rely on a pre-set list of custodians that can trigger a recovery to help the user recover from a lost key. However, a common worry with such systems is that one of the custodians could go rogue and attempt to take over the user’s account. We deal with this threat by allowing the user to submit a fraud-proof showing that the key is not lost, and once this is proven, we punish the custodian by slashing their deposit. It is essential to give the user a sufficiently long enough time period, e.g., a week or a month, to submit the fraud-proof, as otherwise, the user may not have enough time to react. You can play around with a live demo of KelpMe on testnet at https://kelpme.io/ 

More generally speaking, KelpMe is an instance of a class of mechanisms called “interactive mechanisms”. Interactive mechanisms leverage synchrony (the assumption that the mechanism’s messages reach the user within a specified period) to secure users’ assets. Our recent work shows that synchrony opens a rich design space of mechanisms that are strictly more secure than commonly used one-shot mechanisms (like the OR, AND or multi-sig wallets): see this blog for an overview of the important ideas. KelpMe also has a no-guardian mode for users who do not want to use a custodian, extending ideas from Kelp.