原文:多次元ガス価格設定
編集者: Odaily Planet デイリー・アッシャー
イーサリアム ネットワークでは、リソースは制限されており、単一リソース「ガス」を通じて価格が設定されます。ガスは、特定のトランザクションまたはブロックを処理するために必要な「計算量」の尺度です。ガスにはいくつかの種類の「努力」が組み合わされていますが、最も重要なものは次のとおりです。
基本的な計算 ( ADD 、 MULTIPLY など)
Ethereum ストレージの読み取りおよび書き込み (SSTORE、SLOAD、ETH 転送など)
データ帯域幅
ブロックZK-SNARKプルーフを生成するコスト
たとえば、 このトランザクションには合計 47,085 ガスの費用がかかりました。これには、(i) 「基本料金」として 21,000 ガス、(ii) トランザクションの一部としての呼び出しデータ バイトとして 1,556 ガス、(iv) ログ作成のための 2,149 ガスが含まれます。残りはEVMの実行に使用されます。ユーザーが支払わなければならない取引手数料は、取引によって消費されたガスに比例します。ブロックには最大 3,000 万のガスを含めることができ、平均ブロックに 1,500 万のガスが含まれるように、ガス価格はEIP-1559 ターゲット メカニズムを通じて継続的に調整されます。
このアプローチには 1 つの大きな利点があります。すべての取引が 1 つの仮想リソースに統合されるため、市場設計が非常にシンプルになります。コストを最小限に抑えるためにトランザクションを最適化することは簡単で、可能な限り最高の手数料 ( MEVを除く) を請求するためにブロックを最適化することも比較的簡単です。また、手数料を節約するために特定のトランザクションを他のトランザクションとバンドルするという奇妙なインセンティブもありません。
しかし、このアプローチには大きな非効率性もあります。つまり、ネットワークが処理できるものの実際の基本的な制限がそうではないにもかかわらず、さまざまなリソースを相互変換可能として扱います。この問題を理解する 1 つの方法は、以下の画像を見ることです。
𝑛 リソースに重大なセキュリティ制約がある場合、1 次元の Gas はスループットを最大 𝑛 倍低下させる可能性があります。したがって、多次元Gasの概念には長年の関心があり、EIP-4844を通じて、今日ではイーサリアム上で実際に多次元Gasを使用できるようになりました。この記事では、このアプローチの利点と、それをさらに改善する可能性について説明します。
ブロブ: カンクンのアップグレードされた多次元ガス
今年の初めの時点では、平均ブロックサイズは 150 KB でした。これの大部分は畳み込みデータ、つまりセキュリティのためにデータをオンチェーンに保存するL2 プロトコルです。このデータのコストは高くなります。コンボリューションでのトランザクション コストは、イーサリアム L1 での対応するトランザクション コストよりも 5 ～ 10 分の 1 です。ただし、このコストでさえ、多くのユースケースでは高すぎます。
この問題は、各ブロックに個別の畳み込みに適したデータ空間 (「ブロブ」と呼ばれる) を導入することで最終的に解決されました。
カンクンのアップグレード後、イーサリアム ブロックには最大 (i) 3,000 万のガスと (ii) 6 つの Blob を含めることができ、それぞれに約 125 KB の通話データを含めることができます。どちらのリソースにも独立した価格があり、 EIP-1559 と同様の独立した価格設定メカニズムによって調整され、ブロックあたり 1,500 万ガスと 3 Blob の平均使用量を目標としています。
その結果、畳み込みのコストは 100 分の 1 に削減され、畳み込みのトランザクション量は 3 倍以上増加しますが、理論上の最大ブロック サイズはわずかに増加します (1.9 MB から 2.6 MB へ)。
ローリング取引手数料 ( growthepie.xyzによって提供されます)。 Dencun フォークは 2024 年 3 月 13 日に発生し、BLOB の多次元の価格設定が導入されました。
多次元ガスとステートレスクライアント
将来的には、ステートレスクライアントは証拠の保存という問題に直面するでしょう。ステートレス クライアントは、データをローカルにほとんどまたはまったく保存せずに、ブロックチェーンを検証できる新しいタイプのクライアントです。データ自体を保存せずに、ブロックの特定部分のイーサリアムの状態を検証するための証明を受け入れます。
ブロックは平均して約 1,000 回のストレージ読み取りおよび書き込み操作を実行しますが、理論上の最大値は数千万回になる可能性があります。現在の計画は、イーサリアムのステート ツリー設計を Merkle Patricia ツリーから Verkle ツリーに移行することで、ステートレス クライアントをサポートすることです。ただし、Verkle ツリーは量子耐性がないため、新しい STARK 証明システムには適していません。
したがって、多くの人は、Verkle を完全にスキップするか、Verkle の移行から数年後にアップグレードして、バイナリ Merkle ツリーと STARK を通じてステートレス クライアントをサポートしたいと考えています。バイナリ ハッシュ ツリー ブランチの STARK 証明には多くの利点がありますが、証明の生成は遅く、高速要件を満たすことができません。
将来的には、1000 個の値を 1 秒以内に証明できる時代が来ると予想されますが、 14,285 個の値の速度は達成されないでしょう。この問題を解決するために、多次元気体の概念が提案されています。この方法では、ストレージ アクセスをそれぞれ制限および課金することができ、ブロックあたりの平均ストレージ アクセスが 1,000 回になるようにする一方で、ネットワークのセキュリティと効率を向上させるためにブロックあたり 2,000 回の制限を設定します。
多次元ガスの幅広い用途
州サイズの拡大も考慮すべきリソースです。イーサリアムの状態サイズを増やす場合、フルノードはより多くのデータを保持する必要があります。他のリソースとは異なり、状態サイズの増加は主に、短期的な急増ではなく、長期的な継続的な使用によって制限されます。したがって、状態サイズが大きくなる操作を処理するには、別の Gas ディメンションを追加することを検討してください。このアプローチの目標は、ブロックごとの制限を設定するのではなく、特定の平均使用量を対象としたスライド価格を設定することです。
これは、リソースごとに異なる質問をすることができる多次元 Gas の強力な性質を示しています。(i) 各リソースの理想的な平均使用量は何か、(ii) 各リソースの安全な最大使用量は何か。これらのパラメータを設定することで、各ブロックの最大使用量ではなく、ネットワークのセキュリティに基づいてガスの価格を調整できます。より複雑な状況に対処する場合は、複数のガスを使用できます。たとえば、ゼロからゼロ以外の SSTORE 操作では、ステートレス クライアント認証ガスやストレージ拡張ガスなど、さまざまな種類のガスを消費できます。
トランザクションごとの最大価値: 多次元ガスを取得するための、より強力だがよりシンプルな戦略
1 次元の Gas システムでは、トランザクションの Gas コストは、データと計算の両方で消費された Gas に基づいて決定されます。ただし、多次元のガス システムでは、トランザクションで消費される主なリソースに基づいてガスのコストを決定できます。このアプローチにより、セキュリティを維持しながらスループットが向上します。
EIP-7623 は、バイトあたりの最低価格を引き上げることでブロック内のトランザクションが占有するスペースを削減する同様のソリューションを提案しましたが、これはまた、より多くの個別リソースを消費するトランザクションは依然として高額の手数料を支払わなければならないなど、いくつかの問題を引き起こしました。また、コストを節約するために、データ集約型トランザクションと計算集約型トランザクションをまとめてバンドルするインセンティブも生み出します。このアプローチには制限がありますが、その利点にはそれだけの価値があります。しかし、開発作業をさらに進めたい場合は、より理想的なソリューションがあります。
多次元 EIP-1559: より困難だがより理想的な戦略
多次元 EIP-1559 の中核は、ブロックの平均使用量が目標レベルにとどまるように、excess_blobs パラメーターを追跡することで BLOB の基本料金を調整することです。
ブロックに含まれる BLOB の数が目標値を超えると、使用量を減らすために基本料金が増加し、それ以外の場合は減少します。この価格設定メカニズムにより、ブロック内のトランザクション価格を動的に調整して、ブロックを半分だけ満たした状態に保つことができます。同時に、短期的に使用量が急増すると、取引における合理的な競争を確保するための制限メカニズムも発動されます。
イーサリアムでは、このガス価格設定方法は長年にわたって存在しており、2020 年に EIP-1559 で非常によく似たメカニズムが導入されました。 EIP-4844 の導入により、Gas と Blob には 2 つの変動価格が存在します。
ユーザーとブロックビルダーにとって、エクスペリエンスは以前と同様ですが、対応するために 2 つの別々の料金が必要になります。ただし、開発者にとっては、複数価格および複数制限環境に適応するために EVM 機能を再設計する必要があるため、いくつかの課題が追加される可能性があります。
多次元の価格設定、EVM、およびサブコール
EVM には、トランザクションごとに設定される合計の Gas 制限と、コントラクトが他のコントラクトを呼び出すときの個別の Gas 制限の 2 種類の Gas 制限があります。これにより、コントラクトは、呼び出し後に他の計算のためのガスがまだ残っていることを確認しながら、信頼できないコントラクトを呼び出すことができます。ただし、さまざまな種類の執行にわたって多次元のガス価格設定を実現するには課題があります。この多次元アプローチでは、ガス タイプごとに複数の制限を提供するサブコールが必要ですが、これは EVM にとって大幅な変更となり、既存のアプリケーションと互換性がありません。
多次元の Gas 提案は、多くの場合、データと実行という 2 つの次元だけで止まります。データは EVM の外部に分散されるため、個別に価格を設定するために内部変更を行う必要はありません。開発者にとって、これは、複数の価格と複数の制約に対応するために、EVM とその周囲のインフラストラクチャを再設計することを意味します。場合によっては、どの方法がより効果的であるかを明確に言うことができないため、最適化がより困難になる可能性があり、開発プロセスに影響を与える可能性があります。
いくつかの課題はありますが、EIP-7623 と同様のものを実装することで解決できます。このスキームでは、ストレージ操作に追加料金を請求し、トランザクションの終了時に返金して、メイン呼び出しに後続の操作を実行するのに十分なガスが残っていることを確認できます。
まとめ
いずれの場合でも、多次元実行ガスの導入が開始されると、システムの複雑さが大幅に増加することは避けられないと思われることを強調する価値があります。
したがって、私たちは複雑な決断を迫られています。L1 スケーラビリティのロックを解除することによる大きなメリットと引き換えに、EVM レベルでのさらなる複雑さを受け入れるかどうか、受け入れる場合、どの具体的な提案がプロトコルの経済性とアプリケーション開発担当者にとってより適しているかということです。 ?おそらく、最良のソリューションはこれまでに説明したものでも上で説明したものでもありません。より洗練された効率的なソリューションを考え出す余地がまだあります。
IOS
Android