この記事の由来はAragonこの記事の由来は

副題

背景

背景主要なデジタル ガバナンス プロジェクトとして、Aragon Labs は研究と革新的なガバナンス モデルに多額の投資を行ってきました。私たちは、可能性を秘めているものの、いくつかの技術的な問題も抱えているさまざまなレイヤー 2 ガバナンス ソリューションを特定しました。

私たちは、専用の投票ブロックチェーンである Vochain 上でガスフリー投票プロセスを実装することができ、イーサリアム クロスチェーンからヴォチェイン。しかしこれまでのところ、クロスチェーンの結果をイーサリアムに転送する可能性は未解決の研究課題となっています。そのために、アラゴン研究所は新たに設計された実験を実行しています。

この設計により、主観的なオラクルやその他の信頼できるコンポーネントを使用せずに、オフチェーン投票プロセスの結果をイーサリアムにクロスチェーンできるようになります。

私たちの提案は、完全にオフチェーンで行われる投票プロセスを可能にし、結果はオンチェーン ガバナンスと同じ整合性でイーサリアム上に適用され、オンチェーン ガバナンスのコストの数分の一が可能になります。

副題

投票プロトコルの概念実証の要件

技術的ソリューションを設計する前に、研究プロトコルのパラメーターを定義しました。

1. 投票プロトコルの要件は次のとおりです。

2. ライセンスフリー。

3. 検閲に対する抵抗。

4. 結果をイーサリアムにバインドする機能。

5. ガソリン代を発生させない有権者。

6. トークンのクロスチェーンから解放されます。

7. できるだけシンプル (サイドチェーンなし)。

ERC-20/ERC-777およびNFTでの投票に使用できます。

1. 概念実証設計として、次の制約を受け入れます。

2. ユーザーの匿名性なし: 投票はイーサリアム アドレスにバインドできます。

3. 領収書がないわけではありません。投票用紙を購入することは可能です。

4. 中継者に対する明確なインセンティブ制度はありません。

副題

理想的なプロポーズ

提案の設計によれば、新しい投票プロセスを作成する際、主催者は有権者国勢調査用の ERC-20 トークンの契約アドレスを指定するトランザクションをイーサリアムに送信します。このアドレスのストレージ ルート ハッシュは、指定されたブロックの高さでこのプロセスの国勢調査ルートになります。特定のトークンを保有している人は誰でも、トークン残高のマークル証明を提供することで資格を証明できます (EIP-1186 経由)。その後、証明と署名を zk-SNARK ロールアップリレーラーに送信することで投票でき、最終結果の証明が計算されます。

存在する潜在的な問題は、結果を理論的に計算した zk-SNARK 証明の参加者 (コーディネーター) が、投票の除外を決定することで結果をレビューできる可能性があることです。この問題は、(コーディネーターだけでなく) 誰でも新しい投票を送信できるようにすることで解決します。コーディネーターが投票を含めていないことを検出した場合、どのユーザーも自分の投票を含む集計を生成して送信できます。

• 私たちの提案では、zk-SNARKS を次の目的に使用します。

• マークル ツリー アキュムレータを介して投票せずにアドレスを検証します。

• ユーザーが Proof of Storage を通じてトークンを所有していることを検証します。

• 一連の投票の部分的な結果を計算します。

上記のパターンに基づいて、次の 2 つの主な問題が見つかります。

副題

ERC-20 ストレージの証明は、SNARK で検証するのが非常に複雑です。これは、再帰長プレフィックス (RLP) 解析と複数の Kecmack -256 ハッシュ検証の使用が部分的に原因ですが、どちらも最先端の SNARK 要約技術では計算効率が低くなります。この問題は解決するのが難しいため、現在、この問題を解決するためにオプティミスティック検証を使用しています。

副題

問題 2: ECDSA/Secp256k1 署名検証は SNARK に優しくない

ユーザー署名の検証に使用できる現在の暗号化標準の 1 つは ECDSA です。これは、イーサリアム署名からの BabyJubJub キーを使用し、その署名を元の秘密キーとして使用し、ユーザーがアドレスを回復できるようにします。この方法はユーザーの署名に依存しているため、ユーザーを騙して Web3 ウォレットで不正なトランザクションに署名させる悪意のあるプロキシに対して脆弱です。この脆弱性は、ブラウザウォレットがトランザクションの署名に使用するあらゆる場所に存在します。潜在的な解決策は、秘密キーを導出する導出パスとして Web アドレスを使用することです。

もう 1 つの課題は、各トークン所有者のイーサリアム アドレスが、投票プロセスによって作成されたブロックの高さで投票するための BabyJubJub 公開キーを承認することを証明することです。これは、イーサリアム アドレスを BabyJubJub 公開キーにマッピングする「シングルトン」スマート コントラクトを通じて行われ、ユーザーは標準トランザクションを通じて自分のキーをスマート コントラクトに追加する必要があります。アドレスとキーのマッピングは、オプティミスティック ストレージ不正証明を使用して実現できます。これらの認証キーはさまざまな投票プロセスで複数回使用されることが予想されるため、このソリューションは再利用可能な設計を通じてデータの可用性の問題にも対処します。

• 要約すると、以下を除くほとんどの検証を SNARK で処理できます。

• アドレスが以前にマークル ツリー アキュムレータ → SNARK を通じて投票されていないことを確認します。

• ユーザーがトークンを持っているかどうかを、Storage Proof → Optimistic を通じて確認します。

• 副題

ユーザー

• ユーザー

• アカウントの投票情報と保管証明を取得し、投票パケットに署名を生成して、中継者または中継者のグループに転送します。

副題

投票スマートコントラクト

ERC-20 スマート コントラクト アドレス、ERC-20 アドレスのスロット インデックス → バランス マッピング、投票プロセスの開始ブロックのステート ルート ハッシュ、投票を計算するためのプロセス パラメーターを含む投票プロセスを登録します。

• SNARK は、zk-Rollup を通じて新しい投票の登録を監視することで、次のことを証明します。

• 結果の計算。

• 投票署名は BabyJubJub キーによって決定されます。

• 投票アキュムレータを常に最新の状態に保ちます。

有権者のリストを常に最新の状態に保ってください。

• 誰でも最後の投票登録不正の証拠に異議を申し立てられるようにします。ただし、次の条件のいずれかを満たす必要があります。

• 保管の証明。投票者のイーサリアムアドレスにトークンがないことを証明します。

• BabyJubJub キーが投票したことの証明 (キーは「投票済み」マークル ツリーにあります)。

副題

• 中継者

• フェーズ 0: イーサリアム上で選出プロセスが作成され、利用可能なリレーラーのリストからリレーラーが選択されます。選挙主催者は選挙手数料（コーディネーターに報酬）を支払う必要があります。主催者は、結果に応じて、DAO スマート コントラクトの選択後に実行する必要がある EVM バイトコードを提供します。

• フェーズ 1: 投票が始まります。誰でも、選択したコーディネーターに投票パケット (HTTPs または libp2p トランスポート) を送信できます。コーディネーターは、選択された結果をバッチでロールアップし、zk-SNARK 証明を構築し、証明と結果をイーサリアムにアップロードし、ユーザーが投じた投票を収集して検証し、他のリレーラーにブロードキャストします。

• フェーズ 2: 投票に参加していないことを検出したコーディネーターは、自分の投票をロールアップし、有効性の zk-SNARK 証明を投票スマート コントラクトに送信できます。さらに、投票が誤って追加されたことが検出された場合、以前に追加された結果が無効であるという不正の証拠を送信することができ、それを作成したコーディネーターは削減されます。

  フェーズ 3: 投票日の制限に達した場合:

  誰でも (通常はコーディネーター)、最終結果を入力として使用して、EVM バイトコードの実行を呼び出します。

副題

回線と契約

zk-SNARK は投票リストを集約します。 zk-SNARK 証明は、特定の投票リスト、国勢調査ルート、選挙識別子 (electionId)、および集計結果に基づいて有効です。

• zk-SNARK の入力:

• ハッシュ入力は、SNARK 検証のガスコストを削減するためのものです。

• プライベート選挙識別子。

• 計算された投票結果。

• 現在のヌリファイアのルート (ヌリファイアのルート)。

• 空のルーンルートを更新しました。

• バッチ内の投票数。

投票値と対応する BabyJubJub のキー署名。

• 調整結果をアップロードするためのスマート コントラクト関数呼び出しへの入力は次のとおりです。

• 選挙識別子。

• バッチ内の投票者の公開鍵のリスト。

• 空のルーンルートを更新しました。

• スナークの証拠。

副題

概念実証の実装

最小限の実行可能なスマート コントラクトと回路を実装し、ソリューションのコストと実現可能性を確認しました。概念実証には、ユーザー登録、投票集計、および不正行為の証明の検証のみが含まれます。

• テストの結果、次のようなガス代が発生しました。

• ユーザー キー レジストリの展開: 258536

• 登録: 68956

• 投票の展開: 6673,159

• 新規投票数: 25989

• 累計集計数: 291801

• 不正証拠 2: 908822 (アカウント ERC-20 残高がゼロ)

副題

今後の研究

1. この調査に基づいて、次のアイデアをさらに詳しく検討していきたいと思います。

2. SNARK を介した標準の kecak/ECDSA/Sec256k1 署名の検証。私たちは、近いうちに PLOOKUP でこれらのスキームを検証できるようになると考えています。これにより、次の 2 つの可能性が考えられます。

3. BabyJubJub キーが Secp256k1 キーから派生していることの証明。

4. 投票署名自体を検証します。

5. 保管の証拠はSNARK内で検証されます。コストは膨大になるかもしれませんが、この種の複雑な配線は zkVM によって簡単に統合できると考えています。私たちは、イーサリアムクライアントがガスコスト制限の上昇を優先してアーカイブノードからドロップアウトすることを懸念しているため、別の研究分野は、Proof of Storage に EIP1186 以外の方法を試すことです。

6. カウントを計算するために、いくつかのオペコードが zkVM で実行されるように埋め込まれており、一般的なプログラム可能な投票回路が利用可能になります。zk.money投票の証明はブラウザで生成され、バッチ処理によって混合され、結果は次のように再帰的に集計されます。

7. プロトコル。これにより、投票プロセスのプライバシーが強化されます。

8. 計算にコストがかかる場合でも、ブラウザ レベルで分散方式で SNARK を計算できます。これにより、可視性の高いサーバーへの依存がなくなり、完全に P2P となり、投票者にすべての権限が与えられます。

9. ネットワーク レベルで投票プロトコルにプライバシーとミキシングを組み込みます。

10. イーサリアム 2.0 と完全に相互運用可能な合理的な暗号経済モデルを見つけてください。