探討账戶架構:為什么三密鑰系統是理想的解決方案?
原文作者:Norswap
原文編譯:深潮 TechFlow
我為 0x Fable 思考了很多關於錢包和用戶入門的問題。以下我的一些觀點。我們將討論:
-
我理想的账戶架構;
-
安全考慮;
-
現有 Web3 登錄提供商的概況,
顯然,在入門過程中要求用戶安裝錢包軟件並保存助記詞是不可取的。我們需要一個友好、相對安全、並有一定前瞻性的方法。
架構
每個用戶都會獲得自己的智能帳戶,其中包含三個密鑰:
-
設備密鑰——最初可以存儲在本地,但希望未來能使用通行密鑰/webauthn。
-
補充密鑰,例如由提供商控制並通過社交登錄解鎖的密鑰。
-
備份密鑰,例如由第三方保管(可以簡單地作為電子郵件附件或存放在 Dropbox / Google Drive 上)。
如果這聽起來技術含量不高或不安全,恐怕你已經被提供商甜言蜜語所迷惑,因為它們實際上並沒有比這更安全(很多時候甚至更少——例如,密鑰(2)和(3)都由同一方控制)。
在這個設置中,你可以使用設備密鑰進行操作,不需要用戶互動。對於涉及資產的轉账和交易,你可以要求使用補充密鑰。
簡單的模式是讓用戶用 Google/ Apple /Facebook 等登錄,然後添加一個確認提示。這使得入門變得簡單。但是,如果用戶需要更多的安全性,就可以用傳統的 EOA 來代替這把密鑰。此外,任何一對密鑰都可以用來替換備份密鑰,備份密鑰只需是一個托管在雲端的文件。
安全分析
這有多安全?大部分情況下,他是安全的。兩個設備或實體必須在同一時間被破壞才會發生資金損失。
主要的是,有一些配置風險可能降低安全性。例如,在 Google Drive 上托管備份密鑰,同時將補充密鑰分配給你的 Google 帳戶。或者使用一個熱錢包作為補充密鑰,這與設備密鑰有着相同的風險。用戶可能會弄丟他的備份。最好定期提示用戶輪換設備密鑰,迫使他找到備份密鑰。
如果備份密鑰是公开存儲的,它也非常容易被盜。這比熱錢包還要糟糕,後者在磁盤上加密密鑰(並需要密碼在內存中解密)。無論如何,通行密鑰的增加(允許你使用設備認證登錄應用程序)將解決這個問題。
要明白,社交登錄意味着信任一個提供商。提供商基本上有一個他可以隨心所欲使用的密鑰,但他向你承諾,只有在你使用社交账戶登錄後,他才會按照你的要求使用它。最後,請注意,當補充密鑰是由 dapp 創作者提供的,或者沒有確認提示時,那么 dapp 創建者就很容易欺騙用戶(因為他們編寫了擁有設備密鑰的前端,並且擁有或可以控制補充密鑰)。
現有提供商概況
今天有誰提供這個?據我所知,沒有。問題通常是,要么沒有備份密鑰,要么它是由相同的實體保管的(例如 Coinbase 錢包)。
市場主要分為兩類:
-
提供集成多密鑰解決方案的提供商,要么使用智能账戶,要么使用 MPC(多方計算,一種密碼學技術)將多個密鑰組合成單個 EOA。
-
更低級別的提供商,為你保管用戶密鑰,並允許他們在登錄後籤名。
這裏有很多全棧提供商: Particle Network 、 Privy 、Alembic Tech、 Magic 、Web3 Auth、 Turnkey 、 Dynamic 、0x Pass、 Fireblocks 、 Portal 、 Capsule 、ZeroDev、Keyp、 Circle Developers。
密鑰保管商如: Lit Protocol 、Amazon 。
是的,有很多這樣的東西。他們之間基本上沒有什么區別。當商業模式透明時,這些通常每年每用戶收費 0.02 到 0.05 美元。對我來說,這似乎是相當合理的。
有趣的是,所有這些都被定位為开發工具。似乎沒有一家公司試圖應用這些技術來成為用戶的主要錢包。
當然,要與現有的 dapps 合作,你需要安裝錢包軟件。所以,系統的優勢減少到去除助記詞。但你也可以讓 dapps 推廣你作為最容易入門的方式(如果他們集成了你,甚至無需安裝錢包軟件)。你獲得用戶,dapp 可以免費輕松入門。雙贏。
對提供商的擔憂
除了不實現我理想的架構,這些解決方案往往還引入了大的中心化因素,比如 REST API,或者一些 MPC 計算,如果它們停業,您將無法自己進行這些計算(甚至公开發布嗎?已審核?) .
目前還不清楚如果您停止與提供商的合作會發生什么。他們擁有(部分)你的用戶的密鑰!這與我對 Rollups-as-a-service 的擔憂非常相似。
在這之後,一個 RaaS 創始人告訴我,允許輕松退出和避免創始人欺騙他們的用戶(這將對 RaaS 產生不良影響)之間存在權衡。
以下是如何使用上述架構輕松切換提供商:用戶在鏈上提交他們社交账戶的哈希(例如 [email protected])。每個社交登錄提供商都有自己的私鑰(沒有必要為每個用戶擁有一個密鑰,而且通常也不更安全)。智能账戶引用一個單例合約,該合約保存當前提供商的账戶。切換提供商就像更改這個账戶一樣簡單。
最後的思考
我們顯然正在朝着理想的 Onboarding 目標邁進。理想的情況是,這些易於入門的錢包與用戶直接建立關系。然後,dapps 可以完全忽略這個問題,只需與錢包籤訂合作夥伴關系, 確定默認的登錄錢包是誰。
如果做不到這一點,我的解決方案必須是推出我自己的系統 ——在上面的架構中創建自己的社交登錄提供商並不困難。然而,我“寧愿”使用外部提供商。如上所述,如果 dapp 創建者控制免費密鑰,那么系統就不是完全去中心化的。
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。