Web3 正在快速扩张：新的应用、协议和功能每天都在出现。但对很多人来说，真正的门槛并不是「链上功能不够多」，而是如何安全地保管与恢复钱包密钥。
目前行业最常见的做法仍然是助记词。但它也带来现实问题：有人会把助记词截图保存、同步到相册或云端；也有人写在纸上却遗失、损坏，最终导致资产无法找回。类似的损失故事并不少见，而这些风险往往并非「技术问题」，而是日常习惯带来的失误。
近几年，越来越多「更像 Web2」的钱包形态出现——例如用熟悉的登录方式来创建、备份与恢复钱包。它们的目标是降低使用门槛，但实现方式是否真正去中心化、是否真正自托管，差异非常大。
一些方案会把密钥拆成多份「分片」。分片本身不是问题，关键在于：如果某一个参与方（比如服务提供商的后端）单独持有足够多的分片（达到阈值），那它在现实中就具备了重建完整密钥的能力——这会让「自托管」变成名义上的承诺。
也有方案把私钥放进硬件安全模块（HSM）里，并宣称只会按规则代签交易。听起来合理，但如果规则判断/策略执行不在可信边界内（例如在 HSM 外部完成），在极端情况下就可能被绕过或被操纵，从而产生不符合用户意愿的签名。
OneKey 的 Keyless Wallet 选择用 Google / Apple 登录 + PIN 的方式，把「好用」与「自托管」放在同一套设计里：你用熟悉的账号体系完成登录与恢复流程，但在底层，我们采用分布式的密钥管理/签名机制，让任何单一方（包括 OneKey）都无法仅凭自身条件重建你的完整密钥或单独发起转账。
换句话说：即使服务端、某个组件或某一方遭遇入侵，攻击者也无法只通过攻破 OneKey 就直接「拿走你的钱包」。
OneKey 的解决方案
OneKey 的无私钥钱包基于一套分布式的密钥管理机制，目标是让你不必再承担「抄写、保管、搬运助记词」的高风险流程，而是用你更熟悉的方式完成创建与恢复：Google / Apple 登录 + PIN。
更少负担，但不牺牲自托管边界
传统钱包依赖助记词（通常是 12/24 个单词，取决于实现），用户需要自己保存并在需要时手动恢复。Keyless Wallet 让你只需要记住一个 PIN，同时把“恢复能力”建立在分布式架构上，而不是把完整控制权交给任何单一服务方。
双重验证：账号 + PIN
Keyless Wallet 使用两种验证要素：
你的 Google / Apple 账号
你的 PIN
这意味着：即使账号被盗，没有 PIN 也无法完成关键操作；反过来，仅有 PIN 也无法在没有账号登录的情况下恢复或访问钱包。两者缺一不可，降低单点失守带来的风险。
助记词只在你通过验证后，才会在设备上出现
在 Keyless Wallet 设计里，完整助记词/完整私钥不会长期以明文形式存放在任何单一位置。只有当你在设备上通过账号与 PIN 的验证后，钱包才会在你的设备上完成必要的恢复与使用流程。
当涉及到备份/恢复时：
与助记词相关的数据会以加密后的形式存放在服务端用于可用性（例如跨设备恢复）。
解密所需的关键材料会被拆分并分散在多个参与方/节点中管理（「分片」机制）。
因此，除了你完成验证并在设备侧触发恢复外，任何单一方（包括 OneKey）都无法单独把它还原成可用的明文密钥。
技术详解
这一节会解释：当你用 Google / Apple 创建一个新的无私钥钱包时，设备端与服务端分别做了什么；以及「备份」和「恢复」为什么既好用，又不会让任何单一方拿到你的完整密钥。
备份无私钥钱包
在 Onboarding 中创建无私钥钱包时，你可以：
在首页中点击「使用 Google 继续」
或点击「•••」按钮 → 无私钥钱包 → 选择 Google 或者 Apple
注意：Keyless Wallet 与传统助记词钱包是两套独立体系。目前不支持把“已有助记词钱包”迁移为 Keyless Wallet，它们彼此独立、并行存在。
让我们通过用户使用 Google 或 Apple 创建钱包时发生的情况。
Step 1 — 在设备端生成助记词、加密，并保存密文
设备本地生成一组新的助记词（作为钱包密钥材料的随机来源）。
设备同时生成一个对称密钥（Symmetric Key）。
使用该对称密钥对助记词加密，得到助记词密文（Seed Ciphertext）。
仅将助记词密文发送到 OneKey 后端进行安全存储（用于跨设备恢复的可用性）。
关键点：
助记词明文与对称密钥都只在设备侧产生与处理，不会直接发送出设备。
密文本身不能用于签名；没有对称密钥，就无法把密文还原为可用的助记词/密钥材料。
Step 2 — 拆分对称密钥为 2-of-2 两份分片
回到设备侧：将对称密钥通过 Shamir Secret Sharing 拆分为 2-of-2 两份分片：
Backend Share：由 OneKey 后端持有
Juicebox Share：储存在分布式存储协议 Juicebox 中
关键点：在 2-of-2 阈值下，任何单一分片都不足以重建对称密钥。
即使 OneKey 同时拿到「助记词密文 + 后端分片」，也无法单独恢复钱包或发起签名。
Step 3 — 将网络分片写入分布式网络，并由 PIN 保护访问
将 Juicebox share 写入 Juicebox 网络。
用户设置 PIN，PIN 用于保护从 Juicebox 取回该分片的访问过程。
实现上，我们把该分片进一步拆成多个子分片（Sub-shares），分别分发到不同节点保存；取回分片时，需要输入 PIN 并通过网络的阈值校验。
恢复无私钥钱包
Step 1 — 身份验证并获取助记词密文 + 后端分片
设备使用你的 Google / Apple 账号完成身份验证。
验证通过后，设备从 OneKey 后端获取两项数据：
助记词密文（Seed Ciphertext）
Backend share
Step 2 — 输入 PIN 取回 Juicebox share
在设备上输入 PIN。
设备使用 PIN 从分布式存储协议 Juicebox 中取回 Juicebox share。
Step 3 — 重建对称密钥并解密
设备将 Backend share + Juicebox share 组合，重建原始的对称密钥（Symmetric Key）。
使用该对称密钥解密助记词密文，在设备端恢复出原始助记词。
恢复完成后，钱包会在 OneKey App 内按正常钱包方式使用。
综合分析
最终状态
用户：可访问其 Google / Apple 账号，并记住 PIN
OneKey Client（设备端）：拥有可用的助记词
OneKey server：保存 Ciphertext 与 Backend share
Juicebox Realms：分别保存 Juicebox Sub-share 1/2（用于还原 Juicebox share）
安全属性
OneKey server 数据库被入侵：攻击者即使拿到 Ciphertext + Backend share，也无法单独重建 Symmetric Key，因此无法解密出助记词。
Juicebox 部分 Realm/节点不可信：只要攻击者拿不到足够的 Juicebox Sub-share（达不到恢复所需数量），就无法还原 Juicebox share，也就无法帮助重建 Symmetric Key。
账号被盗：仅有账号不足以从 Juicebox 侧取回 Juicebox Sub-share，因为取回过程受 PIN 保护；没有 PIN 就无法完成恢复链路。
安全性
OneKey 无私钥钱包的设计目标是：在尽可能降低使用门槛的同时，不把「控制权」集中到任何单一方手里。由于「恢复钱包」是最敏感的路径之一，我们把协议的安全边界与威胁模型放在设计的核心位置，确保可用性提升不以安全性为代价。
安全目标
我们希望满足以下两点：
任何第三方（包括 OneKey）都不应能够单方面重建或使用用户的私钥/助记词。
用户恢复钱包的唯一方式是同时满足两类验证：
通过 Google / Apple 账号完成身份验证；
并证明自己掌握 PIN。
为什么 OneKey（单方）无法重建你的密钥
要在设备端恢复出可用的助记词/密钥材料，至少需要同时具备：
助记词密文（Ciphertext）
对称密钥的两份分片（Backend share + Juicebox share）
这带来几个直接结论：
当少于阈值数量的 Juicebox Realm/节点出现恶意行为时：攻击者无法拼出有效的 Juicebox share，因此无法重建对称密钥。
即使假设分布式分片网络整体受损：攻击者仍然缺少 OneKey 后端侧的 Backend share 或密文，无法单独完成恢复。
即使 OneKey 后端遭到攻击：攻击者也仍然缺少 Juicebox 侧的分片；仅凭后端数据无法重建对称密钥，也就无法解密助记词密文。
为什么「账号 + PIN」缺一不可
在身份与访问控制上，无私钥钱包将「谁是你（账号身份）」与「只有你知道的东西（PIN）」拆开处理：
账号侧：OneKey 使用成熟的 OAuth 2.0 登录/授权流程对接 Google / Apple，用于完成身份验证与授权。
PIN 侧：PIN 用于保护你从分布式存储协议 Juicebox 取回关键分片的过程。即使攻击者拿到了账号，也无法在不知道 PIN 的情况下取回对应分片并完成恢复。
加密与密钥管理
在加密与密钥拆分层面，无私钥钱包遵循「密文可存储、密钥不可集中」的原则：
助记词加密：使用认证加密算法（AES-256）对助记词/密钥材料加密生成密文，并在恢复时验证完整性。
密钥拆分与重建：使用 Shamir Secret Sharing 对对称密钥进行分片与重建（按阈值规则）。
后端静态加密：后端存储的分片会先通过云服务 KMS 与加密算法进行加密处理，再进行存储，确保全程无明文可见，从而保障密钥数据安全。
可靠性
理解 OneKey 无私钥钱包的一个关键点是：恢复需要同时满足两个条件——你能登录对应的 Google / Apple 账号，并且记得 PIN。
与传统 Web2「忘记密码可找回」不同，OneKey 无法替你找回 PIN，也无法替你重建私钥/助记词。这不是缺陷，而是安全边界的一部分：一旦服务方能够获取其中任何一个要素，「自托管」的核心属性就会被削弱。
也因此，真正的「零信任」方案必然要求用户承担一部分责任：账号要能找回、PIN 要能记住。
忘记 PIN 的情况
另一方面，无私钥钱包的助记词也会在已登录的设备上以可用形式存在。
因此，如果你忘记了 PIN，但你仍然有一台已登录且还能正常使用钱包的设备，通常可以在该设备上重置 PIN，并完成新的备份配置（以确保后续仍能跨设备恢复）。
PIN 定期验证提醒
为了降低「时间久了忘记 PIN」的风险，OneKey 会在适当的时候提示你验证一次 PIN。
如果你在验证时发现自己确实记不清 PIN，可以趁仍有设备可用时尽快完成 PIN 重置，并重新生成/更新备份配置。
最终可用性边界
综合来说，只要满足以下任一条件，你通常就能继续访问你的无私钥钱包：
你仍有一台可用的已登录设备；或
你能登录 Google / Apple 账号，并且记得 PIN（用于在新设备上恢复）。
我们建议：做一次「跨设备恢复演练」
因为恢复流程本质上就是「登录账号 + 输入 PIN」，我们建议你在创建无私钥钱包后，尽快在另一台设备上做一次恢复演练。
这样你会同时拥有：
设备 A 的访问点
设备 B 的访问点
一份可用于新设备恢复的备份路径（账号 + PIN）
总结
对很多新用户来说，助记词虽然是行业常见方案，但它的使用方式并不直观：在新设备上输入助记词摩擦很大；该怎么保存、保存到哪里更安全，也经常让人困惑。
无私钥钱包尝试提供另一种平衡：
用更熟悉的方式（Google / Apple + PIN）降低上手门槛，同时通过分布式的密钥管理设计，让任何单一方（包括 OneKey）都无法单独重建你的完整密钥，从而在「好用」与「自托管安全边界」之间取得更适合大众的折中。