MACI: オンチェーンガバナンスにおける共謀防止フレームワーク

Eric Zhang

Architect @DoraFactory @DoraHacks

この記事の背景については「Quadratic Voting and Quadratic Funding」(https://matataki.io/p/6113)を参照してください。この記事の公開から 1 か月後、BSC 財団は DoraHacks 開発者プラットフォーム HackerLink 上で BSC エコシステム (https://hackerlink.io/grant) に対する二次資金調達の第 1 ラウンドを開始し、その後 15 日間でプロジェクトを受け取りました。世界中の 60 以上の開発者チームから提出されました。

「Quadratic Voting and Quadratic Funding」では、Vitalik のブログ「Quadratic Payments」で言及されている 3 つの問題 (身元贈収賄、共謀、合理的無視) を紹介しました。これら 3 つの問題は二次投票に限定されるものではなく、オンチェーンのガバナンス メカニズムが遭遇する一般的な問題です。したがって、これらの問題の解決策は、二次投票をよりスケーラブルかつ安全にするだけでなく、より多くのオンチェーンガバナンスメカニズムに利益をもたらすことができます。

この記事の目的は、「非協力的な二次投票」または「共謀耐性のある二次投票」メカニズムの設計を準備することです。このシナリオでは、有権者は互いに協力できないため、共謀の可能性はありません。このメカニズムの基本的なフレームワークは、Vitalik Buterin が Ethresear で公開した記事「Minimal anti-collusion interaction インフラストラクチャ」[1] (MACI) です。したがって、まず MACI のメカニズムを説明し、MACI を使用して二次投票を改善し、共謀の可能性を排除する方法をさらに検討します。

MACI: Minimal Anti-Collusion Infrastructure

MACI は「最小化反共謀フレームワーク」です。背景資料については、Vitalik Buterin のブログ https://ethresear.ch/t/minimal-anti-collusion-infrastructor/5413 および「共謀について」 https://vitalik.ca/general/2019/04/03/collusion を参照してください。 .html

設定

設定

公開鍵のリストを含むスマート コントラクト \(R\) があるとします。\(K_1 ... K_n\),そして、これらの公開鍵をスマート コントラクトに登録するために必要な関数がいくつかあります。さらに、身元を確認するための次の 2 つの条件を満たす参加者の公開鍵のみが R に入ることができます。

アカウントは「合法的な」参加者（独立した個人、特定の国の国籍を持ち、フォーラムで十分な評判があり、一定量以上のトークンを保有しているなど、特定のコミュニティのメンバー）に属します。 ..)

アカウント所有者の個人管理キー (例: 必要に応じて証明用に印刷可能)

各ユーザーは一定の金額を賭ける必要があります。誰かが秘密鍵を漏洩した場合、秘密鍵を入手した人は直接お金を引き出すことができ、そのアカウントはリストから削除されます。このメカニズムにより、誰でも秘密鍵を他の人に渡すことができなくなります。

また、秘密鍵を持っているオペレーター (\(operator\)) がいるとします。\(k_\omega\),および対応する公開鍵\(K_\omega\).

最後に、メカニズムがあるとします。\(M\),それは関数です\(action^n \rightarrow Outputs\),埋め込む

埋め込む

開始時刻 \(T_{start}\) に、\(operator\) が実際の状態を開始します\(S_{start} = {i: (key=K_i, action = \phi)}, i \in 1...n\).

開始時刻 \(T_{start}\) と終了時刻 \(T_{end}\) の間、登録された参加者は誰でも、参加者自身の秘密鍵 \(k\) 暗号化を使用してメッセージを R に送信できます。メッセージには次の 2 種類があります。

合意された行動: 例: 投票。参加者は暗号化されたメッセージを送信する必要がある\(enc(msg = (i, sign(msg = action, key = k_i)), pubkey = K_\omega)\),ここで、 \(k_i\) は参加者の現在の秘密鍵、 \(i\) は \(R\) の参加者の ID です。

キー再生成: 参加者は暗号化されたメッセージを送信する必要があります\(enc(msg = (i, sign(msg = NewK_i, key = k_i)), pubkey = K_\omega)\),\(NewK_i\) は参加者が変更する公開鍵です。\(k_i\) はこの参加者の現在の秘密鍵です

現時点でのオペレーターの仕事は、チェーンにアップロードされた順序で各メッセージを処理することです。具体的な処理プロセス:

オペレーターの秘密キーを使用してメッセージを復号化します。復号化に失敗した場合、または復号化に対応する情報を上記 2 種類の情報に復号できない場合は、この情報を直接スキップします。

\(state[i].key\) を使用してメッセージの署名を検証します

デコードされたメッセージが合意された動作 (\(action\)) である場合、次のように設定します。\(state[i] = action\),デコードされたメッセージが新しい公開キーの場合は、次のように設定します。\(state[i].key = NewK_i\)

\(T_{end}\) の後、オペレータは出力ステータスをアナウンスする必要があります\(M(state[1].action, ... , state[n].action)\),同時に、この出力が正しい結果であることを証明するために ZK-SNARK が与えられます。

このメカニズムが共謀防止となる理由

参加者が \(action\) \(A\) を実行するなど、自分が何をしたかを証明したいとすると、チェーン上のトランザクションを参照できます。\(enc(msg = (i, sign(msg = A, key = k_i)),pubkey = K_\omega)\) を指定し、トランザクションに \(A\) の暗号化された情報が実際に含まれていることを検証するゼロ知識証明を提供します。ただし、他のトランザクションを送信していないことを証明することはできません。たとえば、以前のトランザクションを送信し、公開鍵を新しい \(NewK_i\) に置き換えた可能性があります。したがって、以前の証明は無意味になります。キー、彼は何か他のことをしたかもしれません。

参加者が秘密鍵を他の人に渡すことも可能ですが、その場合、その人は鍵を入手するとすぐに変更を試みることができます。この場合、1) 成功率は 50% で、2) 鍵を入手した人は以前の賭け金のデポジットを直接奪い取ります。

MACI に関する未解決の問題

受信者は、信頼できるハードウェア環境、または信頼できるマルチ署名の場合に秘密キーを販売します。

元の秘密キーは信頼できるハードウェア環境で攻撃され、秘密キーが攻撃者が事前に知らない秘密キーに変更されるのを防ぎます。

前者の場合、特別に設計された複雑な署名メカニズムが使用されますが、この設計は信頼できるハードウェアやマルチ署名には適していません。ただし、この設計では、検証機能が ZKP に適していることを保証する必要があります。

2 番目のケースは、「対面ゼロ知識証明」によって解決できます。たとえば、参加者は秘密鍵を \(x + y = k_i\) に分解し、\(X = x*G\) を公開し、\(Y = y*G\),そして、検証者に \(x\) と \(y\) が入った 2 つの封筒を見せ、検証者は 1 つを開けて、発表された \(Y\) が正しいことを確認してから、\(X + Y = K_i\)。

非協力的な二次投票

このメカニズムは、投票を含むさまざまなオンチェーン ガバナンス メカニズムを改善するために使用できます。二次資金調達では、プールサイズが非常に大きい場合、または二次資金調達がより大きなシナリオ（総選挙、議会予算承認など）の問題で使用される場合、共謀は対処しなければならない問題になります。したがって、共謀防止二次資金調達メカニズムを設計すると、二次資金調達を拡張できます。

[1]Vitalik Buterin, Minimal anti-collusion infrastructure,

https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413