VitalikによるEthereumの可能な未来（6）：The Splurge

Ethereumプロトコル設計の約半分はさまざまなタイプのEVM改良に関するもので、残りはさまざまなニッチなテーマで構成されています。これが「Splurge（繁栄）」の意味です。

原文タイトル：《Possible futures of the Ethereum protocol, part 6: The Splurge》

執筆：Vitalik Buterin

翻訳：zhouzhou，BlockBeats

以下は原文内容（読みやすさのために一部編集されています）：

いくつかの事柄は単一のカテゴリに分類するのが難しく、Ethereumプロトコル設計には多くの「細部」がEthereumの成功にとって非常に重要です。実際、内容の約半分はさまざまなタイプのEVM改良に関するもので、残りはさまざまなニッチなテーマで構成されています。これが「Splurge（繁栄）」の意味です。

2023年ロードマップ：Splurge

Splurge：主要な目標

• EVMを高性能かつ安定した「最終形態」にする
• アカウント抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントを利用できるようにする
• 取引手数料経済を最適化し、スケーラビリティを高めつつリスクを低減する
• 先進的な暗号技術を探求し、Ethereumを長期的に大幅に改善する

EVM改良

どんな問題を解決するのか？

現在のEVMは静的解析が困難であり、効率的な実装やコードの形式的検証、さらなる拡張が難しくなっています。また、EVMの効率は低く、多くの高度な暗号技術を実装するのが難しい（明示的なプリコンパイルによるサポートが必要）。

それは何で、どのように機能するのか？

現在のEVM改良ロードマップの第一歩はEVM Object Format（EOF）で、次のハードフォークで導入予定です。EOFは一連のEIPで、新しいEVMコードバージョンを規定し、多くの独自の特徴を持っています。最も顕著なのは：

• コード（実行可能だがEVMから読み取り不可）とデータ（読み取り可能だが実行不可）の分離
• 動的ジャンプの禁止、静的ジャンプのみ許可
• EVMコードがガスに関連する情報を観察できなくなる
• 新しい明示的なサブルーチン機構の追加

EOFコードの構造

Splurge：EVM改良（続き）

旧式コントラクトは引き続き存在し作成可能ですが、最終的には段階的に廃止される可能性があり（EOFコードへの強制変換もあり得る）、新しいコントラクトはEOFによる効率向上の恩恵を受けます——まずサブルーチン機能によるバイトコードの縮小、次にEOF特有の新機能やガスコスト削減です。

EOF導入後はさらなるアップグレードが容易になり、現在最も進んでいるのはEVM Modular Arithmetic eXtensions（EVM-MAX）です。EVM-MAXはモジュラー演算専用の新しい操作群を作り、他のオペコードからアクセスできない新しいメモリ空間に配置します。これによりMontgomery乗算などの最適化が可能になります。

新しいアイデアとしては、EVM-MAXとSingle Instruction Multiple Data（SIMD）機能の組み合わせがあります。SIMDはEthereumの理念として長く存在し、最初はGreg ColvinのEIP-616で提案されました。SIMDは多くの暗号技術（ハッシュ関数、32ビットSTARKs、格ベース暗号など）を高速化でき、EVM-MAXとSIMDの組み合わせは両者の性能志向拡張を自然なペアにします。

組み合わせた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コードでは以下のような動作：

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

実際の実装では、これが並列処理されます。

• XOR、AND、OR、NOT、SHIFT（循環・非循環含む）も追加可能、少なくとも2のべき乗の法数に対して。同時にISZERO（EVMメインスタックに出力をプッシュ）も追加。これにより楕円曲線暗号、小規模フィールド暗号（Poseidon、Circle STARKsなど）、従来のハッシュ関数（SHA256、KECCAK、BLAKEなど）、格ベース暗号が実現可能。他のEVMアップグレードもあり得るが、現時点では注目度は低い。

既存の研究リンク

• EOF: 
• EVM-MAX: 
• SIMD: 

残された作業とトレードオフ

現在、EOFは次のハードフォークで導入予定です。最後の瞬間に削除される可能性も常にあります——過去のハードフォークでも機能が一時的に削除されたことがありますが、そうすると大きな課題に直面します。EOFを削除すると、今後のEVMアップグレードはEOFなしで行う必要があり、可能ではあるものの困難が増します。

EVMの主なトレードオフはL1の複雑さとインフラの複雑さです。EOFはEVM実装に多くのコードを追加する必要があり、静的コードチェックも比較的複雑です。しかし、その代わりに高級言語やEVM実装の簡素化などのメリットがあります。Ethereum L1の継続的な改良を優先するロードマップはEOFを含み、その上に構築すべきだと言えるでしょう。

重要な作業は、EVM-MAX＋SIMDのような機能を実装し、さまざまな暗号操作のガス消費をベンチマークすることです。

ロードマップの他の部分との相互作用は？

L1がEVMを調整するとL2も調整しやすくなります。両者が同期調整しないと非互換が生じ、不利益をもたらします。また、EVM-MAXとSIMDは多くの証明システムのガスコストを下げ、L2をより効率的にします。さらに、より多くのプリコンパイルを同等のEVMコードで置き換えることが容易になり、効率に大きな影響を与えずに済む可能性があります。

アカウント抽象化

どんな問題を解決するのか？

現在、取引はECDSA署名による1つの方法でしか検証できません。当初、アカウント抽象化はこれを超え、アカウントの検証ロジックを任意のEVMコードにできるようにすることを目指していました。これにより、以下のような多様な応用が可能になります：

• 耐量子暗号への切り替え
• 古い鍵のローテーション（広く推奨されるセキュリティプラクティス）
• マルチシグウォレットやソーシャルリカバリーウォレット
• 低価値操作用の鍵と高価値操作用の別の鍵（または鍵セット）の使い分け

プライバシープロトコルがリレーなしで動作できるようになり、複雑さが大幅に低減し、中央依存点が排除されます。

2015年にアカウント抽象化が提案されて以来、その目標は多くの「利便性目標」も含むように拡大しました。例えば、ETHを持たないがERC20を持つアカウントがERC20でガスを支払えるようにするなどです。以下はこれらの目標のまとめ図です：

MPC（マルチパーティ計算）は40年以上の歴史を持つ技術で、鍵を複数の部分に分けて複数のデバイスに保存し、暗号技術を使って鍵部分を直接組み合わせることなく署名を生成します。

EIP-7702は次のハードフォークで導入予定の提案で、EIP-7702はアカウント抽象化の利便性をすべてのユーザー（EOAユーザーも含む）に提供するという認識の高まりから生まれました。短期的にすべてのユーザー体験を改善し、2つのエコシステムへの分裂を回避することを目的としています。

この作業はEIP-3074から始まり、最終的にEIP-7702となりました。EIP-7702はアカウント抽象化の「利便機能」をすべてのユーザー、つまり今日のEOA（外部所有アカウント、ECDSA署名で制御されるアカウント）にも提供します。

図から分かるように、一部の課題（特に「利便性」課題）はMPCやEIP-7702のような漸進的技術で解決できますが、アカウント抽象化提案の主要なセキュリティ目標は、元の問題を遡って解決することでしか実現できません：スマートコントラクトコードによる取引検証の制御です。これが未だ実現されていない理由は、安全な実装が課題だからです。

それは何で、どのように機能するのか？

アカウント抽象化の核心はシンプルです：スマートコントラクトが取引を発行できるようにする（EOAだけでなく）。複雑さのすべては、分散型ネットワーク維持に優しい方法でこれを実現し、DoS攻撃を防ぐことにあります。

典型的な重要課題は「多重無効化問題」です：

もし1000個のアカウントの検証関数が単一の値Sに依存しており、現在のSの値でメモリプール内の取引がすべて有効なら、単一の取引でSの値を反転させると、メモリプール内の他のすべての取引が無効になります。これにより攻撃者は非常に低コストでメモリプールにゴミ取引を送り、ネットワークノードのリソースを詰まらせることができます。

長年の努力の末、機能拡張とDoSリスク制限を両立させるため、「理想的なアカウント抽象化」を実現する解決策が生まれました：ERC-4337です。

ERC-4337はユーザー操作の処理を2段階に分けます：検証と実行。すべての検証が先に処理され、すべての実行がその後に処理されます。メモリプールでは、ユーザー操作の検証段階が自身のアカウントのみを参照し、環境変数を読み取らない場合のみ受け入れられます。これにより多重無効化攻撃を防ぎます。また、検証ステップには厳格なガス制限も課されます。

ERC-4337は追加プロトコル標準（ERC）として設計されました。当時Ethereumクライアント開発者はMergeに集中しており、他の機能に手が回らなかったためです。そのためERC-4337はユーザー操作というオブジェクトを使い、通常の取引ではありません。しかし最近、少なくとも一部をプロトコルに書き込む必要性が認識されています。

主な理由は2つです：

1. EntryPointコントラクトの本質的な非効率性：各バンドルで約100,000ガスの固定オーバーヘッド、各ユーザー操作ごとに数千ガスの追加オーバーヘッド。
2. Ethereumの属性保証の必要性：インクルージョンリストによるインクルージョン保証をアカウント抽象化ユーザーにも転送する必要がある。

さらにERC-4337は2つの機能を拡張しています：

• Paymasters（支払い代理）：あるアカウントが他のアカウントの手数料を支払う機能。これは検証段階が送信者アカウントのみアクセス可能というルールに反するため、安全性を確保するために特別な処理が導入されています。
• Aggregators（集約者）：BLS集約やSNARKベースの集約など、署名集約をサポート。Rollupで最高のデータ効率を実現するために必要です。

既存の研究リンク

• アカウント抽象化の歴史に関する講演：
• ERC-4337：
• EIP-7702：
• BLSWalletコード（集約機能使用）：
• EIP-7562（プロトコルに書き込むアカウント抽象化）：
• EIP-7701（EOFベースのプロトコルアカウント抽象化）：

残された作業とトレードオフ

現在主に解決すべきは、アカウント抽象化を完全にプロトコルに導入する方法です。最近人気のプロトコルアカウント抽象化EIPはEIP-7701で、この提案はEOF上でアカウント抽象化を実現します。アカウントは検証用の独立したコード部分を持つことができ、設定されていれば、そのアカウントからの取引の検証ステップで実行されます。

この方法の魅力は、ネイティブアカウント抽象化の2つの等価な見方を明確に示すことです：

1. EIP-4337をプロトコルの一部とする
2. 署名アルゴリズムがEVMコード実行である新しいEOAタイプ

検証中に実行可能なコードの複雑さに厳格な制限を設ける——外部状態へのアクセスを許可せず、初期段階ではガス制限も量子耐性やプライバシー保護アプリに無効なほど低く設定する——場合、この方法の安全性は非常に明確です：ECDSA検証を同等の時間を要するEVMコード実行に置き換えるだけです。

しかし、時間が経つにつれ、これらの制限を緩和する必要があります。プライバシー保護アプリがリレーなしで動作できることや量子耐性は非常に重要です。そのため、検証ステップが極端に簡素であることを要求せず、より柔軟にDoSリスクを解決する方法を見つける必要があります。

主なトレードオフは「少数の人しか満足しない案を早く書く」か「より理想的な案を得るために長く待つ」かです。理想的な方法は何らかのハイブリッドでしょう。ハイブリッドの一つは、いくつかのユースケースを早く書き、他のユースケースの探求に時間を残すことです。もう一つはL2でより野心的なアカウント抽象化バージョンを先に展開することです。ただし、L2チームが提案採用に自信を持たないと実装に踏み切れず、L1や他のL2が将来互換案を採用できる保証が必要です。

もう一つ明確に考慮すべき応用はキーストアアカウントです。これらはL1または専用L2にアカウント関連状態を保存し、L1や互換L2で利用可能です。これを効果的に行うには、L2がL1SLOADやREMOTESTATICCALLのようなオペコードをサポートする必要があり、L2のアカウント抽象化実装もこれらの操作をサポートする必要があります。

ロードマップの他の部分との相互作用は？

インクルージョンリストはアカウント抽象化取引をサポートする必要があります。実際には、インクルージョンリストの要件と分散型メモリプールの要件は非常に似ていますが、インクルージョンリストの方が柔軟性がやや高いです。また、アカウント抽象化実装はL1とL2でできるだけ調整すべきです。将来的に大多数のユーザーがキーストアRollupを使うことを期待するなら、アカウント抽象化設計もそれを前提にすべきです。

EIP-1559改良

どんな問題を解決するのか？

EIP-1559は2021年にEthereumで有効化され、平均ブロックインクルージョン時間を大幅に改善しました。

待機時間

しかし、現在のEIP-1559実装にはいくつかの問題があります：

1. 数式にやや欠陥がある：50%のブロックを目標にしているわけではなく、分散により約50-53%の満杯ブロックを目指している（これは数学者が「算術-幾何平均不等式」と呼ぶものに関係）。
2. 極端な状況での調整が十分に速くない。

後にblob用に使われた数式（EIP-4844）は第一の問題を解決するために設計され、全体的にもよりシンプルです。しかしEIP-1559自体もEIP-4844も第二の問題を解決しようとはしていません。そのため現状は2つの異なるメカニズムが混在する中間状態であり、時間とともに両方とも改良が必要だという意見もあります。

さらに、EIP-1559とは無関係なEthereumリソース価格設定の弱点もありますが、EIP-1559の調整で解決可能です。主な問題の一つは平均と最悪ケースの差です：Ethereumのリソース価格は最悪ケース（1ブロックで全ガス消費が1リソースを占有）に対応できるよう設定されますが、実際の平均使用量ははるかに低く、非効率を生みます。

多次元ガスとは何で、どう機能するのか？

これらの非効率問題の解決策は多次元ガスです：異なるリソースごとに異なる価格と制限を設けます。この概念は技術的にはEIP-1559とは独立していますが、EIP-1559があることで実現が容易になります。EIP-1559がなければ、複数リソース制約を持つブロックの最適なパッキングは複雑な多次元ナップサック問題になります。しかしEIP-1559があれば、ほとんどのブロックはどのリソースでも満杯にならないため、「十分な手数料を払う取引を受け入れる」だけで十分です。

現在、実行とデータブロブ用に多次元ガスがあります。原則として、これをさらに多次元（calldata、状態読み書き、状態サイズ拡張など）に拡張できます。

EIP-7706はcalldata専用の新しいガス次元を導入します。同時に、3種類のガスを1つの（EIP-4844スタイルの）フレームワークに統一し、多次元ガスメカニズムを簡素化、EIP-1559の数学的欠陥も解決します。EIP-7623はより厳密な解決策で、平均と最悪ケースのリソース問題に対し、全く新しい次元を導入せずに最大calldataを厳しく制限します。

さらなる研究方向は更新速度問題の解決です。EIP-4844メカニズムが導入した重要な不変条件（長期的に平均使用量が目標値に近づく）を維持しつつ、より高速な基礎料金計算アルゴリズムを探すことです。

既存の研究リンク

• EIP-1559 FAQ: 
• EIP-1559の実証分析: 
• 高速調整を許可する改良提案: 
• EIP-4844 FAQの基礎料金メカニズムに関する部分: 
• EIP-7706: 
• EIP-7623: 
• 多次元ガス: 

残された作業とトレードオフは？

多次元ガスの主なトレードオフは2つあります：

1. プロトコルの複雑さ増加：多次元ガス導入でプロトコルが複雑化します。
2. ブロックを満杯にする最適アルゴリズムの複雑さ増加：ブロック容量を最適に埋めるアルゴリズムも複雑になります。

calldataに関してはプロトコルの複雑さは比較的小さいですが、EVM内部のガス次元（ストレージ読み書きなど）では複雑さが増します。問題は、ユーザーがガス制限を設定するだけでなく、コントラクトが他のコントラクトを呼び出す際にも制限を設定することです。現状では、これらは単一次元でしか設定できません。

単純な解決策は、多次元ガスをEOF内部だけで利用可能にすることです。EOFは他のコントラクト呼び出し時にガス制限を設定できません。非EOFコントラクトはストレージ操作時にすべてのガスタイプの料金を支払う必要があります（例えば、SLOADがブロックのストレージアクセスガス制限の0.03%を占める場合、非EOFユーザーも実行ガス制限の0.03%分を支払う）。

多次元ガスのさらなる研究は、これらのトレードオフを理解し、理想的なバランス点を見つけるのに役立ちます。

ロードマップの他の部分との相互作用は？

多次元ガスの成功実装により、特定の「最悪ケース」リソース使用が大幅に削減され、STARKedハッシュベースのバイナリツリーなどのニーズに対応するための性能最適化圧力が減少します。状態サイズ増加に明確な目標を設定することで、クライアント開発者が将来の計画や要件見積もりを容易に行えます。

前述の通り、EOFの存在により、ガスが観測不可という特性から、より極端な多次元ガスの実装が容易になります。

検証可能遅延関数（VDFs）

どんな問題を解決するのか？

現在、EthereumはRANDAOベースのランダム性を使って提案者を選出しています。RANDAOのランダム性は、各提案者が事前にコミットした秘密を公開し、その秘密をランダム性に混ぜることで機能します。

各提案者は「1ビットの操作権」を持ちます：現れないことでランダム性を変えられます（コストあり）。この方式は提案者選出には合理的ですが、ランダム性を必要とするオンチェーンアプリには理想的ではありません。理想的には、より堅牢なランダム性ソースを見つけるべきです。

VDFとは何で、どう機能するのか？

検証可能遅延関数は、並列化で高速化できない順次計算のみ可能な関数です。単純な例は繰り返しハッシュ：for i in range(10**9): x = hash(x)。出力結果をSNARKで正しさ証明し、ランダム値として使えます。

この発想は、時刻Tで利用可能な情報を入力に選び、T時点では出力が未知であることです：誰かが完全に計算を実行した後、T以降にのみ出力が得られます。誰でも計算できるため、結果を隠すことはできず、操作もできません。

VDFの主なリスクは予期せぬ最適化です：誰かが予想より速く関数を実行し、T時点で公開される情報を操作できることです。

予期せぬ最適化は2つの方法で起こり得ます：

1. ハードウェア加速：誰かが既存ハードウェアより速いASICを作る。
2. 予期せぬ並列化：誰かが関数を並列化してより速く実行する方法を見つける（たとえ100倍のリソースが必要でも）。

成功するVDFの構築は、この2つの問題を回避しつつ、実用的な効率を維持することです（例えば、ハッシュベース手法はリアルタイムでSNARK証明するには重いハードウェアが必要）。ハードウェア加速は、公益参加者が最適に近いVDF ASICを自作・配布することで通常解決されます。

既存の研究リンク

• VDF研究サイト: 
• EthereumにおけるVDF攻撃の考察（2018年）: 
• 提案されたVDF MinRootへの攻撃: 

残された作業とトレードオフは？

現時点でEthereum研究者のすべての要件を満たすVDF構造はありません。こうした関数を見つけるにはさらなる研究が必要です。もし見つかれば、主なトレードオフは導入するかどうか：機能性とプロトコル複雑性・セキュリティリスクの単純なトレードオフです。

VDFが安全だと考えても、最終的に安全でなかった場合、実装方法によっては安全性がRANDAO仮定（攻撃者ごとに1ビット操作権）やそれよりやや悪い状態に退化します。したがって、VDFが失敗してもプロトコルは壊れませんが、それに強く依存するアプリや新機能は壊れます。

ロードマップの他の部分との相互作用は？

VDFはEthereumプロトコル内で比較的自己完結した構成要素であり、提案者選出のセキュリティ向上以外にも、（i）ランダム性を必要とするオンチェーンアプリや（ii）暗号化メモリプールにも応用があります。ただし、VDFベースの暗号化メモリプールには追加の暗号発見が必要です。

覚えておくべきポイントは、ハードウェアの不確実性を考慮すると、VDF出力生成と必要時点の間に「余裕」が生じることです。つまり、情報は数ブロック前に利用可能になります。これは許容可能なコストですが、単一スロットファイナリティや委員会選出設計では考慮すべきです。

難読化とワンタイム署名：暗号技術の遠い未来

どんな問題を解決するのか？

Nick Szaboの最も有名な論文の一つは、1997年に書かれた「God Protocol」についてのものです。この論文で彼は、多くの多者アプリケーションが「信頼できる第三者」に依存してインタラクションを管理していると指摘しました。彼の見解では、暗号技術の役割は、実際には特定の参加者を信頼せずに同じ仕事をする、シミュレートされた信頼できる第三者を作ることです。

これまでのところ、この理想は部分的にしか実現できていません。必要なのが、データと計算が停止・検閲・改ざんできない透明な仮想マシンだけで、プライバシーが目標でなければ、ブロックチェーンで実現できます（スケーラビリティは限定的ですが）。

プライバシーが目標の場合、最近まで特定アプリごとに個別のプロトコルを開発するしかありませんでした：基本認証用のデジタル署名、匿名性用のリング署名やリンク可能リング署名、信頼できる発行者の仮定下でのIDベース暗号、チャーム型電子マネー用のブラインド署名など。この方法では新しいアプリごとに多大な作業が必要です。

2010年代、私たちは初めて異なる、より強力な方法を垣間見ました。この方法はプログラマブル暗号技術に基づいています。各アプリごとに新プロトコルを作る代わりに、強力な新プロトコル——具体的にはZK-SNARKs——を使い、任意のプログラムに暗号保証を追加できます。

ZK-SNARKsは、ユーザーがデータに関する任意の主張を証明でき、証明は（i）検証が容易で、（ii）主張以外のデータを一切漏らしません。これはプライバシーとスケーラビリティの両面で大きな進歩であり、AIにおけるトランスフォーマーの登場に匹敵します。何千人年ものアプリ特化作業が、想定外の幅広い問題に対応できるこの汎用ソリューションに置き換えられました。

しかし、ZK-SNARKsは同様に強力な3つの汎用プリミティブのうちの1つに過ぎません。これらのプロトコルは非常に強力で、私が子供の頃遊んだカードゲーム・アニメ「遊☆戯☆王」のエジプト神カードを思い出させます。

エジプト神カードは非常に強力な3枚のカードで、作成過程が致命的であるという伝説があり、その強さゆえにデュエルでの使用は禁止されています。同様に、暗号技術にもこの3つのエジプト神プロトコルがあります：

ZK-SNARKsとは何で、どう機能するのか？

ZK-SNARKsは3つのプロトコルのうち、最も成熟度が高いものです。過去5年間で証明者の速度と開発者フレンドリーさが大幅に向上し、Ethereumのスケーラビリティとプライバシー戦略の基盤となりました。しかし、ZK-SNARKsには重要な制限があります：証明するにはデータを知っている必要があります。各ZK-SNARKアプリの状態には唯一の「所有者」が必要で、その人が状態の読み書きを承認する必要があります。

この制限がない2番目のプロトコルは完全準同型暗号（FHE）です。FHEはデータを見ずに暗号化データ上で任意の計算を行えます。これにより、ユーザーの利益のためにユーザーデータ上で計算しつつ、データとアルゴリズムの両方を秘密にできます。

また、MACIのような投票システムを拡張し、ほぼ完璧なセキュリティとプライバシー保証を得ることもできます。長らくFHEは効率が低すぎて実用化できないと考えられていましたが、今や十分に高速化され、実用アプリも登場し始めています。

Cursiveは、双方計算と完全準同型暗号（FHE）を使ったプライバシー保護の共通関心発見アプリです。

ただし、FHEにも制限があります：FHEベース技術では誰かが復号鍵を持つ必要があります。これはM-of-N分散設定にでき、Trusted Execution Environment（TEE）で第2層防御も可能ですが、やはり制限です。

3つ目のプロトコルは、前2つの組み合わせよりも強力です：不可区別難読化（indistinguishability obfuscation）。この技術はまだ成熟には遠いですが、2020年時点で標準的なセキュリティ仮定に基づく理論的に有効なプロトコルが得られ、最近は実装も始まっています。

不可区別難読化は「暗号化プログラム」を作成でき、任意の計算を実行しつつ、プログラムの内部詳細をすべて隠します。簡単な例として、秘密鍵を難読化プログラムに入れ、素数にしか署名できないようにし、このプログラムを他人に配布できます。彼らは素数に署名できますが、鍵を抽出できません。しかし、これは一例に過ぎません。ハッシュと組み合わせれば、他の暗号プリミティブやさらに多くの機能を実現できます。

不可区別難読化プログラムが唯一できないのは、自身のコピー防止です。ただし、これについても、すべての人が量子コンピュータを持つことを前提にした、より強力な技術が将来登場する可能性があります：量子ワンショット署名（quantum one-shot signatures）です。

難読化とワンタイム署名を組み合わせることで、ほぼ完璧な信頼不要の第三者を構築できます。暗号技術だけでは実現できない唯一の目標は、ブロックチェーンによる検閲耐性の保証です。これらの技術はEthereum自体をより安全にするだけでなく、その上により強力なアプリを構築できます。

これらのプリミティブがどのように追加能力をもたらすかを理解するため、投票を例にします。投票は非常に強い検証性とプライバシーなど多くの複雑なセキュリティ属性が必要な興味深い問題です。強いセキュリティ属性を持つ投票プロトコルは数十年前から存在しますが、任意の投票プロトコル（二次投票、ペア制限付き二次資金調達、クラスターマッチング二次資金調達など）にも対応できる設計を目指します。つまり、「集計」ステップを任意のプログラムにしたいのです。

まず、投票結果をブロックチェーン上で公開すると仮定します。これで公開検証性（誰でも最終結果の正しさを検証可能）と検閲耐性（投票妨害不可）は得られますが、プライバシーはありません。

次にZK-SNARKsを追加し、各票が匿名でありつつ、認可された有権者だけが一度だけ投票できることを保証します。

さらにMACIメカニズムを導入し、投票は中央サーバーの復号鍵で暗号化されます。中央サーバーは重複票の除外など集計処理を行い、ZK-SNARKで結果を証明します。これにより、サーバーが不正をしても保証が維持され、サーバーが誠実なら強制防止保証（ユーザーが自分の投票を証明できない）が追加されます。ユーザーは投票を証明できますが、その票を打ち消す投票をしていないことは証明できません。これにより買収やその他の攻撃を防ぎます。

FHEで集計を行い、N/2-of-N閾値復号計算を行います。これにより強制防止保証はN/2-of-Nに向上します。

集計プログラムを難読化し、認可があった場合のみ結果を出力するよう設計します。認可方法はブロックチェーンコンセンサスの証明や何らかのPoW、またはその組み合わせです。これにより強制防止保証はほぼ完璧になります：ブロックチェーンコンセンサスの場合、検証者の51%が共謀しない限り破られません。PoWの場合、すべて共謀しても個別有権者の行動抽出は非常に高コストです。最終集計結果に小さなランダム調整を加え、抽出難度をさらに高めることもできます。

ワンタイム署名を追加します。これは量子計算に依存するプリミティブで、特定タイプの情報に対して一度だけ署名できます。これにより強制防止保証が真に完璧になります。

不可区別難読化は他にも強力な応用をサポートします。例えば：

1. DAO、オンチェーンオークション、その他任意の内部秘密状態を持つアプリ
2. 真の汎用信頼設定：誰かが鍵を含む難読化プログラムを作成し、任意のプログラムを実行して出力を提供、hash(key, program)を入力にプログラムに渡す。これにより、誰でも自身のプログラムを入れて事前鍵と自分の鍵を組み合わせて設定を拡張でき、あらゆるプロトコルの1-of-N信頼設定に利用可能。
3. ZK-SNARKsの検証を署名1つで実現：信頼できる環境で、誰かが有効なZK-SNARKの場合のみ鍵で署名する難読化プログラムを作成すれば簡単に実現。
4. 暗号化メモリプール：暗号化取引が簡単になり、将来のオンチェーンイベント発生時のみ復号可能。これにはVDFの成功実行も含められる。

ワンタイム署名を使えば、ブロックチェーンは最終性反転の51%攻撃から守られます（検閲攻撃は依然可能）。ワンタイム署名のようなプリミティブにより量子通貨も可能となり、ブロックチェーンなしで二重支払い問題を解決できます（ただし、より複雑なアプリには依然としてチェーンが必要）。

これらのプリミティブが十分に効率化されれば、世界の大半のアプリが分散化可能になります。主なボトルネックは実装の正しさ検証です。

既存の研究リンク：

• 不可区別難読化プロトコル（2021）: 
• 難読化がEthereumにどう役立つか: 
• 最初に知られたワンタイム署名構造: 
• 難読化の試み実装（1）: 
• 難読化の試み実装（2）: 

残された作業とトレードオフは？

やるべきことはまだ多く、不可区別難読化は非常に未成熟です。候補構造の実行速度は驚くほど遅く（それ以上かもしれません）、アプリで使うには現実的ではありません。不可区別難読化は「理論上」多項式時間ですが、実際には宇宙の寿命より長いかもしれません。最近のプロトコルは実行時間が改善されましたが、それでも通常利用には遅すぎます：ある実装者は1年の実行時間を見積もっています。

量子コンピュータはまだ存在しません。ネット上で見かける構造は、4ビット以上の計算ができないプロトタイプか、実質的な量子コンピュータではありません。最近、「本物の」量子コンピュータが近いという兆しもありますが、一般人がノートPCやスマホで量子コンピュータを使えるようになるには、強力な機関が楕円曲線暗号を破れる日よりさらに数十年かかるでしょう。

不可区別難読化の重要なトレードオフはセキュリティ仮定です。特殊仮定を使ったよりアグレッシブな設計も存在します。これらは現実的な実行時間を持つことが多いですが、特殊仮定は時に破られることがあります。時間が経てば格理論の理解が進み、破られにくい仮定が提案されるかもしれませんが、この道はリスクが高いです。より保守的な方法は「標準」仮定に安全性が帰着できるプロトコルを使うことですが、十分高速なプロトコルが得られるまで時間がかかるかもしれません。

ロードマップの他の部分との相互作用は？

極めて強力な暗号技術はゲームチェンジャーになり得ます。例えば：

1. ZK-SNARKsの検証が署名と同じくらい簡単になれば、集約プロトコルは不要になり、チェーン上で直接検証できます。
2. ワンタイム署名により、より安全なPoSプロトコルが実現できます。
3. 多くの複雑なプライバシープロトコルは、プライバシー保護EVM一つで代替可能になります。
4. 暗号化メモリプールがより実現しやすくなります。

最初はアプリ層で恩恵が現れるでしょう。EthereumのL1は本質的にセキュリティ仮定で保守的である必要があるからです。しかし、アプリ層だけの利用でもZK-SNARKs登場時のように破壊的なインパクトを持つ可能性があります。