# イーサリアムスマートコントラクトのGas最適化ベストプラクティスイーサリアムのメインネットのGas費用は常に厄介な問題であり、特にネットワークが混雑している時にはより顕著です。ピーク時にはユーザーは高額な取引手数料を支払う必要があることがよくあります。したがって、スマートコントラクトの開発段階でGas費用の最適化を行うことが非常に重要です。Gas消費の最適化は、取引コストを効果的に削減するだけでなく、取引効率を向上させ、ユーザーにとってより経済的で効率的なブロックチェーン体験を提供します。この記事では、イーサリアム仮想マシン(EVM)のGas料金メカニズム、Gas料金最適化の核心概念、およびスマートコントラクトを開発する際のGas料金最適化のベストプラクティスについて概説します。これらの内容が開発者にインスピレーションと実用的な支援を提供し、一般ユーザーがEVMのGas料金の運用方法をよりよく理解し、ブロックチェーンエコシステムの課題に共同で対処できることを願っています。## EVMのGas料金メカニズムの概要EVM互換のネットワークでは、「Gas」は特定の操作を実行するために必要な計算能力を測る単位です。EVMの構造レイアウトでは、Gas消費は操作の実行、外部メッセージの呼び出し、およびメモリとストレージの読み書きの3つの部分に分かれています。各取引の実行には計算リソースが必要なため、無限ループやサービス拒否(DoS)攻撃を防ぐために一定の手数料が徴収されます。取引を完了するために必要な手数料は「Gas費」と呼ばれます。EIP-1559(ロンドンハードフォーク)が有効になって以来、Gas料金は以下の式で計算されます:ガス料金 = 使用されたガスの単位 * (ベース料金 + プライオリティ料金)基礎費用は廃棄され、優先費用はインセンティブとして機能し、バリデーターが取引をブロックチェーンに追加することを奨励します。取引を送信する際により高い優先費用を設定することで、取引が次のブロックに含まれる可能性を高めることができます。これはユーザーがバリデーターに支払う「チップ」のようなものです。### 1. EVMにおけるGasの最適化を理解するSolidityでスマートコントラクトをコンパイルすると、コントラクトは一連の"オペコード"、すなわちopcodesに変換されます。任意の操作コード(、例えば契約の作成、メッセージ呼び出しの実行、アカウントストレージへのアクセス、および仮想マシン上での操作の実行)には、公認のGas消費コストがあります。これらのコストはイーサリアムのホワイトペーパーに記録されています。複数回のEIPの修正を経て、一部のオペコードのGasコストが調整され、黄皮書の内容と異なる可能性があります。### 2.ガス最適化の基本概念Gasの最適化の核心理念は、EVMブロックチェーン上でコスト効率の高い操作を優先的に選択し、Gasコストの高い操作を避けることです。EVMでは、以下の操作のコストが低いです:- メモリ変数の読み書き- 定数と不変変数の読み取り - ローカル変数を読み書きする- calldata 配列や構造体などの calldata 変数を読み取る- 内部関数呼び出しコストが高い操作には次のものが含まれます:- コントラクトストレージに保存されている状態変数の読み書き- 外部関数呼び出し- ループ操作## EVMガス料金最適化のベストプラクティス上述の基本概念に基づいて、私たちは開発者コミュニティのためにGas費用最適化のベストプラクティスリストを整理しました。これらのプラクティスに従うことで、開発者はスマートコントラクトのGas費用消費を削減し、取引コストを低下させ、より効率的でユーザーフレンドリーなアプリケーションを構築できます。### 1.ストレージの使用をできるだけ減らすSolidityにおいて、Storage(ストレージ)は限られたリソースであり、そのGas消費はMemory(メモリ)よりもはるかに高いです。スマートコントラクトがストレージからデータを読み取ったり書き込んだりするたびに、高額なGasコストが発生します。イーサリアムのホワイトペーパーの定義によれば、ストレージ操作のコストはメモリ操作の100倍以上高いです。例えば、OPcodesmloadとmstore命令は3ガス単位しか消費しないのに対し、ストレージ操作であるsloadとsstoreは、最も理想的な状況でもコストが少なくとも100単位必要です。ストレージ使用の制限方法には、以下が含まれます:- 非永続データをメモリに保存する- ストレージの変更回数を減らす: 中間結果をメモリに保存し、すべての計算が完了した後に結果をストレージ変数に割り当てます。! [イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス](https://img-cdn.gateio.im/social/moments-30f0bc370a7b9ca65f3d623c31262b76)### 2. 変数パッキングスマートコントラクト中使用のStorage slot(ストレージスロット)の数量および開発者がデータを表現する方法は、Gas費の消費に大きく影響します。Solidityコンパイラは、コンパイルプロセス中に連続したストレージ変数をパッケージ化し、32バイトのストレージスロットを変数ストレージの基本単位として使用します。変数のパッケージ化とは、変数を合理的に配置することで、複数の変数が単一のストレージスロットに適合できるようにすることを指します。この詳細な調整により、開発者は20,000ガス単位(を節約できます。未使用のストレージスロットを保存するには20,000ガス)が必要ですが、現在は2つのストレージスロットのみが必要です。各ストレージスロットはGasを消費するため、変数のパッケージ化は必要なストレージスロットの数を減らすことによってGasの使用を最適化します。### 3. データタイプの最適化変数は様々なデータ型で表現できますが、異なるデータ型に対応する操作コストも異なります。適切なデータ型を選択することで、Gasの使用を最適化するのに役立ちます。例えば、Solidityでは整数は異なるサイズに細分化できます:uint8、uint16、uint32など。EVMが256ビット単位で操作を実行するため、uint8を使用するとEVMは最初にそれをuint256に変換する必要があり、この変換は追加のガスを消費します。単独で見ると、ここでuint256を使用する方がuint8よりも安価です。しかし、以前に提案した変数のパッキング最適化を使用する場合は異なります。開発者が4つのuint8変数を1つのストレージスロットにパッキングできるなら、それらを反復処理する総コストは4つのuint256変数よりも低くなります。こうすることで、スマートコントラクトは1回のストレージスロットの読み書きで、1回の操作で4つのuint8変数をメモリ/ストレージに入れることができます。! [イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス](https://img-cdn.gateio.im/social/moments-55fcdb765912ef9cd238c46b1d248cff)### 4. 固定サイズの変数を動的変数の代わりに使用するデータが32バイト以内に制御できる場合は、bytesまたはstringsの代わりにbytes32データ型を使用することをお勧めします。一般的に、固定サイズの変数は可変サイズの変数よりもガスを少なく消費します。バイトの長さを制限できる場合は、bytes1からbytes32の最小長を選択するようにしてください。### 5. マッピングと配列Solidityのデータリストは、2つのデータ型で表すことができます: 配列(Arrays)とマッピング(Mappings)ですが、それらの構文と構造はまったく異なります。マッピングはほとんどの場合、効率が高くコストが低いですが、配列はイテラブルでデータ型のパッキングをサポートしています。したがって、データリストを管理する際には、イテレーションが必要な場合やデータ型のパッキングによってガス消費を最適化できる場合を除いて、マッピングを優先して使用することをお勧めします。! [イーサリアムスマートコントラクトのガス最適化のためのトップ10ベストプラクティス](https://img-cdn.gateio.im/social/moments-5f3d7e103e47c886f50599cffe35c707)### 6. メモリの代わりに calldata を使用する関数の引数で宣言された変数は、calldataまたはmemoryに格納できます。二者の主な違いは、memoryは関数によって変更可能であり、calldataは不変であるということです。この原則を覚えておいてください: 関数の引数が読み取り専用である場合、memoryではなくcalldataを優先的に使用すべきです。これにより、関数のcalldataからmemoryへの不必要なコピー操作を避けることができます。### 7. 可能な限り Constant/Immutable キーワードを使用してくださいConstant/Immutable変数は、コントラクトのストレージに保存されません。これらの変数はコンパイル時に計算され、コントラクトのバイトコードに保存されます。したがって、ストレージと比較して、アクセスコストははるかに低くなるため、可能な限りConstantまたはImmutableキーワードを使用することをお勧めします。! [イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス](https://img-cdn.gateio.im/social/moments-9c566626ab499ef65d6f5089a2876ad3)### 8. オーバーフロー/アンダーフローが発生しないことを確認した上でUncheckedを使用する開発者が算術操作がオーバーフローやアンダーフローを引き起こさないことを確認できる場合、Solidity v0.8.0で導入されたuncheckedキーワードを使用して、余分なオーバーフローやアンダーフローのチェックを回避し、Gasコストを節約できます。さらに、0.8.0以上のバージョンのコンパイラではSafeMathライブラリを使用する必要がなくなりました。なぜなら、コンパイラ自体にオーバーフローとアンダーフローの保護機能が組み込まれているからです。### 9. オプティマイザモディファイアのコードは、修正された関数に埋め込まれており、モディファイアを使用するたびにそのコードがコピーされます。これにより、バイトコードのサイズが増加し、ガス消費が増加します。内部関数_checkOwner()にロジックを再構築することにより、修飾子内でこの内部関数を再利用できるようになり、バイトコードのサイズを削減し、Gasコストを低減することができます。! [イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス](https://img-cdn.gateio.im/social/moments-c0701f9e09280a1667495d54e262dd2f)### 10. ショートサーキット最適化||および&&演算子に関して、論理演算はショートサーキット評価が行われます。つまり、最初の条件が論理式の結果を決定できる場合、2番目の条件は評価されません。Gas消費を最適化するためには、計算コストが低い条件を前に置くべきです。そうすることで、コストの高い計算をスキップできる可能性があります。! [イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス](https://img-cdn.gateio.im/social/moments-a823fb7761aafa6529a6c45304e0314b)## その他の一般的な推奨事項### 1. 不要なコードを削除する契約に未使用の関数や変数が存在する場合は、それを削除することをお勧めします。これは、契約のデプロイコストを削減し、契約のサイズを小さく保つ最も直接的な方法です。以下は幾つかの実用的なアドバイスです:最も効率的なアルゴリズムを使用して計算を行います。契約内で特定の計算結果を直接使用する場合は、これらの冗長な計算プロセスを排除すべきです。本質的に、使用されていない計算は削除されるべきです。イーサリアムでは、開発者はストレージスペースを解放することでGas報酬を得ることができます。不要になった変数がある場合は、deleteキーワードを使用して削除するか、デフォルト値に設定する必要があります。ループ最適化: 高コストのループ操作を避け、可能な限りループを統合し、繰り返し計算をループ本体から移動します。### 2. プリコンパイルされたスマートコントラクトを使用するプレコンパイルされたコントラクトは、暗号化やハッシュ操作などの複雑なライブラリ関数を提供します。コードはEVM上で実行されるのではなく、クライアントノードのローカルで実行されるため、必要なGasが少なくて済みます。プレコンパイルされたコントラクトを使用することで、スマートコントラクトの実行に必要な計算作業を減らすことができ、Gasを節約できます。プレコンパイルされたコントラクトの例には、楕円曲線デジタル署名アルゴリズム(ECDSA)およびSHA2-256ハッシュアルゴリズムが含まれます。スマートコントラクト内でこれらのプレコンパイルされたコントラクトを使用することにより、開発者はガスコストを削減し、アプリケーションの実行効率を向上させることができます。### 3. インラインアセンブリコードを使用するインラインアセンブリ(in-line assembly)は、開発者がEVMによって直接実行可能な低レベルかつ高効率なコードを記述することを可能にし、高価なSolidityオペコードを使用する必要がありません。インラインアセンブリは、メモリとストレージの使用をより正確に制御することも可能にし、さらにGas料金を削減します。さらに、インラインアセンブリは、Solidityのみを使用して実現するのが難しい複雑な操作を実行でき、Gas消費の最適化に対してより多くの柔軟性を提供します。しかし、インラインアセンブリの使用はリスクを伴い、エラーが発生しやすくなります。したがって、経験豊富な開発者の操作に限定して慎重に使用するべきです。### 4. Layer 2ソリューションの使用Layer 2ソリューションを使用することで、イーサリアムメインネット上に保存および計算する必要があるデータを削減できます。
14の方法でイーサリアムのスマートコントラクトのGas費用を最適化し、開発者のコストをドロップする
イーサリアムスマートコントラクトのGas最適化ベストプラクティス
イーサリアムのメインネットのGas費用は常に厄介な問題であり、特にネットワークが混雑している時にはより顕著です。ピーク時にはユーザーは高額な取引手数料を支払う必要があることがよくあります。したがって、スマートコントラクトの開発段階でGas費用の最適化を行うことが非常に重要です。Gas消費の最適化は、取引コストを効果的に削減するだけでなく、取引効率を向上させ、ユーザーにとってより経済的で効率的なブロックチェーン体験を提供します。
この記事では、イーサリアム仮想マシン(EVM)のGas料金メカニズム、Gas料金最適化の核心概念、およびスマートコントラクトを開発する際のGas料金最適化のベストプラクティスについて概説します。これらの内容が開発者にインスピレーションと実用的な支援を提供し、一般ユーザーがEVMのGas料金の運用方法をよりよく理解し、ブロックチェーンエコシステムの課題に共同で対処できることを願っています。
EVMのGas料金メカニズムの概要
EVM互換のネットワークでは、「Gas」は特定の操作を実行するために必要な計算能力を測る単位です。
EVMの構造レイアウトでは、Gas消費は操作の実行、外部メッセージの呼び出し、およびメモリとストレージの読み書きの3つの部分に分かれています。
各取引の実行には計算リソースが必要なため、無限ループやサービス拒否(DoS)攻撃を防ぐために一定の手数料が徴収されます。取引を完了するために必要な手数料は「Gas費」と呼ばれます。
EIP-1559(ロンドンハードフォーク)が有効になって以来、Gas料金は以下の式で計算されます:
ガス料金 = 使用されたガスの単位 * (ベース料金 + プライオリティ料金)
基礎費用は廃棄され、優先費用はインセンティブとして機能し、バリデーターが取引をブロックチェーンに追加することを奨励します。取引を送信する際により高い優先費用を設定することで、取引が次のブロックに含まれる可能性を高めることができます。これはユーザーがバリデーターに支払う「チップ」のようなものです。
1. EVMにおけるGasの最適化を理解する
Solidityでスマートコントラクトをコンパイルすると、コントラクトは一連の"オペコード"、すなわちopcodesに変換されます。
任意の操作コード(、例えば契約の作成、メッセージ呼び出しの実行、アカウントストレージへのアクセス、および仮想マシン上での操作の実行)には、公認のGas消費コストがあります。これらのコストはイーサリアムのホワイトペーパーに記録されています。
複数回のEIPの修正を経て、一部のオペコードのGasコストが調整され、黄皮書の内容と異なる可能性があります。
2.ガス最適化の基本概念
Gasの最適化の核心理念は、EVMブロックチェーン上でコスト効率の高い操作を優先的に選択し、Gasコストの高い操作を避けることです。
EVMでは、以下の操作のコストが低いです:
コストが高い操作には次のものが含まれます:
EVMガス料金最適化のベストプラクティス
上述の基本概念に基づいて、私たちは開発者コミュニティのためにGas費用最適化のベストプラクティスリストを整理しました。これらのプラクティスに従うことで、開発者はスマートコントラクトのGas費用消費を削減し、取引コストを低下させ、より効率的でユーザーフレンドリーなアプリケーションを構築できます。
1.ストレージの使用をできるだけ減らす
Solidityにおいて、Storage(ストレージ)は限られたリソースであり、そのGas消費はMemory(メモリ)よりもはるかに高いです。スマートコントラクトがストレージからデータを読み取ったり書き込んだりするたびに、高額なGasコストが発生します。
イーサリアムのホワイトペーパーの定義によれば、ストレージ操作のコストはメモリ操作の100倍以上高いです。例えば、OPcodesmloadとmstore命令は3ガス単位しか消費しないのに対し、ストレージ操作であるsloadとsstoreは、最も理想的な状況でもコストが少なくとも100単位必要です。
ストレージ使用の制限方法には、以下が含まれます:
! イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス
2. 変数パッキング
スマートコントラクト中使用のStorage slot(ストレージスロット)の数量および開発者がデータを表現する方法は、Gas費の消費に大きく影響します。
Solidityコンパイラは、コンパイルプロセス中に連続したストレージ変数をパッケージ化し、32バイトのストレージスロットを変数ストレージの基本単位として使用します。変数のパッケージ化とは、変数を合理的に配置することで、複数の変数が単一のストレージスロットに適合できるようにすることを指します。
この詳細な調整により、開発者は20,000ガス単位(を節約できます。未使用のストレージスロットを保存するには20,000ガス)が必要ですが、現在は2つのストレージスロットのみが必要です。
各ストレージスロットはGasを消費するため、変数のパッケージ化は必要なストレージスロットの数を減らすことによってGasの使用を最適化します。
3. データタイプの最適化
変数は様々なデータ型で表現できますが、異なるデータ型に対応する操作コストも異なります。適切なデータ型を選択することで、Gasの使用を最適化するのに役立ちます。
例えば、Solidityでは整数は異なるサイズに細分化できます:uint8、uint16、uint32など。EVMが256ビット単位で操作を実行するため、uint8を使用するとEVMは最初にそれをuint256に変換する必要があり、この変換は追加のガスを消費します。
単独で見ると、ここでuint256を使用する方がuint8よりも安価です。しかし、以前に提案した変数のパッキング最適化を使用する場合は異なります。開発者が4つのuint8変数を1つのストレージスロットにパッキングできるなら、それらを反復処理する総コストは4つのuint256変数よりも低くなります。こうすることで、スマートコントラクトは1回のストレージスロットの読み書きで、1回の操作で4つのuint8変数をメモリ/ストレージに入れることができます。
! イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス
4. 固定サイズの変数を動的変数の代わりに使用する
データが32バイト以内に制御できる場合は、bytesまたはstringsの代わりにbytes32データ型を使用することをお勧めします。一般的に、固定サイズの変数は可変サイズの変数よりもガスを少なく消費します。バイトの長さを制限できる場合は、bytes1からbytes32の最小長を選択するようにしてください。
5. マッピングと配列
Solidityのデータリストは、2つのデータ型で表すことができます: 配列(Arrays)とマッピング(Mappings)ですが、それらの構文と構造はまったく異なります。
マッピングはほとんどの場合、効率が高くコストが低いですが、配列はイテラブルでデータ型のパッキングをサポートしています。したがって、データリストを管理する際には、イテレーションが必要な場合やデータ型のパッキングによってガス消費を最適化できる場合を除いて、マッピングを優先して使用することをお勧めします。
! イーサリアムスマートコントラクトのガス最適化のためのトップ10ベストプラクティス
6. メモリの代わりに calldata を使用する
関数の引数で宣言された変数は、calldataまたはmemoryに格納できます。二者の主な違いは、memoryは関数によって変更可能であり、calldataは不変であるということです。
この原則を覚えておいてください: 関数の引数が読み取り専用である場合、memoryではなくcalldataを優先的に使用すべきです。これにより、関数のcalldataからmemoryへの不必要なコピー操作を避けることができます。
7. 可能な限り Constant/Immutable キーワードを使用してください
Constant/Immutable変数は、コントラクトのストレージに保存されません。これらの変数はコンパイル時に計算され、コントラクトのバイトコードに保存されます。したがって、ストレージと比較して、アクセスコストははるかに低くなるため、可能な限りConstantまたはImmutableキーワードを使用することをお勧めします。
! イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス
8. オーバーフロー/アンダーフローが発生しないことを確認した上でUncheckedを使用する
開発者が算術操作がオーバーフローやアンダーフローを引き起こさないことを確認できる場合、Solidity v0.8.0で導入されたuncheckedキーワードを使用して、余分なオーバーフローやアンダーフローのチェックを回避し、Gasコストを節約できます。
さらに、0.8.0以上のバージョンのコンパイラではSafeMathライブラリを使用する必要がなくなりました。なぜなら、コンパイラ自体にオーバーフローとアンダーフローの保護機能が組み込まれているからです。
9. オプティマイザ
モディファイアのコードは、修正された関数に埋め込まれており、モディファイアを使用するたびにそのコードがコピーされます。これにより、バイトコードのサイズが増加し、ガス消費が増加します。
内部関数_checkOwner()にロジックを再構築することにより、修飾子内でこの内部関数を再利用できるようになり、バイトコードのサイズを削減し、Gasコストを低減することができます。
! イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス
10. ショートサーキット最適化
||および&&演算子に関して、論理演算はショートサーキット評価が行われます。つまり、最初の条件が論理式の結果を決定できる場合、2番目の条件は評価されません。
Gas消費を最適化するためには、計算コストが低い条件を前に置くべきです。そうすることで、コストの高い計算をスキップできる可能性があります。
! イーサリアムスマートコントラクトのガス最適化のためのトップ10のベストプラクティス
その他の一般的な推奨事項
1. 不要なコードを削除する
契約に未使用の関数や変数が存在する場合は、それを削除することをお勧めします。これは、契約のデプロイコストを削減し、契約のサイズを小さく保つ最も直接的な方法です。
以下は幾つかの実用的なアドバイスです:
最も効率的なアルゴリズムを使用して計算を行います。契約内で特定の計算結果を直接使用する場合は、これらの冗長な計算プロセスを排除すべきです。本質的に、使用されていない計算は削除されるべきです。
イーサリアムでは、開発者はストレージスペースを解放することでGas報酬を得ることができます。不要になった変数がある場合は、deleteキーワードを使用して削除するか、デフォルト値に設定する必要があります。
ループ最適化: 高コストのループ操作を避け、可能な限りループを統合し、繰り返し計算をループ本体から移動します。
2. プリコンパイルされたスマートコントラクトを使用する
プレコンパイルされたコントラクトは、暗号化やハッシュ操作などの複雑なライブラリ関数を提供します。コードはEVM上で実行されるのではなく、クライアントノードのローカルで実行されるため、必要なGasが少なくて済みます。プレコンパイルされたコントラクトを使用することで、スマートコントラクトの実行に必要な計算作業を減らすことができ、Gasを節約できます。
プレコンパイルされたコントラクトの例には、楕円曲線デジタル署名アルゴリズム(ECDSA)およびSHA2-256ハッシュアルゴリズムが含まれます。スマートコントラクト内でこれらのプレコンパイルされたコントラクトを使用することにより、開発者はガスコストを削減し、アプリケーションの実行効率を向上させることができます。
3. インラインアセンブリコードを使用する
インラインアセンブリ(in-line assembly)は、開発者がEVMによって直接実行可能な低レベルかつ高効率なコードを記述することを可能にし、高価なSolidityオペコードを使用する必要がありません。インラインアセンブリは、メモリとストレージの使用をより正確に制御することも可能にし、さらにGas料金を削減します。さらに、インラインアセンブリは、Solidityのみを使用して実現するのが難しい複雑な操作を実行でき、Gas消費の最適化に対してより多くの柔軟性を提供します。
しかし、インラインアセンブリの使用はリスクを伴い、エラーが発生しやすくなります。したがって、経験豊富な開発者の操作に限定して慎重に使用するべきです。
4. Layer 2ソリューションの使用
Layer 2ソリューションを使用することで、イーサリアムメインネット上に保存および計算する必要があるデータを削減できます。