Vitalik：イーサリアムプロトコルの可能性のある未来 – 散財

著者：イーサリアムの創設者であるVitalik

注：この記事は、最近Ethereumの創設者であるVitalikが発行した一連の記事の6番目の部分です。イーサリアムプロトコルの可能性のある先物、パート6：散財」、5番目の部分を参照してください」Vitalik：Ethereum Protocolの可能性のある未来 – パージ」、4番目の部分を参照してください」Vitalik：イーサリアムの可能性のある未来“。 見る “Vitalik：scourge段階の重要な目的」、2番目の部分を参照してください」Vitalik：イーサリアムプロトコルはサージ段階でどのように発生するべきですか」、最初の部分を参照してください」Ethereum Posで他に何を改善できるか」。

---

彼らのフィードバックとコメントをしてくれたジャスティン・ドレイクとティム・ベイコーに感謝します。

いくつかのことは、カテゴリに分類するのが難しいことです。Ethereum Protocol Designには、Ethereumの成功にとって非常に価値のある「小さなこと」がたくさんありますが、より大きなサブカテゴリに分類されるのに適していません。実際、これらの約半分はさまざまなEVMの改善に関連付けられていますが、残りはさまざまなニッチのテーマで構成されています。これが「散財」の目的です。

Splurge、2023ロードマップ

散財：主な目的

• EVMを高性能で安定した「最終状態」に導入する

• すべてのユーザーがより安全で便利なアカウントから利益を得られるように、アカウントの抽象化をプロトコルに紹介します

• 取引料金の経済を最適化し、スケーラビリティを改善し、リスクを減らします

• 長期的にイーサリアムを改善できる高度な暗号化技術を探索する

EVMの改善

それはどのような問題を解決しますか？

今日のEVMは静的分析を実行することが困難であるため、効率的な実装、正式な検証コード、および時間の経過とともにさらに拡大することは困難です。さらに、それは非常に非効率的であり、事前コンパイルによって明示的にサポートされていない限り、複数の形式の高度な暗号化を実装することは困難です。

それは何であり、どのように機能しますか？

現在のEVM改善ロードマップの最初のステップは、EVMオブジェクト形式（EOF）です。これは、次のハードフォークに含まれる予定です。EOFは、多くのユニークな機能を備えたEVMコードの新しいバージョンを指定するために使用される一連のEIPです。

• コード（実行可能ファイル、しかしEVMから読み取らない）とデータ（読み取り可能ですが実行可能ではない）の分離。

• 動的ジャンプは禁止されており、静的ジャンプのみが許可されています。

• EVMコードは、ガス関連の情報を観察できなくなりました。

• 新しい明示的なサブルーチンメカニズムを追加しました。

EOFコードの構造

古いスタイルの契約は引き続き存在し、作成することができますが、古いスタイルの契約は最終的に非推奨になる可能性があります（そして、おそらくそれらをEOFコードに変換することさえ強制します）。新しい契約はEOFによってもたらされる効率の向上から利益を得ます。最初に、サブルーチン関数を使用すると、バイトコードはわずかに小さくなり、新しいEOF固有の関数、またはEOF固有のガスコストが削減されます。

EOFの導入により、さらにアップグレードを導入するのが簡単になりました。現在最も完全なものは、EVMモジュラー算術拡張（EVM-Max）です。EVM-Maxは、モジュラー算術用に設計された一連の新しい操作を作成し、他のオペコードからアクセスできない新しいメモリ空間に配置します。これにより、モンゴメリーの乗算などの最適化を使用できます。

新しいアイデアは、EVM-Maxと単一命令マルチデータ（SIMD）機能を組み合わせることです。シムドは、グレッグ・コルビンのEIP-616以来、イーサリアムのアイデアでした。SIMDを使用して、ハッシュ関数、32ビットスターク、ドットマトリックスベースの暗号化など、さまざまな形式の暗号化を加速できます。EVM-MaxとSIMDは、EVMのパフォーマンス指向の拡張機能のペアを形成します。

結合されたEIPの近似設​​計は、EIP-6690から始まり、次に以下を開始します。

• （i）任意の奇数または（ii）2（最大2^768）の任意の電力を弾性率として許可します

• 各evmmax opcode（add、sub、mul）について、このバージョンは3つの即時番号x、y、zを使用しませんが、x_skip、y_start、y_skip、z_skip、countの7つの即時番号を使用します。 。Pythonコードでは、これらのオペコードは以下に相当する操作を実行します。

実際の実装がない限り、並行して処理されます。

• 可能であれば、XORを追加し、または、そうでない、および少なくとも2つの電源モジュロにシフト（ループと非環式）をシフトします。また、Iszeroを追加しました（EVMメインスタックに出力を押します）。

これは、楕円曲線暗号化、小さなドメイン暗号化（ポセイドン、円形のスタークなど）、従来のハッシュ機能（SHA256、ケッカック、ブレイクなど）、およびDOTマトリックスベースの暗号化を実装するのに十分強力です。

他のEVMのアップグレードも実装される場合がありますが、これまでのところ注目を集めていません。

どのような研究が利用可能ですか？

EOF：https://evmobjectformat.org/

evm-max：https://eips.ethereum.org/eips/eip-6690

シムド：https://eips.ethereum.org/eips/eip-616

残りのことは何ですか、そしてどのようなトレードオフがありますか？

現在、EOFプランは次のハードフォークに含まれています。常に削除することは可能ですが、前のハードフォークの機能は最後の最後に削除されましたが、そうするのは困難な戦いになるでしょう。EOFの削除とは、EVMの将来のアップグレードでEOFが使用されないことを意味しますが、これは実行できますが、より難しい場合があります。

EVMの主なトレードオフは、L1の複雑さとインフラストラクチャの複雑さです。EOFはEVM実装に追加された多くのコードであり、静的コード検査は非常に複雑です。ただし、それと引き換えに、高レベルの言語の簡素化、EVM実装の簡素化、およびその他の利点を獲得します。Ethereum L1への継続的な改善を優先するためのロードマップがEOFに含まれ、構築されると言えます。

重要な仕事は、EVM-Max Plus SIMDのようなものを実装し、さまざまな暗号化操作に必要なガスの量をベンチマークすることです。

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

L1はEVMを調整して、L2を同じ調整を行いやすくします。1つの調整ともう1つの調整は、独自の欠点がある互換性を引き起こします。さらに、EVM-Max Plus SIMDは、多くのプルーフシステムのガスコストを削減し、より効率的なL2になります。また、効率に大きな影響を与えることなく、同じタスクを実行できるEVMコードに置き換えることにより、より多くの事前縮小を削除することが容易になります。

アカウントの抽象化

それはどのような問題を解決しますか？

現在、トランザクションは、ECDSA署名の1つの方法でのみ検証できます。当初、アカウントの抽象化はこれを超えるように設計されており、アカウントの検証ロジックが任意のEVMコードになるようにしました。これにより、さまざまなアプリケーションを実現できます。

• 量子耐性暗号化技術に切り替えます。

• 古いキーの回転（推奨されるセキュリティ慣行と広く考えられている）;

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

• 1つのキーおよび高価値操作を使用して、別のキー（またはキーのセット）を使用して、値の低価値操作に署名します。

• リピーターなしでプライバシープロトコルが機能するようにすることで、その複雑さが大幅に減少し、重要な中央依存関係が排除されます。

アカウントの抽象化が2015年に開始されて以来、ターゲットは拡張され、ETH NO ETHなどの多数の「利便性目標」が含まれていますが、一部のERC20アカウントはそのERC20でガスを支払うことができます。これらの目標の概要を次の表に示します。

ここでは、マルチパーティコンピューティングです。キーを複数の部品に分割し、キーの個々の部分を直接組み合わせることなく、暗号化を使用して署名を生成します。

EIP-7702は、次のハードフォークで導入される予定のEIPです。EIP-7702は、EOAユーザーを含むすべてのユーザーにアカウントの抽象化を提供し、短期的に全員のユーザーエクスペリエンスを改善し、2つのエコシステムに分割することを避ける必要性を高めた結果です。この作業はEIP-3074で始まり、最終的にEIP-7702でピークに達しました。EOA（外部所有のアカウント、つまりECDSA署名によって管理されているアカウント）を含むすべてのユーザーがアカウント抽象を利用できるようにするEIP-7702「コンビニエンス関数」。

チャートからは、いくつかの課題（特に「便利な」課題）はマルチパーティコンピューティングまたはEIP-7702などのプログレッシブテクノロジーによって解決できることがわかります。最初の問題を解決するために戻って：スマート契約コードがトランザクションの確認を制御することを許可します。これがこれまでに行われていない理由は、安全に実装することが挑戦であるためです。

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

本質的に、アカウントの抽象化は簡単です。スマートコントラクト（EOAだけでなく）でトランザクションを開始できるようにします。完全な複雑さは、分散型ネットワークのメンテナンスを促進し、サービス攻撃の拒否を防ぐ方法でこれを行うことに由来します。

重要な課題の実例は、複数の無効化の問題です。

1000のアカウント検証関数がすべて単一の値に依存し、メモリプールのSの現在の値に応じて有効なトランザクションがある場合、S値をフリップするトランザクションは、メモリプールの他のすべてのトランザクションを無効にする可能性があります。これにより、攻撃者は非常に低コストでメモリプールをスパムし、ネットワークノードのリソースをブロックできます。

長年にわたり、DOSのリスクを制限しながら能力を拡大する努力は、「理想的なアカウントの抽象化」を達成するためのソリューションに関する合意につながりました：ERC-4337。

ERC-4337の仕組みは、ユーザー操作の処理を検証と実行の2つの段階に分割することです。すべての検証が最初に処理され、次にすべての実行が処理されます。メモリプールでは、ユーザー操作の検証フェーズが独自のアカウントのみに触れ、環境変数を読み取らない場合にのみ、ユーザー操作が受け入れられます。これにより、複数の無効な攻撃が防止されます。検証ステップは、厳格なガス制限も実施します。

ERC-4337は、Ethereumクライアント開発者が当時のマージに焦点を当てており、他の機能を処理する余分な能力がなかったため、プロトコル外標準（ERC）として設計されました。これが、ERC-4337が通常のトランザクションではなく独自のオブジェクト（ユーザー操作と呼ばれる）を使用する理由です。ただし、最近、この一部を契約に含める必要性を認識しました。2つの主な理由は次のとおりです。

• エントリポイントは、契約として本質的に非効率的です。パッケージごとに〜100kのガスオーバーヘッドを固定し、ユーザー操作ごとに数千の追加料金を固定します。

• イーサリアムプロパティ（インクルージョンリストによって作成されたインクルージョン保証など）がアカウントの抽象ユーザーに継続することを確認する必要があります。

さらに、ERC-4337は2つの機能も拡張します。

• 支払人：あるアカウントが別のアカウントに代わって料金を支払うことを許可する機能。これは、検証フェーズ中に送信者のアカウント自体のみにアクセスするというルールに違反するため、支払人のメカニズムを許可し、安全であることを確認するために特別な処理が導入されます。

• アグリゲーター：BLS集約やスナークベースの集約などの署名集約機能をサポートしています。これは、要約で最高のデータ効率を達成するために必要です。

どのような研究が利用可能ですか？

アカウント抽象履歴紹介：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（embedアカウント要約）：https://eips.ethereum.org/eips/eip-7562

EIP-7701（EOFベースの埋め込みAA）：https://eips.ethereum.org/eips/eip-7701

残りのことは何ですか、そしてどのようなトレードオフがありますか？

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

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

このアプローチで魅力的なのは、ネイティブアカウントの抽象化を表示する2つの同等の方法を明確に示していることです。

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

• 署名アルゴリズムがEVMコード実行である新しいタイプのEOA

最初に検証中にコード実行可能ファイルの複雑さを厳密に制限する場合 – 外部の状態アクセスを許可しない場合、または量子耐性またはプライバシー保護されたアプリケーションに使用するために最初からガス制限を低く設定することさえ、これは方法は非常に明白です。これは、ECDSAの検証を、同様の時間を必要とするEVMコード実行に置き換えるだけです。ただし、時間の経過とともに、これらの制限を緩和する必要があります。これにより、プライバシーを保護するアプリケーションがリピーターなしで動作し、Quantumに抵抗することができます。これを行うには、非常に簡単な検証手順を必要とせずに、より柔軟な方法でDOSのリスクを解決する方法を見つける必要があります。

主なトレードオフは、「「より長く待って、おそらくより理想的な解決策を手に入れるのではなく、できるだけ早く満足する人が少ないものを取る」ことです。理想的なアプローチは、ある種の混合アプローチかもしれません。ハイブリッドアプローチの1つは、いくつかのユースケースをガイドとしてより速く採用し、他の人に対処するためにより多くの時間を残すことです。別のアプローチは、最初にL2にアカウントのより野心的な抽象バージョンを展開することです。しかし、これには、提案を採用するために一生懸命働くことをいとわないL2チームにとって、L1および/または他のL2が後で互換性のあるものを採用することを確認する必要があるという課題があります。

明示的に考慮する必要がある別のアプリケーションは、L1または専用のL2にアカウントに関連する状態を保存するが、L1および互換性のあるL2で使用できるキーストアアカウントです。これを効果的に行うには、L1SloadやRemotestaticCallなどのオペコードをサポートするためにL2が必要になる場合がありますが、L2のアカウントの抽象実装もサポートする必要があります。

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

含まれるリストには、アカウントの抽象的なトランザクションのサポートが必要です。実際、リストを含めることの要件は、最終的には分散型メモリプールの要件と非常によく似ていますが、リストを含めることの柔軟性はわずかに高くなっています。さらに、理想的には、アカウントの抽象的な実装は、L1とL2で可能な限り調整する必要があります。将来、ほとんどのユーザーがKeystoreの概要を使用することを期待している場合、アカウントの抽象化設計でこれを考慮する必要があります。

EIP-1559の改善

それはどのような問題を解決しますか？

EIP-1559は2021年にイーサリアムで発売され、平均ブロック包含時間を大幅に改善しました。

ただし、EIP-1559の現在の実装は、いくつかの方法で完全ではありません。

• 式にはわずかに欠陥があります。ブロックの50％をターゲットにする代わりに、分散に基づいて完全なブロックの50〜53％を標的とします（これは、数学者が「AM-GM不平等」と呼ぶものに関連しています）。

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

後にBlobs（EIP-4844）に使用された式は、最初の問題を解決するように明確に設計されており、一般的により簡潔でした。EIP-1559自体もEIP-4844も、2番目の問題を解決しようとはしませんでした。したがって、現状は、2つの異なるメカニズムを含む中途半端な放棄の紛らわしい状態であり、1つでも時間の経過とともに改善する必要があるということです。

さらに、Ethereum Resource Pricingには、EIP-1559とは関係のない他の弱点がありますが、EIP-1559を調整することで解決できます。1つの大きな問題は、平均シナリオと最悪のシナリオの違いです。イーサリアムのリソース価格は、最悪のシナリオを処理できるように設定する必要があります。この方法でははるかに低く、非効率性が引き起こされます。

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

これらの非効率性の問題の解決策は、多次元ガスです。さまざまなリソースにさまざまな価格と制限を設定します。この概念は技術的には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-1559実証分析：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-exponential-eip-1559-fee-adjustment-mechanism-work

EIP-7706：https://eips.ethereum.org/eips/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内でのみ多次元ガスを利用できるようにすることです。非EOF契約は、ストレージ操作を実行するときにあらゆる種類のガス料金を支払う必要があります（たとえば、Sloadがブロックストレージアクセスガス制限の0.03％を費やした場合、非EOFユーザーにも実行にガス制限の0.03％が請求されます）

多次元ガスに関するより多くの研究を行うことは、トレードオフを理解し、理想的なバランスを見つけるのに役立ちます。

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

多次元ガスの実装を成功させることで、いくつかの「最悪の」リソースの使用を大幅に削減することで、たとえば、際立ったハッシュに基づいてバイナリツリーをサポートするためにパフォーマンスを最適化する圧力を減らします。州の規模の成長のための厳しいターゲットを設定すると、クライアント開発者が将来のニーズを計画し、見積もることが容易になります。

上記のように、EOFはガスが観察できないため、より極端な多次元バージョンのガスの実装が容易です。

検証された遅延関数（VDF）

それはどのような問題を解決しますか？

今日、EthereumはRandaoベースのランダム性を使用して提案者を選択しています。ランダオベースのランダム性の実用的な原則は、各提案者が事前に約束した秘密を明らかにし、明らかにした各秘密をランダム性に混ぜることを要求することです。したがって、各提案者には「1ビットの操作権」があります。（価格で）表示されないことでランダム性を変えることができます。提案者にとってこれは合理的です。これは、1つをあきらめることで2つの新しい提案の機会を与えることができる人はほとんどいないからです。しかし、ランダム性を必要とするオンチェーンアプリケーションの場合、これは不可能です。理想的には、ランダム性のより強いソースが見つかります。

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

検証可能な遅延関数は、順番にのみ計算でき、並列化によって加速できない関数です。簡単な例は、ハッシュを繰り返すことです。範囲でi：x = hash（x）を計算します（10 ** 9）。出力はスナークの正確性によって証明され、ランダム値として使用できます。アイデアは、入力は時間tで利用可能な情報に基づいて選択されるということですが、出力は時間tで明確ではありません：誰かが計算を完全に実行した後のThed Tの後の時間にのみ利用可能になります。誰でも計算を実行できるため、結果を隠すことは不可能であるため、結果を操作する能力はありません。

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

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

• 予期しない並列化：誰かが、リソースの100倍以上が必要であっても、並列化により機能をより速く実行する方法を見つけました。

成功したVDFを作成するタスクは、両方の問題を回避しながら効率的で実用的であり続けることです（たとえば、ハッシュベースのアプローチの問題の1つは、リアルタイムのスナークがハードウェアが必要であることが証明されることです）。ハードウェアアクセラレーションは、多くの場合、公共の利益関係者がVDFS自体の最適なASICに合理的に近くで作成および分配できるようにすることで解決されます。

どのような研究が利用可能ですか？

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

2018年にイーサリアムで使用されているVDFに対する攻撃に関する考え：https://ethresear.ch/t/veriaiable-delay-functions-and-atcacks/2365

Minrootへの攻撃（提案されたVDF）：https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf

残りのことは何ですか、そしてどのようなトレードオフがありますか？

現在、イーサリアム研究者のすべてのニーズを完全に満たすVDF構造はありません。このような機能を見つけるには、さらに作業が必要です。私たちがそれを持っている場合、主なトレードオフはそれが含まれているかどうかです。機能とプロトコルの複雑さとセキュリティリスクの間の単純なトレードオフです。VDFが安全だと思うが、最終的には安全でないと思う場合、セキュリティはRandao仮説（攻撃者ごとに1ビット操作）またはさらに悪いことに、実装方法に応じて格下げされます。したがって、VDFが壊れていても、プロトコルが破損しますが、アプリケーションまたは新しいプロトコル機能が大きく依存していることになります。

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

VDFはイーサリアムプロトコルの比較的独立したコンポーネントですが、提案者の選択のセキュリティを改善することに加えて、（i）ランダム性に依存するオンチェーンアプリケーション、および潜在的に（ii）暗号化されたメモリにも使用できます。プール。ただし、暗号化されたメモリプールのVDFベースの生産は、まだ発生していない他の暗号化の発見に依存しています。

覚えておくべきことの1つは、ハードウェアの不確実性を考えると、VDF出力の生成と出力が必要な「ギャップ」があることです。これは、情報がいくつかのブロックの前に利用可能になることを意味します。これは許容可能なコストかもしれませんが、単一のスロット最終性または委員会の選択デザインなどで考慮する必要があります。

混乱と1回限りの署名：暗号化の未来

それはどのような問題を解決しますか？

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

「数学的に信頼されたプロトコル」、ニック・サボが描いたチャート

これまでのところ、私たちはこの理想に部分的にしかアプローチできません。必要なのは、データとコンピューティングをシャットダウンしたり、検閲したり、改ざんしたりできない透明な仮想コンピューターである場合、プライバシーは目標ではありません。プライバシーが目標である場合、最近まで、特定のアプリケーション用の特定のプロトコルのみを開発できました：基本認証のためのデジタル署名、元の匿名フォームのリング署名、リンク可能なリングシグネチャ、アイデンティティベースの暗号化（信頼できる特定の仮定の下でより便利な暗号化を実装します発行者）、チョウムの電子現金の盲目の署名など​​。このアプローチでは、新しいアプリケーションごとに行うには多くの作業が必要です。

2010年代には、プログラム可能な暗号化に基づいた別のより強力なアプローチを初めて見ました。新しいアプリケーションごとに新しいプロトコルを作成する代わりに、強力な新しいプロトコル（特にZK-SNARK）を使用して、任意のプログラムに暗号化保証を追加できます。Zk-Snarkを使用すると、ユーザーは次のようなデータのステートメントを証明できます。これはプライバシーとスケーラビリティの大きな進歩であり、人工知能の変圧器効果に例えます。何千人もの人々が1年間の特定のアプリケーション作業を行い、突然、普遍的なソリューションに置き換えられ、プラグインだけで驚くほど幅広い問題を解決できます。

しかし、Zk-Snarkは、同様に非常に強力な3つの普遍的なプリミティブの最初のものです。これらのプロトコルは非常に強力であるため、私がそれらを考えると、Yu-Gi-Ohの非常に強力なカードのセット、カードゲームとテレビ番組を思い出させてくれます。エジプトのゴッドカードは3枚の非常に強力なカードであり、伝説によれば、それらを致命的で強力にすることができるため、決闘で使用することは許可されていません。同様に、暗号化には3つのエジプトの神プロトコルがあります。

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

Zk-Snarkは、私たちがすでに持っている3つのプロトコルの1つであり、高いレベルの成熟に達しました。過去5年間、ZK-SNARKはスピードと開発者の親しみやすさを証明することで大きな進歩を遂げ、イーサリアムのスケーラビリティとプライバシーポリシーの礎となりました。しかし、Zk-Snarkには1つの重要な制限があります。それを証明するためにデータを知る必要があります。ZK-SNARKアプリケーションの各状態には、読み取りまたは書き込みを承認するために存在する必要がある「所有者」が必要です。

2番目のプロトコルには、この制限、すなわち完全に準同型暗号化（FHE）はありません。FHEを使用すると、暗号化されたデータを表示せずに計算を実行できます。これにより、データとアルゴリズムをプライベートに保ちながらユーザーに利益をもたらすためにユーザーデータの計算を実行できます。また、Maciなどの投票システムを拡大して、ほぼ完璧なセキュリティとプライバシー保証を保証することもできます。FHEは長い間、実用的ではないほど非効率的であると考えられてきましたが、今では最終的にはアプリケーションを見始めているほど効率的になりました。

Cursiveは、プライバシー発見にコンピューティングとFHEの両方を使用するアプリケーションです。

しかし、FHEには制限もあります。FHEベースのテクノロジーには、復号化キーを保持する必要があります。これは、M-of-N分布のセットアップである可能性があります。Tシャツを使用してレイヤー2防御を追加することもできますが、それはまだ制限です。

これにより、3番目のプロトコルが得られます。これは、他の2つのプロトコルを組み合わせたものよりも強力です。区別できない混乱です。2020年の時点では、成熟していませんが、標準的なセキュリティの仮定に基づいて理論的に効果的なプロトコルを開発し、最近作業の実装を開始しました。見分けがつかない難読化により、任意の計算を実行する「暗号化されたプログラム」を作成できるため、プログラムのすべての内部詳細が非表示になります。簡単な例を示すために、秘密鍵を難読化されたプログラムに入れることができます。これにより、それを使用して素数に署名し、プログラムを他のプログラムに配布できます。プログラムを使用して任意の素数に署名できますが、キーを取得することはできません。しかし、それ以上のことがあります。ハッシュで使用することができ、他の暗号化の原始的なものを実装するために使用できます。

難読化されたプログラムができない唯一のことは、それ自体がコピーされるのを防ぐことです。しかし、このためには、より強力なものが来ようとしていますが、それは誰もが量子コンピューターを持っていることに依存しています：量子1回限りの署名。

難読化と1回限りの署名を使用して、ほぼ完璧で信頼のないサードパーティを構築できます。暗号化技術ではできない唯一のことは、ブロックチェーンが必要なことです。これは、検閲抵抗を確保するためです。これらの技術により、イーサリアム自体をより安全にすることができるだけでなく、イーサリアムの上により強力なアプリケーションを構築することもできます。

これらのプリミティブのそれぞれが追加の機能を追加する方法を理解するために、重要な例を見てみましょう：投票。投票は魅力的な質問です。なぜなら、非常に強力な検証可能性やプライバシーなど、満たす必要がある多くのトリッキーなセキュリティ属性があるからです。強力なセキュリティを備えた投票プロトコルは何十年も前から存在していますが、任意の投票プロトコルを処理できるデザインが必要であると言って、問題を難しくしましょう。つまり、「カウントカウント」ステップが任意の手順であることを望んでいます。

• まず、ブロックチェーンに投票を公開したとしましょう。これにより、一般の検証可能性（誰でも、投票カウントルールと適格性ルールなど、最終結果が正しいことを確認できます）と検閲抵抗（投票を止めることはできません）を提供します。しかし、プライバシーはありません。

• 次に、Zk-Snarkを追加します。現在、私たちにはプライバシーがあります。すべての投票は匿名であり、認定された有権者のみが投票できること、および各有権者が1回しか投票できないことを保証します。

• 次に、Maciメカニズムを追加します。投票は、中央サーバーの復号化キーに暗号化されます。中央サーバーは、重複投票の破棄や、答えを証明するZK-SNARKを公開するなど、投票カウントプロセスを実行する必要があります。これにより、以前の保証が保持されます（サーバーがチートしていても！）が、サーバーが正直である場合、必須の抵抗保証が追加されます。ユーザーは、たとえ望んでいても投票する方法を証明できません。これは、ユーザーが投票した投票を証明できる一方で、投票をキャンセルするために別の投票をしなかったことを証明できないためです。これにより、贈収賄やその他の攻撃が防止されます。

• FHEで内部でカウントを実行し、N/2-of-Nしきい値の復号化計算を実行して復号化します。これにより、1-1ではなく、n/2-of-nであることが保証されている強制抵抗が保証されます。

• カウントプロセスを難読化し、難読化プロセスを設計して、ブロックチェーンコンセンサスの証明であろうと、一定量の作業証明、またはその両方を通じて、ライセンスの場合にのみ出力を与えることができます。これにより、必須の抵抗がほぼ完全に保証されます。ブロックチェーンコンセンサスの場合、それを共謀するために51％のバリデーターが必要です。個々の有権者を抽出する試みも非常に高価です。プログラムに最終結果をわずかにランダムに調整させることもでき、個々の有権者の行動を抽出することをより困難にすることができます。

• Quantum Computingに依存するプリミティブである1回限りの署名を追加し、一度に何らかのタイプのメッセージに署名するために署名を使用できるようにしました。これにより、防止防止が真の完璧さを保証します。

無差別な難読化は、他の強力なアプリケーションを可能にすることもできます。例えば：

• DAO、オンチェーンオークションおよび内部秘密のステータスを持つその他のアプリケーション。

• 本当に普遍的な信頼できる設定：誰かがキーを使用してファジープログラムを作成し、任意のプログラムを実行して出力を提供することができます。ハッシュ（キー、プログラム）を入力としてプログラムに入れます。このようなプログラムを考えると、誰でもそれ自体にプログラムを入力し、プログラムの既存のキーと独自のキーを組み合わせて、プロセスの設定を拡張できます。これを使用して、あらゆるプロトコルに対して1-of-n信頼できる設定を生成できます。

• Zk-Snarks、その検証は署名のみです。これを実装することは簡単です。信頼できるセットアップがあります。このセットアップでは、有効なZK-SNARKの場合にのみメッセージに署名するファジープログラムを作成します。

• 暗号化されたメモリプール。暗号取引は非常に簡単になっているため、特定のオンチェーンイベントが将来発生した場合にのみ復号化されます。これには、VDFの実行の成功も含まれる場合があります。

一度限りの署名を使用すると、検閲攻撃がまだ存在する可能性がありますが、51％の最終反転攻撃からブロックチェーンを保護できます。1回限りの署名と同様のプリミティブは、量子通貨を実装し、ブロックチェーンなしで二重支払いの問題を解決できますが、より複雑なアプリケーションにはまだブロックチェーンが必要です。

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

どのような研究が利用可能ですか？

2021年の差別的な難読化協定：https://eprint.iacr.org/2021/1334.pdf

混乱イーサリアムを助ける方法：https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

最初に既知の1回限りの署名構造：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

残りのことは何ですか、そしてどのようなトレードオフがありますか？

やることはまだたくさんあります。無差別な混乱は非常に未熟であり、候補構造は、アプリケーションよりも何百万倍遅い（またはそれ以上）。無差別な混乱は、「理論的」における多項式時間の実行時間で知られていますが、宇宙の寿命よりも実際に実行するのに時間がかかります。新しいプロトコルにより、ランタイムは極端になりませんが、オーバーヘッドはまだ定期的に使用するには高すぎます。1つの実装者は、ランタイムが1年になると予想しています。

量子コンピューターは存在しません。今日インターネットで読むことができるすべての構造は、4ビットより大きな計算を実行できないプロトタイプであるか、実際には量子コンピューターではなく、量子部品を含む可能性がありますが、 Shorアルゴリズムやグローバーアルゴリズムなど、意味の実際の計算を実行することはできません。最近、「本物の」量子コンピューターがそれほど遠くないという兆候があります。ただし、「実際の」量子コンピューターがまもなく出てきたとしても、普通の人がラップトップや電話に量子コンピューターを持っている時代は、楕円曲線コードをクラックできる量子コンピューターを取得する強力な機関よりも数十年後になる可能性があります。

無差別な混乱のための重要なトレードオフは、セキュリティの仮定です。奇妙な仮定を使用するより急進的なデザインがあります。これらには通常、より現実的な実行時間がありますが、奇妙な仮定は時々破られます。時間が経つにつれて、私たちは最終的に、壊れないと仮定するのに十分な庭についての十分な知識を持っているかもしれません。しかし、この道はより危険です。より保守的なアプローチは、セキュリティを「標準」の仮定として証明できるプロトコルに固執することですが、これは、十分に速く実行されるプロトコルを取得するのに時間がかかることを意味する場合があります。

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

非常に強力な暗号化技術は、ゲームチェンジャーになる可能性があります。例えば：

• 署名と同じくらい簡単に検証できるZK-SNARKを取得すると、チェーン上で直接検証できない場合があります。

• 1回限りの署名は、より安全な利害関係の契約の証拠を意味する場合があります。

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

• 暗号化されたメモリプールの実装が簡単になります。

第一に、Ethereum L1は本質的にセキュリティの仮定で保守的である必要があるため、アプリケーション層で利点が発生します。ただし、アプリケーションレイヤーのみを使用しても、Zk-Snarkの出現と同じように、ゲームチェンジャーになる可能性があります。