跳至内容
0%

非加密原生用户如何选择智能钱包基础设施

发布于 2025年11月12日2 分钟阅读

为非加密用户选择智能钱包基础设施指南插图

如今,全球有52亿人使用数字钱包,但大多数人从未接触过加密货币,而他们也不应该为了使用你的应用而去学习加密货币。如果你是在为普通用户构建应用,你需要能够彻底隐藏区块链细节的钱包基础设施。

Smart Wallets 屏蔽了这些复杂性,让区块链账户变得像其他登录方式一样普通。不需要助记词,不需要 gas 费,也不需要"连接钱包"这种会在用户完成注册前就把 90% 的人吓跑的弹窗。

在本指南中,我们将介绍如何为非加密用户实现钱包基础设施,包括如何选择合适的方案、评估服务商时需要关注哪些方面,以及上线前如何测试。

从定义用户开始

在选择 SDK 之前,先弄清楚这些钱包实际的使用者是谁,以及他们为什么要用。

至少构建三个用户画像。比如二十多岁、期望使用 Face ID 和即时结账的"移动优先购物者";需要引导式入门的"对 DeFi 感兴趣的新手";或是需要 SSO 集成的"企业员工"。为每个画像记录人口特征、技术熟练程度和主要使用动机。

设定具体目标。我们建议将账户创建时间控制在 30 秒以内,杜绝助记词泄露,并将首次交易成功率维持在 95% 以上。用户现在默认期望应用支持基于 passkey 或社交/邮箱的身份验证,以及无 gas 交易。

梳理你最主要的三种交易流程。 用户是在实体店里点击支付吗?发起点对点转账?还是应用内购买?记录每种流程并标出摩擦点。一个需要先买 ETH 才能支付 gas 费才能完成交易的用户,就是一个会流失的用户。

Smart Wallets 的实际工作原理

smart wallet 本质上是一个智能合约,可以执行可编程逻辑、管理密钥并代替用户支付 gas 费。传统的加密钱包要求用户自行保管 12 个单词的助记词,而 smart wallet 在幕后处理密钥管理,用户只需通过他们已经熟悉的方式进行身份验证——Face ID、指纹,或邮箱一次性验证码。

我们已经处理了超过4 亿笔 smart wallet 交易,占所有 smart wallet 活动的 85% 以上。这类基础设施已经从实验阶段走向了生产就绪。

内嵌式与外部 smart wallet

在实现 smart wallet 时,你有两种架构选择:

内嵌式钱包通过 SDK 直接集成到你的应用中。用户无需离开你的界面或下载其他应用,所有操作都在应用内完成。这适合消费者应用、游戏、DeFi 以及需要你完全掌控整个体验的忠诚度计划。

外部 smart wallet 是第三方品牌钱包,用户可以像使用Coinbase Smart Wallet那样将其带入你的应用。你可以将连接体验嵌入到应用中,但用户通过第三方的界面管理自己的资产。他们可以在多个应用中使用同一个钱包,从而获得一致的体验以及对密钥的完全掌控权。

Feature
Embedded Smart Wallets
External Smart Wallets

集成方式

应用内 SDK

通过第三方连接

UX 复杂度

极低

中等到较高

适用场景

消费者应用、金融应用、游戏、忠诚度计划

高级用户、跨应用场景

示例

Privy、Alchemy、Dynamic

Safe、Coinbase Smart Wallets

UX 上的突破:passkey 与 gas 代付

两项技术让 smart wallet 对主流用户变得可行:

Passkey 身份验证用助记词取代了用户在银行应用中已经信任的生物识别安全方式。钱包服务商在安全隔离区中生成并存储密钥,用户通过指纹或人脸扫描进行身份验证。Apple、Google 和 Microsoft 都原生支持 passkey,这意味着你是在操作系统级别的安全原语之上构建应用。

Gas 代付意味着由你来支付交易费用,而不是用户。他们无需购买 ETH、了解 gas 价格,或担心交易失败。账户抽象框架——特别是 ERC-4337——让这一切成为标准做法。paymaster 合约代替用户支付费用,你可以设置诸如"赞助前 10 笔交易"或"赞助 100 美元以下的交易"这样的策略。

这两项技术结合起来,消除了两大主要障碍:复杂的身份验证和前置的代币要求。

评估服务商时该关注什么

有三点决定了一个服务商能否与你一起扩展:安全态势、gas 代付的实现方式,以及开发者体验。

安全性、审计与密钥隔离

查阅 QuantstampOpenZeppelin 等机构出具的第三方审计报告。检查是否有硬件级别的密钥隔离——用户密钥是否与服务商基础设施分开存储。留意是否提供 MFA 选项以及 SOC 2 等合规认证。

密钥隔离能确保即使服务商遭到攻击,用户密钥依然安全。要求服务商详细讲解他们的密钥管理架构。如果他们无法说清楚,这就是一个危险信号。

Gas 代付与账户抽象

服务商通过 paymaster——代替用户支付费用的智能合约——来实现账户抽象。

构建一个对比矩阵:

  • 服务商是否代付 gas?支持哪些链?
  • 能否设置自定义策略?(比如只赞助前 N 笔交易?还是限定交易金额以下?)
  • 用户用完 gas 额度后会发生什么?
  • 如何为 paymaster 余额充值?

有些服务商允许你根据交易类型或用户行为有条件地赞助 gas。当你需要在用户体验和成本控制之间取得平衡时,这种灵活性很重要。

API 设计、多链支持与定价

要求提供具体的 API 示例。能否通过一次 API 调用就创建一个钱包?签名并发送一笔交易需要多少行代码?开发者体验决定了你的产品上市速度。

如果你想看完整的实现方式,我们构建了一个预配置的 quickstart 仓库,其中包含了完整的流程——身份验证、钱包创建和交易。你可以克隆它,几分钟内就能跑起一个可用的演示。

要求服务商保证定价透明。有些服务商收取固定月费,有些采用按用量计费。许多服务商为早期项目提供免费额度。多链支持同样必不可少,这能让用户获得最广泛的流动性接入。

询问速率限制、SLA 保证和支持响应时间。一旦进入生产阶段,这些运营细节比功能清单更重要。

上线前先测试

在上线前先在受控环境中做原型验证。生产环境中调试的成本要高得多。

搭建沙箱环境

配置一个测试网环境——Ethereum 用 Sepolia,Base 用 Base Sepolia。从服务商处获取沙箱 API 密钥。编写自动化脚本,模拟 1000 个并发注册,测量高负载下的响应时间。

大规模测试能揭示手动测试中看不到的瓶颈。一个能顺畅处理十次注册的服务商,在数百次并发下可能就会崩溃。我们是吃过这个亏才明白的。

测试关键流程与恢复场景

列出测试用例:

  • 成功注册
  • 邮箱验证失败
  • 设备丢失后的恢复
  • Passkey 重置
  • Gas 代付交易失败
  • 网络拥堵场景

明确定义恢复方式。通过可信联系人进行社交恢复对用户友好,但需要用户提前指定联系人。托管式代管方式简单,但需要信任服务商。硬件备份密钥安全性高,但用户可能会丢失。

每种恢复方式都是在便利性和安全性之间做取舍。根据你用户的技术熟练程度和风险承受能力来选择。对于面向大众消费者的应用,我们倾向于以托管式代管为主、可选社交恢复为辅的方式。对于 DeFi 协议,完全的用户自主权则更为重要。

衡量关键指标

设定目标阈值:

  • API 响应时间低于 200 毫秒
  • 错误率低于 1%
  • "创建钱包"这一步骤的用户流失率低于 5%

NFC 非接触支付通常在一秒内完成。如果你的钱包在点击支付场景下达不到这个速度,用户会注意到——他们会怪你的应用,而不是区块链。

持续跟踪这些指标。API 延迟或错误率的突然上升,会在演变成用户投诉之前就预示基础设施问题。

上线、监控、迭代

生产环境才是理论真正接受检验的地方。真实用户会以测试从未预料到的方式给系统施加压力。

实时监控与安全

集成 Grafana 或 CloudWatch 之类的仪表盘,跟踪活跃用户数、gas 代付交易量以及异常检测。对异常模式设置告警——失败交易激增、地理分布异常,或账户创建速度过快。

AI 驱动的欺诈检测能捕捉到人工难以发现的模式。美国财政部利用机器学习识别欺诈的成功案例证明了这种方法在规模化场景下的有效性。你也需要类似的能力。

恢复与合规

记录一套逐步的恢复流程:身份验证、恢复密钥签发、钱包重新绑定。在合规与隐私之间取得平衡——在必要的地方实施 KYC/AML 验证,但不要过度收集用户数据。

现在许多司法辖区都要求金融服务提供 KYC。可以与 PersonaOnfido 等专业服务商合作,让他们处理身份验证工作,同时确保你保持合规。除非你有专门的合规团队,否则不要自行搭建这套系统。

通过迭代实现规模化

安排季度回顾以评估新功能。语音支付在 2023 年增长了 25%,并且持续获得更多用户。对 UI 元素做 A/B 测试——生物识别提示的转化率是否比 passkey 选项更高?哪种引导流程的流失率最低?

用户行为能揭示什么真正有效。让数据引导你的路线图,而不是靠对用户"应该"想要什么的假设。

常见问题

Smart wallet 在没有助记词的情况下是如何工作的?

Smart wallet 使用基于 passkey 的身份验证或托管式密钥管理。服务商在硬件安全模块中生成并安全管理密钥,用户通过 Face ID、指纹或邮箱验证码登录。助记词从来不会以用户可能丢失或泄露的形式存在。

什么是无 gas 交易?

无 gas 交易是指钱包服务商代替你支付区块链费用的交易。这消除了用户在交易前必须先获取原生代币的需求——这是主流用户采用的最大障碍。在底层,paymaster 合约代付 gas 费,你再根据自己的定价方案向服务商偿付。

如何满足 KYC/AML 的合规要求?

集成一个 KYC 服务商,在钱包创建时验证用户身份,并持续监控交易模式。大多数内嵌式钱包服务商都支持可插拔的 KYC 集成。这样你无需自行搭建身份验证基础设施或直接处理敏感用户数据,也能满足合规要求。

如果用户丢失设备会怎样?

恢复方式包括通过可信联系人进行社交恢复、由服务商提供的托管式代管,或者存储在其他设备上的次要 passkey。每种方式都与经过验证的用户身份绑定。对于消费者应用,我们建议以托管式代管作为主要恢复方式,社交恢复作为备用方案——这样能在安全性和易用性之间取得最佳平衡。

我应该使用内嵌式钱包还是外部 smart wallet?

如果你需要将用户摩擦降到最低、提供无缝的应用内体验,使用内嵌式钱包——这适合消费者应用、游戏、DeFi 和忠诚度计划。如果用户需要跨应用的可移植性、对密钥的完全掌控权,或高级 DeFi 功能,则使用外部 smart wallet。大多数面向大众用户的应用应该从内嵌式钱包开始。

下一步

如果你正在为非加密用户构建钱包基础设施,先从定义用户画像和交易流程开始,然后用几家服务商做原型验证,看哪种方案最适合你的场景。

我们构建 Smart Wallets 正是为了解决这些问题。它通过单一 SDK 处理身份验证、gas 代付和账户抽象,并支持跨链使用。你可以在一个下午内完成集成,交付出一套感觉像其他登录系统一样自然的钱包基础设施。

访问我们的文档开始使用,或者联系我们讨论你的具体需求。

常见问题解答

什么是 smart wallet?

Smart wallet 是一个智能合约,它执行可编程逻辑、管理密钥并代替用户支付 gas,从而消除了对助记词的需求,并允许用户通过 Face ID、指纹或邮箱等方式进行身份验证。

内嵌式与外部 smart wallet 有什么区别?

内嵌式钱包通过 SDK 直接集成到你的应用中,提供无缝的应用内体验;而外部 smart wallet 是第三方品牌钱包,用户可以将其带入你的应用,并在多个应用之间使用。

Smart wallet 在没有助记词的情况下是如何工作的?

Smart wallet 使用基于 passkey 的身份验证或托管式密钥管理,服务商在硬件安全模块中安全管理密钥,用户通过 Face ID、指纹或邮箱验证码登录。

什么是无 gas 交易?

无 gas 交易是指钱包服务商通过 paymaster 合约代替你支付区块链费用的交易,从而消除了用户在交易前必须先获取原生代币的需求。

如果用户丢失设备会怎样?

恢复方式包括通过可信联系人进行社交恢复、由服务商提供的托管式代管,或者存储在其他设备上的次要 passkey,所有方式都与经过验证的用户身份绑定。

在评估 smart wallet 服务商时应该关注哪些安全特性?

关注 Quantstamp 或 OpenZeppelin 等机构出具的第三方审计报告、硬件级别的密钥隔离、MFA 选项,以及 SOC 2 等合规认证。

我应该选择支持 gas 代付的服务商吗?

是的,gas 代付对主流用户采用至关重要,因为它让你能够代替用户支付交易费用,用户无需购买 ETH 或了解 gas 价格。

在选择服务商时,哪些开发者体验因素比较重要?

优先选择那些 API 设计清晰、能通过一次调用创建钱包、支持多链、定价透明、有速率限制和 SLA 保证,并且支持响应速度快的服务商。

Background gradient

构建区块链应用

Alchemy 将最强大的 Web3 开发者产品和工具与资源、社区及专业支持结合在一起。