ヴィタリック：イーサ・プロトコルの未来 - The Splurge

著者：Vitalik（イーサリアム創設者）、編纂者：Deng Tong（Golden Finance）

注：この記事は、イーサリアムの創設者であるVitalikが最近発表した、イーサリアムプロトコルの未来に関する連載記事の第6回：The Splurgeです。https://vitalik.eth.limo/general/2024/10/29/futures6.html" target="_blank">イーサリアムプロトコルの可能な未来、パート6：スプラージまた、パート5については「ヴィタリック：イーサリアム・プロトコルの可能な未来-粛清」、パート4は「Vitalik: The Future of Ether The Verge"にあります。パート3は"Vitalik: Ether's The Scourge Phase"で、パート2は"Vitalik: The Future of Ether The Verge"でご覧いただけます。"Vitalik: Etherプロトコルのサージ・フェーズはどのように進化すべきか"、パート1は「EtherのPoSで他に改善できること」です。

Justin DrakeとTim Beikoのフィードバックとコメントに感謝します。

カテゴリーに入れるのが難しいものもあります。Etherプロトコルの設計には、Etherの成功にとって価値のある「小さなこと」がたくさんありますが、大きなサブカテゴリーには当てはまりません。実際、それらの約半分は様々なEVMの改善に関連するもので、残りは様々なニッチなトピックで構成されています。それが「スプラッシュ」なのだ。

2023年までのロードマップ「The Splurge」

スプラージ：主な目標

• EVMを高性能と安定性の「究極の」状態にする。

• アカウント抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントから恩恵を受けられるようにする

• EVMをプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントから恩恵を受けられるようにする

• リスクを軽減しながら、取引手数料の経済性を最適化し、スケーラビリティを向上させる

• 長期的にイーサをより良くすることができる先進的な暗号技術を探求する

• イーサをadvanced crypto

EVM improvements

What problem does it solve?

今日のEVMは静的に分析することが難しく、効率的な実装を作成したり、コードを正式に検証したり、さらに長期的に拡張したりすることが困難です。さらに、非常に非効率的であるため、プリコンパイルによって明示的にサポートされない限り、多くの形式の高度な暗号を実装することは困難です。

それは何であり、どのように機能するのでしょうか？"list-style-type: disc;">

EOFコードの構造

旧式のコントラクトは存在し続け、作成することができますが、最終的には非推奨となる可能性があります（EOFコードへの変換を余儀なくされる可能性もあります）。新しいコントラクトは、EOFの効率向上の恩恵を受けるでしょう。まず、サブルーチン機能を使用してバイトコードがわずかに小さくなり、次に新しいEOF固有の機能、またはEOF固有のガスコストが削減されます。

EOFの導入により、さらなるアップグレードの導入が容易になった。現在最も完成度が高いのはEVM Modular Arithmetic Extension（EVM-MAX）で、モジュール演算用に設計された新しい演算セットを作成し、他のオペコードではアクセスできない新しいメモリ空間に配置します。これにより、モンゴメリ乗算などの最適化が可能になります。

より新しいアイデアは、EVM-MAXを単一命令複数データ（SIMD）機能と組み合わせることです。SIMDは、Greg ColvinのEIP-616以来、イーサネットのためのアイデアであり、ハッシュ関数、32ビットSTARK、およびドットマトリクスベースの暗号化を含む、多くの形式の暗号化を高速化するために使用することができます。

組み合わせたEIPのおおよその設計は、EIP-6690から始まり、

• (i)任意の奇数または(ii)任意の2のべき乗(最大2^>768)をモジュロとして許可します。768)をモジュロとして使用できます

• 各EVMMAXオペコード(add、sub、mul)について、3つの即値x、y、zを使用する代わりに、7つの即値を使用するバージョンを追加します: x_start、x_skip、y_start、y_skip、z_start、z_skip、count。Pythonのコードでは、これらのオペコードは以下の演算と等価です。

並列処理される実用的な実装を除きます。

• XOR, AND, OR, NOT, SHIFT (cyclic and acyclic)を、可能であれば少なくとも2の累乗に追加する。また、ISZERO (出力をEVMメインスタックにプッシュ)を追加します。

これは、楕円曲線暗号、小領域暗号(たとえば、Poseidon、circular 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を削除することはいつでも可能ですが -- 以前のハードフォークでは、最後の最後で機能が削除されました -- そうすることは困難な戦いです。EOFを削除することは、将来のEVMのアップグレードがEOFを使用できなくなることを意味します。

EVMの主なトレードオフは、L1の複雑さとインフラの複雑さです。EOFはEVM実装に追加するコードの量が多く、静的コードチェックは非常に複雑です。EOFはEVM実装に追加するコードが多く、静的コードチェックは非常に複雑です。しかし、それと引き換えに、高級言語の簡素化、EVM実装の簡素化、その他の利点が得られます。イーサネットL1の継続的な改善を優先するロードマップには、EOFが含まれ、その上に構築されるであろうことは言うまでもない。

主要な取り組みは、EVM-MAXにSIMDを加えたようなものを実装し、さまざまな暗号操作にどれだけのガスが必要かをベンチマークすることです。

他のロードマップとどのように相互作用するのでしょうか?

L1がEVMを調整することで、L2が同じことをしやすくなります。一方は調整、もう一方はいくつかの非互換性を生み出し、それ自体に欠点がある。さらに、EVM-MAX プラス SIMD は、多くの証明システムのガス コストを削減し、より効率的な L2 につながります。 また、効率にそれほど影響を与えずに同じタスクを実行できる EVM コードに置き換えることで、より多くのプリコンパイルを削除しやすくなります。

Account abstraction

どのような問題を解決するのか?

現在、トランザクションはECDSA署名という1つの方法でしか検証できません。当初、Account Abstractionはこれを超えて、アカウントの検証ロジックを任意のEVMコードにすることを目的としていました。

• Switching to quantum-resistant cryptography;

• Rotating old keys (widely considered a recommended security practice).

• 複数署名ウォレットとソーシャルリカバリーウォレット。

• 価値の低い操作に署名するために1つの鍵を使い、価値の高い操作に署名するために別の鍵（または鍵のセット）を使うこと。プライバシープロトコルをリピータなしで動作させることができます。img src="https://img.jinse.cn/7313720_watermarknone.png" title="7313720" alt="H1zgVd7sDijV9duJNZiafWujqp5akPkBOzgehpGW.jpeg">

  この場合のMPCとは、マルチパーティコンピューティングのことで、鍵を複数の部分に分割し、それらを複数のデバイスに保存し、鍵の部分を直接組み合わせることなく、暗号を使って署名を生成する40年前の技術です。

  EIP-7702は、次のハードフォークで導入が予定されているEIPです。eip-7702は、短期的にすべての人のユーザー体験を向上させ、2つのエコシステムへの分裂を避けるために、EOAユーザーを含むすべてのユーザーにアカウント抽象化の利便性を提供する必要性が認識され始めた結果です。この作業はEIP-3074で始まり、EOA（外部所有アカウント、すなわちECDSA署名によって制御されるアカウント）を含むすべてのユーザーがアカウント抽象化の「利便性機能」を利用できるようにしたEIP-7702で頂点に達しました。

  図表からわかるように、課題の一部（特に「利便性」の課題）は、マルチパーティコンピューティングやEIP-7702のようなインクリメンタルな技術によって解決できますが、アカウント抽象化の当初の提案のセキュリティ目標のほとんどは、スマートコントラクトコードがトランザクションの検証を制御できるようにするという、当初の問題に戻って解決することによってのみ解決できます。スマートコントラクトコードがトランザクション検証を制御できるようにすることである。スマートコントラクトのコードがトランザクションの検証を制御できるようにすることです。これがこれまで行われてこなかった理由は、これを安全に実装することが難しいからです。

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

  要するに、アカウントの抽象化はシンプルで、スマートコントラクト（EOAだけでなく）を介してトランザクションを開始できるようにすることです。全体の複雑さは、分散型ネットワークを維持し、サービス拒否攻撃を防ぐのに役立つ方法でこれを行うことから生まれます。

  重要な課題の例として、多重無効化問題があります。

  

  検証関数がすべてある単一の値Sに依存する1,000のアカウントがあり、メモリプール内にSの現在の値に基づいて有効なトランザクションがある場合、Sの値を反転させるトランザクションは、プール内の他のすべてのトランザクションを無効にする可能性があります。.これにより、攻撃者は非常に低コストでメモリプールをスパムし、ネットワークノードのリソースを詰まらせることができます。

  何年にもわたり、DoSのリスクを抑えつつ機能を拡張する試みが行われ、「理想的なアカウントの抽象化」を実現する方法についてのソリューションに合意しました：ERC-4337です。

  

  ERC-4337の仕組みは、ユーザーアクションの処理を2つのフェーズに分けるというものです：検証」と「実行」です。すべての検証が最初に処理され、次にすべての実行が処理されます。メモリ・プールでは、ユーザー・アクションの検証フェーズが、自身のアカウントにのみ触れ、環境変数を読み込まない場合にのみ、ユーザー・アクションが受け入れられます。これにより、多重無効化攻撃を防ぐことができる。認証ステップでは、厳格なガス制限も実施されます。

  ERC-4337は、イーサリアムのクライアント開発者がマージに集中し、他の機能を処理する余力がなかった時期に、追加プロトコル標準（ERC）として設計されました。ERC-4337が通常のトランザクションの代わりに独自のオブジェクト（ユーザーアクションと呼ばれる）を使用しているのはこのためです。しかし最近になって、少なくともその一部をプロトコルに含める必要性に気づきました。

  • EntryPoint 固有の契約としての非効率性：パケットごとの固定～10万ガスのオーバーヘッドと、ユーザーアクションごとの数千の追加料金；

  • Etherの属性(包含リストによって作成された包含保証など)がアカウント抽象化ユーザーに引き継がれるようにする必要があります。

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

  • Payers:アカウントが別のアカウントに代わって料金を支払うことを可能にする機能。機能。これは、検証段階では送信者のアカウント自体にしかアクセスできないというルールに違反するため、特別な処理を導入して、支払い者メカニズムを許可し、安全性を確保しました。

  • アグリゲーター：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 code (using aggregation): https://github.com/getwax/bls-wallet.="https://github.com/getwax/bls-wallet">https://github.com/getwax/bls-wallet

  EIP-7562（埋め込み口座の抽象化）：https://eips.ethereum.org/EIPS/eip-7562

  EIP-7701 (EOFベースの埋め込みAA): https://eips.ethereum.org/EIPS/eip-7701

  何が残っていて、トレードオフは何でしょうか?

  残された主な問題は、アカウントの抽象化をプロトコルに完全に組み込む方法です。アカウント抽象化のための最近人気のあるEIPは、EOFの上にアカウント抽象化を実装したEIP-7701です。アカウントは検証のために別のコードセクションを持つことができ、もしアカウントにそのコードセクションが設定されていれば、そのコードはそのアカウントのトランザクションの検証ステップ中に実行される。

  EIP-7701アカウントのEOFコード構造

  このアプローチの魅力的な点は、以下の2つの等価な方法を明確にすることです。

  • EIP-4337 だが、プロトコルの一部として

  • 署名アルゴリズムが

  認証中に実行可能なコードの複雑さを厳しく制限することから始める場合--外部状態へのアクセスを許可しない、あるいは量子耐性やプライバシー保持のアプリケーションで使用できないように、最初はガスの上限を低く設定することでもよい--、このアプローチの安全性は次のようになります。-- このアプローチの安全性は明らかです。ECDSAの検証を、同じような時間を要するEVMコードの実行に置き換えるだけです。しかし、プライバシー保護アプリケーションをリピータなしで動作させ、量子耐性を持たせることが重要であるため、時間の経過とともにこれらの制限を緩和する必要があります。そのためには、極めて単純な検証ステップを必要とすることなく、より柔軟な方法でDoSリスクに対処する方法を見つける必要があります。

  主なトレードオフは、「より長く待って、おそらくより最適なソリューションを得る」ことよりも、「より少ない人々が満足するものをできるだけ早く得る」ことのようです。理想的なアプローチは、ある種のハイブリッドかもしれません。ひとつのハイブリッドなアプローチは、いくつかのユースケースをより早く制定し、他のユースケースに対応するために時間をかけることだろう。もうひとつのアプローチは、より野心的なバージョンのアカウント抽象化をまずL2に展開することだろう。しかし、これには、L2チームが提案を採用することに意欲的に取り組むためには、L1および/または他のL2が後に互換性のあるものを採用することを確信する必要があるという課題が伴います。

  明示的に考慮する必要があるもう1つのアプリケーションは、L1または専用のL2にアカウントに関連する状態を保存するが、L1と互換性のあるL2で使用できるキーストアアカウントです。これを効果的に行うには、L2がL1SLOADやREMOTESTATICCALLなどのオペコードをサポートする必要があるかもしれません。

  ロードマップの残りの部分とどのように相互作用しますか?

  インクルードリストはアカウント抽象化トランザクションをサポートする必要があります。実際、インクルードリストと分散メモリプールの要件は、インクルードリストの方が若干柔軟ではありますが、非常に似ています。加えて、理想的には、アカウント抽象化の実装は、L1とL2でできる限り調和されるべきである。将来、ほとんどのユーザーがキーストア集約を使用すると予想される場合、アカウント抽象化の設計はこれを考慮すべきである。

  EIP-1559 の改善点

  どのような問題を解決するのか?

  EIP-1559は2021年にイーサでローンチされ、平均ブロックインクルード時間を大幅に改善しました。

  

  しかしながら、EIP-1559の現在の実装は、いくつかの点で不完全です。

  • 計算式に若干の欠陥があります。その代わりに、分散に基づいて完全なブロックの～50～53％を目標にします（これは数学者が「AM-GMの不等式」と呼ぶものに関連しています）。

  • 極端な条件下では十分に速く調整できません。

  後のblobの公式(EIP-4844)は、最初の問題を解決するために明確に設計され、一般的により簡潔でした。したがって、現状は2つの異なるメカニズムを含む混乱した中途半端な状態であり、どちらも時間をかけて改善する必要がある場合さえあります。

  そのほかにも、EIP-1559とは無関係ですが、EIP-1559を微調整することで対処できる、イーサのリソース価格設定の弱点があります。主要な問題は、平均的なケースと最悪のケースの違いです。イーサのリソース価格設定は、ブロックのガス消費全体が1つのリソースを占有する最悪のケースを処理するように設定されなければなりませんが、平均的なケースの使用量ははるかに低く、非効率につながります。

  

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

  これらの非効率性に対する解決策は、多次元ガスである。このコンセプトは技術的にはEIP-1559とは無関係ですが、EIP-1559によって簡単になります。EIP-1559がなければ、複数のリソース制約を持つブロックを最適にパッキングすることは、複雑な多次元バックパッキング問題です。EIP-1559がなければ、複数のリソース制約を持つブロックを最適にパッキングすることは、複雑な多次元バックパッキング問題です。EIP-1559があれば、ほとんどのブロックはどのリソースでも完全にロードされることはないので、「十分な報酬を支払うものは何でも受け入れる」というシンプルなアルゴリズムで十分です。

  私たちは今日、実行とブロブのための多次元ガスを持っています。原理的には、呼び出しデータ、状態の読み取り/書き込み、状態サイズの拡張など、より多くの次元を追加することができます。

  EIP-7706は、コールデータ用の新しいガス次元を導入します。また、すべての3つのタイプのガスを単一の(EIP-4844スタイルの)フレームに所属させることによって、多次元ガスメカニズムを単純化することによって、EIP-1559の数学的欠点に対処しています。

  EIP-7623は、まったく新しい次元を導入することなく、最大コールデータをより厳密に制約することによって、平均ケース対最悪ケースのリソース問題に対するより正確なソリューションです。

  さらなる方向性は、更新レートの問題に対処し、EIP-4844メカニズムによって導入された重要な不変性（すなわち、平均使用量が長期的に完全に目標に近いこと）を保持しながら、基本コストを計算するためのより高速なアルゴリズムを見つけることです。

  どのような研究がありますか？

  EIP-1559 FAQ: https://notes.ethereum.org/@vbuterin/eip-1559-faq

  EIP-1559Empirical Analysis: https://dl.acm.org/doi/10.1145/3548606.3559341

  迅速な調整を可能にする改善案：https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf

  EIP-4844のFAQ、基礎となる手数料メカニズムに関するセクション: https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#How-does-the-the-exponential-EIP-1559-blob-fee-adjustment-mechanism-work

  EIP-7706:https://eips.ethereum.org/EIPS/eip-7706

  EIP-7706:EIP-7623：https://eips.ethereum.org/EIPS/eip-7623

  多次元ガス：https://vitalik.eth.limo/general/2024/05/09/multidim.html

  
  

  残された課題とトレードオフとは？

  多次元ガスには、主に2つのトレードオフがあります。

プロトコルの複雑さは、calldataにとっては比較的小さな問題ですが、「EVM内部」のガス次元(たとえば、ストレージの読み取りと書き込み)にとってははるかに大きな問題です。コントラクトが他のコントラクトを呼び出すときに制限を設定するのだ。そして今日、彼らが制限を設定できる唯一の方法は、一次元的なものです。

この問題をなくす簡単な方法は、多次元ガスをEOF内部でのみ利用できるようにすることです。EOF以外のコントラクトは、ストレージ操作を実行するときに、すべてのタイプのガス料金を支払う必要があります（たとえば、SLOADがブロックストレージアクセスのガス制限の0.03%を使用する場合、EOF以外のユーザーも、ガス制限を実施するために、ガス制限の0.03%を請求されることになります）

多次元ガスに関する研究がもっと進めば、トレードオフを理解し、理想的なバランスを見つけ出すのに役立つでしょう。

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

多次元ガスの実装に成功すれば、「最悪のケース」のリソース使用量を大幅に削減することができます。したがって、たとえばSTARKedハッシュに基づくバイナリツリーをサポートするためにパフォーマンスを最適化するプレッシャーを軽減することができます。状態サイズの成長に対して厳しい目標を設定することで、クライアント開発者は将来の要件を計画し、見積もることが容易になります。

前述したように、EOFのGas unobservabilityのため、多次元Gasのより極端なバージョンは実装しやすくなります。

Verifiable Delay Function (VDF)

どのような問題を解決するのか?

今日、イーサネットは提案者を選択するのに RANDAO ベースのランダム性を使用しています。RANDAOベースのランダム性は、各提案者に事前に約束した秘密を明らかにするよう求め、明らかにされた秘密をそれぞれランダム性に混ぜることで機能します。このように、各提案者は「1ビット操作権」を持っている。つまり、現れないことでランダム性を（代償を払って）変えることができるのだ。これは提案者を見つけるには理にかなっている。なぜなら、1人をあきらめることで2人の新しい提案者を得られる人はほとんどいないからだ。しかし、ランダム性を必要とするオンチェーン・アプリケーションでは、これは機能しない。理想的には、より強固なランダム性の源を見つけることです。

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

検証可能な遅延関数は、逐次的にしか計算できず、並列化によって高速化できない関数です。簡単な例として、ハッシュの繰り返しがあります：(10**9)の範囲でiを計算します：x = hash(x)。出力はSNARKで正しさが証明されており、乱数値として使用できる。この考え方は、入力は時間Tの時点で利用可能な情報に基づいて選択され、出力は時間Tの時点ではわからないというものである。誰でも計算を実行できるため、結果を隠すことは不可能であり、したがって結果を操作する能力もありません。

検証可能な遅延関数の主なリスクは、偶発的な最適化です。誰かが予想よりもはるかに速く関数を実行する方法を見つけ出し、将来の出力に基づいて時刻Tで明らかにする情報を操作できるようになります。

• ハードウェアアクセラレーション：誰かが、計算ループが既存のハードウェアよりもはるかに速く動作するASICを作ります。

• 偶然の並列化：関数を並列化することで、100倍以上のリソースが必要であるにもかかわらず、より速く実行する方法を見つけた人がいます。

成功するVDFを作成するタスクは、効率を実用的なものに保ちながら、これらの問題の両方を回避することです(たとえば、ハッシュベースの手法の1つの問題は、リアルタイムのSNARK証明がハードウェアに非常に負荷がかかることです)。ハードウェアアクセラレーションは、多くの場合、公益参加者自身がVDFのために合理的に最適に近いASICを作成し、配布することで解決されます。

どのような研究がありますか？

vdfresearch.org:https://vdfresearch.org/

イーサで使われるVDFに対する2018年の攻撃についての考察：https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365

MinRoot（提案されているVDF）に対する攻撃：https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf

残された課題、そしてトレードオフとは？

現時点では、イーサネット研究者のすべてのニーズを完全に満たすVDF構造はありません。そのような機能を見つけるためには、より多くの作業を行う必要があります。もしそれがあれば、主なトレードオフは、それを含めるかどうかだけです。機能性とプロトコルの複雑さとセキュリティリスクの間の単純なトレードオフです。VDFが安全だと思っていたのに結局は安全でなかった場合、その実装方法によっては、セキュリティはRANDAOの想定（攻撃者1人あたり1ビットの操作）かそれ以下に格下げされることになる。そのため、VDFが危険にさらされたとしても、プロトコルは壊れませんが、アプリケーションや、VDFに大きく依存する新しいプロトコルの機能は壊れてしまいます。

ロードマップの残りの部分とどのように相互作用するのでしょうか?

VDFはイーサネットプロトコルの比較的自己完結的なコンポーネントですが、提案者の選択のセキュリティを向上させることに加えて、(i)ランダム性に依存するオンチェーンアプリケーション、および潜在的に(ii)暗号化されたメモリプールに使用することができます。

念頭に置いておくべきことの1つは、ハードウェアの不確実性を考慮すると、VDF出力が生成されるときとそれが必要とされるときとの間には、何らかの「ギャップ」があるということです。これは、情報が数ブロック先まで利用可能であることを意味します。これは許容可能なコストかもしれませんが、例えば、単一スロットのファイナリティや委員会が選択した設計の文脈で考慮されるべきです。

Obfuscation and One-time signatures: the future of cryptography

What problem does it solve?

ニック・シャボの最も有名な投稿のひとつは、1997年の「God Protocol」に関する記事でした。その中で彼は、マルチパーティアプリケーションはしばしば、相互作用を管理するために「信頼できるサードパーティ」に依存していると指摘しています。彼の見解では、暗号の役割は、実際に特定の参加者の信頼を必要とすることなく、同じ仕事をする信頼されたサードパーティをシミュレートすることです。

「数学的に信頼できるプロトコル」、ニック・サボ

へ。今のところ、私たちはこの理想に部分的にしか近づくことができません。必要なのは、データや計算を停止したり、検閲したり、改ざんしたりすることができない透明な仮想コンピューターだけで、プライバシーが目標ではないのであれば、ブロックチェーンは、スケーラビリティに制限があるとはいえ、それを実現することができる。基本的な認証のためのデジタル署名、原始的な匿名性のためのリング署名とリンク可能なリング署名、IDベースの暗号化（信頼できる発行者に関する特定の仮定の下でより簡単な暗号化を可能にする）、Chaumian e-cashのためのブラインド署名などである。このアプローチは、新しいアプリケーションごとに多くの作業を必要とする。

2010年代、私たちはプログラマブル暗号化に基づく、異なる強力なアプローチを初めて目にしました。新しいアプリケーションごとに新しいプロトコルを作成する代わりに、強力な新しいプロトコル、特にZK-SNARKを使用して、任意のアプリケーションに暗号保証を追加することができました。 ZK-SNARKは、(i)検証が容易であること、(ii)ステートメントそのもの以外のデータを明らかにしないことを証明する方法で、ユーザーが保持するデータに関する任意のステートメントを証明することを可能にする。これはプライバシーとスケーラビリティにとって大きな前進であり、私はこれをAIにおけるトランスフォーマー効果に例えている。何千人もの人々による1年分の用途に特化した作業が、突然、驚くほど幅広い問題を解決するために単純にプラグインできる汎用的なソリューションに置き換わるのです。

しかし、ZK-SNARKは、同様に非常に強力な3つの汎用プリミティブの最初のものに過ぎません。これらのプロトコルはとても強力で、私が子供の頃によく遊んだり見たりしていたカードゲームやテレビ番組である「遊戯王」の非常に強力なカードセット、「エジプト神カード」を思い起こさせます。エジプト神カードは非常に強力な3枚のカードで、伝説によれば、これを作ると命取りになり、あまりに強力なためデュエルでは使ってはいけないとされている。同様に暗号では、3つのエジプト神プロトコルがあります。

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

ZK-SNARKは、私たちがすでに持ち、高い成熟度に達している3つのプロトコルのうちの1つです。過去5年間で、ZK-SNARKは証明速度と開発者の使いやすさの面で大きな進歩を遂げ、イーサネットのスケーラビリティとプライバシー戦略の要となりました。しかし、ZK-SNARKには重要な制限があります。データを証明するためには、データを知っている必要があり、ZK-SNARKアプリケーションの各状態には、それに対する読み取りまたは書き込みを承認するために存在しなければならない「所有者」がいなければなりません。

このような制限がない2つ目のプロトコルは、完全同型暗号化（FHE）であり、暗号化されたデータを見ずに任意の計算を実行することができます。これにより、データとアルゴリズムを非公開にしたまま、ユーザーの利益のためにユーザーデータに対して計算を実行することができます。また、MACIのような投票システムを拡張して、完璧に近いセキュリティとプライバシーを実現することもできる。長い間、FHEは実用的な使用には効率が悪すぎると考えられていましたが、現在ではようやく十分に効率的になってきており、アプリケーションを見かけるようになってきています。

Cursiveは、2者間コンピューティングと共通の関心に対するFHEを使用する、プライバシーを保持する発見アプリです。

しかし、FHEには限界があります。FHEベースの技術には、誰かが復号鍵を保持する必要があります。これはM-of-Nの分散セットアップかもしれませんし、TEEを使用して2層目の防御を追加することもできますが、それでも限界です。

このため、他の2つを合わせたよりも強力な第3のプロトコル、「見分けがつかない難読化」があります。成熟には程遠いものの、2020年現在、私たちは標準的なセキュリティの仮定に基づいた理論的に有効なプロトコルを持ち、最近実装作業を始めています。識別不可能な難読化によって、任意の計算を実行する「暗号化されたプログラム」を作成することができ、プログラムの内部詳細がすべて隠される。簡単な例として、素数の署名にしか使えないように難読化したプログラムに秘密鍵を入れ、そのプログラムを他の人に配布することができる。他の人はそのプログラムを使ってどんな素数にも署名できるが、鍵を取り出すことはできない。しかし、それ以上のことができる。ハッシュと一緒に使うことで、他のどんな暗号プリミティブの実装にも使えるし、それ以上のこともできる。

難読化にできない唯一のことは、それ自体がコピーされるのを防ぐことです。

難読化装置にできない唯一のことは、自分自身がコピーされるのを防ぐことです。

そのためには、量子コンピュータを誰もが持っているかどうかによりますが、さらに強力なものが登場します。

量子ワンタイムシグネチャは、量子コンピュータを使用することで、量子化されたワンタイムシグネチャを作成することができます。

難読化とワンタイムシグネチャを組み合わせることで、信頼される必要のない、ほぼ完璧なサードパーティを構築することができます。暗号だけではできない唯一のこと、そしてブロックチェーンが必要なことは、検閲への耐性を保証することです。これらの技術によって、イーサ自体をより安全にするだけでなく、その上にさらに強力なアプリケーションを構築することができるようになる。

これらのプリミティブがそれぞれどのように機能を追加するのかを理解するために、重要な例である投票を見てみましょう。投票は、非常に強力な認証とプライバシーを含む、満たすべき多くのトリッキーなセキュリティ特性を持つため、魅力的な問題です。強力なセキュリティーを持つ投票プロトコルは何十年も前から存在しているが、ここでは問題を難しくして、任意の投票プロトコルを扱えるような設計が必要だとしよう：2次投票、ペアワイズ拘束2次ファンディング、クラスターマッチング2次ファンディングなど。つまり、「数える」ステップは任意の手順であってほしいのです。

• まず、投票をブロックチェーン上で公開するとします。これにより、公的な検証可能性（集計ルールや参加資格ルールを含め、最終結果が正しいことを誰でも検証できる）と検閲耐性（投票する人を止められない）が得られる。しかし、プライバシーはない。

• そこで、ZK-SNARKを追加します。これでプライバシーが確保されます。すべての投票は匿名であり、承認された投票者のみが投票でき、各投票者は一度しか投票できないことが保証されます。

• 次に、MACIメカニズムを追加します。投票は中央サーバーの復号キーに暗号化されます。中央サーバーは、重複投票を破棄し、答えを証明するZK-SNARKを発行することを含む、開票処理を実行する必要があります。しかし、もしサーバーが正直であれば、強制的な抵抗保証が追加されます：ユーザーが投票方法を証明したくてもできないのです。なぜなら、ユーザーは自分が投票したことを証明することはできても、その投票を取り消すような別の投票をしなかったことを証明することはできないからです。これにより、賄賂やその他の攻撃を防ぐことができる。

• 私たちはFHE内部で投票カウントを実行し、それを復号するためにN/2-of-Nの閾値復号計算を実行します。

• 私たちは投票カウント手順を難読化し、ブロックチェーンのコンセンサス証明、一定数のプルーフ・オブ・ワーク、またはその両方によってライセンスされた場合にのみ出力を行うように難読化手順を設計します。ブロックチェーン・コンセンサスの場合、それを破るには検証者の51％が結託する必要がある。一方、プルーフ・オブ・ワークの場合、たとえ全員が結託したとしても、1人の投票者の行動を抽出しようとして別の投票者のサブセットで集計を再実行することは、法外なコストがかかるだろう。個々の投票者の行動を抽出することをさらに難しくするために、最終結果に対してプログラムに小さなランダムな調整をさせることさえできます。

• 私たちはワンタイム署名を追加しました。これは量子計算に依存するプロト言語で、ある種のメッセージに署名するために署名を一度だけ使用できるようにするものです。これにより、強制に強い保証が本当に完璧なものになります。

見分けにくさは、他の強力なアプリケーションも可能にします。例えば、

• DAO、連鎖オークション、および任意の内部秘密状態を持つ他のアプリケーションです。

• 真に普遍的な信頼されるセットアップ：誰かがキーを含むファジープログラムを作成し、hash(key, program)を入力としてプログラムに入れることで、任意のプログラムを実行し、出力を提供することができます。このようなプログラムがあれば、誰でもそのプログラムを自分自身の中に入れ、プログラムの既存の鍵と自分の鍵を組み合わせ、その過程でセットアップを拡張することができる。これは、あらゆるプロトコルに対して、1-of-Nの信頼できる設定を生成するために使用することができます。

• ZK-SNARK（ZK-SNARKの検証は署名だけです。これを実装するのは簡単です。信頼された設定があり、それが有効なZK-SNARKである場合にのみ鍵でメッセージに署名するファジープログラムを誰かが作成します。

• 暗号化メモリープール。トランザクションを暗号化するのは非常に簡単で、将来チェーン上で何らかのイベントが発生した場合にのみ復号化されます。

ワンタイムシグネチャを使えば、検閲攻撃はまだ可能ですが、偶発性逆転攻撃の51%からブロックチェーンを免れることができます。ワンタイムシグネチャに似たプリミティブは量子通貨を可能にし、ブロックチェーンなしで二重支払いの問題を解決することができますが、より複雑なアプリケーションの多くは依然としてブロックチェーンを必要とするでしょう。

これらのプリミティブが十分に効率的であれば、世界のほとんどのアプリケーションは分散化できる。主なボトルネックは、実装の正しさを検証することだ。

どのような研究があるのでしょうか？

2021年の見分けがつかない難読化プロトコル: https://eprint.iacr.org/2021/1334.pdf

How obfuscation can help Ether: https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

最初に知られたワンタイムシグネチャーの構成：https://eprint.iacr.org/2020/107.pdf

難読化を試みた実装(1):https://mediatum.ub.tum.de/doc/1246288/1246288.pdf

難読化された実装の試み(2):https://github.com/SoraSuegami/iOMaker/tree/main

何が残っていて、何がトレードオフなのでしょうか?

やるべきことはたくさん残っています。見分けがつかない難読化は非常に未熟で、候補の構築はアプリの何百万倍 (またはそれ以上) も遅いです。見分けがつかない難読化は「理論的には」多項式時間の実行時間で知られていますが、実際には宇宙の寿命よりも実行に時間がかかります。新しいプロトコルでは、実行時間はそれほど極端ではありませんが、それでも通常の使用にはオーバーヘッドが大きすぎます。

量子コンピュータは存在すらしていません。今日インターネット上で目にする量子コンピュータは、4ビット以上の計算ができないプロトタイプであるか、あるいは本当の量子コンピュータではなく、量子コンポーネントを含んでいるかもしれませんが、ショールのアルゴリズムやグローバーのアルゴリズムのような本当に意味のある計算を実行することはできません。最近、"本物の "量子コンピューターがそう遠くない将来に登場する兆しが見えてきた。しかし、「本物の」量子コンピューターがすぐに利用できるようになったとしても、一般の人々がノートパソコンや携帯電話で量子コンピューターを利用できるようになるのは、楕円曲線暗号を解読できる強力な組織が量子コンピューターにアクセスできるようになる数十年後かもしれません。

見分けにくさのトレードオフの鍵は、セキュリティの仮定です。エキゾチックな仮定を使用する、より急進的な設計があります。これらは通常、より現実的な実行時間を持ちますが、奇妙な仮定は時に破綻します。時間が経てば、いずれはグリッドについて十分な知識を得て、破綻しないような仮定ができるようになるかもしれない。しかし、この道はより危険である。より保守的なアプローチは、セキュリティが「標準的な」仮定であることが証明できるプロトコルに固執することですが、それは十分に高速に動作するプロトコルを得るのに時間がかかることを意味するかもしれません。

ロードマップの他の部分とはどのような関係があるのでしょうか？

極めて強力な暗号は、ゲームチェンジャーになり得る。例えば、

• 署名と同じくらい簡単に検証できるZK-SNARKができれば、集約プロトコルは必要なくなるかもしれません。

• 1回限りの署名は、より安全な利益証明プロトコルを意味するかもしれません。

• 多くの複雑なプライバシープロトコルは、プライバシーを保持するEVMを持つ「だけ」で置き換えることができます。

• 暗号化メモリプールの実装が容易になります。

イーサネットL1は本質的にセキュリティの仮定において保守的である必要があるため、まず第一に、利点はアプリケーション層にあります。しかし、ZK-SNARKの出現がそうであったように、アプリケーション層だけを使用しても、ゲームチェンジャーになる可能性があります。