Best practices and business reflections from zkLogin builders

With zkLogin going live on Sui mainnet, builders can start offering silky smooth account creation services for their applications. As with any new technology integration, there are many important issues builders need to consider in order to reduce risk and optimize successfully.

This article outlines some of these considerations and highlights the clear guidance provided in the zkLogin documentation.

zkLogin only offers self-hosted addresses

Most Web3 solutions with user-friendly onboarding processes come from hosting providers. These providers manage users' private keys and provide familiar recovery paths in case users forget their passwords. While this solution is available for businesses willing to meet the regulatory obligations required to host assets, many builders do not have the time or budget to undertake this process.

This is where zkLogin comes in, this native self-hosted path reduces regulatory burden and shortens the time it takes to simply log in. The challenge, however, is that each builder must consider how comfortable their users are with self-hosting and whether zkLogin is a good fit for all, some, or not at all their users. This understanding will help builders identify other account creation and key management systems that may wish to be incorporated on zkLogin.

Web credentials should be kept off-chain

zkLogin uses the best encryption methods currently available to ensure that on-chain addresses are not directly associated with web credentials, including those provided by credential providers. For example, if you use a Google account to generate a Sui address, Google is never notified and cannot associate the address with you. This design is intentional and critical, especially because global privacy laws such as Europe's GDPR and the U.S.'s CCA require credential providers to comply. Application builders should be as familiar as possible with the many privacy laws that govern what user information users can share with whom and their obligations to store, protect, and delete user data.

When implementing zkLogin, builders typically have the option of generating a user's on-chain address using either a subcredential (the user's unique alphanumeric identifier) or an actual web credential (e.g., email address). It is recommended to separate issues of on-chain account derivation from issues of identity or discovery (e.g., a more convenient way for users to interact with each other). Users may not want, expect, or benefit from having their information irreversibly placed in their on-chain address. One approach is to use name services (similar to domain name URLs) as an identity layer for users to help mitigate this risk.

Prover and Salt management involves privacy

The Sui documentation provides a detailed overview of how zkLogin generated addresses work. In short, the user will log in using their OAuth web account to generate a JSON Web Token (JWT). The application will then provide a JWT and a salt (a common cryptographic term for random data) to a zero-knowledge (zk) proof generator, which will then provide the proof as part of the transaction on Sui. This process ensures that web account information is never visible on-chain.

As a builder, you can choose to run your own proof generator and salt management solution, or use a third-party solution. Builders with knowledge of ZK can even choose to build their own proof generator from scratch using common reference strings that are publicly available.

Operating a proof generator and managing salt is a privacy-related task. Any entity performing these services will in principle be able to associate web credentials with Sui addresses, although this information will not be visible on-chain. If you are building an application with privacy concerns (e.g. one where users may store high-value assets or amounts), it is worth considering running the proof generator and doing your own salt management yourself, rather than relying on a third party .

When using third-party services, please ensure that the products, use of third-party services, and compliance with relevant laws regarding disclosure to users are appropriately governed in accordance with your own business policies.

Choice of Salt Management Solution

Choosing a Salt management solution is one of the most important decisions a zkLogin builder must make. The zkLogin documentation outlines several options for Salt management, each with its own convenience, security, and recoverability tradeoffs. At a high level, there are two main options: SSO form and password form.

Builders are conflicted between letting users in and preventing bad actors from accessing assets, and every builder needs to find the right niche for their app between convenience and security. Regardless of the approach, builders using zkLogin should always ensure that all applicable disclosures are provided to users.

Let's build a better internet for everyone

It’s time for blockchain to deliver breakthrough experiences for everyone, and builders on Sui are ready to serve a broad audience. With currently approximately 100 million blockchain addresses and over 4 billion web accounts, zkLogin is a critical step in bringing blockchain to a mainstream audience. When implemented in a thoughtful way, this feature will ensure that Sui provides the best experience for the next billion users.

About Sui Network

Sui is an L1 public chain redesigned and built based on first principles, aiming to provide creators and developers with a development platform capable of hosting the next billion users in Web3. Applications on Sui are based on the Move smart contract language and are horizontally scalable, allowing developers to support a wide range of application development quickly and at low cost. Get more information: https://linktr.ee/sui_apac