プロトコルミニマリズムの初期の哲学
当時「イーサリアム2.0」と呼ばれていた初期の歴史では、クリーンでシンプルで審美的に心地よいプロトコルを作成したいという強い願望があり、可能な限り少ない労力で独自に構築しようとし、そのような作業のほとんどすべてをユーザーに任せました。 理想的には、プロトコルは単なる仮想マシンであり、チャンクの検証は単なる仮想マシン呼び出しです。
"状態遷移関数" (チャンクを処理する関数) は 1 つの VM 呼び出しであり、他のすべてのロジックはコントラクトを通じて発生します (一部のシステム レベルのコントラクトですが、ほとんどはユーザーによって提供されるコントラクトです)。 このモデルの非常に優れた特徴は、ハードフォーク全体でさえ、オフチェーンまたはオンチェーンのガバナンスによって承認され、昇格された特権で実行されるブロックプロセッサコントラクトの単一のトランザクションとして記述できることです。
2015年のこれらの議論は、特に、アカウントの抽象化とスケーリングという2つの分野に当てはまります。 スケーリングの場合、アイデアは、上のチャートの自然な拡張のように感じるスケーリングの最大抽象形式を作成しようとすることです。 コントラクトは、ほとんどのイーサリアムノードによって保存されていないデータを呼び出すことができ、プロトコルはこれを検出し、ある種の非常に一般的な拡張コンピューティング機能で呼び出しを解決します。 仮想マシンの観点からは、呼び出しは別のサブシステムに入り、しばらくすると魔法のように正しい答えを返します。
この考え方を簡単に検討しましたが、あらゆる種類のブロックチェーンスケーリングが可能であることを検証することに集中しすぎたため、すぐにあきらめました。 後で説明しますが、データ可用性サンプリングとZK-EVMの組み合わせは、イーサリアムスケーリングの可能な未来が実際にこのビジョンに非常に近いように見えることを意味します! 一方、アカウントの抽象化については、最初から何らかの実装が可能であることを知っていたため、すぐに「取引は単なる呼び出し」という純粋な出発点にできるだけ近いものを実現しようとする研究が始まりました。
トランザクションの処理と、送信者アドレスからの実際の基になるEVM呼び出しの間には、多くの定型コードがあり、その後にさらに定型コードがあります。 このコードをできるだけゼロに近づけるにはどうすればよいですか?
ここでの主なコードの1つは、トランザクションが正しいノンスと署名を持っていることを確認する役割を担うvalidate_transaction(state、tx)です。 当初から、アカウント抽象化の実用的な目標は、ユーザーが基本的な非増分検証とECDSA検証を独自の検証ロジックに置き換えて、ユーザーがソーシャルリカバリやマルチシグネチャウォレットなどの機能をより簡単に使用できるようにすることでした。 したがって、単純なEVM呼び出しとして適用を再設計する方法を見つけることは_transaction単なる「コードをクリーンにするためのクリーンなコード」タスクではありません。 代わりに、ロジックをユーザーのアカウントコードに移行して、ユーザーが必要とする柔軟性を提供します。
ただし、apply_transactionにできるだけ少ない固定ロジックが含まれていると主張すると、多くの課題が発生します。 最も初期のアカウント抽象化提案の1つであるEIP-86を見ることができます。
EIP-86をそのまま含めると、イーサリアムスタックの他の部分の複雑さが大幅に増し、本質的に同じコードを他の場所に記述する必要があるという犠牲を払って、EVMの複雑さを軽減します、同じハッシュ番号を持つ同じトランザクションがチェーンに複数回現れるなど、まったく新しい奇妙なカテゴリを導入することを除いて、複数の無効化の問題は言うまでもありません。
アカウントの抽象化における複数の無効化の問題。 オンチェーンに含まれる1つのトランザクションは、mempool内の他の何千ものトランザクションを無効にする可能性があり、mempoolを安価に氾濫させやすくなります。
それ以来、アカウントの抽象化は段階的に進化してきました。 EIP-86は後にEIP-208となり、最終的には実用的なEIP-2938となった。
ただし、EIP-2938はミニマリストではありません。 その内容は次のとおりです。
· 新しいトランザクション タイプ
· 3つの新しい取引スコープのグローバル変数
· ガス価格とガス制限チェックの処理、EVMとしてのブレークポイントの実行、1回限りの料金でのETHの一時的な保存のための非常に不格好なPAYgasオペコードを含む2つの新しいオペコード
· トランザクション検証フェーズ中に禁止されているオペコードのリストを含む、マイニングおよび再ブロードキャスト戦略の複雑なセット
イーサリアムのコア開発者(イーサリアムクライアントの最適化とマージの実装に焦点を当てている)を関与させることなくアカウントの抽象化を実装するために、EIP-2938は最終的に完全にプロトコル外のERC-4337に再設計されました。
これはERCであるため、ハードフォークを必要とせず、技術的には「イーサリアムプロトコルの外部」に存在します。 だから。。。。。。 問題は解決しましたか? そうではないことがわかりました。 ERC-4337の現在の中期ロードマップでは、実際にはERC-4337の多くを一連のプロトコル機能に変えることが含まれており、これはこのパスを検討する必要がある理由の有用な指針となる例です。
パッケージERC-4337
最終的にERC-4337をプロトコルに戻す主な理由はいくつかあります。
ガス効率:EVM内で実行される操作は、ストレージスロットなどのガス高価な機能を使用する場合の非効率性を含め、ある程度の仮想マシンのオーバーヘッドをもたらします。 現在、これらの追加の非効率性は、少なくとも20,000ガス以上になります。 これらのコンポーネントをプロトコルに入れることは、これらの問題を排除する最も簡単な方法です。
コードバグのリスク:ERC-4337の「エントリーポイント契約」に恐ろしいバグがある場合、すべてのERC-4337互換ウォレットですべての資金が枯渇する可能性があります。 コントラクトをプロトコル内機能に置き換えると、ハードフォークを介してコードエラーを修正するという暗黙の義務が生じ、それによってユーザーの資金が枯渇するリスクが排除されます。
txt.origin などの EVM オペコードのサポート。 ERC-4337 自体が txt.origin に、一連のユーザーアクションをトランザクションにパッケージ化する「バンドラー」のアドレスを返すようにします。 ネイティブアカウントの抽象化は、txt.originがトランザクションを送信する実際のアカウントを指すようにすることでこの問題を解決し、EOAと同じように機能させます。
検閲耐性:提案者とビルダーの分離の課題の1つは、個々のトランザクションのレビューが容易になることです。 この問題は、イーサリアムプロトコルが単一のトランザクションを認識できる世界で大幅に軽減でき、提案者はほとんどすべての場合に次の2つのスロットに含める必要があるトランザクションのリストを指定できます。 ただし、プロトコル外のERC-4337は、「ユーザー操作」を単一のトランザクションにカプセル化するため、ユーザー操作はイーサリアムプロトコルに対して不透明になります。 したがって、イーサリアムプロトコルによって提供される包含リストは、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チャンクを構成し、これらのチャンクにアクセスするには、証人ブランチ_costの2倍(合計3,800ガス)と証人チャンク_costの413倍(合計82,600ガス)を支払う必要があります。 そして、それはバージョン0.6.0でチェーン上に23, 689バイトを持っているERC-4337エントリポイント自体についてさえ言及し始めていません(VerkleツリーEIPルールに従ってロードするために約158, 700ガス)。
これは問題につながります:実際にこれらのコードにアクセスするためのガスコストは、トランザクション全体で何らかの形で償却する必要があります。 ERC-4337が使用している現在のアプローチはあまり良くありません:バンドル内の最初のトランザクションは1回限りのストレージ/コード読み取りコストを消費し、他のトランザクションよりもはるかに高価になります。 プロトコル内カプセル化により、これらのパブリック共有ライブラリをプロトコルの一部にし、すべての人が自由にアクセスできるようにします。
この例から何を学ぶことができますか、そしていつパッケージングがより一般的になるでしょうか? **
この例では、プロトコルでアカウントの抽象化の側面をカプセル化するためのいくつかの異なる理論的根拠が見られます。
「複雑さをエッジに押し上げる」市場ベースのアプローチは、固定費が高い場合に失敗する可能性が最も高いです。 実際、長期的なアカウントの抽象化ロードマップは、各ブロックに多くの固定費があるように見えます。 標準化されたウォレットコードをロードするための244、100ガスは1つのことです。 しかし、集約により、ZK-SNARK検証に数十万のガスが追加され、プルーフオブチェーン検証のオンチェーンコストも追加される可能性があります。 多くの市場の非効率性を導入することなく、これらのコストをユーザーに請求する方法はなく、これらの機能の一部を誰もが無料でアクセスできるプロトコル機能に変換すると、この問題がうまく解決されます。
コードのバグに対するコミュニティ全体の対応。 一部のコードスニペットがすべてのユーザーまたは非常に幅広いユーザーによって使用されている場合、通常、ブロックチェーンコミュニティは、発生したバグを修正するためにハードフォークに責任を負う方が理にかなっています。 ERC-4337は大量のグローバル共有コードを導入しており、ハードフォークを介してコードのバグを修正することは、ユーザーに多くのETHを失わせるよりも長期的には間違いなく合理的です。
場合によっては、プロトコルの機能を直接活用することで、より強力な形式を実現できます。 ここでの重要な例は、包含リストなどのプロトコル内反検閲機能です:プロトコル内の包含リストは、プロトコル外の方法よりも検閲耐性を保証でき、ユーザーレベルの操作がプロトコル内の包含リストから真に利益を得るには、単一のユーザーレベルの操作がプロトコルに対して「読み取り可能」である必要があります。 もう1つのあまり知られていない例は、BLSがプロトコルおよびネットワークレベルで実装する必要がある「集約」メカニズムをサポートしているため、BLSのカプセル化を支持して放棄されたステークキーアカウントを抽象化した2017時代のイーサリアムプルーフオブステーク設計であり、多数の署名の処理をより効率的にすることができます。
ただし、プロトコル内のアカウントの抽象化をカプセル化することでさえ、現在の状況と比較すると、依然として巨大な「カプセル化解除」であることを覚えておくことが重要です。 現在、最上位のイーサリアムトランザクションは、単一のsecp 256k1楕円曲線署名で検証された外部所有のアカウント(EOA)からのみ開始できます。 アカウントの抽象化はこれを排除し、検証基準の定義をユーザーに任せます。 したがって、アカウントの抽象化に関するこのストーリーでは、カプセル化に反対する最大の議論、つまりさまざまなユーザーのニーズを満たす柔軟性も見られます。
最近カプセル化されたと見なされた機能の他のいくつかの例を見て、このストーリーをさらに肉付けしましょう。 ZK-EVM、提案者とビルダーの分離、プライベートメモリ、流動性ステーキング、新しいプリコンパイルに特に注意を払います。
パッケージ ZK-EVM
イーサリアムプロトコルの別の潜在的なカプセル化ターゲットであるZK-EVMに注目しましょう。 現在、多数のZKロールアップがあり、ZK-SNARKでの同様のイーサリアムブロックの実行を検証するために、すべてがかなり類似したコードを記述する必要があります。 PSE ZK-EVM、Kakarot、Polygon ZK-EVM、Linea、Zethなど、独立した実装のかなり多様なエコシステムがあります。
EVM ZKロールアップスペースでの最近の論争は、ZKコードで発生する可能性のあるバグの処理方法に関係しています。 現在、これらの実行中のシステムはすべて、バグが発生した場合に構成証明システムを制御する何らかの形の「セキュリティ理事会」メカニズムを備えています。 昨年、私は、プロジェクトが認証システムと安全保障理事会に対する信頼のレベルを明確にし、時間の経過とともに組織に対する権限を徐々に低下させることを奨励するための標準化されたフレームワークを作成しようとしました。
中期的には、ロールアップは複数の認証システムに依存する可能性があり、安全保障理事会は、2つの異なる認証システムが異なる極端な場合にのみ権限を持ちます。
しかし、一部の作業は冗長に感じる感じがあります。 すでにイーサリアムベースレイヤーがあり、EVMがあり、実装のバグを処理するための実用的なメカニズムがすでにあります:バグがある場合、クライアントはそれを修正するために更新し、チェーンは機能し続けます。 バグのあるクライアントの観点からは、ファイナライズされたブロックは確認されなくなるようですが、少なくともユーザーがお金を失うことはありません。 同様に、ロールアップがEVMと同等の役割を維持したい場合、独自のガバナンスを実装して、イーサリアムベースレイヤーへのアップグレードに合わせて内部ZK-EVMルールを絶えず変更する必要がありますが、最終的にはイーサリアムベースレイヤー自体の上に構築されるため、いつアップグレードするか、新しいルールに従って。
これらのL2 ZK-EVMは基本的にイーサリアムと全く同じEVMを使用しているので、ベースレイヤーEVMの実装自体と同様に、なんとか「ZKでのEVMの実行検証」をプロトコル機能に組み込み、バグやアップグレードなどの例外をイーサリアムの社会的コンセンサスを適用して処理できないか。
これは重要でやりがいのあるトピックです。
ネイティブZK-EVMにおけるデータの可用性に関する議論の1つのトピックは、ステートフルネスです。 ZK-EVMが「監視」データを運ぶ必要がない場合、データ効率ははるかに高くなります。 つまり、特定のデータが前のブロックですでに読み書きされている場合、証明者がそれにアクセスでき、再度使用できるようにする必要がないと単純に想定できます。 ストレージとコードをリロードしないだけではありません。 ステートフル圧縮は、1つのロールアップがデータを正しく圧縮する場合、ステートレス圧縮と比較して最大3倍のデータを保存できることがわかりました。
つまり、ZK-EVM プリコンパイルには 2 つのオプションがあります。
プリコンパイルでは、すべてのデータが同じチャンクで使用可能である必要があります。 これは、証明者がステートレスになる可能性があることを意味しますが、このプリコンパイルされたZKロールアップを使用することは、カスタムコードでロールアップを使用するよりもはるかに高価であることも意味します。
プリコンパイルにより、ポインタは以前に実行、使用、または生成されたデータを指すことができます。 これにより、ZKロールアップはほぼ最適になりますが、より複雑になり、証明者によって保存する必要がある新しい状態が導入されます。
これから何を学ぶことができますか? ロールアップはすでに独自のカスタムバージョンを構築しており、イーサリアムはEVMを実行するためにL1で複数の実装とオフチェーンの社会的コンセンサスを重み付けすることをいとわないが、これは間違っていると感じているが、まったく同じ仕事をしているL2は、安全保障理事会が関与する複雑なガジェットを実装しなければならない。 しかし、その一方で、細部には大きな問題があります:ZK-EVMにはさまざまなバージョンがあり、コストとメリットが異なります。 ステートフルとステートレスの区別は、表面を傷つけるだけです。 他のシステムで実証されているカスタムコードである「ほぼEVM」をサポートしようとすると、より多くの設計スペースが公開される可能性があります。 したがって、ZK-EVM をカプセル化することは、有望かつ課題の両方を提示します。
ラッパーとビルダーの分離 (ePBS)
MEVの台頭により、ブロック生産は大規模な経済活動になり、複雑な参加者は、トランザクションのメモリプールを監視してそれらを含むだけのデフォルトのアルゴリズムよりも多くの収益を生み出すブロックを生成できるようになりました。 これまでのところ、イーサリアムコミュニティは、通常のバリデーター(「提案者」)がブロック構築を専門の参加者(「ビルダー」)にアウトソーシングできるようにするMEV-Boostなどのプロトコル外の提案者とビルダーの分離スキームを使用してこの問題を解決しようとしました。
ただし、MEV-Boostは、リレーと呼ばれる新しいクラスの参加者で信頼を前提としています。 過去2年間で、「カプセル化PBS」を作成するための多くの提案がありました。 これの利点は何ですか? この場合、答えは簡単です:プロトコル機能で直接構築されたPBSは、プロトコル機能なしで構築されたPBSよりも強力です(信頼の仮定が弱いという意味で)。 これは、カプセル化プロトコル内の価格オラクルの場合と似ていますが、この場合、強い反対もあります。
プライベート メモリ プールのカプセル化
ユーザーがトランザクションを送信すると、チェーンに含まれる前であっても、すぐに公開され、すべての人に表示されます。 これにより、多くのアプリケーションのユーザーは、プリエンプティブトランザクションなどの経済的攻撃に対して脆弱になります。
最近では、ブロックに不可逆的に受け入れられるまでユーザーのトランザクションを暗号化する「プライベートメモリプール」(または「暗号化されたメモリプール」)の作成に特化したプロジェクトが数多くあります。
しかし、問題は、そのようなスキームが特別な種類の暗号化を必要とすることです:ユーザーがシステムをフラッディングして最初に復号化するのを防ぐために、トランザクションが実際に不可逆的に受け入れられた後、暗号化を自動的に復号化する必要があります。
この形式の暗号化を実現するには、さまざまなトレードオフ手法があります。 ジョン・シャルボノーはかつてそれをうまく言いました:
フラッシュボットプロテクトなどの集中型オペレーターを暗号化します。
タイムロック暗号化は、特定の順次計算ステップの後に誰でも復号化でき、並列化することはできません。
しきい値暗号化、データの復号化を正直な多数決委員会に信頼します。 具体的な推奨事項については、「クローズドビーコンチェーンの概念」を参照してください。
SGX などの信頼できるハードウェア。
残念ながら、各暗号化には異なる弱点があります。 すべてのソリューションには、それを信頼するユーザーのサブセットがありますが、レイヤー1で実際に受け入れられるほど信頼できるソリューションはありません。 したがって、少なくともレイテンシー暗号化が完成するか、その他の技術的ブレークスルーが行われるまでは、レイヤー1でアンチアドバンストレード機能をカプセル化することは、多くのアプリケーションソリューションが登場するのに十分な価値のある機能であっても、難しい提案のように思えます。
カプセル化された流動性ステーキング
イーサリアムDeFiユーザーの一般的なニーズは、ETHをステーキングに同時に使用し、他のアプリケーションで担保として使用できることです。 もう一つの一般的なニーズは、単に便宜上です:ユーザーは、ノードを実行し、常にオンラインに保つという複雑さなしに、ステーキング(およびオンラインステーキングキーの保護)ができるようにしたいと考えています。
これまでのところ、これらのニーズの両方を満たす最も単純なステーキング「インターフェース」は、ETHを「ステークETH」に変換し、保持して元に戻すというERC 20トークンです。 実際、LidoやRocket Poolなどの流動性ステーキングプロバイダーはすでにそうし始めています。 しかし、流動性ステーキングにはいくつかの自然な集中化メカニズムがあります:ETHは最も身近で流動性が高いため、人々は自然に最大のバージョンのステーキングETHに入ります。
ステーキングETHの各バージョンには、誰が基礎となるノードオペレーターになることができるかを決定するためのメカニズムが必要です。 攻撃者が加わり、ユーザーの資金で攻撃を増幅するため、無制限にすることはできません。 現在、上位2つは、DAOホワイトリストノードオペレーターを備えたLidoと、8ETHをデポジットしたノードを誰でも実行できるロケットプールです。 2つの方法には異なるリスクがあります:ロケットプールアプローチは、攻撃者がネットワーク上で51%の攻撃を実行し、ユーザーにほとんどのコストを支払わせることを可能にします。 DAOアプローチに関しては、特定のステーキングトークンが支配的である場合、すべてのイーサリアムバリデーターのかなりの部分を制御する単一の潜在的に攻撃可能なガバナンスガジェットになります。 確かに、Lidoのようなプロトコルにはすでに予防策が講じられていますが、防御層では不十分な場合があります。
短期的には、エコシステム参加者に多様な流動性ステーキングプロバイダーの使用を促して、単一の企業からのシステミックリスクの可能性を減らすことが1つの選択肢です。 しかし、長期的には、これは不安定な均衡であり、問題を解決するために道徳的圧力に頼りすぎることは危険です。 当然の疑問が生じます:流動性ステーキングの集中化を弱めるために、プロトコルにある種の機能をカプセル化することは理にかなっていますか?
ここでの重要な質問は、どのようなプロトコル内機能かということです。 プロトコル内の代替可能な「ステーキングETH」トークンを単に作成することの問題は、ノードを実行するユーザーを選択するためにカプセル化されたイーサリアム全体のガバナンスを持っている必要があるか、オープンである必要があることですが、これにより攻撃者のツールになります。
興味深いアイデアは、流動性ステーキングの最大化に関するDankrad Feistの記事です。 まず、弾丸を噛み、イーサリアムが51%攻撃された場合、攻撃ETHの5%のみが没収される可能性があります。 これは妥当なトレードオフです。 現在2,600万ETH以上がステークされており、特に低コストで実行できる「モデル外」攻撃の数を考えると、攻撃コストの3分の1(約800万ETH)は過剰です。 実際、シングルスロットファイナリティを実装するというスーパー委員会の提案でも、同様のトレードオフが検討されています。
攻撃ETHの5%のみが没収されることを受け入れる場合、賭けられたETHの90%以上は没収の影響を受けないため、プロトコル内で代替可能な流動性ステーキングトークンとして使用でき、他のアプリケーションで使用できます。
道は面白いです。 しかし、それはまだ疑問を残します:正確に何がカプセル化されていますか? ロケットプールは非常によく似た仕組みで、各ノードオペレーターが資金を提供し、残りを流動性ステーカーが提供します。 いくつかの定数を調整するだけで、最大ペナルティを2ETHに制限することができ、ロケットプールの既存のrETHはリスクフリーになります。
簡単なプロトコル調整で、他のスマートなことも実行できます。 たとえば、ノードオペレーター(高い担保要件)と預金者(最低担保要件がなく、いつでも参加および退出できる)の2つの「層」のステーキングを備えたシステムが必要だが、含めなければならないトランザクションのリストを提案するなど、ランダムにサンプリングされた預金者委員会に権限を与えることで、ノードオペレーターの集中化を防ぎたいとします(検閲に強い理由から)、非アクティブなリーク中のフォーク選択の制御、またはブロック署名の要求。 これは、各バリデーターが(i)通常のステーキングキー、および(ii)セカンダリステーキングキーを出力するために各スロットで呼び出すことができるETHアドレスを提供するようにプロトコルを微調整することにより、本質的にプロトコルから切り離す方法で実現できます。 プロトコルは両方のキーに電力を与えますが、各スロットの2番目のキーを選択するメカニズムはステーキングプールプロトコルに任せることができます。 一部の機能を直接カプセル化する方がよい場合もありますが、この「いくつかのものを含め、他のすべてをユーザーに任せる」設計スペースが存在することに注意してください。
より多くのプリコンパイルをカプセル化する
プリコンパイル済み(または「プリコンパイル済みコントラクト」)は、複雑な暗号化操作を実装するイーサリアムコントラクトであり、そのロジックはEVMスマートコントラクトコードではなく、クライアントコードにネイティブに実装されています。 プリコーディングはイーサリアム開発の初期に採用された妥協案でした:仮想マシンのオーバーヘッドは非常に複雑で高度に専門化されたコードには大きすぎるため、重要なアプリケーションにとって価値のあるいくつかの重要な操作をローカルコードに実装して高速化することができました。 今日、これには基本的にいくつかの特定のハッシュ関数と楕円曲線演算が含まれています。
現在、基本的なイーサリアムアカウントのsecp 256 K1とはわずかに異なる楕円曲線であるsecp 256 R1のプリコンパイルを追加するためのプッシュがあり、信頼できるハードウェアモジュールによって十分にサポートされているため、広く使用するとウォレットのセキュリティが向上します。 近年、コミュニティはBLS-12-377、BW 6-761、一般化されたペアリング、およびその他の機能のプリコンパイルの追加も推進しています。
より多くのプリコンパイルされたファイルに対するこれらの要求に対する反論は、以前に追加されたプリコンパイルの多く(RIPEMDやBLAKEなど)は予想よりもはるかに少ない使用量になり、それらから学ぶ必要があるということです。 特定の操作のためにプリコンパイルを追加するのではなく、EVM-MAXや休止状態であるが常に回復可能なSIMD提案などのアイデアに基づくより穏やかなアプローチに焦点を当てるべきであり、EVM実装は幅広いコードクラスを低コストで実行できます。 おそらく、既存のめったに使用されないプリコンパイルでさえも削除し、同じ関数のEVMコードの(必然的に効率の低下する)実装に置き換えることができます。 とはいえ、高速化するのに十分な価値のある特定の暗号化操作が存在する可能性は依然としてあるため、それらをプリコンパイル済みとして追加することは理にかなっています。
これらすべてから何を学びましたか?
できるだけカプセル化したくないという願望は理解でき、良いです。 これは、ユーザーのさまざまなニーズに簡単に適応し、ソフトウェアの肥大化の呪いを回避できるミニマリストソフトウェアを作成するというUnix哲学の伝統に由来しています。 しかし、ブロックチェーンはパーソナルコンピューティングのオペレーティングシステムではなく、社会システムです。 これは、プロトコルに特定の機能をカプセル化することが理にかなっていることを意味します。
多くの場合、これらの他の例は、アカウントの抽象化で見られるものと似ています。 しかし、私たちはいくつかの新しい教訓も学びました。
カプセル化は、スタック内の他の場所に集中化するリスクを回避するのに役立ちます。
多くの場合、基本的なプロトコルを最小限かつシンプルに保つことは、エコシステムのプロトコルの一部を超えて複雑さを押し上げます。 Unixの哲学的観点からは、これは良いことです。 ただし、プロトコル外のエコシステムが集中化するリスクがある場合がありますが、通常は固定費が高いためです(ただしそれだけではありません)。 カプセル化により、事実上の集中化が削減される場合があります。
カプセル化するコンテンツが多すぎると、プロトコルに対する信頼とガバナンスの負担が過度に拡大する可能性があります。
これは「イーサリアムのコンセンサスをオーバーロードしないでください」に関する以前の記事のトピックです:特定の機能をカプセル化すると信頼モデルが弱まり、イーサリアム全体がより「主観的」になると、イーサリアムの信頼できる中立性が弱まります。 このような場合、イーサリアム自体に導入しようとするよりも、イーサリアムの上に特定の機能をメカニズムとして提示する方が良いでしょう。 ここでは、暗号化されたメモリプールが最良の例であり、少なくともレイテンシ暗号化が改善されるまでは、カプセル化が少し難しい場合があります。
カプセル化が多すぎると、プロトコルが複雑になりすぎる可能性があります。
プロトコルの複雑さは、プロトコルにあまりにも多くの機能を追加することによって増加する可能性のある体系的なリスクです。 プリコンパイルが最良の例です。
長期的には、カプセル化機能は、ユーザーのニーズが予測できないため、裏目に出る可能性があります。
多くの人が重要だと考え、多くのユーザーによって使用される機能は、実際には定期的に使用されない可能性があります。
さらに、流動性ステーキング、ZK-EVM、およびプリコンパイルされたケースは、中道の可能性を示しています:最小限の実行可能なエンチェックメント。 プロトコルは機能全体をカプセル化する必要はありませんが、主要な課題に対処する特定の部分を含めることができるため、偏執的すぎたり狭すぎたりすることなく、機能を簡単に実装できます。 この例は次のとおりです。
完全な流動性誓約システムをカプセル化する代わりに、ステーキングペナルティルールを変更して、信頼できない流動性誓約をより実現可能にすることをお勧めします。
より多くのプリコンパイラをカプセル化する代わりに、EVM-MAXやSIMDをカプセル化して、より幅広いオペレーティングカテゴリの効率的な実装を容易にします。
EVM検証は、ロールアップの概念全体をカプセル化する代わりに、単にカプセル化することができます。
前のチャートは次のように展開できます。
何かをラップすることが理にかなっている場合があり、めったに使用されないプリコンパイルを削除することがその一例です。 前述のように、アカウント全体の抽象化もカプセル化解除の重要な形式です。 既存のユーザの後方互換性をサポートしたい場合、そのメカニズムは実際にはプリコンパイルされたカプセル化を解除するものと驚くほど似ているかもしれません:提案の1つはEIP-5003で、EOAが同じ(またはより良い)機能を持つコントラクトにアカウントを変換できるようにします。
どの機能をプロトコルに導入し、どの機能をエコシステムの他のレイヤーに任せるべきかは、複雑なトレードオフです。 このトレードオフは、ユーザーのニーズと利用可能なアイデアとテクノロジースイートの理解が改善し続けるにつれて、時間の経過とともに改善し続けると予想されます。
17k 人気度
34k 人気度
9k 人気度
8k 人気度
2k 人気度
ヴィタリック・ブテリン:イーサリアムはより多くの機能をカプセル化する必要がありますか?
プロトコルミニマリズムの初期の哲学
当時「イーサリアム2.0」と呼ばれていた初期の歴史では、クリーンでシンプルで審美的に心地よいプロトコルを作成したいという強い願望があり、可能な限り少ない労力で独自に構築しようとし、そのような作業のほとんどすべてをユーザーに任せました。 理想的には、プロトコルは単なる仮想マシンであり、チャンクの検証は単なる仮想マシン呼び出しです。
"状態遷移関数" (チャンクを処理する関数) は 1 つの VM 呼び出しであり、他のすべてのロジックはコントラクトを通じて発生します (一部のシステム レベルのコントラクトですが、ほとんどはユーザーによって提供されるコントラクトです)。 このモデルの非常に優れた特徴は、ハードフォーク全体でさえ、オフチェーンまたはオンチェーンのガバナンスによって承認され、昇格された特権で実行されるブロックプロセッサコントラクトの単一のトランザクションとして記述できることです。
2015年のこれらの議論は、特に、アカウントの抽象化とスケーリングという2つの分野に当てはまります。 スケーリングの場合、アイデアは、上のチャートの自然な拡張のように感じるスケーリングの最大抽象形式を作成しようとすることです。 コントラクトは、ほとんどのイーサリアムノードによって保存されていないデータを呼び出すことができ、プロトコルはこれを検出し、ある種の非常に一般的な拡張コンピューティング機能で呼び出しを解決します。 仮想マシンの観点からは、呼び出しは別のサブシステムに入り、しばらくすると魔法のように正しい答えを返します。
この考え方を簡単に検討しましたが、あらゆる種類のブロックチェーンスケーリングが可能であることを検証することに集中しすぎたため、すぐにあきらめました。 後で説明しますが、データ可用性サンプリングとZK-EVMの組み合わせは、イーサリアムスケーリングの可能な未来が実際にこのビジョンに非常に近いように見えることを意味します! 一方、アカウントの抽象化については、最初から何らかの実装が可能であることを知っていたため、すぐに「取引は単なる呼び出し」という純粋な出発点にできるだけ近いものを実現しようとする研究が始まりました。
トランザクションの処理と、送信者アドレスからの実際の基になるEVM呼び出しの間には、多くの定型コードがあり、その後にさらに定型コードがあります。 このコードをできるだけゼロに近づけるにはどうすればよいですか?
ここでの主なコードの1つは、トランザクションが正しいノンスと署名を持っていることを確認する役割を担うvalidate_transaction(state、tx)です。 当初から、アカウント抽象化の実用的な目標は、ユーザーが基本的な非増分検証とECDSA検証を独自の検証ロジックに置き換えて、ユーザーがソーシャルリカバリやマルチシグネチャウォレットなどの機能をより簡単に使用できるようにすることでした。 したがって、単純なEVM呼び出しとして適用を再設計する方法を見つけることは_transaction単なる「コードをクリーンにするためのクリーンなコード」タスクではありません。 代わりに、ロジックをユーザーのアカウントコードに移行して、ユーザーが必要とする柔軟性を提供します。
ただし、apply_transactionにできるだけ少ない固定ロジックが含まれていると主張すると、多くの課題が発生します。 最も初期のアカウント抽象化提案の1つであるEIP-86を見ることができます。
EIP-86をそのまま含めると、イーサリアムスタックの他の部分の複雑さが大幅に増し、本質的に同じコードを他の場所に記述する必要があるという犠牲を払って、EVMの複雑さを軽減します、同じハッシュ番号を持つ同じトランザクションがチェーンに複数回現れるなど、まったく新しい奇妙なカテゴリを導入することを除いて、複数の無効化の問題は言うまでもありません。
アカウントの抽象化における複数の無効化の問題。 オンチェーンに含まれる1つのトランザクションは、mempool内の他の何千ものトランザクションを無効にする可能性があり、mempoolを安価に氾濫させやすくなります。
それ以来、アカウントの抽象化は段階的に進化してきました。 EIP-86は後にEIP-208となり、最終的には実用的なEIP-2938となった。
ただし、EIP-2938はミニマリストではありません。 その内容は次のとおりです。
· 新しいトランザクション タイプ
· 3つの新しい取引スコープのグローバル変数
· ガス価格とガス制限チェックの処理、EVMとしてのブレークポイントの実行、1回限りの料金でのETHの一時的な保存のための非常に不格好なPAYgasオペコードを含む2つの新しいオペコード
· トランザクション検証フェーズ中に禁止されているオペコードのリストを含む、マイニングおよび再ブロードキャスト戦略の複雑なセット
イーサリアムのコア開発者(イーサリアムクライアントの最適化とマージの実装に焦点を当てている)を関与させることなくアカウントの抽象化を実装するために、EIP-2938は最終的に完全にプロトコル外のERC-4337に再設計されました。
これはERCであるため、ハードフォークを必要とせず、技術的には「イーサリアムプロトコルの外部」に存在します。 だから。。。。。。 問題は解決しましたか? そうではないことがわかりました。 ERC-4337の現在の中期ロードマップでは、実際にはERC-4337の多くを一連のプロトコル機能に変えることが含まれており、これはこのパスを検討する必要がある理由の有用な指針となる例です。
パッケージERC-4337
最終的にERC-4337をプロトコルに戻す主な理由はいくつかあります。
ガス効率:EVM内で実行される操作は、ストレージスロットなどのガス高価な機能を使用する場合の非効率性を含め、ある程度の仮想マシンのオーバーヘッドをもたらします。 現在、これらの追加の非効率性は、少なくとも20,000ガス以上になります。 これらのコンポーネントをプロトコルに入れることは、これらの問題を排除する最も簡単な方法です。
コードバグのリスク:ERC-4337の「エントリーポイント契約」に恐ろしいバグがある場合、すべてのERC-4337互換ウォレットですべての資金が枯渇する可能性があります。 コントラクトをプロトコル内機能に置き換えると、ハードフォークを介してコードエラーを修正するという暗黙の義務が生じ、それによってユーザーの資金が枯渇するリスクが排除されます。
txt.origin などの EVM オペコードのサポート。 ERC-4337 自体が txt.origin に、一連のユーザーアクションをトランザクションにパッケージ化する「バンドラー」のアドレスを返すようにします。 ネイティブアカウントの抽象化は、txt.originがトランザクションを送信する実際のアカウントを指すようにすることでこの問題を解決し、EOAと同じように機能させます。
検閲耐性:提案者とビルダーの分離の課題の1つは、個々のトランザクションのレビューが容易になることです。 この問題は、イーサリアムプロトコルが単一のトランザクションを認識できる世界で大幅に軽減でき、提案者はほとんどすべての場合に次の2つのスロットに含める必要があるトランザクションのリストを指定できます。 ただし、プロトコル外のERC-4337は、「ユーザー操作」を単一のトランザクションにカプセル化するため、ユーザー操作はイーサリアムプロトコルに対して不透明になります。 したがって、イーサリアムプロトコルによって提供される包含リストは、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チャンクを構成し、これらのチャンクにアクセスするには、証人ブランチ_costの2倍(合計3,800ガス)と証人チャンク_costの413倍(合計82,600ガス)を支払う必要があります。 そして、それはバージョン0.6.0でチェーン上に23, 689バイトを持っているERC-4337エントリポイント自体についてさえ言及し始めていません(VerkleツリーEIPルールに従ってロードするために約158, 700ガス)。
これは問題につながります:実際にこれらのコードにアクセスするためのガスコストは、トランザクション全体で何らかの形で償却する必要があります。 ERC-4337が使用している現在のアプローチはあまり良くありません:バンドル内の最初のトランザクションは1回限りのストレージ/コード読み取りコストを消費し、他のトランザクションよりもはるかに高価になります。 プロトコル内カプセル化により、これらのパブリック共有ライブラリをプロトコルの一部にし、すべての人が自由にアクセスできるようにします。
この例から何を学ぶことができますか、そしていつパッケージングがより一般的になるでしょうか? **
この例では、プロトコルでアカウントの抽象化の側面をカプセル化するためのいくつかの異なる理論的根拠が見られます。
「複雑さをエッジに押し上げる」市場ベースのアプローチは、固定費が高い場合に失敗する可能性が最も高いです。 実際、長期的なアカウントの抽象化ロードマップは、各ブロックに多くの固定費があるように見えます。 標準化されたウォレットコードをロードするための244、100ガスは1つのことです。 しかし、集約により、ZK-SNARK検証に数十万のガスが追加され、プルーフオブチェーン検証のオンチェーンコストも追加される可能性があります。 多くの市場の非効率性を導入することなく、これらのコストをユーザーに請求する方法はなく、これらの機能の一部を誰もが無料でアクセスできるプロトコル機能に変換すると、この問題がうまく解決されます。
コードのバグに対するコミュニティ全体の対応。 一部のコードスニペットがすべてのユーザーまたは非常に幅広いユーザーによって使用されている場合、通常、ブロックチェーンコミュニティは、発生したバグを修正するためにハードフォークに責任を負う方が理にかなっています。 ERC-4337は大量のグローバル共有コードを導入しており、ハードフォークを介してコードのバグを修正することは、ユーザーに多くのETHを失わせるよりも長期的には間違いなく合理的です。
場合によっては、プロトコルの機能を直接活用することで、より強力な形式を実現できます。 ここでの重要な例は、包含リストなどのプロトコル内反検閲機能です:プロトコル内の包含リストは、プロトコル外の方法よりも検閲耐性を保証でき、ユーザーレベルの操作がプロトコル内の包含リストから真に利益を得るには、単一のユーザーレベルの操作がプロトコルに対して「読み取り可能」である必要があります。 もう1つのあまり知られていない例は、BLSがプロトコルおよびネットワークレベルで実装する必要がある「集約」メカニズムをサポートしているため、BLSのカプセル化を支持して放棄されたステークキーアカウントを抽象化した2017時代のイーサリアムプルーフオブステーク設計であり、多数の署名の処理をより効率的にすることができます。
ただし、プロトコル内のアカウントの抽象化をカプセル化することでさえ、現在の状況と比較すると、依然として巨大な「カプセル化解除」であることを覚えておくことが重要です。 現在、最上位のイーサリアムトランザクションは、単一のsecp 256k1楕円曲線署名で検証された外部所有のアカウント(EOA)からのみ開始できます。 アカウントの抽象化はこれを排除し、検証基準の定義をユーザーに任せます。 したがって、アカウントの抽象化に関するこのストーリーでは、カプセル化に反対する最大の議論、つまりさまざまなユーザーのニーズを満たす柔軟性も見られます。
最近カプセル化されたと見なされた機能の他のいくつかの例を見て、このストーリーをさらに肉付けしましょう。 ZK-EVM、提案者とビルダーの分離、プライベートメモリ、流動性ステーキング、新しいプリコンパイルに特に注意を払います。
パッケージ ZK-EVM
イーサリアムプロトコルの別の潜在的なカプセル化ターゲットであるZK-EVMに注目しましょう。 現在、多数のZKロールアップがあり、ZK-SNARKでの同様のイーサリアムブロックの実行を検証するために、すべてがかなり類似したコードを記述する必要があります。 PSE ZK-EVM、Kakarot、Polygon ZK-EVM、Linea、Zethなど、独立した実装のかなり多様なエコシステムがあります。
EVM ZKロールアップスペースでの最近の論争は、ZKコードで発生する可能性のあるバグの処理方法に関係しています。 現在、これらの実行中のシステムはすべて、バグが発生した場合に構成証明システムを制御する何らかの形の「セキュリティ理事会」メカニズムを備えています。 昨年、私は、プロジェクトが認証システムと安全保障理事会に対する信頼のレベルを明確にし、時間の経過とともに組織に対する権限を徐々に低下させることを奨励するための標準化されたフレームワークを作成しようとしました。
中期的には、ロールアップは複数の認証システムに依存する可能性があり、安全保障理事会は、2つの異なる認証システムが異なる極端な場合にのみ権限を持ちます。
しかし、一部の作業は冗長に感じる感じがあります。 すでにイーサリアムベースレイヤーがあり、EVMがあり、実装のバグを処理するための実用的なメカニズムがすでにあります:バグがある場合、クライアントはそれを修正するために更新し、チェーンは機能し続けます。 バグのあるクライアントの観点からは、ファイナライズされたブロックは確認されなくなるようですが、少なくともユーザーがお金を失うことはありません。 同様に、ロールアップがEVMと同等の役割を維持したい場合、独自のガバナンスを実装して、イーサリアムベースレイヤーへのアップグレードに合わせて内部ZK-EVMルールを絶えず変更する必要がありますが、最終的にはイーサリアムベースレイヤー自体の上に構築されるため、いつアップグレードするか、新しいルールに従って。
これらのL2 ZK-EVMは基本的にイーサリアムと全く同じEVMを使用しているので、ベースレイヤーEVMの実装自体と同様に、なんとか「ZKでのEVMの実行検証」をプロトコル機能に組み込み、バグやアップグレードなどの例外をイーサリアムの社会的コンセンサスを適用して処理できないか。
これは重要でやりがいのあるトピックです。
ネイティブZK-EVMにおけるデータの可用性に関する議論の1つのトピックは、ステートフルネスです。 ZK-EVMが「監視」データを運ぶ必要がない場合、データ効率ははるかに高くなります。 つまり、特定のデータが前のブロックですでに読み書きされている場合、証明者がそれにアクセスでき、再度使用できるようにする必要がないと単純に想定できます。 ストレージとコードをリロードしないだけではありません。 ステートフル圧縮は、1つのロールアップがデータを正しく圧縮する場合、ステートレス圧縮と比較して最大3倍のデータを保存できることがわかりました。
つまり、ZK-EVM プリコンパイルには 2 つのオプションがあります。
プリコンパイルでは、すべてのデータが同じチャンクで使用可能である必要があります。 これは、証明者がステートレスになる可能性があることを意味しますが、このプリコンパイルされたZKロールアップを使用することは、カスタムコードでロールアップを使用するよりもはるかに高価であることも意味します。
プリコンパイルにより、ポインタは以前に実行、使用、または生成されたデータを指すことができます。 これにより、ZKロールアップはほぼ最適になりますが、より複雑になり、証明者によって保存する必要がある新しい状態が導入されます。
これから何を学ぶことができますか? ロールアップはすでに独自のカスタムバージョンを構築しており、イーサリアムはEVMを実行するためにL1で複数の実装とオフチェーンの社会的コンセンサスを重み付けすることをいとわないが、これは間違っていると感じているが、まったく同じ仕事をしているL2は、安全保障理事会が関与する複雑なガジェットを実装しなければならない。 しかし、その一方で、細部には大きな問題があります:ZK-EVMにはさまざまなバージョンがあり、コストとメリットが異なります。 ステートフルとステートレスの区別は、表面を傷つけるだけです。 他のシステムで実証されているカスタムコードである「ほぼEVM」をサポートしようとすると、より多くの設計スペースが公開される可能性があります。 したがって、ZK-EVM をカプセル化することは、有望かつ課題の両方を提示します。
ラッパーとビルダーの分離 (ePBS)
MEVの台頭により、ブロック生産は大規模な経済活動になり、複雑な参加者は、トランザクションのメモリプールを監視してそれらを含むだけのデフォルトのアルゴリズムよりも多くの収益を生み出すブロックを生成できるようになりました。 これまでのところ、イーサリアムコミュニティは、通常のバリデーター(「提案者」)がブロック構築を専門の参加者(「ビルダー」)にアウトソーシングできるようにするMEV-Boostなどのプロトコル外の提案者とビルダーの分離スキームを使用してこの問題を解決しようとしました。
ただし、MEV-Boostは、リレーと呼ばれる新しいクラスの参加者で信頼を前提としています。 過去2年間で、「カプセル化PBS」を作成するための多くの提案がありました。 これの利点は何ですか? この場合、答えは簡単です:プロトコル機能で直接構築されたPBSは、プロトコル機能なしで構築されたPBSよりも強力です(信頼の仮定が弱いという意味で)。 これは、カプセル化プロトコル内の価格オラクルの場合と似ていますが、この場合、強い反対もあります。
プライベート メモリ プールのカプセル化
ユーザーがトランザクションを送信すると、チェーンに含まれる前であっても、すぐに公開され、すべての人に表示されます。 これにより、多くのアプリケーションのユーザーは、プリエンプティブトランザクションなどの経済的攻撃に対して脆弱になります。
最近では、ブロックに不可逆的に受け入れられるまでユーザーのトランザクションを暗号化する「プライベートメモリプール」(または「暗号化されたメモリプール」)の作成に特化したプロジェクトが数多くあります。
しかし、問題は、そのようなスキームが特別な種類の暗号化を必要とすることです:ユーザーがシステムをフラッディングして最初に復号化するのを防ぐために、トランザクションが実際に不可逆的に受け入れられた後、暗号化を自動的に復号化する必要があります。
この形式の暗号化を実現するには、さまざまなトレードオフ手法があります。 ジョン・シャルボノーはかつてそれをうまく言いました:
フラッシュボットプロテクトなどの集中型オペレーターを暗号化します。
タイムロック暗号化は、特定の順次計算ステップの後に誰でも復号化でき、並列化することはできません。
しきい値暗号化、データの復号化を正直な多数決委員会に信頼します。 具体的な推奨事項については、「クローズドビーコンチェーンの概念」を参照してください。
SGX などの信頼できるハードウェア。
残念ながら、各暗号化には異なる弱点があります。 すべてのソリューションには、それを信頼するユーザーのサブセットがありますが、レイヤー1で実際に受け入れられるほど信頼できるソリューションはありません。 したがって、少なくともレイテンシー暗号化が完成するか、その他の技術的ブレークスルーが行われるまでは、レイヤー1でアンチアドバンストレード機能をカプセル化することは、多くのアプリケーションソリューションが登場するのに十分な価値のある機能であっても、難しい提案のように思えます。
カプセル化された流動性ステーキング
イーサリアムDeFiユーザーの一般的なニーズは、ETHをステーキングに同時に使用し、他のアプリケーションで担保として使用できることです。 もう一つの一般的なニーズは、単に便宜上です:ユーザーは、ノードを実行し、常にオンラインに保つという複雑さなしに、ステーキング(およびオンラインステーキングキーの保護)ができるようにしたいと考えています。
これまでのところ、これらのニーズの両方を満たす最も単純なステーキング「インターフェース」は、ETHを「ステークETH」に変換し、保持して元に戻すというERC 20トークンです。 実際、LidoやRocket Poolなどの流動性ステーキングプロバイダーはすでにそうし始めています。 しかし、流動性ステーキングにはいくつかの自然な集中化メカニズムがあります:ETHは最も身近で流動性が高いため、人々は自然に最大のバージョンのステーキングETHに入ります。
ステーキングETHの各バージョンには、誰が基礎となるノードオペレーターになることができるかを決定するためのメカニズムが必要です。 攻撃者が加わり、ユーザーの資金で攻撃を増幅するため、無制限にすることはできません。 現在、上位2つは、DAOホワイトリストノードオペレーターを備えたLidoと、8ETHをデポジットしたノードを誰でも実行できるロケットプールです。 2つの方法には異なるリスクがあります:ロケットプールアプローチは、攻撃者がネットワーク上で51%の攻撃を実行し、ユーザーにほとんどのコストを支払わせることを可能にします。 DAOアプローチに関しては、特定のステーキングトークンが支配的である場合、すべてのイーサリアムバリデーターのかなりの部分を制御する単一の潜在的に攻撃可能なガバナンスガジェットになります。 確かに、Lidoのようなプロトコルにはすでに予防策が講じられていますが、防御層では不十分な場合があります。
短期的には、エコシステム参加者に多様な流動性ステーキングプロバイダーの使用を促して、単一の企業からのシステミックリスクの可能性を減らすことが1つの選択肢です。 しかし、長期的には、これは不安定な均衡であり、問題を解決するために道徳的圧力に頼りすぎることは危険です。 当然の疑問が生じます:流動性ステーキングの集中化を弱めるために、プロトコルにある種の機能をカプセル化することは理にかなっていますか?
ここでの重要な質問は、どのようなプロトコル内機能かということです。 プロトコル内の代替可能な「ステーキングETH」トークンを単に作成することの問題は、ノードを実行するユーザーを選択するためにカプセル化されたイーサリアム全体のガバナンスを持っている必要があるか、オープンである必要があることですが、これにより攻撃者のツールになります。
興味深いアイデアは、流動性ステーキングの最大化に関するDankrad Feistの記事です。 まず、弾丸を噛み、イーサリアムが51%攻撃された場合、攻撃ETHの5%のみが没収される可能性があります。 これは妥当なトレードオフです。 現在2,600万ETH以上がステークされており、特に低コストで実行できる「モデル外」攻撃の数を考えると、攻撃コストの3分の1(約800万ETH)は過剰です。 実際、シングルスロットファイナリティを実装するというスーパー委員会の提案でも、同様のトレードオフが検討されています。
攻撃ETHの5%のみが没収されることを受け入れる場合、賭けられたETHの90%以上は没収の影響を受けないため、プロトコル内で代替可能な流動性ステーキングトークンとして使用でき、他のアプリケーションで使用できます。
道は面白いです。 しかし、それはまだ疑問を残します:正確に何がカプセル化されていますか? ロケットプールは非常によく似た仕組みで、各ノードオペレーターが資金を提供し、残りを流動性ステーカーが提供します。 いくつかの定数を調整するだけで、最大ペナルティを2ETHに制限することができ、ロケットプールの既存のrETHはリスクフリーになります。
簡単なプロトコル調整で、他のスマートなことも実行できます。 たとえば、ノードオペレーター(高い担保要件)と預金者(最低担保要件がなく、いつでも参加および退出できる)の2つの「層」のステーキングを備えたシステムが必要だが、含めなければならないトランザクションのリストを提案するなど、ランダムにサンプリングされた預金者委員会に権限を与えることで、ノードオペレーターの集中化を防ぎたいとします(検閲に強い理由から)、非アクティブなリーク中のフォーク選択の制御、またはブロック署名の要求。 これは、各バリデーターが(i)通常のステーキングキー、および(ii)セカンダリステーキングキーを出力するために各スロットで呼び出すことができるETHアドレスを提供するようにプロトコルを微調整することにより、本質的にプロトコルから切り離す方法で実現できます。 プロトコルは両方のキーに電力を与えますが、各スロットの2番目のキーを選択するメカニズムはステーキングプールプロトコルに任せることができます。 一部の機能を直接カプセル化する方がよい場合もありますが、この「いくつかのものを含め、他のすべてをユーザーに任せる」設計スペースが存在することに注意してください。
より多くのプリコンパイルをカプセル化する
プリコンパイル済み(または「プリコンパイル済みコントラクト」)は、複雑な暗号化操作を実装するイーサリアムコントラクトであり、そのロジックはEVMスマートコントラクトコードではなく、クライアントコードにネイティブに実装されています。 プリコーディングはイーサリアム開発の初期に採用された妥協案でした:仮想マシンのオーバーヘッドは非常に複雑で高度に専門化されたコードには大きすぎるため、重要なアプリケーションにとって価値のあるいくつかの重要な操作をローカルコードに実装して高速化することができました。 今日、これには基本的にいくつかの特定のハッシュ関数と楕円曲線演算が含まれています。
現在、基本的なイーサリアムアカウントのsecp 256 K1とはわずかに異なる楕円曲線であるsecp 256 R1のプリコンパイルを追加するためのプッシュがあり、信頼できるハードウェアモジュールによって十分にサポートされているため、広く使用するとウォレットのセキュリティが向上します。 近年、コミュニティはBLS-12-377、BW 6-761、一般化されたペアリング、およびその他の機能のプリコンパイルの追加も推進しています。
より多くのプリコンパイルされたファイルに対するこれらの要求に対する反論は、以前に追加されたプリコンパイルの多く(RIPEMDやBLAKEなど)は予想よりもはるかに少ない使用量になり、それらから学ぶ必要があるということです。 特定の操作のためにプリコンパイルを追加するのではなく、EVM-MAXや休止状態であるが常に回復可能なSIMD提案などのアイデアに基づくより穏やかなアプローチに焦点を当てるべきであり、EVM実装は幅広いコードクラスを低コストで実行できます。 おそらく、既存のめったに使用されないプリコンパイルでさえも削除し、同じ関数のEVMコードの(必然的に効率の低下する)実装に置き換えることができます。 とはいえ、高速化するのに十分な価値のある特定の暗号化操作が存在する可能性は依然としてあるため、それらをプリコンパイル済みとして追加することは理にかなっています。
これらすべてから何を学びましたか?
できるだけカプセル化したくないという願望は理解でき、良いです。 これは、ユーザーのさまざまなニーズに簡単に適応し、ソフトウェアの肥大化の呪いを回避できるミニマリストソフトウェアを作成するというUnix哲学の伝統に由来しています。 しかし、ブロックチェーンはパーソナルコンピューティングのオペレーティングシステムではなく、社会システムです。 これは、プロトコルに特定の機能をカプセル化することが理にかなっていることを意味します。
多くの場合、これらの他の例は、アカウントの抽象化で見られるものと似ています。 しかし、私たちはいくつかの新しい教訓も学びました。
カプセル化は、スタック内の他の場所に集中化するリスクを回避するのに役立ちます。
多くの場合、基本的なプロトコルを最小限かつシンプルに保つことは、エコシステムのプロトコルの一部を超えて複雑さを押し上げます。 Unixの哲学的観点からは、これは良いことです。 ただし、プロトコル外のエコシステムが集中化するリスクがある場合がありますが、通常は固定費が高いためです(ただしそれだけではありません)。 カプセル化により、事実上の集中化が削減される場合があります。
カプセル化するコンテンツが多すぎると、プロトコルに対する信頼とガバナンスの負担が過度に拡大する可能性があります。
これは「イーサリアムのコンセンサスをオーバーロードしないでください」に関する以前の記事のトピックです:特定の機能をカプセル化すると信頼モデルが弱まり、イーサリアム全体がより「主観的」になると、イーサリアムの信頼できる中立性が弱まります。 このような場合、イーサリアム自体に導入しようとするよりも、イーサリアムの上に特定の機能をメカニズムとして提示する方が良いでしょう。 ここでは、暗号化されたメモリプールが最良の例であり、少なくともレイテンシ暗号化が改善されるまでは、カプセル化が少し難しい場合があります。
カプセル化が多すぎると、プロトコルが複雑になりすぎる可能性があります。
プロトコルの複雑さは、プロトコルにあまりにも多くの機能を追加することによって増加する可能性のある体系的なリスクです。 プリコンパイルが最良の例です。
長期的には、カプセル化機能は、ユーザーのニーズが予測できないため、裏目に出る可能性があります。
多くの人が重要だと考え、多くのユーザーによって使用される機能は、実際には定期的に使用されない可能性があります。
さらに、流動性ステーキング、ZK-EVM、およびプリコンパイルされたケースは、中道の可能性を示しています:最小限の実行可能なエンチェックメント。 プロトコルは機能全体をカプセル化する必要はありませんが、主要な課題に対処する特定の部分を含めることができるため、偏執的すぎたり狭すぎたりすることなく、機能を簡単に実装できます。 この例は次のとおりです。
完全な流動性誓約システムをカプセル化する代わりに、ステーキングペナルティルールを変更して、信頼できない流動性誓約をより実現可能にすることをお勧めします。
より多くのプリコンパイラをカプセル化する代わりに、EVM-MAXやSIMDをカプセル化して、より幅広いオペレーティングカテゴリの効率的な実装を容易にします。
EVM検証は、ロールアップの概念全体をカプセル化する代わりに、単にカプセル化することができます。
前のチャートは次のように展開できます。
何かをラップすることが理にかなっている場合があり、めったに使用されないプリコンパイルを削除することがその一例です。 前述のように、アカウント全体の抽象化もカプセル化解除の重要な形式です。 既存のユーザの後方互換性をサポートしたい場合、そのメカニズムは実際にはプリコンパイルされたカプセル化を解除するものと驚くほど似ているかもしれません:提案の1つはEIP-5003で、EOAが同じ(またはより良い)機能を持つコントラクトにアカウントを変換できるようにします。
どの機能をプロトコルに導入し、どの機能をエコシステムの他のレイヤーに任せるべきかは、複雑なトレードオフです。 このトレードオフは、ユーザーのニーズと利用可能なアイデアとテクノロジースイートの理解が改善し続けるにつれて、時間の経過とともに改善し続けると予想されます。