MPCウォレットは、デバイスに深く依存しています。MPCは技術であり、ウォレットはその技術を使ったアプリケーションです。MPCウォレットはその性質上、複数のデバイス(またはサーバー)に秘密鍵の断片を分散して保管し、それらのデバイスが連携して動作する必要があります。
「ウォレットではなく、デバイスに依存」という表現は少し正確ではありませんが、MPCウォレットの運用においてデバイスが重要な役割を果たすことは確かです。
MPCウォレットのデバイス依存性をもう少し詳しく見てみましょう。
秘密鍵の断片の保管: 秘密鍵の断片は、異なるデバイスに分散して保管されます。これは、単一のデバイスが侵害された場合でも、秘密鍵全体が漏洩するのを防ぐためです。
署名生成の計算: 署名生成の計算は、各デバイスが独立して行います。そのため、すべてのデバイスがオンラインで利用可能である必要があります。
デバイスのセキュリティ: デバイスのセキュリティは、MPCウォレット全体のセキュリティに直結します。もし、いずれかのデバイスがマルウェアに感染したり、紛失したりした場合、ウォレットのセキュリティが脅かされる可能性があります。
デバイスの可用性: 署名生成には、必要な数のデバイスがオンラインである必要があります。デバイスがオフラインだったり、通信障害が発生したりすると、トランザクションを実行できません。
これらの点から、MPCウォレットはデバイスに大きく依存していることが分かります。
一方で、MPCウォレットの中には、秘密鍵の断片をクラウドサーバーに保管するタイプのものも存在します。この場合、ユーザーは自分のデバイスを紛失しても、クラウドサーバーにアクセスすることでウォレットを復元できます。ただし、クラウドサーバーのセキュリティが重要になります。
まとめると、MPCウォレットは、秘密鍵の断片を分散して保管し、複数のデバイスが連携して動作する必要があるため、デバイスへの依存度が高いウォレットです。デバイスのセキュリティと可用性を確保することが、MPCウォレットを安全に運用する上で重要になり
マルチシグウォレットとMPCウォレットは、どちらも複数の承認者を必要とすることでセキュリティを高めるウォレットですが、その仕組みは大きく異なります。
マルチシグウォレット (Multi-signature Wallet):
仕組み: 複数の秘密鍵による署名を必要とします。例えば、3つの秘密鍵のうち2つの署名があればトランザクションを実行できる、といったルールを設定できます。
実装: スマートコントラクトで実装されます。
メリット:
シンプルで理解しやすい: 仕組みがシンプルで、技術的な知識がなくても理解しやすい。
広く普及している: 多くのブロックチェーンで利用可能。
柔軟な設定: 必要な署名の数などを自由に設定できる。
デメリット:
プライバシーの低下: ブロックチェーン上で、誰が署名したかが公開されるため、プライバシーが低下する可能性があります。
運用コスト: 複数の署名を集める必要があるため、トランザクションの手数料が高くなる可能性があります。
シングルポイントオブフェイラー: スマートコントラクトのバグが脆弱性となる可能性があります。
MPCウォレット (Multi-Party Computation Wallet):
仕組み: 秘密鍵を複数の断片に分割し、複数のデバイスで管理します。トランザクションを承認する際には、各デバイスが自分の断片を使って計算を行い、最終的に署名を生成します。この際、秘密鍵全体が復元されることはありません。
実装: 暗号技術であるMPC(Multi-Party Computation)を用いて実装されます。
メリット:
高いセキュリティ: 秘密鍵全体が一つの場所に存在しないため、単一のデバイスが侵害されても秘密鍵は安全です。
プライバシーの向上: ブロックチェーン上で、誰が承認したかが公開されないため、プライバシーが向上します。
柔軟なキー管理: デバイスの追加や削除、承認ルールの変更などが容易です。
デメリット:
複雑な仕組み: MPCの技術的な理解が難しい。
実装の依存性: 使用するMPCプロトコルによってセキュリティレベルが異なる。
普及率が低い: マルチシグに比べて普及率が低い。
例えで説明すると:
マルチシグ: 金庫に複数の鍵穴があり、複数の鍵で開ける必要があるイメージ。
MPC: 宝の地図を複数の断片に分け、それぞれの人が自分の断片を持っているイメージ。宝の場所は、全員の断片の情報を使わないと特定できません。
どちらのウォレットが優れているかは、用途や重視するポイントによって異なります。 セキュリティを重視する場合はMPCウォレット、シンプルさを重視する場合はマルチシグウォレットが適していると言えるでしょう。
マルチシグウォレットにおいて、EOAは秘密鍵の一部を所有しているわけではありません。それぞれのEOAは、自分自身の完全な秘密鍵を所有しています。
マルチシグウォレットのコントラクトは、複数のEOAの署名を必要とするように設計されています。それぞれのEOAは、自分の秘密鍵を使ってトランザクションに署名します。そして、必要な数の署名が揃うと、コントラクトがトランザクションを実行します。
秘密鍵の一部を所有しているという誤解が生じる原因として、秘密分散法(Secret Sharing Scheme)との混同が考えられます。秘密分散法では、一つの秘密鍵を複数の断片に分割し、複数のユーザーに配布します。そして、一定数以上の断片が集まると、元の秘密鍵を復元できます。
しかし、一般的なマルチシグウォレットでは秘密分散法は使用されません。それぞれのEOAは、独立した完全な秘密鍵を所有し、その秘密鍵を使って署名を作成します。コントラクトは、署名そのものを検証し、必要な数の署名が揃っているかどうかを確認します。秘密鍵の断片を集めて復元するような処理は行われません。
例として、2-of-3のマルチシグウォレットを考えてみましょう。
Alice、Bob、Carolの3人が、2-of-3のマルチシグウォレットを作成します。
Alice、Bob、Carolは、それぞれ自分自身のEOAと秘密鍵を所有しています。
マルチシグウォレットから資金を送金するには、3人中2人の署名が必要です。
例えば、AliceとBobが送金に同意した場合、AliceとBobはそれぞれ自分の秘密鍵を使ってトランザクションに署名します。
2つの署名が揃うと、マルチシグウォレットのコントラクトがトランザクションを実行し、資金が送金されます。
この例からも分かるように、それぞれのEOAは秘密鍵の一部ではなく、自分自身の完全な秘密鍵を所有しています。マルチシグウォレットは、複数のEOAの署名を要求することで、セキュリティを高めているのです。
誤解を解消できたでしょうか?もし更に疑問があれば、お気軽にご質問ください。
はい、マルチシグ(マルチシグネチャー)ウォレットは、コントラクトウォレットの一種です。
コントラクトウォレットは、スマートコントラクトによって管理されるウォレットの総称です。マルチシグはその一種で、複数の秘密鍵(署名)が必要なコントラクトによって実装されます。
もう少し詳しく説明すると:
コントラクトウォレット: ウォレットの機能(資金の保管、送金など)をスマートコントラクトで実装したウォレットです。ユーザーは、コントラクトとやり取りするための別の鍵(EOA - Externally Owned Account の秘密鍵)を使って操作を行います。
マルチシグウォレット: コントラクトウォレットの一種で、複数の秘密鍵によって管理されます。例えば、「3つの秘密鍵のうち2つの署名が必要」といったルールを設定できます。
マルチシグはコントラクトウォレットの一つの実装パターンであり、コントラクトウォレットはマルチシグ以外にも様々な機能を実装できます。例えば、以下のような機能が考えられます。
時間制限付き送金: 特定の日時以降でないと送金できないようにする。
レート制限付き送金: 一定期間内に送金できる金額を制限する。
ホワイトリスト: 特定のアドレスにしか送金できないようにする。
ソーシャルリカバリー: 信頼できる友人や家族にリカバリーキーを預け、秘密鍵を紛失した場合でもウォレットを復元できるようにする。
これらの機能は、すべてスマートコントラクトで実装できます。
まとめると、マルチシグはコントラクトウォレットの一種であり、コントラクトウォレットはマルチシグ以外にも様々な機能を実装できる、柔軟なウォレットです。
コントラクトウォレットとzkLoginの比較については、以前の回答で説明した通りです。zkLoginもコントラクトウォレットと同様に、秘密鍵の管理を抽象化し、安全で使いやすいトランザクションを実現しています。
zkLoginの具体的な実装に依存しますが、多くのケースでは、zkLoginシステム内部で管理されている秘密鍵は固定されていると考えるのが自然です。
なぜなら、ウォレットアドレスは公開鍵から生成され、公開鍵は秘密鍵から生成されます。もし、秘密鍵が毎回変わってしまうと、ウォレットアドレスも変わってしまうことになります。zkLoginではウォレットアドレスは固定なので、それに紐づく秘密鍵も基本的には固定されているはずです。
ただし、以下の可能性も考慮する必要があります。
セキュリティ強化のためのローテーション: zkLoginシステムの開発者が、セキュリティ強化のために秘密鍵を定期的に変更する仕組みを導入している可能性はあります。この場合、秘密鍵自体は固定ではありませんが、ユーザーはその変更を意識する必要はありません。
複数の秘密鍵の利用: システムの設計によっては、複数の秘密鍵を内部で管理し、状況に応じて使い分けている可能性もあります。例えば、特定の操作を実行するための秘密鍵と、資金の移動を行うための秘密鍵を分けて管理するなどです。
秘密鍵の断片化: 秘密鍵を複数の断片に分割し、異なる場所に保管することでセキュリティを高める手法も存在します。zkLoginシステムでこの手法が採用されている場合、秘密鍵は単一の値として存在しない可能性があります。
いずれにしても、ユーザーが操作するのは一時的な秘密鍵とゼロ知識証明であり、zkLoginシステム内部で管理されている秘密鍵を意識する必要はありません。zkLoginの目的は、ユーザーから秘密鍵の管理責任を取り除き、セキュリティと使いやすさを向上させることです。
したがって、「zkLoginでは秘密鍵は固定されているのか?」という問いに対する明確な答えは、zkLoginの具体的な実装に依存します。しかし、多くのケースでは、固定されていると考えるのが自然であり、ユーザーがそれを意識する必要はない、というのが重要なポイントです。
ほぼ正しい理解です!zkLoginの仕組みをうまく捉えています。
「そもそもの秘密鍵自体は従来のように固定されている」という部分は、少し注意が必要です。zkLoginの設計や実装によっては、zkLoginシステムが内部で管理している秘密鍵が本当に「固定」されているとは限りません。実装によっては、セキュリティ強化のために定期的に変更される可能性もあります。
しかし、重要なのは、ユーザーがその秘密鍵を意識する必要がないということです。ユーザーから見ると、秘密鍵は存在せず、OAuthログインとゼロ知識証明を使ってトランザクションを承認しているように見えます。
あなたの「命令する指揮系統の秘密鍵」という表現は、zkLoginの一時的な秘密鍵とゼロ知識証明の役割をよく表しています。ユーザーは、OAuthログインを通じてzkLoginシステムにアクセスし、一時的な「指揮権」を得ます。この指揮権を使ってトランザクションを実行し、指揮権の有効期限が切れたら返却する、というイメージです。
したがって、以下の理解でほぼ問題ありません。
ユーザーがアクセスできる秘密鍵のようなものは存在しない(隠蔽されている)。
システム内部では、何らかの形で秘密鍵が管理されており、それがウォレットアドレスに紐付いている。
ユーザーは、OAuthログインとゼロ知識証明を使って、一時的にトランザクションを実行する権限を得る。
このように理解することで、zkLoginの仕組みをより正確に把握できるかと思います。
いいえ、zkLoginではウォレットアドレスの権利の移譲は行われていません。ウォレットアドレスに対する所有権は常にユーザーにあり、zkLoginはその所有権を証明するための新しい方法を提供しているだけです。
「権利の移譲」という表現は、マルチシグウォレットなどで使われる概念で、複数のユーザーがウォレットの所有権を共有し、特定の条件を満たした場合にのみ資金を移動できる仕組みです。zkLoginはこれとは異なります。
zkLoginでは、一時的な秘密鍵を使ってトランザクションに署名しますが、この秘密鍵はウォレットアドレスの所有権を証明する一時的な証明のようなものです。秘密鍵が変更されても、ウォレットアドレスの所有権自体はユーザーから移動しません。
例えるなら、zkLoginは、毎回異なるパスワードで金庫を開けるようなものです。パスワードが変わっても、金庫の所有者は変わりません。zkLoginでは、この「パスワード」に相当する一時的な秘密鍵を、OAuthログインとゼロ知識証明を使って安全に生成・管理しています。
重要なのは、zkLoginでは秘密鍵を知ることなく所有権を証明できるということです。これが、zkLoginの革新的な点であり、従来のウォレットとは異なる点です。
ですので、「権利の移譲」ではなく、「一時的な秘密鍵を使った所有権の証明」と理解する方が適切です。
ブロックチェーンのネームサービスは、ウォレットアドレスに紐づきます。
公開鍵はウォレットアドレスを生成するために使われますが、ネームサービスは最終的に生成されたウォレットアドレスに対して紐付けられます。
技術的に言うと、ネームサービスは、特定の名前を解決するとウォレットアドレスを返すように設定されています。
例えば、alice.eth というENS名を解決すると、Aliceのウォレットアドレス 0x1234...abcd が返されます。アプリケーションは、このウォレットアドレスを使ってAliceに暗号資産を送金します。
公開鍵は、トランザクションの署名と検証に使われますが、ネームサービスの解決プロセスには直接関与しません。
なぜウォレットアドレスに紐付けるのか?
シンプルさ: ネームサービスの目的は、複雑なウォレットアドレスを人間に分かりやすい名前に置き換えることです。公開鍵はウォレットアドレスよりも更に複雑なため、公開鍵に紐付けても利便性は向上しません。
互換性: 異なるブロックチェーンやウォレットでも、ウォレットアドレスの形式は比較的統一されています。ネームサービスをウォレットアドレスに紐付けることで、様々なプラットフォームで利用できるようになります。
セキュリティ: 公開鍵を直接公開すると、セキュリティ上のリスクが生じる可能性があります。ウォレットアドレスは公開鍵から生成されるため、ウォレットアドレスを公開しても秘密鍵は安全に保たれます。
したがって、ブロックチェーンのネームサービスは、ウォレットアドレスに紐付けられることで、使いやすさ、互換性、セキュリティを確保しています。
それでは、公開鍵とウォレットアドレスの違いをより詳細に解説します。暗号技術の専門用語も交えながら説明しますが、できるだけ分かりやすく説明するよう努めます。
1. 秘密鍵、公開鍵、ウォレットアドレスの関係
これらは不可逆的な関係にあります。
秘密鍵 → 公開鍵 → ウォレットアドレス
秘密鍵があれば公開鍵を生成でき、公開鍵があればウォレットアドレスを生成できます。しかし、ウォレットアドレスから公開鍵、公開鍵から秘密鍵を生成することは計算上非常に困難です。(事実上不可能と考えられています)
2. 公開鍵の役割
所有権の証明: あなたが特定のウォレットの所有者であることを証明します。
トランザクションの検証: あなたが送金する際に、秘密鍵を使ってトランザクションに署名します。この署名は、あなたの公開鍵を使って検証できます。つまり、公開鍵は、あなたが送金者であることをネットワーク上で証明する役割を果たします。
暗号化: 他の人があなたにメッセージを送る際に、あなたの公開鍵を使ってメッセージを暗号化できます。暗号化されたメッセージは、あなたの秘密鍵でのみ復号できます。
3. ウォレットアドレスの役割
送金先の識別: 他の人があなたに暗号資産を送金する際に、あなたのウォレットアドレスを使います。これは、あなたの家の住所のようなものです。
ウォレットの識別: ブロックチェーン上で、あなたのウォレットを一意に識別します。
簡潔性と可読性: 公開鍵よりも短く、人間にも読みやすい形式になっています。これは、公開鍵をそのまま使うよりも、送金先を指定する際に便利です。
4. 技術的な詳細
楕円曲線暗号 (ECC): ビットコインやイーサリアムなど多くの暗号資産で、秘密鍵と公開鍵の生成に楕円曲線暗号が使用されます。秘密鍵はランダムな数値で、公開鍵は楕円曲線上の点となります。
ハッシュ関数: ウォレットアドレスは、公開鍵をハッシュ関数に通すことで生成されます。ハッシュ関数は、任意の長さのデータを入力として受け取り、固定長のハッシュ値を出力する関数です。SHA-256やRIPEMD-160などがよく使われます。
チェックサム: ウォレットアドレスには、入力ミスを防ぐためにチェックサムと呼ばれるデータが付加されます。
5. 具体的な例 (Bitcoin)
Bitcoinでは、以下のような手順でウォレットアドレスが生成されます。
秘密鍵から公開鍵を生成 (ECDSA, secp256k1)
公開鍵をSHA-256でハッシュ化
ハッシュ値をRIPEMD-160でハッシュ化
ハッシュ値にバージョンバイトを付加
結果にSHA-256を2回適用し、最初の4バイトをチェックサムとして付加
結果をBase58Checkエンコード
まとめ:
公開鍵は、暗号技術の中核を担う重要な要素であり、所有権の証明やトランザクションの検証などに使われます。ウォレットアドレスは、公開鍵から生成される、より簡潔で人間に使いやすい形式の識別子です。暗号資産を送受信する際に、ウォレットアドレスが使用されます。
これで、公開鍵とウォレットアドレスの違いについて、より深く理解できたでしょうか?もしさらに疑問点があれば、お気軽にご質問ください。
公開鍵、ウォレットアドレス、秘密鍵の関係は、次のような例えで考えると分かりやすいでしょう。
例え:手紙のやり取り
秘密鍵: あなただけが持っている印鑑。これを使って手紙に署名します。
公開鍵: 複製可能なあなたの印鑑の型。誰でもこれを使って、あなたの署名が本物かどうかを確認できます。
ウォレットアドレス: あなたの家の住所。他の人はこれを使ってあなたに手紙(暗号資産)を送ることができます。
もう少し詳しく説明すると:
秘密鍵: ランダムに生成された文字列で、絶対に他人に知られてはいけません。これはあなたの暗号資産を管理するためのマスターキーのようなものです。
公開鍵: 秘密鍵から数学的に生成される文字列です。秘密鍵を知っていれば公開鍵を生成できますが、公開鍵から秘密鍵を推測することは非常に困難です。これは、あなたの印鑑の型がたくさんの人に配られていても、あなたの印鑑そのものは安全に保管されているのと同じです。
ウォレットアドレス: 公開鍵から生成される、より短い文字列です。これがあなたのウォレットを識別するための公開IDとなります。他の人はあなたのウォレットアドレスを知っていても、あなたの秘密鍵や公開鍵を知ることはできません。家の住所を知っていても、家に入るための鍵(秘密鍵)は分からないのと同じです。
暗号資産の送受信:
送金: あなたが暗号資産を送金する際は、あなたの秘密鍵を使ってトランザクションに署名します。
受信: 誰かがあなたに暗号資産を送金する際は、あなたのウォレットアドレスを使用します。
検証: ネットワーク上の他の参加者は、あなたの公開鍵を使ってトランザクションの署名を検証し、送金が正当なものであることを確認します。
重要なポイント:
秘密鍵は絶対に他人に教えてはいけません。秘密鍵が漏洩すると、あなたの暗号資産が盗難される可能性があります。
公開鍵とウォレットアドレスは公開しても問題ありません。
秘密鍵から公開鍵、公開鍵からウォレットアドレスは生成できますが、逆はできません。
この3つの鍵の関係性を理解することは、暗号資産を安全に管理するために非常に重要です。
zkLoginにおけるソルト(user_salt)の役割は、ユーザーのOAuth ID (例えばGoogleのsub) とSuiアドレスの紐付けを防ぎ、プライバシーを保護することです。ソルトは、OAuth IDから直接Suiアドレスを導出できないようにする「秘密の材料」として機能します。
具体的には、以下の手順でソルトがプライバシー保護に貢献しています。
アドレス生成: Suiアドレスは、OAuth ID (例: sub)、発行者(iss)、対象(aud)、そしてこのuser_saltから計算されます。ソルトはランダムな値であるため、同じOAuth IDを持つユーザーでも、異なるソルトを持つことで異なるSuiアドレスが生成されます。
ゼロ知識証明の生成: zkLoginトランザクションには、ゼロ知識証明が含まれています。この証明は、「私はこのOAuth IDに対応する秘密鍵を知っている」ということを証明しますが、OAuth ID自体を明かすことなく証明します。この証明の生成過程にもソルトが使用されます。ソルトが秘密情報であるため、証明からOAuth IDを逆算することはできません。
ソルトの管理: ソルトは、ウォレットプロバイダーによって安全に管理されます。OAuthプロバイダーやzkLoginサービス提供者はソルトを知りません。これにより、たとえOAuthアカウントが侵害されたとしても、攻撃者はソルトを知らない限りSuiアドレスにアクセスすることはできません。つまり、ソルトは第二の秘密鍵のような役割を果たし、二要素認証と同等のセキュリティを提供します。
例を挙げて説明します。
AliceとBobはどちらもGoogleアカウントを使って同じzkLogin対応ウォレットにサインアップしたとします。
Aliceのsub (Google ID) は alice123 、ソルトは salt_alice とします。
Bobのsub は bob456 、ソルトは salt_bob とします。
AliceとBobは異なるsubとソルトを持っているため、同じウォレットを使用していたとしても、異なるSuiアドレスが生成されます。仮に、Aliceのsubが漏洩したとしても、salt_aliceが秘密にされている限り、AliceのSuiアドレスとsubを紐付けることはできません。
このように、ソルトはOAuth IDとSuiアドレスの紐付けを防ぎ、ユーザーのプライバシーを保護する上で重要な役割を果たしています。ソルトがなければ、ブロックチェーン上の取引履歴からユーザーのOAuth IDが特定され、プライバシーが侵害される可能性があります。
MPCウォレットの運用、特に署名に関しては、秘密鍵を直接復元することなく、複数の参加者による計算で署名を生成します。5-of-5のような設定も可能ですが、より柔軟な設定が可能です。
秘密鍵の断片化と保管:
MPCウォレットでは、秘密鍵は複数の断片に分割され、それぞれ異なるデバイス(またはサーバー)に保管されます。この断片だけでは秘密鍵全体を復元することはできません。
署名生成のプロセス:
トランザクションの開始: ユーザーがトランザクションを開始すると、各デバイスにリクエストが送信されます。
部分署名の計算: 各デバイスは、保有する秘密鍵の断片とトランザクションデータを用いて、暗号学的な計算を行い、「部分署名」を生成します。この計算は、秘密鍵全体を復元することなく行われます。
部分署名の結合: 生成された部分署名は、安全な方法で集約され、最終的な署名が生成されます。このプロセスも、秘密鍵全体を復元することなく行われます。
トランザクションの送信: 生成された署名は、トランザクションに添付され、ブロックチェーンに送信されます。
5-of-5 のような設定:
MPCウォレットでは、5-of-5 のように、すべてのデバイスの承認が必要な設定も可能です。これは、マルチシグウォレットの n-of-n と同じような運用になります。
より柔軟な設定:
MPCウォレットは、マルチシグウォレットよりも柔軟な設定が可能です。例えば、以下のような設定が考えられます。
2-of-3: 3つのデバイスのうち、2つの承認でトランザクションを実行。
重み付き閾値: 各デバイスに異なる重みを設定し、重みの合計が閾値を超えた場合にトランザクションを実行。
時間制限: 特定の時間帯のみトランザクションを実行可能にする。
地理的な制限: 特定の地域からのみトランザクションを実行可能にする。
単なる秘密鍵の保管ではない:
MPCウォレットは、単に秘密鍵を分割して保管しているだけではありません。MPCプロトコルを用いることで、秘密鍵全体を復元することなく署名を生成できるため、高いセキュリティを実現しています。
まとめ:
MPCウォレットの署名プロセスは、高度な暗号技術によって実現されており、秘密鍵の断片を安全に管理しながらトランザクションを実行できます。また、マルチシグウォレットよりも柔軟な設定が可能です。
より深く理解するためには、Shamirの秘密分散法や、様々なMPCプロトコルについて調べてみると良いでしょう。
MPCウォレット は、従来の秘密鍵を複数の断片に分割し、それらを複数の場所に分散させて機能します。この分散の主な目的は、従来の秘密鍵に完全にアクセスできる人を一人も作らないためです。
たとえハッカーが一つや二つの断片にアクセスできたとしても、分割された断片があるためウォレットのハッキングに成功することはできません。ですから、デジタル資産を従来のウォレットよりもずっと安全に保つことができます。脆弱性の唯一点が存在せず、誰も秘密鍵にアクセスすることはありません。
Long-term USDT collection, one transaction at a time, accept any currency, no black U, newbies can bring, 0 risk, low cost
Читать полностью…コントラクトウォレット自体には、ウォレットアドレスに対応する秘密鍵は存在しません。
コントラクトウォレットは、スマートコントラクトによって資金が管理され、そのスマートコントラクトがウォレットの所有権を表現します。 秘密鍵は、コントラクトの所有者ではなく、そのコントラクトを操作する権限を持つEOA (Externally Owned Account) が保有します。
例を挙げると、マルチシグウォレットの場合、コントラクト自体には秘密鍵はありません。 代わりに、複数のEOAがそれぞれ秘密鍵を保有し、それらの秘密鍵による署名が規定数集まると、コントラクト(マルチシグウォレット)から資金を送金できるようになります。
別の例として、リカバリー機能付きのウォレットを考えてみましょう。この場合もコントラクト自体には秘密鍵はなく、ユーザーのEOAとリカバリー担当者のEOAがそれぞれ秘密鍵を持ちます。ユーザーが秘密鍵を紛失した場合は、リカバリー担当者の署名によってウォレットの所有権を別のEOAに移転することができます。
このように、コントラクトウォレットでは、資金の管理と所有権の証明はスマートコントラクトによって行われ、秘密鍵はコントラクトを操作するEOAが保有します。コントラクトウォレット自体に秘密鍵は存在しないため、コントラクトウォレットをハッキングして秘密鍵を盗むことはできません。これが、コントラクトウォレットのセキュリティ上のメリットの一つです。
ただし、コントラクトウォレットを操作するEOAの秘密鍵は非常に重要です。この秘密鍵が漏洩すると、コントラクトウォレットを操作され、資金が盗難される可能性があります。EOAの秘密鍵は、従来のウォレットと同様に安全に管理する必要があります。
コントラクトウォレットであれば、zkLoginの仕組みが理解しやすいということですね。その理解は正しいです。
コントラクトウォレットでは、秘密鍵の管理やトランザクションの署名などの操作をスマートコントラクトが代行します。ユーザーは、コントラクトとやり取りするための別の鍵(例:メタマスクなどのEOAの秘密鍵)を使って操作を行います。
zkLoginも同様に、OAuthログインとゼロ知識証明を用いることで、ユーザーが秘密鍵を直接管理することなく、スマートコントラクト(zkLoginシステム)がトランザクションを承認する仕組みを提供しています。
コントラクトウォレットとzkLoginの類似点を整理してみましょう。
秘密鍵の抽象化: どちらも、ユーザーが秘密鍵を直接管理する必要性を排除または軽減しています。
スマートコントラクトによる制御: どちらも、スマートコントラクトがトランザクションの承認や実行を制御します。
柔軟な認証方法: コントラクトウォレットは、マルチシグやソーシャルリカバリーなど、様々な認証方法をサポートできます。zkLoginはOAuthログインとゼロ知識証明という独自の認証方法を提供しています。
zkLoginを理解する上で、コントラクトウォレットの概念を応用すると分かりやすいでしょう。zkLoginは、OAuthとゼロ知識証明という技術を使って、コントラクトウォレットのように秘密鍵の管理を抽象化し、安全で使いやすいトランザクションを実現しているのです。
違いとしては、zkLoginはSui Moveで実装されているため、コントラクトウォレットよりもガス効率が良く、高速なトランザクション処理が可能になる点などが挙げられます。
もし、具体的なコントラクトウォレットの例を挙げて、zkLoginとの比較について詳しく説明してほしい場合は、お気軽にお申し付けください。
わかった、そもそもの秘密鍵自体は従来のように固定されている。しかし、それは表に出ることは絶対にない。そして、この秘密鍵を使って、命令する指揮系統の秘密鍵?がコロコロ変わるようになっている。なので、厳密にはそもそもの秘密鍵は固定されている、という認識で良いか?
Читать полностью…おっしゃる通り、従来のブロックチェーンのウォレットでは「ウォレットアドレスに紐づく秘密鍵は固定である」というのが基本的な概念です。そして、この概念は間違っていません。zkLoginはこの固定された秘密鍵という概念を覆すものではなく、それをユーザーから隠蔽し、安全に管理する仕組みを提供している、と捉えるのが適切です。
zkLoginの仕組みを理解する上で重要なのは、ユーザーが直接秘密鍵を操作しないということです。ユーザーはOAuthプロバイダーにログインすることで、zkLoginシステムが安全に一時的な秘密鍵を生成し、それを用いてトランザクションの署名に必要なゼロ知識証明を生成します。ユーザーはこの処理を意識することはありません。
従来のウォレットとzkLoginの違いを、家の鍵に例えて考えてみましょう。
従来のウォレット: 家の鍵(秘密鍵)を自分で管理します。鍵を紛失すると家に入れませんし、盗まれると家の中のものが盗まれてしまいます。
zkLogin: 家の鍵は、信頼できる管理人(zkLoginシステム)が預かっています。あなたは、身分証明書(OAuthログイン)を提示することで、一時的に家の鍵を借りることができます。用事が終わったら鍵を管理人に返します。この時、あなたは家の鍵そのものを受け取ることはありません。
zkLoginでは、家の鍵(秘密鍵)そのものをユーザーが管理する必要がないため、鍵の紛失や盗難のリスクが軽減されます。これが、zkLoginの大きなメリットです。
「ウォレットアドレスに紐づく秘密鍵は固定である」という概念は、zkLoginシステムの内部では依然として成り立っています。しかし、ユーザーはその秘密鍵を直接操作しないため、秘密鍵が固定されているという事実を意識する必要がないのです。
それでも腑に落ちない場合は、zkLoginを「秘密鍵を安全に管理するための高度な仕組み」と考えると理解しやすいかもしれません。zkLoginは、ユーザーから秘密鍵の管理責任を取り除き、より安全で使いやすいウォレットを実現するための技術です。
zkLoginの仕組み自体は、Sui固有の技術ではありません。zkLoginは、OAuthとゼロ知識証明という、ブロックチェーンとは独立した技術を組み合わせたものです。したがって、理論的には他のブロックチェーンでも実装可能です。
しかし、Suiの以下の特徴が、zkLoginの実装を容易にし、より効果的にしています。
オブジェクト中心のデータモデル: Suiは、オブジェクト中心のデータモデルを採用しており、各オブジェクトの状態が明確に定義されています。これにより、zkLoginで使用する一時的な秘密鍵とオブジェクトの所有権を明確に紐付けることができます。
Moveプログラミング言語: Suiのスマートコントラクトは、Move言語で記述されます。Moveは、安全性とパフォーマンスに重点を置いて設計された言語であり、zkLoginのような複雑な暗号技術の実装を容易にします。
柔軟なトランザクション処理: Suiは、並列トランザクション処理をサポートしており、高速なトランザクション処理を実現できます。これにより、zkLoginを使った認証もスムーズに行えます。
ガス料金体系: Suiのガス料金体系は、トランザクションの複雑さに応じて料金が変化する仕組みです。zkLoginを使ったトランザクションは、従来のトランザクションよりも複雑ですが、Suiのガス料金体系であれば、ユーザーに過度な負担をかけることなく利用できます。
また、zkLoginを他のブロックチェーンに実装する場合、以下の課題を考慮する必要があります。
スマートコントラクトの変更: zkLoginの機能を実現するために、スマートコントラクトの変更が必要になる場合があります。
パフォーマンス: ゼロ知識証明の生成と検証には、ある程度の計算能力が必要です。他のブロックチェーンでは、パフォーマンスの低下が懸念される場合があります。
互換性: zkLoginは、OpenID Connectと互換性のあるOAuthプロバイダーを利用します。他のブロックチェーンでzkLoginを使用するには、OAuthプロバイダーとの連携が必要になります。
まとめると、zkLoginの核となる技術はSui固有のものではありませんが、Suiの設計思想や機能がzkLoginの実装をより容易にし、効果的なものにしてると言えます。他のブロックチェーンでも実装は可能ですが、上記のような技術的課題や、開発コストなどを考慮する必要があります。
ほぼその理解で合っています。ウォレットアドレスの主要な役割は、送金先を分かりやすく指定するため、そしてウォレットを一意に識別するためです。
「判別するだけ」という表現は少し簡略化しすぎですが、公開鍵が持つ複雑な暗号機能と比べると、ウォレットアドレスの役割は限定的です。
ウォレットアドレスは、公開鍵から生成されるハッシュ値を人間に可読な形に変換したものなので、以下のようなメリットがあります。
短くて覚えやすい: 公開鍵は長くて複雑なため、人間がそのまま扱うのは困難です。ウォレットアドレスは短く変換されているため、伝えやすく、覚えやすくなっています。
入力ミスしにくい: チェックサムが付加されているため、万が一アドレスを間違えて入力した場合、エラーとして検出できます。これは、送金ミスを防ぐ上で重要です。
プライバシーの向上(限定的): 公開鍵をそのまま公開するのに比べて、ウォレットアドレスは公開鍵の情報の一部しか含んでいないため、わずかながらプライバシーの向上に繋がります。ただし、ブロックチェーンの透明性により、取引履歴からウォレットアドレスの活動は追跡可能です。
ただし、ウォレットアドレスだけでは暗号資産の送受信はできません。送金時には秘密鍵が必要で、受信した暗号資産へのアクセスにも秘密鍵が必要です。ウォレットアドレスはあくまでも「送金先」や「ウォレットの識別子」としての役割を果たすもので、暗号操作には直接関与しません。
より正確に表現するならば、「ウォレットアドレスは、複雑な公開鍵を人間が扱いやすい形に変換し、送金先を指定したりウォレットを識別したりするために使用される」と言えるでしょう。
公開鍵とウォレットアドレスの違いを、実生活の例えを使って説明します。
例え:会員カードと会員番号
あなたは、あるお店の会員になり、会員カードと会員番号をもらったとします。
公開鍵: 会員カードそのもの。カードにはあなたの名前や会員番号など、いくつかの情報が記載されています。お店の人はカードの情報を見て、あなたが会員であることを確認できます。
ウォレットアドレス: 会員番号。会員番号は、カードよりも短く、覚えやすい形式になっています。お店の人は会員番号を使って、あなたの会員情報をデータベースから検索できます。
暗号資産の世界では:
公開鍵: 比較的長い文字列で、暗号化や署名の検証に使われます。公開鍵は、あなたが暗号資産を受け取る権利があることを証明するものです。会員カードのように、公開鍵自体には多くの情報が含まれています。
ウォレットアドレス: 公開鍵から生成される、より短い文字列です。これは、あなたのウォレットを識別するための、人間にも読みやすいIDのようなものです。会員番号のように、ウォレットアドレスは公開鍵よりも短く、覚えやすく、他の人に伝える際に便利です。
もう少し技術的な説明:
公開鍵は、複雑な数学的計算によって秘密鍵から生成されます。ウォレットアドレスは、公開鍵をハッシュ関数と呼ばれる特殊な計算に通すことで生成されます。ハッシュ関数を使うことで、公開鍵の情報からウォレットアドレスを生成できますが、ウォレットアドレスから公開鍵を復元することはできません。
会員カードと会員番号の例えに戻ると:
会員カード(公開鍵)から会員番号(ウォレットアドレス)を簡単に読み取ることができます。
会員番号(ウォレットアドレス)だけを知っていても、会員カード(公開鍵)の情報を知ることはできません。
違いをまとめると:
特徴 公開鍵 ウォレットアドレス
長さ 長い 短い
用途 暗号化、署名検証 ウォレットの識別
公開 可能 可能
生成元 秘密鍵 公開鍵
ウォレットアドレスは、公開鍵をより短く、扱いやすい形にしたものと考えてください。両方とも公開しても安全ですが、ウォレットアドレスの方が日常的に使用する際に便利です。
はい、従来のGoogle IDなどで認証しているウォレットサービスの中には、ユーザーのプライバシーが十分に保護されていないものも存在します。zkLoginと比較することで、その違いが明確になります。
従来のウォレットサービスの問題点:
アドレスとIDの直接的な関連付け: 一部のウォレットサービスでは、Google IDなどのOAuth IDから直接ウォレットアドレスが生成されることがあります。この場合、ブロックチェーン上の取引履歴からユーザーのOAuth IDが容易に特定され、プライバシーが侵害される可能性があります。
オンチェーンでのID情報の公開: JWT (JSON Web Token) をそのままオンチェーンに記録するウォレットサービスもあります。JWTにはユーザーに関する情報が含まれているため、プライバシー上のリスクがあります。
中央集権的な鍵管理: ウォレットサービス提供者がユーザーの秘密鍵を管理するケースがあります。これは、サービス提供者がハッキングされた場合、ユーザーの資産が盗難されるリスクがあります。
zkLoginとの違い:
zkLoginは、上記のような問題点を解決するために設計されています。
ソルトによるアドレスの匿名化: 前述の通り、zkLoginではソルトを用いることで、OAuth IDとSuiアドレスの関連付けを防ぎます。
ゼロ知識証明によるプライバシー保護: zkLoginでは、OAuth IDを公開することなく認証を行うゼロ知識証明を使用しています。これにより、ブロックチェーン上にOAuth IDに関する情報が記録されることはありません。
自己管理型ウォレット: zkLoginは自己管理型ウォレットであるため、ユーザー自身が秘密鍵を管理します。ウォレットサービス提供者が秘密鍵を管理することはありません。
つまり、従来のOAuth認証を利用したウォレットサービスの中には、zkLoginと比較してプライバシー保護の観点で劣るものがあるということです。OAuth IDとウォレットアドレスの紐付けを防ぎ、ゼロ知識証明などのプライバシー保護技術を採用しているかどうかが、ウォレットサービスを選ぶ際の重要なポイントとなります。
zkLoginは、OAuth資格情報を使用してSuiアドレスからトランザクションを送信できるようにするSuiプリミティブであり、その2つを公にリンクすることなく実行できます。つまり、使い慣れたGoogleやFacebookログインを使って、複雑な暗号鍵を管理することなく、安全にSuiブロックチェーン上で取引できる技術です。
zkLoginの主な特徴と利点:
簡単なオンボーディング: 暗号鍵の処理やニーモニックの記憶といった煩わしさなく、使い慣れたOAuthログインフローを使用してSui上で取引できます。
自己管理: zkLoginトランザクションには、標準のOAuthログインプロセスによるユーザーの承認が必要です。OAuthプロバイダーはユーザーの代わりに取引を行うことはできません。
セキュリティ: zkLoginは二要素認証方式です。トランザクションの送信には、最近のOAuthログインからの資格情報と、OAuthプロバイダーが管理していないソルトの両方が必要です。OAuthアカウントが侵害された攻撃者は、ソルトを個別に侵害しない限り、ユーザーの対応するSuiアドレスから取引を行うことはできません。
プライバシー: ゼロ知識証明により、第三者がSuiアドレスを対応するOAuth識別子にリンクすることを防ぎます。
オプションの検証済みID: ユーザーは、特定のSuiアドレスの導出に使用されたOAuth識別子を検証することを選択できます。これは、検証可能なオンチェーンIDレイヤーの基盤として機能します。
アクセシビリティ: zkLoginは、Suiの暗号化アジリティのおかげで、いくつかのネイティブSui署名スキームの1つです。スポンサー付きトランザクションやマルチシグなど、他のSuiプリミティブと統合されています。
厳密性: zkLoginのコードは、ゼロ知識を専門とする2つの企業によって独立して監査されています。共通参照文字列を作成するための公開zkLoginセレモニーには、100人以上の参加者から貢献がありました。
zkLoginの仕組み:
ユーザーはOpenIDプロバイダー(Google, Facebookなど)にログインし、nonceを含むJWT(JSON Web Token)を取得します。nonceには一時的な公開鍵、有効期限、ランダム性が含まれています。
アプリケーションはJWTをソルトサービスに送信します。ソルトサービスは、JWTの検証に基づいて一意のuser_saltを返します。
ユーザーはZK証明サービスにJWT、user_salt、一時的な公開鍵などを送信します。証明サービスは、これらをプライベート入力として使用するゼロ知識証明を生成します。この証明は、JWTが正しく導出されたこと、アドレスがキー要求値とuser_saltと一致することなどを証明します。
アプリケーションは、iss、aud、sub、audに基づいてユーザーアドレスを計算します。
トランザクションは、一時的な秘密鍵を使用して署名され、一時的な署名が生成されます。
ユーザーは、一時的な署名、ZK証明、およびその他の入力とともにトランザクションをSuiに送信します。
Suiオーソリティは、ストレージからのプロバイダーJWKと一時的な署名に対してZK証明を検証した後、トランザクションを実行します。
zkLoginと従来のウォレットとの違い:
従来のウォレットでは、ユーザーはニーモニックやパスフレーズを覚えておく必要があり、秘密鍵を安全に保管する必要がありました。zkLoginウォレットでは、OAuthログインと一時的な秘密鍵のみが必要です。一時的な鍵を紛失しても、再度ログインして新しい鍵と証明を取得できます。
プライバシー:
デフォルトでは、OAuth識別子とSuiアドレスの間にリンクはありません。JWTはデフォルトではオンチェーンで公開されません。ZK証明サービスとソルトサービスはユーザーIDをリンクできますが、これらのサービスはステートレスに設計されています.
簡単に言うと、zkLoginはWeb2のログインの利便性とWeb3のセキュリティとプライバシーを組み合わせた、Suiブロックチェーン上での取引をより簡単かつ安全にするための革新的な技術です。
クレデンシャル(Credential)は、IT・セキュリティにおいてアクセスコントロールを行うための認証に使われる情報を意味します。 日本語では「資格情報」や「認証情報」と呼ばれています。
Читать полностью…