ガス最適化の手法

ガス最適化の手法とは？

ガス最適化の手法とは、暗号資産のトランザクションやスマートコントラクトに必要な計算リソースとブロックチェーンストレージを削減する方法です。

Ethereumやその他のEVM互換ネットワークでは、Ethereum Virtual Machineが実行する各操作にガスコストが設定されています。

コントラクトストレージの読み取り、ブロックチェーン状態の変更、データのコピー、別のコントラクトの呼び出し、イベントの出力、バイトコードのデプロイはいずれもガスを消費します。

トランザクションを送信するユーザーは通常、課金されるガス量と実効ガス価格に基づく手数料を支払います。

基本的な計算式は「トランザクション手数料＝課金ガス量×実効ガス価格」です。

ガス最適化では、この計算式の課金ガス量を減らします。

ブロックスペースの需要に応じて変動する、ガス1単位あたりの市場価格を直接制御するものではありません。

適切に最適化されたコントラクトは、ユーザーコストを抑え、各ブロックにより多くの処理を収め、トランザクションの信頼性を高め、ネットワーク需要が高い期間でも分散型アプリケーションを実用的にできます。

ただし、ガス最適化によってアクセス制御、算術処理の安全性、リエントランシー対策、会計の正確性、その他のセキュリティ特性を損なってはなりません。

最善の最適化は通常、少量のガス節約だけを目的とした複雑なコードではなく、処理を減らすシンプルな設計です。

暗号資産におけるガス最適化の重要性

不要なオンチェーン処理はすべて、トランザクションを送信するユーザーまたはアプリケーションのコストになります。

1回のトランザクションでは小さな差に見えても、スマートコントラクトが数千回、数百万回の処理を行うと、大きな差になる場合があります。

ガス使用量を抑えると、トークン送金、分散型金融の操作、NFT関連の処理、ガバナンス投票、ブロックチェーンゲームなどをより低コストで利用できます。

効率的なコントラクトは、ストレージの読み書きや計算処理が少なくて済むため、バリデーターやノードにとっても処理しやすくなります。

繰り返しループを実行する、多数の残高を更新する、新しいコントラクトを作成する、1つのトランザクション内で複数の外部システムを呼び出すアプリケーションでは、ガス最適化が特に重要です。

実行コストが取引や強制決済で期待される利益を上回る可能性があるため、自動化された暗号資産戦略でも重要です。

ガス最適化によって、法定通貨換算でトランザクションが安価になるとは限りません。ガス価格やネイティブ暗号資産の市場価格が上昇する場合があるためです。

最適化によって削減されるのは、ユーザーが費用を負担するネットワーク処理量です。

ガスが消費される場所を理解する

スマートコントラクトのコードを変更する前に、開発者は主なガス消費源を把握する必要があります。

永続ストレージは、保存データをブロックチェーンの状態の一部として維持しなければならないため、通常、最もコストの高いリソースの一つです。

メモリは1回の実行中に使う一時的なデータで、一般に永続ストレージより低コストですが、割り当てるメモリ領域が広がるほどコストが上昇します。

calldataにはトランザクションや外部関数の入力が含まれます。コピーされない限り、変更可能なコントラクトメモリにはなりません。

コントラクトのデプロイでは、初期化コードの実行と、生成されたランタイムバイトコードの保存にガスを消費します。

外部コントラクトの呼び出しには、アカウントアクセス、引数のエンコード、戻り値の処理、呼び出し先コントラクトの処理にかかる追加コストが発生します。

暗号計算、イベントログ、コントラクトの作成、大規模なループも、合計ガス使用量に大きく影響する場合があります。

公式のEthereumガスドキュメントでは、トランザクションとEVM操作に必要な計算量をガスで測る仕組みが説明されています。

最適化の前にガスを測定する

ガス最適化は、推測ではなく測定から始める必要があります。

コードを変更する前に、デプロイコストと重要な関数の実行コストを記録してください。

テストでは、現実的なトランザクションサイズ、通常のユーザー操作、サポートされる最大入力、失敗時の経路、通常とは異なるブロックチェーン状態を網羅する必要があります。

配列の要素が1つなら低コストの関数でも、要素が1,000個になると安全性やコストに問題が生じる場合があります。

ガススナップショットを使うと、コードの改訂ごとに関数のコストを比較し、意図しない増加を検出できます。

実行トレースを使えば、どのオペコード、ストレージスロット、内部呼び出し、外部呼び出しが最も多くのガスを消費するかを特定できます。

Solidityコンパイラのドキュメントに記載されているとおり、コンパイラはガス使用量を推定できます。ただし、動的ループや外部コントラクトの動作に依存する場合、推定値を取得できない、または信頼性が低いことがあります。

ローカルのブロックチェーンや、継続的に運用されているパブリックテストネットでテストすると、より現実に近い測定値を得られます。

開発者は、ほとんど呼び出されないコードに時間を費やすのではなく、実際にユーザーが実行する高コストの処理を最適化してください。

最新のSolidityコンパイラを使用する

新しいSolidityコンパイラのリリースには、多くの場合、コード生成の改善、最適化の修正、新しいEVM命令への対応、セキュリティ修正が含まれます。

公式Solidityウェブサイトによると、2026年7月時点でリリース済みの最新コンパイラはバージョン0.8.36です。

本番環境用のコンパイラを選ぶ前に、開発者はSolidity公式ウェブサイトと既知のコンパイラバグ一覧を確認してください。

すべての開発者、テストシステム、デプロイパイプラインで一貫したバイトコードを生成できるよう、ビルド設定で使用するバージョンを固定してください。

実際のビルド環境を管理せずに広範なpragmaを指定すると、コンパイラのリリースごとに異なるコードが生成される場合があります。

新しいコンパイラを使う場合も、最適化や言語の変更がバイトコード、デプロイコスト、コントラクトの動作に影響する可能性があるため、十分なテストが必要です。

Solidityオプティマイザーを有効にして設定する

Solidityオプティマイザーは、式を単純化し、不要な操作を削除し、繰り返し行う計算を統合することで、デプロイ時のバイトコードと実行時のガス消費量を削減できます。

Solidityオプティマイザーのドキュメントでは、最適化によってコードサイズと実行コストを削減できると説明されています。

オプティマイザーのruns設定は、デプロイ後のコードが実行される頻度の予想を示します。

runsの値が低いと、一般にデプロイ用バイトコードの小型化が重視されます。

runsの値が高いと、デプロイ時のコードサイズが大きくなる一方、実行時に繰り返し呼び出す際のコストを抑えられる場合があります。

すべての暗号資産コントラクトに最適なruns値が共通しているわけではありません。

ほとんど呼び出されないものの頻繁にデプロイされるコントラクトと、数百万件のトランザクション処理が見込まれるコントラクトでは、異なる設定が適している場合があります。

複数の設定を実際のテストで比較し、デプロイコストや実行コストだけでなく、ライフサイクル全体のコストを評価してください。

via-IRコンパイルパイプラインではレガシーパイプラインと異なる最適化結果が得られる場合があります。パイプラインの変更は重要なビルド変更として扱い、十分にテストしてください。

永続ストレージへの書き込みを減らす

永続ストレージへの書き込みは、ガスを節約できる余地が特に大きい処理の一つです。

既存の状態から安全に計算できる情報や、必要なときにユーザーから提供される情報を、コントラクトに保存しないようにしてください。

値が変わらないことを事前に確認できる場合、同じ値を繰り返し書き込むことは避けるべきです。

5つの状態変数を個別に更新するコントラクトよりも、書き込みの少ないシンプルな会計モデルを採用したコントラクトの方が低コストになる場合があります。

また、他のスマートコントラクトから情報を利用する必要があるのか、それともオフチェーンアプリケーションだけが必要とするのかを検討してください。

将来のコントラクト実行に影響するデータは、通常ストレージに保存する必要があります。

ウォレット、インターフェース、分析にしか必要ない情報は、代わりにイベントに記録できる場合があります。

Ethereumの現行ルールでは、ストレージの削除で限定的なガス払い戻しが発生する場合がありますが、払い戻しには上限があり、ストレージを無料にする方法として扱うべきではありません。

後から払い戻しを得るために不要なデータを作成するのではなく、設計上の合理的な理由に基づいて、不要になった状態を削除してください。

繰り返し行うストレージ読み取りをキャッシュする

基となる状態が変わらない場合、ストレージスロットを何度も読み取るより、一度読み取ってローカルの値を再利用する方が低コストです。

Ethereumでは、EIP-2929に基づいてコールドアクセスとウォームアクセスが区別されています。

トランザクション内で未アクセスのストレージスロットに初めてアクセスするとコールドアクセスとなり、より高いコストがかかります。

同じトランザクション中に同じスロットへ再度アクセスするとウォームアクセスとなり、コストが下がります。

ウォーム状態のストレージ読み取りであっても、関数内ですでに利用できるスタックやメモリの値を使うより高コストになる場合があります。

関数内で頻繁に使う状態変数をローカル変数にコピーして計算し、最後に結果を一度だけ書き戻せる場合があります。

ただし、外部呼び出しによって関連状態が変わる可能性がある場合や、キャッシュした値が古くなる場合には、この方法を使わないでください。

外部呼び出しの前後で状態をキャッシュする際は、チェック・効果・相互作用の原則に従い、リエントランシーを慎重に分析してください。

状態変数を慎重にパックする

Ethereumのストレージは32バイトのスロット単位で構成されています。

並び順と合計サイズが適切であれば、複数の小さな値型変数を1つのスロットにまとめられます。

たとえば、小さな整数値やBoolean値を複数、別々のスロットではなく1つのスロットに格納できる場合があります。

Solidityのストレージレイアウトドキュメントでは、変数、構造体、配列、継承、パッキングがスロット割り当てに与える影響が説明されています。

そのため、変数の順序によってコントラクトが必要とするスロット数が変わる場合があります。

ただし、可能な限り小さな整数を使えば常に安くなるとは限りません。

EVMでは通常、256ビットワードを使って算術演算を行います。そのため、小さな整数型では追加のマスキングや変換処理が必要になる場合があります。

パックした複数の値をまとめて読み書きすることが多い場合、パッキングの効果が最も明確になります。

パックしたスロット内の値を1つだけ更新する場合は、スロットの読み取り、ワードの一部変更、結合した値の書き戻しが必要になることがあります。

アップグレード可能なコントラクトではストレージレイアウトも互換性の一部です。デプロイ後にガス節約だけを目的として既存の状態変数の順序を変更しないでください。

constantとimmutableの変数を使う

コンパイル後に値が変わらない場合、Solidityで可能であれば通常は

として宣言します。

コントラクトの構築時に選択され、その後変更されない値は

として宣言できます。

constantとimmutableは値がコードにインライン化されるか、コントラクトコードとともに保存されるため、通常の永続ストレージアクセスを回避できます。

公式のSolidityコントラクトドキュメントでは、これらの変数と通常の状態変数との違いが説明されています。

固定設定値、恒久的なアドレス、数学定数、デプロイ後に変更できない上限値などが、一般的な候補です。

アプリケーションでガバナンスやその他の認可された手続きを通じて値を更新する必要がある場合は、immutableにしないでください。

ガスを節約するために必要な柔軟性をなくすと、後により大きな運用上の問題が生じる可能性があります。

読み取り専用の外部入力にはcalldataを使う

変更する必要のない外部関数の引数には、

のデータロケーションを使用できる場合があります。

calldataは読み取り専用であり、実行開始時に入力全体をメモリへコピーする必要がありません。

特に外部関数に渡される配列、バイト列、文字列、構造体で有効です。

データを変更する必要がある場合や、メモリ内に新たな値を作成する場合は、memoryが適しています。

関数パラメーターを

からより小さい整数型に変えるだけでcalldataサイズが必ず小さくなるとは限りません。

標準のABIエンコーディングでは、静的値は通常32バイトのワードに格納されます。また、小さい型では変換や検証処理が追加される場合があります。

ソースコード上の型名だけから推測するのではなく、測定によってガス節約を確認してください。

トランザクションのcalldataを最小限にする

トランザクションのcalldataに含まれる各バイトは、固有トランザクションコストに加算されます。

不要な配列、重複フィールド、長いテキスト文字列、非効率なエンコードは、ユーザーのトランザクションコストを増やす場合があります。

繰り返し使う完全な値を、コントラクトが保存済みの設定に紐付ける簡潔な識別子に置き換えられることがあります。

既存の状態やトランザクション送信者から安全に導き出せる情報を送らずに済む場合もあります。

特殊なシステムでは圧縮が有効な場合がありますが、データの展開自体にガスを消費するため、期待した節約が得られないことがあります。

PectraではEIP-7623が有効化され、データ量の多いトランザクションに対するガス下限が引き上げられました。

このため、EVMでの実行量が比較的少なく、大量のデータを含むトランザクションでは、calldataの効率が特に重要です。

簡潔なcalldataのコストと、デコードに必要な追加処理を比較してください。

トランザクション内で完結する状態にはTransient Storageを使う

Transient Storageを使うと、1回のトランザクション中の内部呼び出し間で利用でき、トランザクションの終了時に自動消去される値をコントラクトに保存できます。

Ethereumでは、EIP-1153を通じて

とのオペコードが導入されました。

永続的なブロックチェーン状態の一部にならないため、Transient Storageは永続ストレージより低コストです。

一般的な用途として、1回のトランザクションの実行中だけ必要なリエントランシーロックがあります。

現在のSolidityバージョンでは、コントラクトがCancun EVMまたはそれ以降の互換バージョンを対象とする場合、値型の状態変数にTransient Storageを利用できます。

後続のトランザクションまで保持する必要のある情報には、Transient Storageを使わないでください。

また、通常の呼び出し、delegate call、コンポーザブルなコントラクトにおける動作も慎重に理解する必要があります。

SolidityのTransient Storageドキュメントでは、状態がトランザクション内でのみ有効であり、呼び出しの種類によって特有の所有動作があると説明されています。

新しい実装を十分にテストし監査するまでは、実績のあるセキュリティ対策をTransient Storageで置き換えないでください。

長いリバート文字列の代わりにカスタムエラーを使う

カスタムエラーは、構造化された失敗情報を返す際にガス効率を高められる方法です。

長いリバート文字列はデプロイ済みコントラクトのバイトコードに含まれ、条件を満たさない場合にエンコードされた戻り値を生成します。

カスタムエラーは、宣言したパラメーターを含む4バイトのセレクターを使うため、デプロイサイズと失敗時のコストを削減できます。

Solidityのカスタムエラードキュメントでは、カスタムエラーが利便性とガス効率を備えたエラー処理方法として説明されています。

ウォレット、開発者、監視システムが問題を特定できるよう、エラー名とパラメーターは明確にしてください。

役立つエラー情報をすべて削除すると、少量のガスを節約できる一方で、失敗した暗号資産トランザクションの調査が大幅に難しくなる場合があります。

ループと配列処理を最適化する

配列やストレージコレクションのサイズに応じて反復回数が増え、上限が厳格に定められていない場合、ループのコストは非常に高くなる可能性があります。

上限のないループは、最終的に1回のトランザクションで提供できるガス量を超え、重要なコントラクト関数が利用できなくなる可能性があります。

可能であれば、大量の処理を上限付きのバッチに分割してください。

ストレージにある配列の長さをループ中に何度も読み取る場合、ローカル変数にその長さを保存できることがあります。

安全であれば、各反復で使用するストレージ値もキャッシュできます。

オーバーフローが発生しないと証明できる場合に限り、ループカウンターの算術処理に

を使えます。

最新のSolidityコンパイラは、一般的なループパターンの多くをすでに最適化します。手動の変更を採用する前にベンチマークを行ってください。

複数のトランザクションに処理を分割すると信頼性が高まる場合がありますが、処理の欠落、重複、順序変更を防ぎながら進捗を安全に追跡する必要があります。

冗長な外部呼び出しを避ける

別のコントラクトを呼び出すとガスを消費し、呼び出し先コントラクトの実行動作にトランザクションが影響されます。

同じ外部値を安全に1回だけ取得して結果を再利用できる場合、関数内で何度も取得することは避けてください。

関連する複数の操作を1つのコントラクト呼び出しにまとめられることがあります。

ただし、バッチ処理では一緒に失敗する処理が増え、calldataのサイズも大きくなる場合があります。

外部呼び出しによって、リエントランシー、予期しない戻り値、多大なガス消費、トランザクション全体のリバートが発生する可能性もあります。

ガス節約のために、戻り値のチェックや安全な呼び出し処理を削除してはなりません。

キャッシュした外部値が実行中に有効であり続けるか、コールバックを通じて外部システムが値を変更できるかを判断してください。

適切な場合はストレージの代わりにイベントを使う

イベントはトランザクションログに情報を記録し、オフチェーンアプリケーションからインデックス化できます。

同等の情報をコントラクトの状態に保存するより、コストが低い場合がよくあります。

活動履歴、ユーザーインターフェースの通知、分析、将来のコントラクト実行で読み取る必要のない記録には、イベントが適しています。

将来のスマートコントラクト実行で必要となる状態の代わりに、イベントを使うことはできません。

通常、スマートコントラクトはEVM実行中に過去のログを取得できません。

重要な会計情報だけをイベントに保存するシステムでは、オフチェーンサービスによる再構築が必要となり、オンチェーンで直接処理を強制できません。

インデックス化されたトピックとログデータではガスコストや検索特性が異なるため、イベントパラメーターの設計にも注意が必要です。

コントラクトのデプロイサイズを縮小する

コントラクトのデプロイでは、初期化処理の実行とランタイムバイトコードの保存にガスがかかります。

未使用の関数、重複するロジック、長いリバート文字列、埋め込みデータは、デプロイコストを増加させる場合があります。

不要なコードを削除し、ライブラリの一部しか必要ない場合は大規模なライブラリをインポートしないようにしてください。

外部ライブラリを使うと複数のデプロイ間で重複するバイトコードを削減できますが、実行時のオーバーヘッドや運用上の依存関係が増える場合があります。

FactoryパターンやCloneパターンを使うと、類似したコントラクトを多数デプロイする際にコストを抑えられます。

Proxyパターンはアップグレードや複数回のデプロイに対応できますが、delegate callのオーバーヘッドに加え、ストレージレイアウト、ガバナンス、セキュリティ上の重大な考慮事項が生じます。

Ethereumでは、通常デプロイされるランタイムバイトコードのサイズがEIP-170で制限され、EIP-3860で初期化コードの計測と上限設定が行われています。

サイズ制限を下回るためだけにコードを分割すると呼び出しコストが増える場合があります。コントラクトのライフサイクル全体を考慮して設計を評価してください。

正しいEVMバージョンを対象にする

コンパイラの出力は、選択するEVMの対象バージョンによって異なります。

新しいEVMを対象にするコンパイラは、古いネットワークでは利用できない命令を使う場合があります。

たとえば、ShanghaiではEIP-3855により

命令が導入され、値0をより小さく安価な命令でプッシュできるようになりました。

DencunではEIP-5656を通じて

が導入され、より効率的なメモリコピーが可能になりました。

互換性のあるネットワーク向けに設定すると、最新のコンパイラはこれらの命令を自動で利用できます。

プロトコルアップグレードが移行先ネットワークで有効化される前に、そのアップグレードを対象にコンパイルしたコントラクトをデプロイすると、失敗する可能性があります。

そのため、ビルドシステムでは、対象チェーンごとに正しいEVMバージョンを設定してください。

テスト後にAccess Listを検討する

Access Listを使うと、トランザクションでアクセスする予定のアカウントとストレージキーを指定できます。

リストに記載された項目は実行開始時からウォーム状態として扱われ、後続のコールドアクセスにかかるコストが減ります。

EIP-2930では、Access Listに含めたアドレスとストレージキーごとに手数料がかかります。

正確なAccess Listを用意すると、特定の予測可能なトランザクションでコストを削減できる場合があります。

効果が小さい項目や使用されない項目を含む不完全または不要なリストでは、各項目の費用を支払うため合計手数料が増える場合があります。

正確な実行経路が変化するブロックチェーンの状態に依存する場合、Access Listの生成が難しいこともあります。

状態を事前に読み込めば必ず安くなると思い込まず、Access Listを使う場合と使わない場合のトランザクション全体をシミュレーションしてください。

ユーザー操作を慎重にまとめる

複数の操作を1つのトランザクションにまとめると、基本トランザクションコストの重複を避けられる場合があります。

たとえば、アプリケーションでユーザーが操作を承認し、その操作を実行するまでを一連のフローとしてまとめられる場合があります。

PectraではEIP-7702が有効化され、外部所有アカウントがスマートコントラクトコードに実行を委任できるようになりました。これにより、トランザクションの一括処理やガス代の肩代わりなど、ウォレット機能がサポートされます。

ただし、各操作に必要なコントラクト処理自体は残るため、バッチ処理ですべての実行コストが必ず下がるわけではありません。

大きなバッチは、実用的なガス上限を超えたり、calldataを増やしたり、1つの処理が失敗した場合に全操作のリバートを引き起こしたりする可能性があります。

一部の処理だけの完了が許可されるか、失敗したサブ処理をどう通知するかをアプリケーション側で定めてください。

バッチ処理システムがユーザー資産に対して広範な権限を持つ可能性があるため、ウォレットの認可と委任先コードを慎重に確認してください。

適切な場合はLayer 2ネットワークを使う

アプリケーションレベルの最適化では消費するガス単位数を減らし、Layer 2ネットワークでは実行とデータに対してユーザーが支払う価格を抑えられる場合があります。

RollupはEthereumメインネットの外で処理を行い、データや証明をEthereumに公開します。

DencunではEIP-4844を通じてBlobを含むトランザクションが導入され、Rollupがより特化した一時的なデータチャネルを利用できるようになりました。

その後、PectraとFusakaによってEthereumのスケーリングとデータ可用性の機能が拡張されました。

最新のEthereum開発者向けガイダンスでは、最近のアップグレードがメインネットの手数料、アカウント機能、Rollupの経済性に与えた影響が説明されています。

Layer 2ネットワークにデプロイしても、効率的なコントラクトが不要になるわけではありません。不要なストレージや計算処理は、引き続きユーザー手数料を増やし、処理能力を圧迫します。

ネットワークを選ぶ前に、ブリッジ、出金、流動性、セキュリティ、相互運用性の要件も評価してください。

必要な場合に限りインラインアセンブリを使う

インラインアセンブリを使うと、開発者はEVM操作を細かく制御でき、場合によってはガスを削減できます。

一方で、Solidityの型チェック、メモリ保護、高水準の安全機能の一部が失われたり、回避されたりします。

短いアセンブリ処理でもレビュー担当者が理解しにくい場合があり、メモリ破損、エンコードの誤り、安全でない呼び出しにつながる可能性があります。

コンパイラは通常のSolidityコードから、手動実装と同等に効率的なコードをすでに生成している場合があります。

そのためアセンブリは、測定で確認されたボトルネック、特殊な暗号処理、低レベルのデータ処理、またはSolidityで効率的に表現できない機能に限定してください。

すべてのアセンブリ最適化について、明確な参照実装と出力を比較するテストを用意してください。

アセンブリがトークン残高、署名、権限、外部呼び出しを扱う場合は、独立したセキュリティレビューが特に重要です。

ガス節約のためにセキュリティを犠牲にしない

ユーザーの暗号資産を失う可能性があるなら、コストが低いスマートコントラクトでも優れているとはいえません。

ガス節約だけを理由に、アクセス制御、入力検証、リエントランシー対策、期限確認、スリッページ保護、会計チェックを削除しないでください。

unchecked算術処理は、到達可能なすべての条件でオーバーフローとアンダーフローが数学的に起こり得ない場合に限って使ってください。

複数の変数を圧縮した値にまとめるとストレージを節約できる一方、ビット操作の誤りが起きやすくなる可能性があります。

Proxyを使うとデプロイコストを削減できる場合がありますが、アップグレード権限やストレージ衝突のリスクが生じます。

オフチェーン署名を使うとトランザクションを減らせますが、ノンス、有効期限、ドメイン分離、リプレイ保護を正しく扱う必要があります。

ガスコストだけでなく、可読性、監査可能性、運用リスク、将来の保守性も考慮して、すべての最適化を評価してください。

ガス最適化でよくある間違い

よくある間違いの一つは、他の値とパッキングせずに小さな整数型を選ぶことです。

EVMは256ビットワードで処理するため、それだけでは小さな型にしても実行コストが減らない場合があります。

別の間違いは、関数が読み取るだけでよいcalldataをすべてメモリにコピーすることです。

3つ目は、後で同じ状態を再作成する予定なのに、払い戻しを狙ってストレージを消去することです。

4つ目は、増加するストレージ配列に上限のないループを適用することです。

5つ目は、デプロイ時と実行時の動作を比較せずに高いオプティマイザーのruns値を選ぶことです。

6つ目は、コントラクトのプロファイリングを行う前に手書きのアセンブリを使うことです。

7つ目は、コンパイラやネットワークのアップグレードでオペコードの動作が変わった後も、以前の最適化が有効だと思い込むことです。

8つ目は、失敗経路のコストを無視し、成功したトランザクションだけを測定することです。

9つ目は、ガス推定値が低いことを、2つの実装でセキュリティやビジネスロジックが同一である証拠とみなすことです。

ガス最適化のプロセスを構築する

信頼できるプロセスは、コントラクトに必要な動作とセキュリティ特性を定義することから始まります。

低レベルの最適化を試みる前に、チームで機能テストを作成します。

次に、デプロイコストと重要な各トランザクション経路のガス使用量を測定します。

ストレージへの高コストの書き込み、ループ、calldata入力、外部呼び出しをプロファイリングによって特定します。

開発者は、アーキテクチャを簡素化し、状態変更を減らし、適切なデータロケーションを選び、テスト済みのコンパイラ最適化設定を有効にできます。

各変更を元のバージョンと比較して測定し、新たなセキュリティリスクがないかレビューしてください。

後続の開発で節約効果が意図せず失われないよう、ガス回帰テストをプロジェクトに残しておきましょう。

本番用の最終バイトコードは、バージョンを固定したコンパイラ、検証済みの設定、正しいEVM対象、レビュー済みの依存関係を使ってコンパイルしてください。

価値の高い暗号資産コントラクトは、社内テストに合格していても、独立したセキュリティ監査を受ける必要があります。

よくある質問

最も効果的なガス最適化手法は何ですか？

通常、永続ストレージの操作を減らし、各トランザクションで行うオンチェーン処理を簡素化する方法が最も効果的です。

Solidityオプティマイザーを使えば常にガスが減りますか？

いいえ。設定によっては実行時のガスを減らす一方でデプロイコストが増えるため、コントラクトのライフサイクル全体をテストしてください。

オプティマイザーのruns設定とは何ですか？

デプロイ後のコードが実行される頻度の予想をコンパイラに伝える設定で、デプロイサイズと繰り返し実行コストのトレードオフに影響します。

ストレージはメモリより高コストですか？

はい。永続ストレージのデータはトランザクション終了後もブロックチェーン状態の一部として残るため、一般に大幅に高コストです。

calldataはmemoryより低コストですか？

読み取り専用の外部入力であれば、入力全体を先にメモリへコピーせずにアクセスできるため、calldataの方が低コストになる場合があります。

小さい整数型は常にガスを節約しますか？

いいえ。複数の値を1つのストレージスロットにパッキングできる場合に最も有効で、単独の小さな整数では追加の変換処理が必要になる場合があります。

開発者がストレージ値をキャッシュする理由は何ですか？

値が変わらず、スタックやメモリから安全に再利用できる場合、キャッシュによって繰り返しのストレージ読み取りを避けられます。

Transient Storageとは何ですか？

Transient Storageはトランザクション内でのみ有効なEVMストレージです。自動的に消去され、リエントランシーロックなどの低コストな一時状態に利用できます。

カスタムエラーはリバート文字列より低コストですか？

一般に、カスタムエラーは長いテキスト文字列を保存して返す代わりに、簡潔なセレクターとエンコード済みパラメーターを使用するため、ガス効率が高くなります。

イベントでコントラクトストレージを置き換えられますか？

将来のスマートコントラクト実行で読み取ったり適用したりする必要のない情報に限り、イベントでストレージを置き換えられます。

ストレージを削除するとガスコストがすべて払い戻されますか？

いいえ。ストレージ消去による払い戻しには上限があり、プロトコル全体のガス払い戻し上限が適用されます。

ガス節約のためにunchecked算術処理を使うべきですか？

オーバーフローやアンダーフローが発生し得ないと証明でき、その安全性の根拠を文書化してテストした場合に限り、unchecked算術処理を使ってください。

トランザクションをまとめれば必ずガスを節約できますか？

いいえ。まとめることでトランザクションの基本コストの重複を減らせる一方、calldata、実行の複雑さ、全体が失敗するリスクが増える場合があります。

Layer 2ネットワークを使えばコントラクトの最適化は不要ですか？

いいえ。ネットワーク手数料は下がる場合がありますが、同じネットワーク内では非効率なコントラクトの方が、最適化されたコントラクトよりも実行リソースを無駄にし、コストが高くなります。

Access Listを使うと常にガスが減りますか？

いいえ。Access Listの項目自体にもコストがかかり、内容が不正確または不要な場合は手数料が増えることがあります。

インラインアセンブリは常にガスを減らせますか？

いいえ。コンパイラが同等に効率的なコードを生成する場合がある一方、安全でないアセンブリは重大なセキュリティや保守上の問題を引き起こす可能性があります。

開発者はどのようにガス使用量を測定できますか？

コンパイラによる推定、自動ガススナップショット、ローカルでのトランザクションテスト、実行トレース、プロファイリングツールを利用できます。

ネットワークアップグレード後にガスコストが変わるのはなぜですか？

Ethereumのアップグレードでオペコードの追加、既存操作の価格変更、calldataルールの変更、より効率的なストレージやメモリ機能の導入が行われる場合があるためです。

ガス最適化でネットワーク手数料の高騰を防げますか？

消費ガス量は削減できますが、多くのユーザーが限られたブロックスペースを競う際に、市場のガス価格が上昇するのを防ぐことはできません。

ガスが最も安いコントラクトが常に最良ですか？

いいえ。わずかなガス節約よりも、正確性、セキュリティ、可読性、保守性の方が重要です。

まとめ

ガス最適化の手法は、暗号資産のスマートコントラクトに必要な計算、ストレージ、calldata、デプロイのリソースを削減します。

大きな節約につながることが多いのは、永続ストレージへの書き込みの最小化、安全なストレージ読み取りのキャッシュ、適切なデータロケーションの選択、不要なcalldataの削減、冗長な外部呼び出しの回避です。

最新のSolidityコンパイラはバイトコードを自動最適化できますが、現実的な測定に基づいてオプティマイザー設定を選ぶ必要があります。

Transient Storage、

、、委任されたアカウントコード、更新されたcalldata価格など、Ethereumの最新機能によって、開発者が最適化に取り組む方法は変化しています。

開発者は正しいEVMバージョンを対象とし、コンパイラ、テスト、プロトコルルールに関する知識を最新の状態に保つ必要があります。

変数のパッキング、カスタムエラー、上限付きループ、バッチ処理、イベント、ライブラリ、Layer 2へのデプロイなどの手法は、アプリケーションの設計に合致すればコストを削減できます。

Access List、Proxy、インラインアセンブリ、unchecked算術処理、圧縮ストレージには、わずかなガス節約のために複雑さやリスクを大きく増やす可能性があるため、特に注意が必要です。

すべての最適化について、デプロイ、正常な実行、失敗経路、長期的なコントラクト利用を含めて測定してください。

ガスレポートの数値を下げるためだけに、セキュリティチェックを削除してはなりません。

最も効果的なガス最適化戦略は、安全で検証可能な暗号資産の運用に必要な最小限のオンチェーン処理だけを行うことです。