「イーサリアムでのログイン」がなぜ革命的なのか?
原題: 「イーサリアムでのサインインがゲームチェンジャーである理由 - パート 1」
オリジナル編集: ETH 中国語
オリジナル編集: ETH 中国語
Sign-In with Ethereum (SIWE) は、インターネット上のユーザーの選択肢に革命をもたらします。
大規模な仲介者と妥協する代わりに、ユーザーはブロックチェーン アカウントを制御するのと同じ秘密キーを使用して (仲介者を通さずに) 直接ログインできるようになりました。 SIWE によって、私たちは大企業がユーザーのサービスへのアクセスやユーザーの行動の監視の能力をもはや奪うことができない新たな道を切り開きます。
SIWEは完全にオープンな認証規格であり、dapps、アプリ、ウォレット、セキュリティ会社などのコミュニティメンバーとのオープンな議論を通じて実現されました。すべての会議の議事録とメモは、Web サイト login.xyz で見つけることができます。このアプローチは、テクノロジー大手や政府ベンダーによる独自の ID システムの非公開開発とは大きく異なります (プライバシーとデジタル権利の擁護者によって抗議されています)。
対照的に、Sign-In with Ethereum (EIP-4361) は、Web ベースのサービスを安全に認証するための Ethereum アカウント用のオープン クリエイティブ コモンズ (CC) 署名形式を定義します。 SIWE はイーサリアム財団と ENS からの直接支援を受けてコミュニティによって構築され、Spruce は昨年末にこのプロジェクトを担当しました。私はここに来て、「イーサリアムでのログイン」が何を意味するのか、そしてそれが Web3 のすべてのビルダーにとって「ウォレットの接続」をどのように超えるのかについて議論できることに興奮しています。
ウォレットへの接続とイーサリアムでのログイン
現在のdappのメイン機能は「Connect Wallet」ボタンです。このボタンをクリックすると、ユーザーは Web3 とブロックチェーンとの対話を開始します。
ウォレットを接続すると、アプリはユーザーがどのアカウントを使用しているかを知ることができますが、それだけです。ウォレットは、スマート コントラクトとのやり取り、暗号通貨の送信、さらには dapps 経由でメッセージに署名するためにどのアカウントを使用するかを簡単に知ることができます。ウォレットに接続する機能は非常にシンプルです。dapp にはユーザーの「記憶がなく」、単純な対話のためのプラットフォームを構築するだけです。
ユーザーの設定やプライベート チャット メッセージを読み込むなど、アプリケーションがユーザーとのコンテキストに応じたより豊かな対話を行う必要がある場合、まず、アカウントの背後にある実際の秘密キーの所有者と通信していることを確認する必要があります。アカウント。 「Connect Wallet」はそのような保証を提供しませんが、SIWE はそのような保証を提供します。言い換えれば、ユーザーとのセッションを確立し、データを安全に読み書きするには、ユーザーを認証する必要があります。 2 つの違いを説明するために、ウォレットに接続する Carl とセッションを確立する Sam という 2 つの例を示しました。
(翻訳者注: セッションは、クライアントとサーバーの間で状態を維持するためのソリューションです。その考え方は、クライアントが初めてアクセスしたときに、サーバーがセッション ID を生成し、それをクライアントに返すというものです。もちろん、サーバーはセッション ID もメモリに保存します。クライアントはセッション ID を取得すると、後続の各リクエストでセッション ID をサーバーに送り返します。これにより、サーバーは、クライアントがアクセスしたことを知るために自身のメモリをクエリできるようになります。ユーザーのログイン認証を実装するために使用できます。サーバーによって生成されたセッション ID はクライアントに返送された後、Cookie に保存されることが多いため、セッションベースの認証は Cookie ベースの認証とも呼ばれます。出典)
カールは dapps を使用しており、素晴らしい経験をしています。彼はUniswapで取引したり、Aaveで借りたり、OpenSeaでNFTを購入したりすることもできます。これらのいくつかの操作を実行するには、ウォレットに接続するだけで済みます。カールの手術は順調に進んでいたのですが、ある日、彼は次のような問題に遭遇しました。カールは、これらの dapps に自分について何かを覚えておいて、3 回目、4 回目、5 回目にこれらの dapps を使用するときに、より良い体験を提供できるようにしたいと考えています。
Carl は、Uniswap が自分の清算設定を自動的にインポートできれば、Aave がお気に入りの融資市場を覚えていて、OpenSea ですら 0x2Fe1a3 の代わりに自分の名前を覚えていられるようになれば、彼の経験はずっと良くなるだろうと考えています。カールは、ウォレットを接続するたびに最初から始めます。
サムにはそんな問題はないでしょう。 Dapp が認証してセッションを確立すると、関連情報が保存されます。サムが切断して再認証した場合でも、セッションは中断したところから続行され、アプリケーションはサムに関するすべてを記憶したままになります。彼の情報は、彼が管理するリモート データベースに保存される可能性もあります。
SIWEの統一
Web3 の全体像を見渡すと、何らかの形式で提供している既存のサービスが数多く見つかります。"Sign-In with Ethereum", しかし、標準に達する人は多くありません。通常、これを使用して、アカウントに関連付けられた独自のメタデータを管理するユーザーとの Cookie ベースのセッションを確立します。たとえば、(OpenSea のように) サイト上で自分のプロファイルをカスタマイズする権限をユーザーに付与したい場合は、変更を加える前にユーザーを認証して、ユーザーだけが自分のプロファイルを編集できるようにする必要があります。ワークフローは次のとおりです。
ウォレットに接続した後の最初のステップは、ユーザーが対話している内容を理解できるように、人間が読めるメッセージをユーザーに提供することです。多くの場合、ユーザーが見るのは、"LOGIN"(ログイン)、またはログインするように指示するテキスト、または場合によっては任意の番号 (ここでは、このランダムな文字と数字のクレイジーなコレクションに署名します)。そのため、代わりに、既存の慣行に基づいて一連の必須フィールドを決定し、多くの優れたセキュリティ対策を導入し、人間の可読性と安全な操作のバランスをとる厳密な構文を導入することができます。さらに、ウォレットは、少なくともこの種の情報をユーザーに提供し続けるために、既存のインターフェースや慣行を変更する必要はありません。
まず、この乱雑な「SIWE」情報をすべて取得し、受け入れられる一般的な方法でユーザーにリクエストを送信できます。
情報の共有 - 共有インターフェース
署名メッセージの形式に同意すると、アプリケーションとウォレットは同じ言語を使用できるようになります。アプリケーションがユーザーに署名リクエストを送信すると、ウォレットはそのリクエストをチェックし、EIP-4361 (SIWE) 情報と一致することを確認して、Web サイトにログインしていることをユーザーに通知します。
この時点で、ウォレットは、ユーザーエクスペリエンスを向上させ、ユーザーが取ろうとしているアクションに疑いの余地を残さない、フレンドリーな様式化されたインターフェイスを表示できます。ユーザーに署名するテキストの任意のブロックを与える代わりに。ウォレットは署名リクエストを「理解」するため、ユーザーは確認ダイアログをクリックするだけで「ログイン」できます。完全な透明性を実現するには、EIP-4361 仕様に記載されているすべての情報とフィールドが、詳細ビューなどの他のサブインターフェイスでも利用できる必要があります。
EIP-4361 の情報から、より明確なインターフェイスを取得できます。
この仕様では、フィッシング攻撃を防ぐためのドメイン バインディングの導入、リプレイ攻撃を防ぐためのノンスの導入など、ウォレットの追加のセキュリティ要件も導入されており、ユーザーはプロセス全体を通じてさらに保護されます。たとえば、ウォレットが有効な SIWE メッセージを見つけたものの、ユーザーが example.com に署名している (ただし、実際にはexampie.com にいる) 場合、ウォレットはユーザーに状況を警告できます。
認証を超えて
SIWE 情報は、特定のリソースにアクセスするための承認、または dapp UX の機能と使いやすさを向上させるためのセッション秘密キーの委任として理解することもできます。たとえば、アプリケーションがユーザーのデータを保存するのではなく、ユーザーが保持しているデータで自分のセッションを強化できる世界を想像してください。詳細については、次の記事を読むことを強くお勧めします。《From Sign-In with Ethereum to Session Keys》
この記事のパート2も近々投稿する予定ですので、お楽しみに!それまでは、SIWE を実装してください。


