原題: 「イーサリアムプロトコルの将来の可能性、パート 6: 散財」
作者: ヴィタリック ブテリン
編集者: zhouzhou、BlockBeats
以下は元の内容です (元の内容は読みやすく、理解しやすいように編集されています)。
単一のカテゴリーに当てはめるのが難しいものもあり、イーサリアムプロトコルの設計にはイーサリアムの成功にとって非常に重要な「小さな詳細」がたくさんあります。実際、コンテンツの約半分はさまざまなタイプの EVM 改善をカバーしており、残りはさまざまなニッチなトピックで構成されており、これが「繁栄」のすべてです。
2023 年のロードマップ: 繁栄
繁栄: 重要な目標
- EVMを高性能で安定した「最終状態」に変える
- プロトコルにアカウント抽象化を導入し、すべてのユーザーがより安全で便利なアカウントを利用できるようにします。
- 取引手数料の経済性を最適化し、リスクを軽減しながら拡張性を高めます
- 長期的にイーサリアムを大幅に改善するための高度な暗号化を探求する
EVMの改善
どのような問題が解決されましたか?
現在の EVM は静的に分析することが難しいため、効率的な実装を作成し、コードを正式に検証し、さらなる拡張を行うことが困難になります。さらに、EVM は非効率的であり、プリコンパイルによって明示的にサポートされていない限り、多くの形式の高度な暗号化を実装するのが困難です。
それは何ですか?またどのように機能しますか?
現在の EVM 改善ロードマップの最初のステップは EVM オブジェクト フォーマット (EOF) であり、次のハード フォークに含まれる予定です。 EOF は、次のような多くの固有の特性を持つ新しい EVM コード バージョンを指定する一連の EIP です。
- コード（実行可能だがEVMからは読み取り不可）とデータ（読み取り可能だが実行不可）の分離
- 動的ジャンプは禁止され、静的ジャンプのみが許可されます。
- EVMコードは燃料関連情報を観察できなくなりました
- 新しい明示的なサブルーチン メカニズムを追加しました
EOFコードの構造
ブーム: EVM の改善 (続き)
レガシー コントラクトは引き続き存在し、作成することができますが、最終的には段階的に廃止される可能性があります (EOF コードに強制される可能性もあります)。新しいスタイルのコントラクトは、EOF によってもたらされる効率向上の恩恵を受けることになります。最初はサブルーチン機能によるわずかに小さいバイトコードから、その後は EOF 固有の新機能やガスコストの削減から恩恵を受けます。
EOF の導入後、さらなるアップグレードが容易になり、現在最も開発されているのは EVM モジュール演算拡張機能 (EVM-MAX) です。 EVM-MAX は、モジュラー算術専用の新しい演算セットを作成し、他のオペコードからはアクセスできない新しいメモリ空間にそれらの演算セットを配置し、モンゴメリ乗算などの最適化を使用できるようにします。
新しいアイデアは、EVM-MAX と単一命令複数データ (SIMD) 機能を組み合わせるというもので、SIMD はイーサリアムで長い間アイデアとして存在しており、Greg Colvin の EIP-616 によって最初に提案されました。 SIMD を使用すると、ハッシュ関数、32 ビット STARK、格子ベースの暗号化など、さまざまな形式の暗号化を高速化できます。EVM-MAX と SIMD を組み合わせることで、これら 2 つのパフォーマンス指向の拡張機能が自然な組み合わせになります。
結合された EIP の大まかな設計は、EIP-6690 から始まり、次のようになります。
- (i) 任意の奇数、または (ii) 2768 までの任意の 2 の累乗を法として許可します。
- EVM-MAX オペコード (加算、減算、乗算) ごとに、3 つの即値 x、y、z を使用する代わりに、7 つの即値 (x_start、x_skip、y_start、y_skip、z_start、z_skip、count) を使用するバージョンを追加します。 Python コードでは、これらのオペコードは次のように機能します。
範囲内の i の場合 (カウント):
mem[z_start + z_skip * count] = op(
mem[x_start + x_skip * count],
mem[y_start + y_skip * count]
）
実際の実装では、これは並行して処理されます。
- 少なくとも 2 のべき乗モジュロについては、XOR、AND、OR、NOT、SHIFT (巡回および非巡回の両方) を追加できる可能性があります。また、ISZERO (EVM メイン スタックに出力をプッシュ) を追加します。これは、楕円曲線暗号、小規模ドメイン暗号 (Poseidon、Circle STARK など)、従来のハッシュ関数 (SHA256、KECCAK、BLAKE など) およびベースの暗号を実装するのに十分強力です。格子暗号法について。他の EVM アップグレードも可能ですが、これまでのところあまり注目されていません。
既存の研究へのリンク
- EOF: https://evmobjectformat.org/
- EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
- SIMD: https://eips.ethereum.org/EIPS/eip-616
残りの作業とトレードオフ
現在、EOF は次のハードフォークに含まれる予定です。土壇場で削除することはいつでも可能ですが、機能は以前のハードフォークで一時的に削除されていましたが、そうすることは非常に困難です。 EOF を削除すると、EVM への今後のアップグレードはすべて EOF なしで実行する必要があり、これは実行可能ですが、より困難になる可能性があります。
EVM の主なトレードオフは、L1 の複雑さとインフラストラクチャの複雑さです。EOF は EVM 実装に追加する必要がある大量のコードであり、静的コード検査も比較的複雑です。ただし、その代わりに、簡素化された高級言語、簡素化された EVM 実装、その他の利点が得られます。イーサリアム L1 の継続的な改善を優先するロードマップには、EOF が含まれ、それに基づいて構築されるべきであると言えます。
実行する必要がある重要な作業は、EVM-MAX と SIMD に類似した機能を実装し、さまざまな暗号化操作のガス消費量をベンチマークすることです。
ロードマップの他の部分と対話するにはどうすればよいですか?
L1 は、L2 がそれに応じてより簡単に調整できるように EVM を調整します。2 つが同時に調整されない場合、非互換性が生じ、悪影響が生じる可能性があります。さらに、EVM-MAX と SIMD により、多くのプルーフ システムのガスコストが削減され、L2 の効率が向上します。また、おそらく効率に大きな影響を与えることなく、同じタスクを実行できる EVM コードでより多くのプリコンパイルを置き換えることが容易になります。
アカウントの抽象化
どのような問題が解決されましたか?
現在、トランザクションは ECDSA 署名という一方向のみで検証できます。当初、アカウントの抽象化はこれを超えて、アカウントの検証ロジックを任意の EVM コードにできるようにすることを目的としていました。これにより、さまざまなアプリケーションが可能になります。
- 耐量子暗号への切り替え
- 古いキーをローテーションする (推奨されるセキュリティ手法として広く考えられています)
- マルチシグネチャウォレットとソーシャルリカバリウォレット
- 低価値の操作には 1 つのキーを使用し、高価値の操作には別のキー (またはキーのセット) を使用します
リレーなしでプライバシー プロトコルが機能できるようにし、複雑さを大幅に軽減し、重要な中心依存点を排除します。
2015 年にアカウントの抽象化が提案されて以来、その目標は、たとえば、ETH を持たないが一部の ERC20 でガソリン代を支払うことができるアカウントなど、多数の「利便性の目標」を含むように拡張されました。これらの目標の概要図は次のとおりです。
MPC (Multi-Party Computation) は、キーを複数の部分に分割して複数のデバイスに保存するために使用される 40 年前のテクノロジーで、暗号化技術を使用してキー部分を直接結合せずに署名を生成します。
EIP-7702 は次のハード フォークで導入される予定の提案です。EIP-7702 は、EOA ユーザーを含むすべてのユーザーに利益をもたらすアカウント抽象化の利便性を提供するという意識の高まりの結果であり、すべてのユーザーを短期的に改善することを目的としています。 2 つのエコシステムに分裂することを経験し、回避します。
この作業は EIP-3074 で始まり、EIP-7702 で最高潮に達しました。 EIP-7702 は、今日の EOA (外部所有アカウント、つまり ECDSA 署名によって制御されるアカウント) を含むすべてのユーザーにアカウント抽象化の「便利な機能」を提供します。
グラフからわかるように、一部の課題 (特に「利便性」の課題) はマルチパーティ コンピューティングや EIP-7702 などの増分テクノロジによって解決できますが、元のアカウント抽象化提案の主なセキュリティ目標は解決することしかできません。元の問題を遡って解決することにより、達成するには: スマート コントラクト コードによるトランザクション検証の制御を許可します。これがこれまで不可能であった理由は、安全に実装することが課題であるためです。
それは何ですか?またどのように機能しますか?
アカウント抽象化の核心はシンプルです。EOA だけでなく、スマート コントラクトがトランザクションを開始できるようにします。全体の複雑さは、分散型ネットワークを維持し、サービス妨害攻撃から保護するのに適した方法でこれを実装することに起因します。
典型的な重要な課題は、多重障害の問題です。
すべての検証機能が 1 つの値 S に依存する 1,000 個のアカウントがあり、現在の値 S によってメモリプール内のすべてのトランザクションが有効になる場合、S の値を反転する 1 つのトランザクションによって、メモリプール内の他のすべてのトランザクションが無効になる可能性があります。 。これにより、攻撃者は非常に低コストでトランザクションをメモリプールにスパム送信し、ネットワーク ノードのリソースを詰まらせることができます。
サービス拒否 (DoS) リスクを制限しながら機能を拡張することを目的とした長年の努力の末、最終的に「理想的なアカウント抽象化」を実現するソリューション、ERC-4337 に到達しました。
ERC-4337 は、ユーザー操作の処理を検証と実行の 2 つの段階に分割することで機能します。すべての検証が最初に処理され、すべての実行が後で処理されます。 mempool では、検証フェーズに自分のアカウントのみが含まれ、環境変数を読み取らない場合にのみ、ユーザー アクションが受け入れられます。これにより、複数の無効化攻撃が防止されます。さらに、検証ステップでは厳格なガス制限が適用されます。
ERC-4337 は追加プロトコル標準 (ERC) として設計されました。当時、イーサリアム クライアントの開発者はマージに集中していて、他の機能に対処するための余分なエネルギーがなかったためです。 ERC-4337 が通常のトランザクションの代わりにユーザー アクションと呼ばれるオブジェクトを使用するのはそのためです。しかし、最近、この少なくとも一部をプロトコルに書き込む必要があることに気づきました。
主な理由は次の 2 つです。
- EntryPoint にはコントラクトとしての非効率性が内在しています。つまり、バンドルごとに約 100,000 ガスの固定オーバーヘッドが発生し、ユーザー操作ごとにさらに数千のガスが発生します。
- イーサリアムのプロパティを保証する必要性: 包含リストとして作成された包含保証をアカウント抽象化ユーザーに転送する必要があります。
さらに、ERC-4337 は次の 2 つの機能も拡張します。
- ペイマスター: あるアカウントが別のアカウントに代わって料金を支払うことを可能にする機能。これは、検証フェーズ中に送信者アカウント自体にのみアクセスできるというルールに違反するため、支払いマスター メカニズムのセキュリティを確保するために特別な処理が導入されます。
- アグリゲータ: BLS 集約や SNARK ベースの集約などのシグネチャ集約関数をサポートします。これは、ロールアップで最大のデータ効率を達成するために必要です。
既存の研究へのリンク
- アカウントの抽象的な歴史に関する講義: https://www.youtube.com/watch?v=iLf8qpOmxQc
- ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
- EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
- BLSWallet コード (集約関数を使用): https://github.com/getwax/bls-wallet
- EIP-7562 (プロトコルに書き込まれたアカウント抽象化): https://eips.ethereum.org/EIPS/eip-7562
- EIP-7701 (EOF ベースの書き込みプロトコル アカウント抽象化): https://eips.ethereum.org/EIPS/eip-7701
残りの作業とトレードオフ
現時点で解決する必要がある主な点は、プロトコルにアカウント抽象化を完全に導入する方法です。プロトコルに記述された最近人気のアカウント抽象化 EIP は、EOF の上にアカウント抽象化を実装する EIP-7701 です。アカウントには検証用に別のコード セクションを含めることができ、アカウントにそのコード セクションが設定されている場合、そのコードはそのアカウントからのトランザクションの検証ステップ中に実行されます。
このアプローチの興味深い点は、ローカル アカウントの抽象化に関する 2 つの同等の視点を明確に示していることです。
- プロトコルの一部として EIP-4337 を含める
- 署名アルゴリズムが EVM コード実行である新しいタイプの EOA
検証中に実行可能コードの複雑さに厳密な制限を設定することから始める場合 (外部状態へのアクセスは許可されず、最初に設定されたガス制限でさえ、耐量子性アプリケーションやプライバシー保護アプリケーションには効果的ではありません)、このアプローチはセキュリティは非常に明確です。ECDSA 検証を、同様の時間がかかる EVM コード実行に置き換えるだけです。
しかし、時間の経過とともに、プライバシー保護アプリケーションがリレーなしで動作できるようにすることと、耐量子性が重要であるため、これらの制限を緩和する必要があります。そのためには、最小限の検証手順を必要とせずにサービス拒否 (DoS) リスクに対処する、より柔軟な方法を見つける必要があります。
主なトレードオフは、「より少ない人を満足させるソリューションを迅速に作成する」ことと、「より長く待って、より理想的なソリューションが得られる可能性がある」ことのようです。理想的なアプローチは、おそらくある種のハイブリッド アプローチです。ハイブリッド アプローチでは、一部のユース ケースをより速く作成し、他のユース ケースを検討するためにより多くの時間を残します。もう 1 つのアプローチは、アカウント抽象化のより野心的なバージョンを最初に L2 にデプロイすることです。ただし、これに関する課題は、特に L1 および/または他の L2 が将来的に互換性のあるアプローチを採用できるようにするために、L2 チームが提案を実装する前に、その提案を採用する作業に自信を持っている必要があることです。
明示的に考慮する必要があるもう 1 つのアプリケーションはキー ストレージ アカウントです。これはアカウント関連の状態を L1 または専用 L2 に保存しますが、L1 および互換性のある任意の L2 で使用できます。これを効率的に行うには、L2 が L1SLOAD や REMOTESTATICCALL などのオペコードをサポートする必要がある場合がありますが、L2 上のアカウント抽象化実装がこれらの操作をサポートしていることも必要です。
ロードマップの他の部分とどのように相互作用するのでしょうか?
インクルードリストはアカウント抽象トランザクションをサポートする必要があり、実際にはインクルードリストのニーズは分散型メモリプールのニーズと非常に似ていますが、インクルードリストには若干柔軟性があります。さらに、アカウント抽象化の実装は、可能な限り L1 と L2 の間で調整される必要があります。将来、ほとんどのユーザーがキー ストレージ ロールアップを使用することが予想される場合、アカウント抽象化の設計はこれに基づいて行う必要があります。
EIP-1559の改善
それはどのような問題を解決しますか?
EIP-1559 は 2021 年にイーサリアムで有効化され、平均ブロック包含時間が大幅に短縮されました。
待ち時間
ただし、現在の EIP-1559 の実装は、次のようなさまざまな点で不完全です。
- この式には少し欠陥があります。ブロックの 50% を対象とするのではなく、分散に応じてブロック全体の約 50 ～ 53% を対象とします (これは数学者が「算術幾何平均不等式」と呼ぶものと関係しています)。
- 極端な状況で十分な速さで調整できない。
後者の BLOB の式 (EIP-4844) は、最初の問題を解決するために特別に設計されており、全体的により単純です。ただし、EIP-1559 自体も EIP-4844 も 2 番目の問題に対処しようとはしていません。したがって、現状は 2 つの異なるメカニズムが関与する乱雑な中間状態であり、時間の経過とともに両方を改善する必要があるという議論があります。
さらに、Ethereum リソースの価格設定には EIP-1559 とは関係のない弱点が他にもありますが、EIP-1559 を調整することで対処できます。主な問題の 1 つは、平均的なケースと最悪のケースの違いです。イーサリアムのリソース価格は、ブロックの全ガス消費量がリソースを占有するが、実際の平均使用量は大幅に増加するという最悪のケースに対処できるように設定する必要があります。これより低いと非効率につながります。
多次元ガスとは何ですか?またどのように機能しますか?
これらの非効率性に対する解決策は多次元ガスです。つまり、リソースごとに異なる価格と制限を設定します。この概念は技術的には EIP-1559 から独立していますが、EIP-1559 の存在により、このソリューションの実装が容易になります。 EIP-1559 がなければ、複数のリソース制約を含むブロックを最適にパッケージ化することは、複雑な多次元のナップザック問題になるでしょう。 EIP-1559 では、ほとんどのブロックはどのリソースでも最大容量に達しないため、「十分な料金を支払うトランザクションを受け入れる」などの単純なアルゴリズムで十分です。
現在、実行およびデータ ブロック用に多次元の Gas を使用していますが、原則として、これを呼び出しデータ (トランザクション データ)、状態の読み取り/書き込み、状態サイズの拡張など、より多くの次元に拡張することができます。
EIP-7706 では、通話データ専用の新しいガス ディメンションが導入されています。同時に、3 種類のガスを (EIP-4844 スタイルの) フレームワークに統合することで多次元のガス メカニズムを簡素化し、EIP-1559 の数学的欠陥も解決します。 EIP-7623 は、まったく新しい次元を導入することなく、平均的および最悪の場合のリソースの問題に対して最大コールデータをより厳密に制限する、より正確なソリューションです。
さらなる研究の方向性は、EIP-4844 メカニズムによって導入された重要な不変条件を維持しながら、更新レートの問題を解決し、より高速な基本料金計算アルゴリズムを見つけることです (つまり、長期的には、平均使用量が目標値にちょうど近くなります) ）。
既存の研究へのリンク
- EIP-1559 よくある質問:EIP-1559 よくある質問
- EIP-1559 に関する実証分析: 実証分析
- 素早い調整を可能にする改善案:改善案
- EIP-4844 FAQ の基本料金メカニズムに関する部分: EIP-4844 FAQ
- EIP-7706:EIP-7706
- EIP-7623:EIP-7623
- 多次元ガス:多次元ガス
残りの努力とトレードオフは何ですか?
多次元ガスには 2 つの主なトレードオフがあります。
- プロトコルの複雑さの増加: 多次元ガスの導入により、プロトコルはより複雑になります。
- ブロックを満たすために必要な最適アルゴリズムの複雑さの増加: ブロックを最大容量にするために必要な最適アルゴリズムも複雑になります。
プロトコルの複雑さは、calldata では比較的小さいですが、EVM 内のガス ディメンション (ストレージの読み取りと書き込みなど) では増加します。問題は、ユーザーがガス制限を設定するだけでなく、契約も他の契約に電話するときに制限も設定することです。そして現在、制限を設定できる唯一の方法は一次元です。
簡単な解決策は、EOF では他のコントラクトを呼び出すときにコントラクトがガス制限を設定できないため、多次元ガスを EOF 内でのみ使用できるようにすることです。非 EOF 契約では、ストレージ操作を実行するときにすべての種類のガスの料金を支払う必要があります (たとえば、SLOAD がブロック ストレージ アクセス ガス制限の 0.03% を占める場合、非 EOF ユーザーにも実行ガスの 0.03% が請求されます)制限料金）。
多次元ガスに関するさらなる研究は、これらのトレードオフを理解し、理想的なバランスを見つけるのに役立ちます。
ロードマップの他の部分とどのように相互作用するのでしょうか?
多次元 Gas の実装が成功すると、特定の「最悪の場合」のリソース使用量を大幅に削減できるため、STARK ハッシュベースのバイナリ ツリーなどの要件をサポートするためにパフォーマンスを最適化するというプレッシャーが軽減されます。状態サイズの拡大に関する明確な目標を設定すると、クライアント開発者が将来のニーズを計画および見積もるのが容易になります。
前に述べたように、EOF の存在により、Gas の観測不可能な性質により、多次元 Gas のより極端なバージョンの実装が容易になります。
検証可能な遅延関数 (VDF)
それはどのような問題を解決しますか?
現在、イーサリアムは提案者を選択するためにRANDAOに基づくランダム性を使用しています。これは、各提案者が事前に約束した秘密を明らかにすることを要求し、公開されたそれぞれの秘密をランダム性に混合することによって機能します。
したがって、各提案者は「1 つのコントロール」を持ちます。つまり、提案者は (コストをかけて) 現れないことでランダム性を変更できます。 1 つの機会を放棄して 2 つの新しい機会を獲得することは非常にまれであるため、このアプローチは提案者を見つけるのに理にかなっています。ただし、これはランダム性を必要とするオンチェーン アプリケーションには理想的ではありません。理想的には、より堅牢なランダム性のソースを見つける必要があります。
VDF とは何ですか?またどのように機能しますか?
検証可能な遅延関数は、逐次的にのみ評価できる関数であり、並列化によって高速化することはできません。簡単な例は、ハッシュの繰り返しです: for i in range(10**9): x = hash(x)。 SNARK を使用して正しいことが証明された出力結果は、ランダム値として使用できます。
その考え方は、入力は時刻 T で利用可能な情報に基づいて選択されるが、出力は時刻 T ではまだ不明であるということです。出力は、誰かが計算を完全に実行した後、T 以降のある時点でのみ利用可能になります。誰でも計算を実行できるため、結果を保留する可能性はなく、結果を操作することもできません。
検証可能な遅延関数の主なリスクは、偶発的な最適化です。誰かが予想よりも速く関数を実行していることに気づき、それによって時間 T で明らかになった情報を操作します。
予期しない最適化は次の 2 つの方法で発生する可能性があります。
- ハードウェア アクセラレーション: 既存のハードウェアよりも高速に計算ループを実行できる ASIC を構築する人がいます。
- 偶発的な並列化: 100 倍のリソースが必要であるにもかかわらず、関数を並列化することで関数をより高速に実行する方法を見つけた人がいます。
成功した VDF を作成するためのタスクは、効率性と実用性を維持しながら両方の問題を回避することです (たとえば、ハッシュ ベースのアプローチの問題の 1 つは、リアルタイムでハッシュを証明する SNARK には重いハードウェアが必要であることです)。ハードウェア アクセラレーションは、公益活動者が独自に最適に近い VDF ASIC を作成して配布することによって対処されることがよくあります。
既存の研究へのリンク
- VDF 研究 Web サイト: vdfresearch.org
- イーサリアムにおける VDF への攻撃について考える、2018 年: 攻撃について考える
- 提案された VDF MinRoot に対する攻撃:MinRoot に対する攻撃
残りの努力とトレードオフは何ですか?
現在、あらゆる面でイーサリアム研究者の要件を完全に満たす VDF 構造は存在しません。このような関数を見つけるには、さらに多くの作業が必要です。見つかった場合の主なトレードオフは、それを含めるかどうかです。これは、機能、プロトコルの複雑さ、およびセキュリティ リスクとの間の単純なトレードオフです。
VDF が安全であると考えていても、その実装方法によっては安全ではないことが判明した場合、セキュリティは RANDAO の想定 (攻撃者ごとに 1 ビットの制御) またはそれよりわずかに悪化します。したがって、VDF に障害が発生しても、プロトコルは壊れませんが、VDF に大きく依存しているアプリケーションや新しいプロトコル機能は壊れます。
ロードマップの他の部分とどのように相互作用するのでしょうか?
VDF は、イーサリアム プロトコルの比較的自己完結型のコンポーネントであり、プロポーザ選択にセキュリティを追加することに加えて、(i) ランダム性に依存するオンチェーン アプリケーション、および (ii) VDF 作成に基づく暗号メモリ プールにも応用できます。暗号化されたメモリ プールは、まだ発生していない追加の暗号発見に依存しています。
覚えておくべき重要な点の 1 つは、ハードウェアの不確実性を考慮すると、VDF 出力の生成と必要性の間にはある程度の「マージン」があるということです。これは、情報が数ブロック前に入手可能になることを意味します。これは許容できるコストですが、単一のタンクまたは設計を選択する委員会を最終決定する際には考慮する必要があります。
難読化とワンタイム署名: 暗号化の遠い未来
それはどのような問題を解決しますか?
Nick Szabo の最も有名な記事の 1 つは、「神の合意」に関する 1997 年の論文です。同氏は論文の中で、多くのマルチパーティ アプリケーションが対話の管理を「信頼できるサードパーティ」に依存していると指摘している。同氏の見解では、暗号化の役割は、実際に特定の参加者に対する信頼を必要とせずに、同じ仕事を行う疑似的な信頼できる第三者を作成することである。
これまでのところ、この理想は部分的にしか達成できていません。データや計算をオフにしたり、検閲したり、改ざんしたりすることができない透明な仮想コンピューターだけが必要であり、プライバシーが目的ではない場合、ブロックチェーンは、拡張性は限られていますが、この目的を達成できます。
プライバシーが目標である場合、最近まで、特定のアプリケーション向けに特定のプロトコルをいくつか開発することしかできませんでした。つまり、基本認証用のデジタル署名、生の匿名性用のリング署名とリンク可能なリング署名、特定の前提条件の下でより便利な暗号化を実現するためのアイデンティティベースの暗号化です。信頼できる発行者、Chaim スタイルの電子マネーのブラインド署名など。このアプローチでは、新しいアプリケーションごとに多くの作業が必要になります。
2010 年代に、私たちはプログラム可能な暗号化に基づく、別のより強力なアプローチを初めて垣間見ることができました。新しいアプリケーションごとに新しいプロトコルを作成するのではなく、強力な新しいプロトコル (特に ZK-SNARK) を使用して、任意のプログラムに暗号化の保証を追加できます。
ZK-SNARK を使用すると、ユーザーは自分が保持しているデータに関する任意の主張を証明でき、その証明は (i) 検証が容易であり、(ii) 主張自体以外のデータは明らかにされません。これはプライバシーとスケーラビリティの両方において大幅な改善であり、私はこれを人工知能におけるトランスフォーマーの影響に例えています。特定の仕事に何千人も何年も応募してきたのが、予想外に幅広い問題に対処できるこの万能ソリューションに突然置き換えられます。
ただし、ZK-SNARK は、3 つの非常に強力な汎用プリミティブの最初の 1 つにすぎません。これらのプロトコルは非常に強力なので、それらについて考えると、遊戯王の非常に強力なカードのセット、つまり私が子供の頃にプレイしたカード ゲームおよびテレビ番組であるエジプトの神カードを思い出します。
エジプトの神のカードは 3 枚の非常に強力なカードであり、伝説によれば、これらのカードを作成するプロセスは致命的である可能性があり、その力により決闘での使用が禁止されています。同様に、暗号化には、次の 3 つのエジプトの神のプロトコルのセットがあります。
ZK-SNARK とは何ですか?またその仕組みは何ですか?
ZK-SNARK は、当社がすでに保有している 3 つのプロトコルのうち、より高いレベルの成熟度を備えたプロトコルの 1 つです。過去 5 年間で証明者の速度と開発者の使いやすさが劇的に向上したことにより、ZK-SNARK はイーサリアムのスケーラビリティとプライバシー戦略の基礎となりました。ただし、ZK-SNARK には重要な制限があります。それを証明するにはデータを知る必要があります。 ZK-SNARK アプリケーションの各状態には、その状態への読み取りまたは書き込みを承認するために存在する必要がある一意の「所有者」が必要です。
この制限のない 2 番目のプロトコルは完全準同型暗号化 (FHE) で、データを参照せずに暗号化されたデータに対してあらゆる計算を実行できます。これにより、データとアルゴリズムを非公開に保ちながら、ユーザーの利益のためにユーザーのデータに対して計算を実行できます。
また、MACI などの投票システムを拡張して、ほぼ完璧なセキュリティとプライバシーを保証することもできます。 FHEは長らく非効率すぎて実用化できないと考えられていましたが、ようやく効率が良くなり実用化され始めています。
Cursive は、プライバシーを保護する共通利益の発見のために、二者間計算と完全準同型暗号化 (FHE) を活用するアプリケーションです。
ただし、FHE には制限があります。FHE に基づくどのテクノロジーでも、誰かが復号化キーを保持する必要があります。これは M-of-N の分散セットアップにすることができ、信頼された実行環境 (TEE) を使用して 2 番目の保護層を追加することもできますが、それでも制限があります。
次に、最初の 2 つの組み合わせよりもさらに強力な 3 番目のプロトコルである区別不能難読化が登場します。このテクノロジーはまだ成熟には程遠いですが、2020 年の時点で、標準的なセキュリティの前提に基づいて理論的に有効なプロトコルがあり、最近それらの実装を開始しました。
区別できない難読化により、プログラムの内部詳細をすべて隠しながら任意の計算を実行する「暗号化されたプログラム」を作成できます。簡単な例として、素数の署名にのみ秘密キーを使用できるように難読化されたプログラムに秘密キーを入れ、このプログラムを他の人に配布することができます。このプログラムを使用して任意の素数に署名できますが、キーを抽出することはできません。ただし、その機能はそれをはるかに超えています。ハッシュと組み合わせて、他の暗号化プリミティブなどを実装するために使用できます。
区別不可能な難読化ツールが実行できない唯一のことは、それ自体がコピーされるのを防ぐことです。ただし、現時点では、誰もが量子コンピューターを所有していることに依存するものではありますが、量子ワンショット署名という、より強力なテクノロジーが待機しています。
難読化とワンタイム署名を組み合わせることで、ほぼ完璧なトラストレスなサードパーティを構築できます。暗号化だけでは達成できず、依然としてブロックチェーンを必要とする唯一の目標は、検閲への耐性です。これらのテクノロジーはイーサリアム自体の安全性を高めるだけでなく、イーサリアム上にさらに強力なアプリケーションを構築することも可能にします。
これらのプリミティブがどのように機能を追加するかをよりよく理解するために、重要な例として投票を使用します。投票は、非常に強力な検証可能性やプライバシーなど、多くの複雑なセキュリティ特性を満たす必要があるため、興味深い問題です。強力なセキュリティ特性を備えた投票プロトコルは何十年も前から存在していますが、私たち自身でそれをより困難にし、二次投票、ペアごとに制限された二次ファンディング、クラスターマッチング二次ファンディングなどの任意の投票プロトコルを処理できる設計を要求することができます。 。言い換えれば、「カウント」ステップを任意の手順にしたいのです。
まず、投票結果をブロックチェーン上で公開するとします。これにより、公的検証可能性 (投票集計や資格ルールを含め、最終結果が正しいことを誰でも検証できます) と検閲耐性 (人々の投票を止めることができません) が得られます。しかし、私たちにはプライバシーがありません。
次に、ZK-SNARK を追加しました。これでプライバシーが確保されました。すべての投票は匿名であり、承認された有権者のみが投票できることが保証され、各有権者は 1 回だけ投票できます。
次に、投票が中央サーバーの復号キーで暗号化される MACI メカニズムを導入します。中央サーバーは、重複投票の排除や ZK-SNARK 証明結果の発行など、投票集計プロセスを担当します。これにより、以前の保証が維持されます (たとえサーバーが不正行為をしたとしても!) が、サーバーが正直であれば強制耐性の保証も追加されます。つまり、ユーザーは、たとえ望んでも、どのように投票したかを証明することができません。これは、ユーザーが自分の投票を証明することはできますが、その投票を相殺するために投票しなかったことを証明することはできないためです。これにより、贈収賄やその他の攻撃が防止されます。
FHE で投票集計を実行し、N/2-of-N しきい値の復号化計算を実行します。これにより、耐強制性の保証が 1-of-1 ではなく N/2-of-N に増加します。
投票集計プログラムを難読化し、承認された場合にのみ結果を出力できるように難読化プログラムを設計します。承認方法は、ブロックチェーンのコンセンサスの証明、ある種の作業証明、またはその両方の組み合わせになります。これにより、強制防止の保証はほぼ完璧になります。ブロックチェーンのコンセンサスの場合、バリデーターの 51% が共謀してクラックする必要があります。プルーフ・オブ・ワークの場合、全員が共謀したとしても、投票は別の方法で再集計されます。有権者の一部を試行する 個々の有権者を抽出するという行為も、非常に費用がかかるでしょう。プログラムに最終的な投票数にランダムな小さな調整を加えて、個々の有権者の行動を抽出する難易度をさらに高めることもできます。
量子コンピューティングに依存して、特定の種類の情報に対して署名を 1 回だけ使用できるようにするプリミティブであるワンタイム署名を追加しました。これにより、抗力の保証が真に完璧になります。
区別できない難読化は、他の強力なアプリケーションもサポートします。例えば：
- 分散型自律組織 (DAO)、オンチェーン オークション、および任意の内部秘密状態を持つその他のアプリケーション。
- 真に普遍的な信頼できるセットアップ: 誰かがキーを含む難読化されたプログラムを作成し、任意のプログラムを実行して出力を提供し、入力として hash(key, Program) をプログラムに入力することができます。このようなプログラムがあれば、誰でもプログラム 3 をそれ自体に組み込み、プログラムのプレキーと独自のキーを組み合わせて、セットアップを拡張できます。これを使用して、任意のプロトコルに対して 1-of-N の信頼できるセットアップを生成できます。
- ZK-SNARK の検証に必要な署名は 1 つだけです。これを実現するのは非常に簡単です。信頼できる環境をセットアップし、有効な ZK-SNARK がある場合にのみそのキーでメッセージに署名する難読化されたプログラムを誰かに作成してもらいます。
- 暗号化されたメモリプール: トランザクションの暗号化が非常に簡単になり、将来特定のオンチェーン イベントが発生した場合にのみ復号化できるようになります。これには、正常に実行された Verifiable Delay Function (VDF) も含まれる場合があります。
ワンタイム署名を使用すると、ブロックチェーンをファイナリティ反転に対する 51% の攻撃から免れることができますが、検閲攻撃の可能性は依然としてあります。ワンタイム署名のようなプリミティブにより量子通貨が可能になり、ブロックチェーンなしで二重支払いの問題が解決されますが、より複雑なアプリケーションの多くは依然としてチェーンを必要とします。
これらのプリミティブを十分に効率化できれば、世界中のほとんどのアプリケーションを分散化できます。主なボトルネックは、実装の正確性を検証することです。
いくつかの既存の研究へのリンクを次に示します。
- 識別不能難読化プロトコル (2021):識別不能難読化
- 難読化がイーサリアムにどのように役立つか: 難読化がイーサリアムにどのように役立つか
- ワンショット署名の最初に知られた構造: ワンショット署名の最初に知られた構造
- 難読化の実装の試み (1): 難読化の実装の試み (1)
- 難読化の実装の試み (2): 難読化の実装の試み (2)
やるべきことは何でしょうか?また、そのトレードオフは何ですか?
やるべきことはまだたくさんあり、区別できない難読化はまだ非常に未熟で、候補となる構築の実行は（それ以上ではないにせよ）驚くほど遅く、アプリケーションで使用するには時間がかかります。区別できない混乱には「理論上の」多項式時間がかかることが知られていますが、実際のアプリケーションでは宇宙の寿命よりも長く実行される可能性があります。最近のプロトコルでは実行時間がいくらか改善されましたが、日常的な使用にはオーバーヘッドがまだ高すぎます。ある実装者は実行時間を 1 年と見積もっていました。
量子コンピューターはまだ存在すらしていません。インターネット上で目にするすべての構成要素は、4 ビット以上の処理ができないプロトタイプであるか、まったく実質的な量子コンピューターではありません。量子パーツはあるかもしれませんが、 Shor のアルゴリズムや、Grover のアルゴリズムのような意味のある計算を実行することはできません。最近、「本物の」量子コンピューターがそう遠くないという兆候が見られます。しかし、たとえ「本物の」量子コンピューターがすぐに利用可能になったとしても、ラップトップや携帯電話で量子コンピューターを使用している一般の人が、強力な機関が楕円曲線暗号を解読できるようになるまでには、まだ数十年待たなければならない可能性があります。
区別できない難読化の場合、重要なトレードオフはセキュリティの前提にあり、特別な前提を使用するより根本的な設計があります。これらの設計は通常、より現実的な実行時間を実現しますが、特別な前提が破られる場合があります。時間が経つにつれて、格子の理解が深まり、簡単に破れない仮説を立てることができるようになるかもしれません。ただし、この道はより危険です。より保守的なアプローチは、セキュリティが「標準」の想定にまで低下していることが証明されているプロトコルを使用し続けることですが、これは、十分に高速に動作するプロトコルを入手するまでに時間がかかることを意味する可能性があります。
ロードマップの他の部分とどのように相互作用するのでしょうか?
非常に強力な暗号化は、次のようなゲームに革命をもたらす可能性があります。
- 検証が署名と同じくらい簡単な ZK-SNARK を取得できれば、集約プロトコルは必要なくなり、チェーン上で直接検証できるようになります。
- ワンタイム署名は、より安全なプルーフ・オブ・ステーク・プロトコルを意味する可能性があります。
- 多くの複雑なプライバシー プロトコルは、プライバシーを保護するイーサリアム仮想マシン (EVM) に簡単に置き換えることができます。
- 暗号化されたメモリ プールの実装が容易になります。
イーサリアムの L1 は本質的にセキュリティの前提において保守的である必要があるため、最初はその利点がアプリケーション層で発生します。ただし、ZK-SNARK の出現の場合のように、アプリケーション層だけを使用すると破壊的になる可能性があります。