感謝 Google 於 9 月 10 日的更新，用戶現在有更多自由選擇儲存密鑰的位置。 @ritualnet 則提供了兩個技術構建模組。 第一個是透過 passkey 簽署交易（使用者簽署一項操作）。 第二個是在智能合約中進行 P-256 簽名驗證，合約會檢查簽名是否真實。 如何使用它們，取決於應用程式開發者。 Ritual 也為在 Ritual 上構建的開發者提供了建議： 批准畫面應清楚說明使用者正在簽署的內容——是登入、提交提案，還是將特定權限委託給 AI 代理。 從一開始就規劃帳戶恢復方案——如果裝置遺失或密鑰變更，該如何處理，以及如何撤銷舊密鑰。 保持代理委託的具體性——明確允許哪些操作、存取何時過期，以及如何撤銷。 Passkeys 將簽署操作轉變為 DApp 中熟悉且直觀的行為，而 Ritual 提供了現成的構建模組——即合約中的簽名及其驗證。 但技術僅佔一半；另一半取決於應用程式是否清楚向使用者說明他們正在簽署的內容，以及帳戶恢復與權限撤銷是否在事前經過周全規劃。 良好的使用者體驗並非來自技術本身，而是建立在每一步的透明度與控制力之上。 @ritualfnd