Web3 正在快速擴張：新的應用程式、協議和功能日新月異。然而，對許多用戶而言，真正的入門障礙不在於缺乏鏈上功能，而在於如何安全地保護和恢復錢包密鑰。
目前，業界標準仍然是助記詞（Mnemonic）。然而，這種方法帶來了現實世界的挑戰：用戶經常截圖保存助記詞，無意中將其同步到雲端相簿；有些人則寫在紙上，結果卻遺失或損壞，導致資產永久丟失。這類事件太過常見。通常，這些風險並非源於技術故障，而是源於日常習慣的疏忽。
近年來，越來越多的「Web2 風格」錢包解決方案應運而生，允許用戶使用熟悉的登入方式創建、備份和恢復錢包。雖然它們的目標是降低入門門檻，但它們的實施方式存在顯著差異——特別是它們是否保持真正的去中心化和自我託管。
中心化分片（Sharding）的風險：一些解決方案將私鑰分割成多個「分片」（Shares）。分割本身不是問題。關鍵風險在於，如果單一參與實體（例如服務提供商的後端）持有足夠數量的分片來滿足恢復閾值，那麼他們理論上就有能力重構完整的密鑰，使得「自我託管」僅僅是一個名義上的承諾。
硬體安全模組（HSM）依賴風險：其他解決方案將私鑰儲存在硬體安全模組（HSM）中，聲稱只會根據嚴格的規則簽署交易。雖然這聽起來很穩妥，但如果規則執行或策略實現發生在信任邊界之外（即 HSM 之外），在極端情況下可能會被規避或操縱，從而導致簽署的交易不符合用戶的意圖。
OneKey 無助記詞錢包的不同之處
OneKey 的無助記詞錢包採用「Google/Apple 登入 + PIN 碼」的方法，將易用性與真正的自我託管融為一體。
您使用熟悉的帳戶系統進行登入和恢復，但底層架構採用分散式密鑰管理和簽名機制。這確保了沒有任何單一實體——包括 OneKey——能夠單方面重構您的完整密鑰或發起轉帳。
換句話說：即使我們的伺服器、特定組件或單一參與實體遭到入侵，攻擊者也不能僅僅透過入侵 OneKey 來「竊取您的錢包」。
OneKey 的解決方案
OneKey 的無助記詞錢包建立在分散式密鑰管理機制之上。其目標是讓您擺脫寫下、儲存和攜帶助記詞的高風險負擔。取而代之的是，您可以使用已知的密碼學方法來創建和恢復錢包：Google / Apple 登入 + PIN 碼。
降低負擔，不犧牲自我託管
傳統錢包依賴助記詞（通常為 12 或 24 個單詞），要求用戶安全儲存並在需要時手動恢復。無助記詞錢包讓您只需記住一個PIN 碼即可管理您的資產。錢包恢復的能力建立在分散式架構之上，確保完整控制權絕不會交給任何單一服務提供商。
雙重驗證：帳戶 + PIN 碼
無助記詞錢包使用兩種驗證因素：
您的 Google / Apple 帳戶
您的 PIN 碼
這意味著，即使您的 Google 或 Apple 帳戶遭到入侵，沒有 PIN 碼也無法執行關鍵操作。反之，僅有 PIN 碼也無法在未登入相關帳戶的情況下恢復或存取錢包。兩者都不可或缺，顯著降低了單點故障的風險。
助記詞僅在驗證後才會出現
在無助記詞錢包的設計中，完整的助記詞或私鑰不會在任何單一位置以明文形式長期儲存。只有當您在自己的設備上成功驗證帳戶和 PIN 碼後，錢包才會在本地完成必要的恢復和激活過程。
備份和恢復工作原理：
加密儲存：與助記詞相關的數據以加密形式儲存在伺服器上，以確保可用性（例如用於跨設備恢復）。
分片機制：解密所需的關鍵材料會被分割並分配給多個實體或節點。
因此，除非您在設備上完成驗證並觸發恢復，否則任何單一實體（包括 OneKey）都無法單方面將其重構為可用的明文密鑰。
技術深入探討
本節將解釋當您使用 Google 或 Apple 創建新的無助記詞錢包時，客戶端（您的設備）和伺服器端會發生什麼。它還闡明了「備份」和「恢復」過程如何在確保單一實體永遠無法存取您的完整私鑰的同時，保持用戶友好的體驗。
備份無助記詞錢包
在入門過程中創建無助記詞錢包時，您可以：
在主螢幕上選擇「繼續使用 Google」。
或者點擊「•••」按鈕 → 無助記詞錢包 → 選擇 Google 或 Apple。
重要提示：無助記詞錢包與傳統助記詞錢包是兩個獨立、分離的系統。目前不支援將「現有的助記詞錢包」遷移到無助記詞錢包；它們是並行存在的。
讓我們逐步了解用戶使用其 Google 或 Apple 帳戶創建錢包時發生的技術過程。
步驟 1 — 在設備上生成、加密和儲存助記詞密文
本地生成：設備在本地生成一個新的助記詞（作為錢包密鑰材料的隨機種源）。
創建對稱密鑰：設備同時生成一個對稱密鑰。
加密：設備使用此對稱密鑰來加密助記詞，生成助記詞密文。
安全儲存：只有助記詞密文會傳輸到 OneKey 後端進行安全儲存（以確保跨設備恢復的可用性）。
要點：
僅限本地處理：明文助記詞和對稱密鑰均僅在設備上生成和處理。它們絕不會直接傳輸到設備外部。
無法使用的密文：密文本身不能用於簽名。沒有對稱密鑰，就不可能將密文解密回可用的助記詞或密鑰材料。
步驟 2 — 將對稱密鑰分割成兩個「2 中取 2」的分片
在設備上，對稱密鑰使用沙米爾秘密分享（Shamir's Secret Sharing, SSS）和 2-of-2 閾值分割成兩個分片：
後端分片（Backend Share）：由 OneKey 後端持有。
Juicebox 分片（Juicebox Share）：儲存在去中心化儲存協議 Juicebox 中。
要點：
在 2-of-2 閾值下，單個分片不足以重構對稱密鑰。即使 OneKey 擁有「助記詞密文」和「後端分片」，它也不能單方面恢復錢包或啟動交易簽名。
步驟 3 — 將網路分片寫入分散式網路，受 PIN 碼保護
Juicebox 分片被寫入 Juicebox 網路。
用戶設定PIN 碼，該 PIN 碼用於保護從 Juicebox 檢索此分片的存取權限。
技術實施：該分片進一步分割成多個子分片（Sub-shares）並分散儲存在不同節點上。要檢索該分片，必須輸入正確的 PIN 碼以通過網路的閾值驗證。
恢復無助記詞錢包
步驟 1 — 驗證身份並檢索助記詞密文 + 後端分片
設備使用您的Google / Apple 帳戶執行身份驗證。
成功驗證後，設備從 OneKey 後端檢索兩段數據：
助記詞密文
後端分片
步驟 2 — 輸入 PIN 碼以檢索 Juicebox 分片
您在設備上輸入PIN 碼。
設備使用 PIN 碼從 Juicebox 分散式儲存協議中檢索Juicebox 分片。
步驟 3 — 重構對稱密鑰和解密
設備組合後端分片 + Juicebox 分片以重構原始對稱密鑰。
它使用此對稱密鑰解密助記詞密文，在設備本地恢復原始助記詞。
恢復完成後，錢包在 OneKey 應用程式內正常運作，就像標準錢包一樣。
綜合分析
最終狀態（數據分佈）
用戶：可以存取其 Google / Apple 帳戶並記得 PIN 碼。
OneKey 客戶端（設備）：擁有可用、已解密的助記詞（暫時用於使用）。
OneKey 伺服器：儲存密文和後端分片。
Juicebox 領域：分別儲存Juicebox 子分片（重構 Juicebox 分片所需）。
安全特性
OneKey 伺服器數據庫被攻破：即使攻擊者獲得密文和後端分片的存取權，他們也無法單方面重構對稱密鑰。因此，他們不可能解密助記詞。
Juicebox 領域/節點被攻破：只要攻擊者沒有獲取足夠數量的Juicebox 子分片（未能達到恢復閾值），他們就無法還原Juicebox 分片，因此無法協助重構對稱密鑰。
帳戶被攻破：僅僅存取 Google 或 Apple 帳戶不足以從 Juicebox 端檢索 Juicebox 子分片。檢索過程受到 PIN 碼的嚴格保護；沒有 PIN 碼，恢復鏈就無法完成。
安全性
OneKey 無助記詞錢包的設計目標是在不將「控制權」集中在任何單一實體手中的情況下，最大限度地降低入門門檻。由於錢包恢復是最敏感的操作之一，我們將協議的安全邊界和威脅模型置於設計核心。這樣可以確保可用性的提高不會以犧牲安全性為代價。
安全目標
我們的架構旨在實現以下兩個關鍵目標：
無單方面存取：任何第三方（包括 OneKey）都不應能夠單方面重構或使用用戶的私鑰或助記詞。
嚴格的恢復條件：用戶恢復其錢包的唯一方法是同時滿足兩個驗證要求：
透過其Google / Apple 帳戶成功進行身份驗證；
並且證明擁有PIN 碼。
為什麼 OneKey（單方面）無法重構您的密鑰
要在您的設備上還原可用的助記詞或密鑰材料，必須同時具備以下所有元素：
助記詞密文
對稱密鑰的兩個分片（後端分片 + Juicebox 分片）
此架構帶來了幾個直接結論：
Juicebox 內部的惡意行為者：如果少於閾值數量的 Juicebox 領域/節點採取惡意行為，攻擊者將無法重構有效的Juicebox 分片，因此無法重構對稱密鑰。
分散式網路完全被攻破：即使在假設整個分散式分片網路被攻破的情況下，攻擊者仍然會缺少 OneKey 後端持有的後端分片或密文，使得獨立恢復不可能實現。
OneKey 後端被攻破：即使 OneKey 後端受到攻擊，攻擊者仍然缺少儲存在 Juicebox 端的 खेली。如果沒有 Juicebox 分片，僅憑後端數據不足以重構對稱密鑰或解密助記詞密文。
為什麼「帳戶 + PIN 碼」都不可或缺
在身份和存取控制方面，無助記詞錢包將「你是誰」（帳戶身份）與「你知道什麼」（PIN 碼）分開：
帳戶方面：OneKey 使用已建立的 OAuth 2.0 登入/授權流程與 Google 和 Apple 介面，以進行身份驗證和授權。
PIN 碼方面：PIN 碼保護從分散式儲存協議（Juicebox）檢索關鍵分片的過程。即使攻擊者攻破您的帳戶，如果不知道 PIN 碼，他們也無法檢索相應的分片或完成恢復。
加密和密鑰管理
在加密和密鑰分割層面，無助記詞錢包遵循「密文可以儲存，但密鑰絕不能集中化」的原則：
助記詞加密：助記詞/密鑰材料使用經過身份驗證的加密算法（AES-256）加密以生成密文，確保恢復期間的完整性驗證。
密鑰分割和重構：沙米爾秘密分享（SSS）用於根據閾值規則分割和重構對稱密鑰。
靜態後端加密：儲存在後端的 खेली在儲存前會先使用雲端 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 碼）的信心得到驗證。
結論
對許多新用戶來說，雖然助記詞是業界標準，但使用它們通常遠非直觀。在新設備上手動輸入助記詞會帶來很大的摩擦，而了解如何或在何處安全地儲存它往往是困惑的根源。
OneKey 無助記詞錢包旨在達成不同的平衡：
它透過使用熟悉的媒介（Google / Apple + PIN 碼）降低了入門門檻。同時，透過分散式密鑰管理架構，它確保了沒有任何單一實體（包括 OneKey）可以單方面重構您的完整密鑰。這在「易用性」與「自我託管安全性的邊界」之間達成了一種非常適合大眾的折衷方案。