ブテリンの最新の長い記事: イーサリアム プロトコルはより多くの機能をカプセル化する必要がありますか?

著者: Vitalik Buterin 編纂者: Odaily Planet Daily Nian yingsitang

*フィードバックとレビューをくださった Justin Drake、Tina Zhen、Yoav Weiss に心より感謝いたします。 *

イーサリアム プロジェクトの開始以来、コア イーサリアムを可能な限りシンプルにし、その上にプロトコルを構築することでこれを可能な限り実現しようとする強い哲学がありました。ブロックチェーン分野では、「L1 で構築」対「L2 重視」の議論は主にスケーリングに関するものと考えられていますが、実際には、デジタル資産交換、プライバシーなど、複数のイーサリアム ユーザーのニーズを満たす上で同様の問題があります。 、ユーザー名、高度な暗号化、アカウントのセキュリティ、検閲への耐性、最先端の保護など。しかし、最近では、これらの機能をより多くコアのイーサリアムプロトコルに組み込むための慎重な試みがいくつか行われています。

この記事では、最小限のカプセル化という元の哲学の背後にある哲学的推論のいくつかと、これらのアイデアについての最近の考え方をいくつか掘り下げていきます。目標は、特定の機能をカプセル化することを検討する価値がある可能性のある目標をより適切に特定するためのフレームワークの構築を開始することです。

プロトコルミニマリズムに関する初期の哲学

当時「イーサリアム 2.0」として知られていたものの初期の歴史では、それ自体を構築することをできるだけ少なくし、そのような作業のほとんどすべてをユーザーに任せる、クリーンでシンプルで美しいプロトコルを作成したいという強い願望がありました。理想的には、プロトコルは単なる仮想マシンであり、ブロックの検証は単なる仮想マシン呼び出しです。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

これは、2015 年の初めにイーサリアム 2.0 がどのようになるかについて話していたときに、ギャビン ウッドと私が描いたホワイトボード図を大まかに再構成したものです。

「状態遷移関数」 (ブロックを処理する関数) は単一の VM 呼び出しであり、他のすべてのロジックはコントラクト (一部はシステム レベルのコントラクトですが、ほとんどはユーザーが提供するコントラクト) を通じて実行されます。このモデルの非常に優れた機能は、ハード フォーク全体であっても、ブロック プロセッサー コントラクトに対する単一のトランザクションとして記述することができ、オフチェーンまたはオンチェーンのガバナンスによって承認され、実行許可がアップグレードされることです。

2015 年のこれらの議論は、特にアカウントの抽象化とスケーリングという 2 つの領域に当てはまります。スケーリングの場合、アイデアは、上の図の自然な拡張のように感じられる、スケーリングの最大限の抽象的な形式を作成しようとすることです。コントラクトは、ほとんどの Ethereum ノードに保存されていないデータを呼び出すことができ、プロトコルはこれを検出し、非常に一般的な拡張コンピューティング機能を介して呼び出しを解決します。仮想マシンの観点から見ると、呼び出しは別のサブシステムに入り、しばらくして魔法のように正しい応答を返します。

私たちはこのアイデアを簡単に検討しましたが、あらゆる種類のブロックチェーンのスケーリングが可能であることを証明することに集中しすぎたため、すぐに放棄しました。ただし、後で説明するように、データ可用性サンプリングと ZK-EVM の組み合わせは、イーサリアム スケーリングの将来の可能性が実際にこのビジョンに非常に近いことを意味します。一方、アカウントの抽象化では、ある種の実装が可能であることは最初からわかっていたため、「トランザクションは単なる呼び出しである」という純粋な出発点にできるだけ近いものを作るために、すぐに研究が始まりました。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

*トランザクションの処理と、送信者アドレスからの実際の基礎となるEVM呼び出しの実行との間には、多くの定型コードがあり、さらに定型コードが続きます。このコードをできるだけゼロに近づけるにはどうすればよいでしょうか? *

ここでの主なコードの 1 つは validate_transaction(state, tx) です。これは、トランザクションの nonce と署名が正しいかどうかをチェックする役割を果たします。当初からのアカウント抽象化の本当の目的は、ユーザーが基本的な非増分検証と ECDSA 検証を独自の検証ロジックに置き換えることを可能にし、ユーザーがソーシャル リカバリやマルチシグネチャ ウォレットなどの機能をより簡単に使用できるようにすることでした。したがって、 apply_transaction を単純な EVM 呼び出しに再構築する方法を見つけることは、単に「コードをクリーンにするためにコードをクリーンにする」タスクではなく、ロジックをユーザーのアカウント コードに移動して、ユーザーに柔軟性を与えることです。必要。

ただし、apply_transaction に含まれる固定ロジックをできるだけ少なくすることを主張すると、最終的には多くの課題が発生します。最も初期のアカウント抽象化提案の 1 つである EIP-86 を見てみましょう。

EIP-86 がそのまま組み込まれると、イーサリアム スタックの他の部分の複雑さが大幅に増加するという代償を払って EVM の複雑さが軽減され、全体の導入に加えて、本質的に同じコードを別の場所に記述する必要があります。たとえば、複数の無効化の問題は言うまでもなく、同じハッシュ値を持つ同じトランザクションがチェーン内で複数回出現する可能性があります。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

*アカウント抽象化における複数の無効化の問題。オンチェーンに含まれる 1 つのトランザクションが mempool 内の他の何千ものトランザクションを無効にする可能性があり、mempool が安価に満たされてしまう可能性があります。 *

それ以来、アカウントの抽象化は段階的に進化してきました。 EIP-86 は後に EIP-208 となり、最終的には実用的な EIP-2938 が登場しました。

ただし、EIP-2938 はミニマリストではありません。その内容は次のとおりです。

  • 新しい取引タイプ
  • 3 つの新しいトランザクション スコープ グローバル変数
  • 2 つの新しいオペコード。EVM 実行ブレークポイントとしてガス価格とガス制限チェックを処理し、1 回限りの支払い用に ETH を一時的に保存する非常に不器用な PAYgas オペコードを含む
  • トランザクション検証段階で禁止されているオペコードのリストを含む、マイニングおよび再送信戦略の複雑なセット

イーサリアムのコア開発者 (イーサリアム クライアントの最適化とマージの実装に重点を置いていた) を関与させずにアカウントの抽象化を達成するための取り組みとして、EIP-2938 は最終的に完全にプロトコル外の ERC-4337 として再設計されました。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

ERC-4337。それは完全に EVM 呼び出しに依存しています。

これは ERC であるため、ハード フォークは必要なく、技術的には「イーサリアム プロトコルの外側」に存在します。それで...問題は解決しましたか?そうではないことが判明しました。 ERC-4337 の現在の中期ロードマップには、実際には、最終的に ERC-4337 の大部分を一連のプロトコル機能に移行することが含まれており、これは、なぜこのパスを検討する必要があるのかを示す有益な例です。

パッケージ ERC-4337

ERC-4337 が最終的にプロトコルに再組み込まれることについては、いくつかの重要な理由が議論されています。

  • ガス効率: EVM 内で実行される操作はすべて、ストレージ スロットなどのガスを高価な機能を使用する場合の非効率を含め、ある程度の仮想マシンのオーバーヘッドを引き起こします。現在、これらのさらなる非効率性を合計すると、少なくとも 20,000 ガス以上になります。これらのコンポーネントをプロトコルに組み込むことが、これらの問題を解決する最も簡単な方法です。
  • コードバグのリスク: ERC-4337 の「エントリーポイントコントラクト」にひどいバグがある場合、ERC-4337 と互換性のあるすべてのウォレットで資金が枯渇する可能性があります。コントラクトをプロトコル内機能に置き換えると、ハードフォークを通じてコードのバグを修正するという暗黙の義務が生じ、それによってユーザーが資金を使い果たすリスクがなくなります。
  • EVM オペコードをサポート (txt.origin など)。 ERC-4337 自体により、txt.origin は一連のユーザー アクションをトランザクションにパッケージ化する「バンドラー」のアドレスを返します。ネイティブ アカウント抽象化は、txt.origin がトランザクションを送信する実際のアカウントを指すようにし、EOA と同じように動作させることで、この問題を解決します。
  • 検閲への抵抗: 提案者と構築者の分離に伴う課題の 1 つは、個々の取引のレビューが容易になることです。イーサリアム プロトコルが単一のトランザクションを識別できる世界では、この問題は包含リストによって大幅に軽減できます。これにより、提案者は、ほぼすべてのケースで次の 2 つのスロットに含める必要があるトランザクションのリストを指定できます。ただし、プロトコル外の ERC-4337 は「ユーザー操作」を 1 つのトランザクションにカプセル化し、イーサリアム プロトコルに対してユーザー操作を不透明にするため、イーサリアム プロトコルによって提供される包含リストは、ERC-4337 ユーザーに対する検閲耐性を提供できません。オペレーション。 ERC-4337 をラップし、ユーザー アクションを「適切な」トランザクション タイプにすれば、この問題は解決します。

現在の形式では、ERC-4337 は「基本的な」イーサリアムトランザクションよりも大幅に高価であることに言及する価値があります。トランザクションのコストは 21,000 ガスですが、ERC-4337 のコストは約 42,000 ガスです。

理論的には、プロトコル内のコストとプロトコル外のストレージにアクセスするコストが一致するまで EVM ガスのコスト システムを調整できるはずです。他のタイプのストレージ編集時に ETH の転送に 9000 ガスを費やす必要がある理由はありません。操作が安くなります。実際、今後の Verkle ツリー変換に関連する 2 つの EIP は、まさにそれを実行しようとしています。しかし、これを行ったとしても、EVM がどれほど効率的になっても、カプセル化されたプロトコル関数の方が必然的に EVM コードよりもはるかに安価になる明白な理由があります。カプセル化されたコードは、プリロードにガスを支払う必要がありません。

完全に機能する ERC-4337 ウォレットは大きく、コンパイルされてオンチェーンに配置される実装は約 12,800 バイトを占めます。もちろん、このコードを一度デプロイし、DELEGATECALL を使用して個々のウォレットからそのコードを呼び出せるようにすることもできますが、コードが使用されるすべてのブロックでコードにアクセスする必要があります。 Verkle ツリー ガス コスト EIP では、12,800 バイトが 413 チャンクを形成します。これらのチャンクにアクセスするには、監視ブランチ_コストの 2 倍 (合計 3,800 ガス) と監視チャンク_コストの 413 倍 (合計 82,600) を支払う必要があります。ガス)。これは ERC-4337 エントリ ポイント自体については触れていません。バージョン 0.6.0 では、チェーン上に 23,689 バイトがあります (Verkle ツリー EIP ルールに従ってロードされるガスは約 158,700)。

これは問題を引き起こします。これらのコードに実際にアクセスするためのガスコストは、何らかの方法でトランザクション全体で償却する必要があります。 ERC-4337 で使用されている現在のアプローチはあまり適切ではありません。バンドル内の最初のトランザクションは 1 回限りのストレージ/コード読み取りコストを消費し、他のトランザクションよりもはるかに高価になります。プロトコル内カプセル化により、これらのパブリック共有ライブラリがプロトコルの一部となり、誰でも自由にアクセスできるようになります。

この例から何が学べるでしょうか?また、カプセル化をより一般的に実践すべきなのはどのような場合でしょうか?

この例では、アカウントの抽象化をプロトコルにカプセル化するためのいくつかの異なる理論的根拠が示されています。

  • **「複雑さを限界まで押し上げる」市場ベースのアプローチは、固定費が高い場合に失敗する可能性が最も高くなります。 **実際、長期的なアカウント抽象化ロードマップでは、ブロックごとに多くの固定コストがかかるようです。標準化されたウォレット コードをロードするための 244,100 ガスは別の話ですが、集約すると、ZK-SNARK 検証と証明検証のオンチェーン コストに数十万のガスが追加される可能性があります。市場の大幅な非効率を招かずにこれらのコストをユーザーに請求する方法はなく、これらの機能の一部を誰もが自由にアクセスできるプロトコル機能に変えることで、この問題は非常によく解決されます。
  • **コードのバグに対するコミュニティ全体の対応。 **コードの一部がすべてのユーザーまたは非常に広範囲のユーザーによって使用されている場合、発生したバグを修正するためにブロックチェーン コミュニティがハード フォークの責任を負う方が合理的であることがよくあります。 ERC-4337 では、大量のグローバル共有コードが導入されており、長期的には、ユーザーに大量の ETH を失わせるよりも、ハード フォークを通じてコードのエラーを修正する方が合理的であることは間違いありません。
  • **場合によっては、その機能を直接活用することで、より強力な形式のプロトコルを実装できることがあります。 **ここでの重要な例は、インクルード リストなど、プロトコル内の検閲耐性機能です: プロトコル内のインクルード リストは、プロトコル外の方法よりも優れた検閲耐性を保証できます。ユーザー レベルの操作がプロトコル内から真の恩恵を受けるためには、リストを含める場合、個々のユーザーレベルの操作はプロトコルにとって「判読可能」である必要があります。もう 1 つのあまり知られていない例は、2017 年時代のイーサリアムのプルーフ オブ ステーク設計にはステーク キーのアカウント抽象化が含まれていましたが、BLS はプロトコルで実装する必要がある「集約」メカニズムをサポートしていたため、カプセル化された BLS を支持して放棄されました。これにより、ネットワーク レベルで大量の署名をより効率的に処理できるようになります。

ただし、カプセル化プロトコル内のアカウント抽象化でさえ、現状と比較すると依然として大きな「カプセル化解除」であることを覚えておくことが重要です。現在、トップレベルのイーサリアムトランザクションは、単一の secp 256k 1 楕円曲線署名を使用して検証される外部所有アカウント (EOA) からのみ開始できます。アカウントの抽象化によりこれが排除され、検証条件の定義はユーザーに委ねられます。したがって、アカウントの抽象化に関するこの話では、カプセル化に反対する最大の理由、さまざまなユーザーのニーズを満たす柔軟性もわかります。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

最近カプセル化が検討されている機能の他の例をいくつか見て、話をさらに具体的にしてみましょう。特に、ZK-EVM、プロポーザーとビルダーの分離、プライベート メモリ プール、流動性ステーキング、および新しいプリコンパイルについて検討します。

パッケージ ZK-EVM

イーサリアム プロトコルのもう 1 つの潜在的なカプセル化ターゲットである ZK-EVM に注目してみましょう。現在、多数の ZK ロールアップがあり、ZK-SNARK で同様の Ethereum ブロックの実行を検証するには、すべてほぼ同様のコードを記述する必要があります。 PSE ZK-EVM、Kakarot、Polygon ZK-EVM、Linea、Zeth など、独立した実装のかなり多様なエコシステムがあります。

EVM ZK ロールアップ分野での最近の論争は、ZK コードに現れる可能性のあるバグに対処する方法に関連しています。現在、運用されているこれらのシステムはすべて、バグが発生した場合に認証システムを制御する何らかの形の「セキュリティ評議会」メカニズムを備えています。昨年、私はプロジェクトが認証システムと安全保障理事会をどの程度信頼しているかを明確にし、時間の経過とともにその組織に対する権限を徐々に削減することを奨励する標準化された枠組みを作成しようとしました。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

*中期的には、ロールアップは複数の認証システムに依存する可能性が高く、安全保障理事会が権限を持つのは2つの異なる認証システムが異なる極端な場合に限られます。 *

ただし、この作品には冗長に感じる部分もあります。私たちはすでにイーサリアムのベースレイヤーを持っており、それにはEVMがあり、実装のバグに対処するための機能するメカニズムがすでにあります。バグがある場合、クライアントはそれを修正するために更新され、チェーンは機能し続けます。 。バグのあるクライアントの観点からは、ファイナライズされたブロックが確認されなくなるように見えますが、少なくともユーザーが資金を失うことはありません。同様に、ロールアップが EVM と同等の役割を維持したいだけの場合は、独自のガバナンスを実装して、イーサリアムベースレイヤーへのアップグレードに一致するように内部 ZK-EVM ルールを常に変更する必要がありますが、最終的には最上位に構築されているため、これは間違っていると感じます。イーサリアムのベースレイヤー自体を管理するため、いつアップグレードするか、どのような新しいルールに従ってアップグレードするかを知っています。

これらの L2 ZK-EVM は基本的にイーサリアムとまったく同じ EVM を使用するため、プロトコル機能に「ZK での EVM 実行の検証」を何らかの形で組み込み、バグやアップグレードなどのイーサリアムの社会的合意を適用することで例外を処理できるでしょうか。ベースレイヤーのEVM実行そのもの?

これは重要かつ挑戦的なテーマです。

ネイティブ ZK-EVM でのデータの可用性に関する議論のトピックの 1 つは、ステートフル性です。 ZK-EVM は、「証人」データを運ぶ必要がなければ、データ効率がはるかに高くなります。つまり、特定のデータが以前のブロックで既に読み取られているか、または書き込まれている場合、証明者はそのデータにアクセスできるため、再度利用可能にする必要はないと単純に想定できます。これは単にストレージとコードをリロードしないというだけではなく、ロールアップがデータを正しく圧縮する場合、ステートフル圧縮はステートレス圧縮と比較して最大 3 倍のデータを節約できることがわかりました。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

これは、ZK-EVM プリコンパイルには 2 つのオプションがあることを意味します。

**1.**プリコンパイルでは、すべてのデータが同じブロック内で利用可能である必要があります。これは、証明者がステートレスである可能性があることを意味しますが、このプリコンパイルされた ZK ロールアップの使用はカスタム コード ロールアップを使用するよりもはるかに高価であることも意味します。

**2.**プリコンパイルにより、ポインターが以前の実行で使用または生成されたデータを指すことができます。これにより、ZK ロールアップは最適に近づきますが、より複雑になり、証明者が保存する必要がある新しい状態が導入されます。

このことから何を学べるでしょうか?何らかの方法で ZK-EVM 検証をカプセル化する十分な理由があります: ロールアップはすでに独自のカスタム バージョンを構築しており、イーサリアムは複数の実装とオフチェーンの社会的合意を重視して L1 に EVM を実装するつもりです。それは間違っていますが、まったく同じ仕事をしているL2は、安全保障理事会が関与する複雑なガジェットを実装する必要があります。しかしその一方で、詳細には大きな問題があります。ZK-EVM にはさまざまなバージョンがあり、コストとメリットも異なります。ステートフルとステートレスの区別は表面をなぞっただけであり、他のシステムによって証明されている「ほぼ EVM」のカスタム コードをサポートしようとすると、より大きな設計スペースが公開される可能性があります。したがって、ZK-EVM のパッケージ化には希望と課題の両方が伴います

カプセル化提案者と構築者の分離 (ePBS)

MEV の台頭により、ブロック生成が大規模な経済活動になり、洗練されたアクターが、単にトランザクションのメモリプールを観察してそれらを含めるデフォルトのアルゴリズムよりも多くの収益を生み出すブロックを生成できるようになりました。これまでのところ、イーサリアム コミュニティは、MEV-Boost などのオフプロトコルの提案者と構築者の分離スキームを使用してこの問題を解決しようとしています。これにより、通常の検証者 (「提案者」) がブロックをプッシュできるようになります。構築は専門のアクター (「構築者」) に委託されます。 ")。

ただし、MEV-Boost は、リレーと呼ばれる新しいクラスのアクターで信頼を仮定します。過去 2 年間、「パッケージ化された PBS」を作成するための提案が数多くありました。これを行うことでどのようなメリットがあるのでしょうか?この場合、答えは非常に簡単です。プロトコル機能を直接使用して構築された PBS は、プロトコル機能を使用せずに構築された PBS よりも (信頼の仮定が弱いという意味で) 強力です。これは、価格オラクルをプロトコル内にカプセル化する場合と似ていますが、この場合には強い反対があります。

プライベートメモリプールをカプセル化する

ユーザーがトランザクションを送信すると、それがオンチェーンに組み込まれる前であっても、トランザクションはすぐに公開され、誰でも見ることができます。このため、多くのアプリケーションのユーザーは、フロントランニングなどの経済攻撃に対して脆弱なままになります。

最近、ユーザーのトランザクションが不可逆的にブロックに受け入れられるまで暗号化する「プライベート メモリプール」(または「暗号メモリプール」)の作成に特化したプロジェクトが数多くあります。

ただし、問題は、そのようなスキームには特別な種類の暗号化が必要であるということです。ユーザーがシステムにフラッディングして最初に復号化するのを防ぐために、トランザクションが実際に不可逆的に受け入れられた後に、暗号化が自動的に復号化される必要があります。

この形式の暗号化を実装するには、さまざまなトレードオフを持つさまざまな技術があります。ジョン・シャルボノーはかつてそれをうまく説明しました:

  • Flashbots Protect などの集中型オペレータ向けの暗号化**。 **
  • タイム ロック暗号化。この暗号化形式は、特定の連続した計算ステップの後に誰でも復号化でき、並列化することはできません。
  • しきい値暗号化、正直な多数派委員会を信頼してデータを復号化します。具体的な提案については、クローズド ビーコン チェーンの概念を参照してください。
  • 信頼できるハードウェア (SGX など)。

残念ながら、各暗号化方式には異なる弱点があります。各ソリューションには、それを信頼するユーザーのセグメントが存在しますが、実際にレイヤー 1 に受け入れられるほど信頼できるソリューションはありません。 **したがって、少なくとも遅延暗号化が完成するか、その他の技術的進歩が起こるまでは、レイヤ 1 にアンチアヘッド取引機能をカプセル化することは、たとえ多くのアプリケーションで解決できるほど価値のある機能であるとしても、難しい命題であると思われます。という計画が浮上しました。

流動性ステーキングをカプセル化する

イーサリアム DeFi ユーザーに共通のニーズは、ETH をステーキングと他のアプリケーションの担保として同時に使用できることです。もう 1 つの一般的な要求は、単に便宜上のものです。ユーザーは、ノードを実行して常にオンラインに保つという複雑な作業を行わずにステーキング (およびオンライン ステーキング キーの保護) できるようにしたいと考えています。

これらの両方のニーズを満たす最も単純なステーキング「インターフェイス」は、単なる ERC 20 トークンです。つまり、ETH を「ステーキング ETH」に変換し、保持してから元に戻します。実際、Lido や Rocket Pool などの流動性ステーキングプロバイダーはすでにこれを行っています。ただし、流動性ステーキングには自然な集中化メカニズムがいくつか作用しています。つまり、人々は自然に ETH の最大バージョンをステーキングするようになります。なぜなら、ETH は最も馴染みがあり、流動性があるからです。

ステーキングされた ETH の各バージョンには、誰が基盤となるノード オペレーターになれるかを決定する何らかのメカニズムが必要です。無制限にすることはできません。そうすると、攻撃者が参加してユーザーの資金を使って攻撃を拡大することになるからです。現在、上位 2 つは Lido と Rocket Pool で、前者は DAO ホワイトリストに登録されたノード オペレーターを持ち、後者は 8 ETH のデポジットで誰でもノードを実行できます。 2 つの方法には異なるリスクがあります。Rocket Pool 方式では、攻撃者がネットワークに対して 51% の攻撃を実行でき、ユーザーにコストのほとんどを支払うことを強います。DAO 方式では、特定のステーキングされたトークンが支配的になると、単一の、侵害された可能性のあるガバナンス ガジェットが、すべての Ethereum バリデーターの大部分を制御します。名誉のために言っておきますが、Lido のようなプロトコルは安全対策を実装していますが、1 層の防御では十分ではない可能性があります。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

短期的には、有力なプレーヤーがシステミックリスクを引き起こす可能性を減らすために、エコシステムの参加者が流動性ステーキングプロバイダーの多様なセットを利用することを奨励することが選択肢の1つとなります。しかし、長期的には、これは不安定なバランスであり、問題を解決するための道徳的圧力に過度に依存することは危険です。当然の疑問が生じます: **流動性ステーキングの集中性を下げるために、プロトコルにいくつかの機能をカプセル化するのは意味があるのでしょうか? **

ここでの重要な質問は、どのような種類のプロトコル内機能があるのかということです。プロトコル内で代替可能な「ステーキング ETH」トークンを単純に作成する場合の問題の 1 つは、誰がノードを実行できるかを選択するためにカプセル化されたイーサリアム全体のガバナンスを持たせるか、オープンエンドにする必要があることですが、そうすると攻撃者のものになってしまうということです。ツール。

興味深いアイデアは、流動性ステーキングの最大化に関する Dankrad Feist の記事です。イーサリアムが 51% の攻撃を受けた場合、攻撃された ETH の 5% のみが削減される可能性があります。これは合理的なトレードオフです。現在 2,600 万 ETH 以上がステーキングされているため、特に一度に実行できる「モデル外の」攻撃の数を考慮すると、その 3 分の 1 (約 800 万 ETH) を攻撃するコストは過大です。より低いコストで。実際、単一スロットのファイナリティを実装するというスーパー委員会の提案でも、同様のトレードオフが検討されています。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

攻撃 ETH の 5% のみがスラッシュされることを受け入れる場合、ステーキングされた ETH の 90% 以上はスラッシュの影響を受けないため、プロトコル内で代替可能なリキッド ステーキング トークンとして使用でき、その後、他のアプリケーションで使用できます。

この道は面白いですね。しかし、それでも疑問が残ります: カプセル化されているものは正確には何でしょうか? **Rocket Pool は非常に似たように機能します。各ノード オペレーターが一部の資金を提供し、流動性ステーカーが残りを提供します。いくつかの定数を調整するだけで、最大スラッシュペナルティを 2 ETH に制限することができ、Rocket Pool の既存の rETH はリスクフリーになります。

単純なプロトコル調整により、他の賢いことも行うことができます。たとえば、ノードオペレーター (高い担保要件) と預金者 (最低担保要件がなく、いつでも参加および脱退可能) という 2 つのステーキングの「層」を持つシステムが必要であるとします。ただし、ランダムにサンプリングされたステーキングに寄付したいとします。預金者委員会には、(検閲への抵抗の理由で)含める必要があるトランザクションのリストを推奨したり、非アクティブなリーク時のフォーク選択を制御したり、ブロックへの署名を要求したりするなど、ノードオペレーターの集中化を防ぐ権限があります。これは、各バリデーターに (i) 通常のステーキング キー、および (ii) を出力するために呼び出される各スロットで使用できる ETH アドレスの提供を要求するようにプロトコルを微調整することで、基本的にプロトコル外の方法で実現できます。二次誓約キー。このプロトコルは両方のキーに権限を与えますが、各スロットで 2 番目のキーを選択するメカニズムはステーキング プール プロトコルに任せることができます。一部の機能を直接カプセル化したほうがまだ良いかもしれませんが、「いくつかのものを含めて、他のものはユーザーに任せる」という設計空間が存在することは注目に値します。

より多くのプリコンパイルをカプセル化する

プリコンパイルされたコントラクト (または「プリコンパイルされたコントラクト」) は、EVM スマート コントラクト コードではなくクライアント コードにネイティブに実装されたロジックを使用して、複雑な暗号化操作を実装する Ethereum コントラクトです。プリコーディングはイーサリアム開発の初期から採用された妥協策です: 仮想マシンのオーバーヘッドは一部の非常に複雑で高度に特殊化されたコードには大きすぎるため、いくつかの重要なアプリケーションをネイティブ コードで実装できます。重要な操作を重視して高速化します。現在、これには基本的に、特定のハッシュ関数と楕円曲線演算が含まれています。

現在、基本的なイーサリアムアカウントに使用されるsecp 256 k 1とはわずかに異なる楕円曲線であるsecp 256 r 1のプリコンパイルを追加する動きがあり、信頼できるハードウェアモジュールによって十分にサポートされているため広く使用されています。ウォレットのセキュリティを高めるために使用します。近年、コミュニティは BLS-12-377、BW 6-761 のプリコンパイル、汎用ペアリング、その他の機能の追加も推進しています。

より多くのプリコンパイラを求めるこれらの要求に対する反論は、以前に追加されたプリコンパイラの多く (RIPEMD や BLAKE など) は最終的に予想よりもはるかに少ない使用率に終わり、我々はこのことから学ぶべきだということです。特定の操作に対してプリコンパイルを追加するのではなく、EVM-MAX や Hibernate-But-Always-Resumable SIMD 提案などのアイデアに基づく、よりソフトなアプローチに焦点を当てる必要があるでしょう。これにより、EVM 実装を低コストで実行できるようになります。幅広いコードクラス。おそらく、ほとんど使用されていない既存のプリコンパイルさえも削除して、同じ関数の (必然的に効率が低下する) EVM コード実装に置き換えることができるでしょう。そうは言っても、高速化すべき価値のある特定の暗号化操作が存在する可能性は依然としてあるため、それらをプリコンパイル済みとして追加することは理にかなっています。

このすべてから私たちは何を学んだのでしょうか?

カプセル化をできるだけ少なくしたいという願望は、理解できるものであり、良いことです。これは、ユーザーのさまざまなニーズに簡単に適応し、ソフトウェアの肥大化の呪縛を回避できる最小限のソフトウェアを作成するという Unix の哲学的伝統に由来しています。ただし、ブロックチェーンはパーソナル コンピューティング オペレーティング システムではなく、社会システムです。これは、プロトコルに特定の機能をカプセル化することが合理的であることを意味します。

多くの場合、これらの他の例は、アカウントの抽象化で見たものと似ています。しかし、私たちはいくつかの新しい教訓も学びました。

  • カプセル化された関数は、スタックの他の領域における集中化のリスクを回避するのに役立ちます:

多くの場合、基本プロトコルを最小限かつシンプルに保つと、複雑さがプロトコルの外側のエコシステムに押し出されます。 Unix 哲学の観点から見ると、これは問題ありません。ただし、通常は(それだけではありませんが)高い固定費が原因で、オフプロトコルのエコシステムが集中化するリスクが時々あります。カプセル化により、事実上の集中化が軽減される場合があります。

  • あまりにも多くのコンテンツをカプセル化すると、プロトコルの信頼性とガバナンスの負担が過度に増大する可能性があります:

これは、「イーサリアムコンセンサスをオーバーロードしないでください」に関する以前の記事の主題です: 特定の機能をカプセル化することで信頼モデルが弱まり、イーサリアム全体がより「主観的」になる場合、これはイーサリアムを弱体化させます。このような場合、特定の機能をイーサリアム自体に取り込むよりも、イーサリアム上のメカニズムとして特定の機能を持たせる方が良いでしょう。ここでの最良の例は暗号化されたメモリ プールですが、少なくともレイテンシの暗号化が改善されるまでは、カプセル化が少し難しい場合があります。

  • カプセル化するコンテンツが多すぎると、プロトコルが過度に複雑になる可能性があります:

プロトコルの複雑さは、プロトコルに追加される機能が多すぎることによって増大するシステム上のリスクです。プリコンパイルがその最良の例です。

  • ユーザーのニーズは予測できないため、長期的には機能のカプセル化は逆効果になる可能性があります:

多くの人が重要だと考え、多くのユーザーが使用する機能であっても、実際にはあまり使用されない可能性があります。

さらに、流動性ステーキング、ZK-EVM、およびプリコンパイルされた例は、中間パス、つまり実行可能な最小限の保管の可能性を示しています。プロトコルは機能全体をカプセル化する必要はありませんが、重要な課題に対処する特定の部分を含めることができるため、過度に偏執的になったり、狭すぎたりすることなく、機能を簡単に実装できます。例としては次のものが挙げられます。

  • 完全な流動性ステーキング システムをカプセル化する代わりに、トラストレス流動性ステーキングをより実現可能にするためにステーキング ペナルティ ルールを変更する方が良いでしょう。
  • より多くのプリコンパイラをカプセル化するよりも、EVM-MAX や SIMD をカプセル化して、より広範なクラスの演算を効率的に実装しやすくすることをお勧めします。
  • ロールアップの概念全体をカプセル化するのではなく、EVM 検証を単純にカプセル化できます。

前の図を次のように拡張できます。

V 神の最新の長い記事: イーサリアム プロトコルはより多くの関数をカプセル化する必要がありますか?

場合によっては、何かをカプセル化することが合理的であり、めったに使用されないプリコンパイラーを削除することがその一例です。前述したように、全体としてのアカウントの抽象化もカプセル化解除の重要な形式です。既存のユーザーに対して下位互換性をサポートしたい場合、そのメカニズムは実際にはプリコンパイルをラップ解除したものと驚くほど似ているかもしれません。提案の 1 つは EIP-5003 です。これにより、EOA はアカウントを同じ (またはより良い)機能的な契約。

どの機能をプロトコルに組み込むべきか、どの機能をエコシステムの他の層に任せるべきかは、複雑なトレードオフです。ユーザーのニーズに対する理解と利用可能な一連のアイデアとテクノロジーが向上し続けるにつれて、このトレードオフは時間の経過とともに改善され続けると予想されます。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)