誠実な行動を強制する

どのようにしてパーティを正直にさせることができますか（プロトコルルールに従います）？

コミットメント、証明などのメカニズムをいくつか見ましたが、それらは単に問題全体を解決するようには見えません。プロトコル設計の構造とそのようなメカニズムが仕事をしなければならないと私には思われます。誰もがそれをうまく分類していますか？
編集し
安全なプロトコルを設計するとき、当事者に正直を強いる場合、この施行には独自の見返りがありますが、設計ははるかに簡単です。安全なプロトコルを設計するときに、設計者は私には現実的でないように思われます。たとえば、すべての関係者が最悪の場合は正直であると想定したり、ユーザーデータを維持するサーバーの正直さを想定したりします。しかし、より厳密なモデルでプロトコルの設計を見ると、そのような仮定はめったにありません（少なくとも、私はそれを見たことはありません。CanettiのUCフレームワークはまだ完全に正式化されていないと思います）。私は不思議に思っていましたが、パーティーを正直にさせることができる方法の良い分類はありますか、それとも入力プロトコルを正直なパーティーを持つものに変換できるコンパイラはありますか？
これは、無関係に見えるかもしれませんが、これが単に仕事をしないと思う理由を説明します。UCフレームワークでプロトコルを設計する場合、理想的/実際のパラダイムの恩恵を受けると、理想的なモデルのすべての通信リンクが認証されますが、これは実際のモデルでは当てはまりません。したがって、プロトコル設計者は、PKI仮定またはCRS（共通参照文字列）を使用してこのチャネルを実装する代替方法を模索しています。しかし、認証プロトコルを設計するとき、認証されたチャネルを想定することは間違っています。UCフレームワークで認証プロトコルを設計していると仮定すると、攻撃者がパーティのIDを偽造する攻撃がありますが、理想的なモデルでは認証済みリンクを想定しているため、この攻撃はこのフレームワークでは想定されていません。あなたは参照するかもしれませんグループキー交換プロトコルに対するインサイダー攻撃のモデリング。カネッティの独創的な作品の中で、鍵交換と安全なチャネルの普遍的に構成可能な概念は、認証プロトコルのセキュリティを保証するのに十分なだけの以前のセキュリティの概念であるSK-Securityに言及していることに気付くでしょう。彼はどういうわけか（これは技術的な問題であることを示すことによって）このコンテキストでのUC定義は制限が厳しすぎ、非情報オラクルと呼ばれる緩和されたバリアントを提供します（これは私を混乱させたので、どこにもこのセキュリティモデルを見たことがない、このセキュリティパターンを他のセキュリティパターンと一致させることはできません。おそらく私の知識不足です：D）。

[補足として、シミュレータの時間に関係なく、ほぼすべてのSk-secureプロトコルをUCセキュアプロトコルに変換できます。たとえば、メッセージの署名を削除して、シミュレーターに相互作用全体をダミーの方法でシミュレートさせることができます。証明については、Universally Composable Contributorry Group Key Exchangeを参照してください！これが多項式で多くのパーティとのグループキー交換プロトコルであるとすると、シミュレータの効率はどうなりますか？これが、このフォーラムでの他の質問の原点です。]

とにかく、プレーンモデル（UC上）への取り組みが欠如しているため、その緩和の必要性をバイパスするだけでプロトコルを安全にする他の手段を探しました。この考えは私の心の中で非常に基本的であり、単純なモデルでカネッティの最新のコミットメント方式を研究しただけで頭に浮かびました：標準的な仮定からの単純なモデルでの適応可能な硬度と構成可能なセキュリティ。
ところで、私は知識がゼロであることの証明を求めていません。理由はわからないので、誰かが（UCフレームワークを介して）並行プロトコルでそれらの1つを使用したときはいつでも、他の人がプロトコルを非効率的であると述べているためです（シミュレータの巻き戻しによる）。

悲しいかな、あなたは人々にプロトコルがするべきであると言っていることを強制することはできません。

プロトコルに従うことを意図した善意のある人々でさえ、時々間違いを犯します。

少なくとも3つのアプローチがあるようです：

• 暗号理論：「悪意のある」エージェントがプロトコルを破壊しようとしている間、「良い」エージェントは常にプロトコルに従うと仮定します。悪意のあるエージェントは何も得ず、優れたエージェントは必要なものを得るように暗号プロトコルを設計します。
• ゲーム理論：すべてのエージェントが自分自身の個人的な関心だけに目を向けていると仮定します。メカニズム設計を使用して、すべての人にとっての総合的なメリットを最大化します。
• 分散型フォールトトレラントネットワーク：すべてのエージェントが偶発的なミスを犯し、少数のボットエージェントが悪意を持って作成された多くのメッセージを吐き出すと仮定します。ボットノードが修正されるまで検出および分離します。エラー検出および訂正（EDAC）を使用して、時々発生する誤りを修正します。初期の誤った情報がルーティングテーブルに格納されていても、最終的には有用な状態に落ち着く収束プロトコルを使用します。

メカニズムの設計 ゲーム理論では、自分の個人的な興味だけのために利己的に見ている人が、デザイナーがやりたいことをやってしまうような状況（オークションのルールを設定するなど）を設計することを、「メカニズム設計」と呼びます。。特に、実装理論を使用すると、「コモンズの悲劇」や「囚人のジレンマ」など、誰にもないことが起こるような設計が不十分な状況を回避して、最終的な結果が誰にとっても全体的なメリットを最大化するように状況を設計できます。長期的な関心。

そのような最も堅牢なプロセスのいくつかは、インセンティブ互換性を持つように設計されています。

ゲーム理論では通常、関連するすべてのエージェントが「合理的」であるという単純化された仮定を行います。ゲーム理論では、「合理的」とは、エージェントが他の結果よりもいくつかの結果を好むことを意味します。狭い自己利益）、そして彼は他の合理的なエージェントが同様に行動して、その行動の選択から生じる可能性のあるすべての可能な結果から最も好ましい結果を得ようとすることを理解するのに十分賢いです。

設計者は、すべての人々が自分の狭い自己利益に従ってのみ行動するという簡単な仮定を一時的に行う場合があります。この仮定により、実装理論を使用して状況を設計しやすくなります。ただし、設計が完了した後、人々が自分の狭い自己利益に従って行動するか（「ホモ経済的」）、または利他的であり、誰にとっても全体的な純利益を最大化したいかどうかは問題ではありません。適切に設計された状況では、両方の種類の人々がまったく同じ選択を行い、最終的な結果が誰にとっても全体的な利益を最大化します。

収束プロトコル

ルーティングプロトコルを設計する場合、ネットワーク内の各ノードは、近隣ノードにメッセージを送信し、そのノードから到達可能な他のノードに関する情報を渡します。

悲しいかな、これらのメッセージには時々エラーがあります。さらに悪いことには、ノードが誤って構成されており、多くの誤解を招くメッセージ、おそらくは悪意を持って作成されたメッセージさえも吐き出します。

人間はメッセージが正しくない可能性があることを知っていますが、通常、適切に機能しているノードがすべてのメッセージを信頼し、情報をルーティングテーブルに格納し、あたかも情報が完全に真実であると信じているかのように判断するようにプロトコルを設計します。

人間が不良ノードをオフにする（またはネットワークから切断する）と、通常、適切な情報を迅速に渡して破損した情報をフラッシュし、有用な状態にすばやく収束するようにプロトコルを設計します。

組み合わせたアプローチ

アルゴリズムによるメカニズムの設計で は、フォールトトレラントなネットワークアプローチとゲーム理論のメカニズムアプローチを組み合わせようとしているようです。

@平井洋一とアーロン、ゲーム理論と暗号を組み合わせる興味深い試みを指摘してくれてありがとう。

Joe Halpernがそのトピックについて説明しています。 http://games2009.dimi.uniud.it/Halpern.pdf

これは、当事者がプロトコルに従うようにインセンティブを与えることに関するものです。それらのメカニズムは、当事者の合理性を必要とし、議論はゲーム理論に基づいています。