“使用以太坊登入” (sign-in with ethereum, siwe) 顛覆了使用者在網際網路上的選擇。
使用者不再需要向一些大型中間商妥協，現在可以使用控制其區塊鏈賬戶的同一個私鑰直接登入(不需要經過中間商)。透過siwe，我們開闢了另一條道路，大公司不再能剝奪使用者訪問服務的能力，也不能監視他們的行為。
siwe 是一個完全公開的認證標準，透過與dapp、app、錢包、安全公司等社羣成員的公開討論來實現。你可以在網站login.xyz 上找到所有的會議記錄和筆記。這種方法與科技巨頭或政府供應商的專有身份系統的封閉式開發大相徑庭(受到隱私和數字權力倡導者的抗議)。
相比之下，sign-in with ethereum (eip-4361) 為以太坊賬戶定義了一種開放的知識共享(creative commons, cc) 簽名格式，以安全地驗證任何基於網路的服務。siwe 由社羣構建，獲得以太坊基金會和ens 的直接支援，並且spruce 於去年年底開始負責該專案。我很高興能在這裡討論“使用以太坊登入” 的意義，以及對於web3 的所有構建者來說它是如何超越“連線錢包” 的。
連線錢包vs. 使用以太坊登入
“連線錢包” 這個按鈕是現在dapp 的主要功能。點選這個按鈕，使用者就開始了與web3 和區塊鏈互動的旅程。
透過連線錢包，應用程式可以知道你使用的是哪個賬戶；然而，僅此而已。你的錢包更容易瞭解你想用哪個賬戶來與智慧合約互動、傳送加密貨幣，甚至透過dapp 對資訊進行簽名。連線錢包的功能非常簡單—— dapp 對你“毫無記憶”，只是為簡單的互動搭建了一個平臺。
當應用程式想要和使用者進行更豐富的情境互動(contextual interactions) 時，比如載入使用者的偏好或隱私聊天訊息，我們首先需要確保我們是在和該賬戶背後的實際私鑰持有者對話，而不是某個假裝對賬戶持有控制權的人。“連線錢包” 不提供這種保證，但siwe 可以。換句話說，我們需要對使用者進行身份驗證，以便與他們建立一個session，然後安全地讀寫他們的資料。為了說明兩者的區別，我舉了以下兩個例子—— 連線錢包的carl 和建立session 的sam：
(譯者注：session 在是一種用來在客戶端與伺服器端之間保持狀態的解決方案。其基於思路是： 客戶端第一次訪問時，伺服器端生成一個session id 返回給客戶端，當然伺服器端也會把這個session id 存在記憶體中，客戶端得到這個session id 後，在後續的每個請求中會把這個session id 傳回伺服器，這樣伺服器查詢自己記憶體就知道這個客戶端曾經訪問過。session 可以用來實現使用者的登入認證。伺服器端生成的session id 傳回客戶端後，往往會儲存在cookie 中，所以session-based 認證也稱為cookie-based 認證。來源)
carl 使用dapp 並有一個很好的體驗。他可以在uniswap 上進行交易，在aave 上借貸，甚至在opensea 上購買nft。進行這幾項操作只需要連線他的錢包。carl 的操作一直都挺順利的，直到有一天，他遇到了這樣的問題：他希望這些dapp 能夠記住他的一些情況，以便在他第三次、第四次和第五次使用這些dapp 時，能給他更好的體驗。
carl 在想，如果uniswap 能自動匯入他的優先清算權，aave 能夠記住他最喜歡的借貸市場，甚至opensea 能記住他的名字而不是0x2fe1a3… 這樣的賬戶，他的體驗會好很多。carl 每次連線他的錢包時都要從頭開始。
sam 就不會有這樣的問題了。dapp 對其進行了認證並且建立了session 之後，相關資訊就會被儲存下來。即便sam 斷開連線並且重新進行認證，session 也會從他離開時的狀態繼續，應用程式仍然記得與他相關的一切。他的資訊甚至可以儲存在他控制的一個遠端資料庫中。
使siwe 一元化
縱觀web3 領域，你會發現許多現有的服務提供某種形式的”sign-in with ethereum”，但沒多少能達到標準的。他們通常會使用它來和使用者建立一個基於cookie 的session，該session 可以管理該賬戶相關的專有後設資料。比如，如果你想要給使用者許可權在你的網站上自定義他們自己的個人檔案(像opensea 那樣)，你應該在使用者可以做出任何更改之前對他們進行身份驗證，以確保只有使用者可以編輯他們自己的個人檔案。工作流程如下所示：
連線錢包後的第一步是給使用者提供人類可讀的訊息，這樣他們才能理解自己進行了什麼互動。在很多案例中，使用者看到的是”login” (登入) 字樣，或者一些讓你登入的文字，甚至有時只是一個任意的數字(在這裡，對這個隨機的瘋狂的字母和數字集合簽名吧)。那麼相反，我們可以根據現有實踐確定一組必需的欄位、設定好許多良好的安全措施和一個在人類可讀和安全執行之間平衡的嚴格語法。此外，錢包不需要改變它們現有介面和實踐，至少可以繼續為使用者提供這類資訊。
首先，我們可以接收所有這些混亂的“siwe” 資訊，並以一種可接受的通用方式向使用者提交請求：
共享資訊- 共享介面
對簽名資訊格式達成一致後，應用程式和錢包現在可以說同一種語言了。當應用程式向使用者提交簽名請求時，錢包可以檢查該請求，檢查它是否與eip-4361 (siwe) 資訊相符，並讓使用者知道他們正在登入一個網站。
在這一點上，錢包可以呈現一個友好的程式化的介面，讓使用者體驗更佳，並且不對使用者將要採取的行動產生任何懷疑。而不是給使用者一個任意的文字塊來簽名。使用者現在只需點選一個確認對話方塊來“登入”，因為錢包能夠“理解” 簽名請求。為了實現完全透明，eip-4361 規範中宣告所有資訊和欄位仍然必須在其他子介面(如詳細檢視) 中可用。
從eip-4361 的資訊中，我們可以得到一個更清晰的介面：
該規範還為錢包引入了額外的安全要求，例如引入域繫結以防止釣魚攻擊；引入nonces 以防止重放攻擊，使用者在整個過程中得到了進一步的保護。比如，如果錢包發現一個有效的siwe 資訊，但是使用者正在對example.com 進行簽名(但實際上是在exampie.com)，錢包可以警告使用者該情況：
身份驗證之外
siwe 資訊也可以被理解為訪問特定資源的授權，或者對session 私鑰的委託，以提高dapp ux 的功能性和易用性。例如，想像一下，在這樣一個世界裡，使用者可以使用他們保留的資料來豐富他們自己的session，而不是應用程式儲存使用者的資料。想要了解更多資訊，強烈建議大家看看這篇文章：
來源| blog.spruceid.com
作者| rocco
