zkLogin构建者的最佳实践和业务思考

随着zkLogin在Sui主网上线，构建者可以开始为其应用程序提供丝滑的帐户创建服务。与任何新技术集成一样，构建者需要考虑许多重要的问题，以降低风险并成功优化。

本文概述了其中一些考虑因素，并突出了zkLogin文档中提供的明确指导。

zkLogin仅提供自托管地址

大多数具有用户友好型入门流程的Web3解决方案来自托管提供商。这些提供商管理用户的私钥，并提供熟悉的恢复路径，以防用户忘记其密码。虽然这种解决方案适用于愿意满足托管资产所需法规义务的企业，但许多构建者没有时间和预算来进行这个过程。

这就是zkLogin的用武之地，这种原生的自托管路径减少了监管负担，并缩短了简单登录的时间。然而，挑战在于，每个构建者都必须考虑其用户对自托管的舒适程度，以及zkLogin是否适合所有、一部分或完全不适合他们的用户。这种理解将有助于构建者确定可能希望在zkLogin上合并的其他帐户创建和密钥管理系统。

Web凭证应保持在链下

zkLogin使用目前可用的最佳加密方法，以确保链上地址不直接与Web凭证相关联，包括由凭证提供商提供的凭证。例如，如果您使用Google帐户生成Sui地址，Google永远不会被通知，也无法将地址与您关联起来。这种设计是有意的，至关重要，尤其是因为全球隐私法律（例如欧洲的GDPR和美国的CCA）要求凭证提供商必须遵守。应用程序构建者应该尽可能的熟悉许多隐私法律，这些法律管理用户可以与谁分享哪些用户信息以及他们对存储、保护和删除用户数据的义务等内容。

在实施zkLogin时，构建者通常可以选择使用子凭证（用户的唯一字母数字标识符）或实际的Web凭证（例如，电子邮件地址）来生成用户的链上地址。建议将链上帐户派生的问题与身份或发现（例如，用户之间更便于互动的方式）的问题分开。用户可能不希望、不期望或不受益于将其信息不可逆地放在其链上地址中。一种方法是使用名称服务（类似于域名URL）作为用户的身份层，以帮助减轻这种风险。

Prover和Salt管理涉及隐私

Sui文档详细概述了zkLogin生成地址的工作方式。简而言之，用户将使用其OAuth Web帐户登录以生成JSON Web Token（JWT）。然后，应用程序将提供JWT和salt（用于随机数据的常见加密术语）给零知识（zk）证明生成器，然后将证明作为Sui上交易的一部分。这个流程确保Web帐户信息永远不会在链上可见。

作为构建者，您可以选择运行自己的证明生成器和salt管理解决方案，或使用第三方解决方案。具有zk知识的构建者甚至可以选择使用公开可用的常见参考字符串从头开始构建自己的证明生成器。

运营证明生成器和管理salt是一个涉及隐私的任务。执行这些服务的任何实体原则上都将能够将Web凭证与Sui地址相关联，尽管这些信息在链上不可见。如果您正在构建一个涉及隐私的应用程序（例如，用户可能会存储高价值资产或金额的应用程序），则值得考虑自己运行证明生成器和进行自己的salt管理，而不是依赖第三方。

使用第三方服务时，请确保根据您自己的业务政策对产品、第三方服务的使用以及遵守相关的有关向用户披露的法律进行适当的治理。