ガス最適化

ガス最適化とは？

ガス最適化とは、暗号資産のスマートコントラクトのデプロイや実行に必要なブロックチェーンリソースを削減するプロセスです。

Ethereumでは、すべてのトランザクションとEthereum Virtual Machineの操作が、測定可能な量のガスを消費します。

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

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

ガス最適化では、コントラクトコード、ストレージの使用、トランザクションデータ、実行経路を効率化して、課金されるガス量を削減します。

ブロックチェーン容量の需要に応じて変化するガス価格を直接制御するものではありません。

適切に最適化されたコントラクトは、トークン送金、分散型金融の操作、ガバナンスの実行、NFT関連の処理、その他の暗号資産トランザクションのコストを抑えられます。

ただし、ガス最適化のためにセキュリティチェックを削除したり、コントラクトの動作を理解しにくくしたりしてはなりません。

目標は、アプリケーションが必要とする、安全で検証可能なオンチェーン処理だけを行うことです。

ガス最適化の仕組み

Ethereumでは、計算処理や状態に関する作業の種類に応じて、異なる量のガスが課金されます。

単純な計算は一般に低コストですが、永続ストレージの変更、コントラクトの作成、暗号処理、外部呼び出しは大幅に高コストになる場合があります。

公式のEthereumガスドキュメントでは、ブロックチェーンのトランザクション処理に必要な計算量をガスで測ると説明されています。

ガス最適化は、どの操作が最も多くのガスを消費するかを特定し、意図した動作を変えずに処理を減らせるか判断するところから始まります。

開発者は、ストレージの繰り返し読み取りを減らす、状態変更をまとめる、トランザクションデータを短縮する、重複した計算を削除する、より効率的なEVM機能を利用するといった方法を取れます。

コンパイラもSolidityのソースコードをより効率的なバイトコードに変換できます。

デプロイコストを削減する最適化もあれば、ユーザーによる各操作のコストを削減する最適化もあります。

最も適切な方法は、コントラクトのデプロイ頻度と各関数の呼び出し頻度によって異なります。

ガス最適化とガス価格の最適化

ガス最適化とガス価格の最適化は、トランザクション手数料の異なる要素に対応します。

ガス最適化では、トランザクションが消費するガス単位数を削減します。

ガス価格の最適化では、ガス1単位あたりの価格が低いときにトランザクションを送信することを目指します。

100,000ガスを消費するコントラクトは、同じ処理を安全に60,000ガスで行うコントラクトよりも、計算コストが高いままです。

ただし、ネットワークの混雑やETHの価格が高い場合、より低コストのコントラクトでも法定通貨換算の手数料は高くなる可能性があります。

ユーザーはネットワーク需要の低下を待ってガス価格を抑えられる場合がありますが、開発者はコントラクトとアプリケーションの設計によってガス使用量を制御します。

両方の方法を組み合わせると、片方だけに頼るよりも合計トランザクションコストを効果的に削減できます。

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

トランザクションコストが高いと、基盤となるサービスが有用でも、ユーザーが暗号資産アプリケーションを利用できなくなる可能性があります。

同じ関数が数千回、数百万回実行される場合、わずかなガス削減でも経済的に大きな意味を持ちます。

ガス使用量を減らすと、暗号資産残高の少ないユーザーにも利用しやすくなる可能性があります。

また、時間制限のあるトランザクションが、必要以上に高い合計手数料を支払わずに取り込みを競えるようになる場合があります。

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

効率的なコントラクトは、限られたブロック容量もあまり消費せず、ネットワークで利用可能なリソースにより多くのトランザクションを収めるのに役立ちます。

そのため、最適化は個々のユーザーとブロックチェーンエコシステム全体の双方にメリットをもたらす可能性があります。

コード変更の前にガスを測定する

コントラクトのどの部分を最適化するか決める前に、開発者はガス消費量を測定してください。

非効率に見えるソースコードでも、コンパイラによってすでに簡略化されている場合があります。

ソースコード上の簡略化によって、かえって明確な実装より高コストのバイトコードが生成される場合もあります。

ガスレポートでは、コントラクトのデプロイ、成功したトランザクション、リバートされたトランザクション、最大サイズの入力、まれな実行分岐を対象にしてください。

1人のユーザーに対しては低コストの関数でも、大きな配列や多数のストレージ項目を処理すると高コストになる場合があります。

自動ガススナップショットを使うと、ソフトウェアの改訂ごとにコストを比較し、予期しない増加を検出できます。

実行トレースでは、高コストのオペコード、ストレージスロット、メモリの拡張、外部コントラクト呼び出しを特定できます。

Solidityコンパイラのドキュメントでは、利用可能なコンパイラ出力、最適化設定、ガス推定について説明されています。

動的ループや外部呼び出しでは、正確なガス使用量がブロックチェーンの状態に左右されるため、開発者は推定値を参考情報として扱う必要があります。

スマートコントラクトのアーキテクチャを最適化する

多くの場合、最大のガス節約につながるのは、個々の式を書き換えることではなく、コントラクトのアーキテクチャを変更することです。

不要な情報を保存するコントラクトは、算術演算を高度に最適化してもコストが高いままです。

オンチェーンで強制適用する必要がある情報と、コントラクト外で計算またはインデックス化できる情報を見極めてください。

重要な残高、権限、所有権記録、担保データは、通常、永続的なオンチェーン状態として保存する必要があります。

表示情報、過去の活動、分析データは、将来のコントラクト実行で読み取る必要がない場合、イベントログに適している可能性があります。

複数の状態更新を、1つの累積値や会計インデックスで表現できるかどうかも検討してください。

状態モデルがシンプルであれば、一般に必要なストレージ操作が少なく、監査もしやすくなります。

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

永続ストレージは、Ethereumのスマートコントラクトが利用できる最も高コストなリソースの一つです。

トランザクションの完了後も、ストレージデータはEthereumの状態の一部として残ります。

新しいストレージ値や変更された値はすべて、ネットワークノードによる処理と維持が必要です。

既存の状態から安全に計算できる情報は、コントラクトに書き込まないようにしてください。

要求された値がすでに保存されている場合も、書き込みを避ける必要があります。

途中段階の更新を複数回行う代わりに、すべての計算後に最終結果を一度だけストレージへ書き込める場合があります。

必要なセキュリティ上またはパフォーマンス上のメリットがない限り、同じデータを重複して保存しないでください。

小さな算術演算を変更するより、ストレージへの書き込みを減らす方が大きく節約できる場合がよくあります。

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

実行中に値が変わらない場合、同じ値をストレージから繰り返し読み込むとガスを無駄にする可能性があります。

コントラクトで値を一度だけローカル変数に読み込み、その後の計算で再利用できる場合があります。

Ethereumでは、EIP-2929に基づいてコールドアクセスとウォームアクセスに異なるコストが適用されます。

トランザクション中にアカウントまたはストレージスロットへ初めてアクセスする場合、同じ場所への2回目以降のアクセスより、一般にコストが高くなります。

ただし、ウォーム状態のストレージ読み取りでも、既存のスタック値やメモリ値を使うより高コストになる場合があります。

外部呼び出しによってキャッシュした値を使用する前に関連するコントラクト状態が変わる可能性がある場合は、キャッシュを避けてください。

外部との相互作用をまたいで状態をキャッシュする場合は、リエントランシーやコールバックの動作を確認する必要があります。

状態変数をパッキングする

Ethereumのストレージは、幅32バイトのスロットに分割されています。

変数のサイズと順序が適切であれば、Solidityは複数の小さな値型変数を同じスロットに配置できます。

公式のSolidityストレージレイアウトドキュメントでは、変数がストレージスロットに割り当てられる仕組みが説明されています。

変数の順序を慎重に決めると、コントラクトに必要なスロット数を減らせる場合があります。

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

EVMは通常256ビットワードで算術演算を行うため、整数型を小さくしても実行時のガスが自動的に減るわけではありません。

パッキングは、まとめた複数の値を一緒に読み書きすることが多い場合に最も有効です。

パックされたスロットのフィールドを1つだけ更新する際、追加のマスキングや結合操作が必要になることがあります。

アップグレード可能なコントラクトでは、既存のストレージ変数の順序を変更してはなりません。保存済みデータが破損する可能性があります。

constantとimmutableの変数を使う

値が変わらない場合、通常の変更可能な状態変数として保存すべきではありません。

Solidityでは、コンパイル時に決まる値を

キーワードで宣言できます。

コントラクトの構築時に決まり、その後固定される値には、

キーワードを使える場合があります。

constantとimmutableは、値がコントラクトのバイトコードに埋め込まれるか、バイトコードを通じて参照されるため、通常のストレージ読み取りを回避できます。

constantとimmutable変数に関するSolidityドキュメントでは、これらの宣言の違いが説明されています。

一般的な例として、恒久的なアドレス、固定上限、数学的な値、デプロイ後に変更できない設定があります。

アプリケーションでガバナンスや認可された管理者による更新が本当に必要な場合、その変数は変更可能な状態に保ってください。

適切なデータロケーションを選ぶ

Solidityのデータは用途に応じて、storage、memory、calldata、Transient Storageに置くことができます。

storageはトランザクション間で保持され、一般に最も高コストの場所です。

memoryは一時的なもので、現在の実行中だけ利用できます。

calldataには、トランザクションやコントラクト呼び出しで渡された読み取り専用の外部入力が含まれます。

Transient Storageは1回のトランザクション中に複数の呼び出しをまたいで保持されますが、トランザクション終了時に自動で消去されます。

必要以上に高コストのデータロケーションを選ぶと、機能が向上しないままトランザクションコストが増加します。

Solidityのデータロケーションドキュメントでは、これらの場所がコピー、変更可能性、データの保持期間に与える影響が説明されています。

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

変更する必要のない外部関数パラメーターは、calldataのままにできる場合があります。

calldataを使うと、大きな配列、文字列、バイト列、構造体をメモリへコピーせずに済む場合があります。

関数が渡された値を調べるだけなら、ガスを削減できる可能性があります。

入力を変更したり、メモリ上に新しい値を構築したりする必要がある場合は、memoryが適しています。

また、calldataの各バイトは固有ガスコストに加算されるため、不要なトランザクションデータを最小限にしてください。

コントラクトが完全な設定をすでに保存している場合、繰り返し使う値を簡潔な識別子に置き換えられることがあります。

データの展開に必要な計算量が節約分を上回る場合があるため、圧縮は慎重に測定してください。

現在のcalldata価格を考慮する

EthereumのPectraアップグレードは2025年5月7日に有効化され、データ量の多いトランザクションの経済性に影響する変更が含まれました。

EIP-7623では、EVMでの実行量が比較的少なく、大量のcalldataを含むトランザクションに対し、より高いガス下限が導入されました。

このルールは、データ量の多いブロックの最大サイズを制限し、ネットワークのレジリエンスを高める目的で設計されました。

計算量が最小限のトランザクションでも、大量のcalldataが含まれていれば常に低コストになるとは限りません。

証明、署名、バッチ、圧縮されたトランザクション情報を送信するアプリケーションでは、現在のプロトコルの動作をベンチマークしてください。

ネットワークの新しいアップグレードにより、calldata、計算、ストレージ、その他のリソースの相対コストが変わる場合があります。

状態が一時的な場合はTransient Storageを使う

Transient Storageは、1回のトランザクション中は利用できる必要があるものの、その後は保持しない情報のために設計されています。

EthereumではEIP-1153を通じて、

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

Transient Storageの値はトランザクション終了時に自動的に破棄されます。

データを永続的に保存する必要がないため、Transient Storageは永続ストレージより低コストです。

一般的な使用例は、1回のトランザクション内で複数の内部または外部呼び出しに共有するリエントランシーロックです。

一時的な会計処理、コールバック、トランザクション内で有効な権限にも利用できます。

残高や後続のトランザクションでも保持する必要がある情報を、storageの代わりにTransient Storageに保存することはできません。

コンポーザブルな暗号資産アプリケーションで使う前に、通常の呼び出しやdelegate callをまたぐ際の動作を理解してください。

Solidityオプティマイザーを使う

Solidityオプティマイザーは、式の簡略化、不要な操作の削除、計算の統合、バイトコードサイズの削減を行います。

Solidityオプティマイザーの公式ドキュメントでは、生成コードに適用される複数の最適化段階が説明されています。

オプティマイザーは、デプロイ時のガス、実行時のガス、またはその両方を削減できます。

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

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

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

すべてのスマートコントラクトに適したruns設定が一律にあるわけではありません。

コントラクトの実際のデプロイ方法と利用頻度を考慮して、複数の設定を比較してください。

IRベースのコンパイルパイプラインでは、従来のパイプラインと異なる結果になる場合があります。完全なテストを通じて評価する必要があります。

最新かつ検証済みのコンパイラを使う

Solidityコンパイラのリリースには、ガス使用量の改善、新しいEVMへの対応、バグ修正、セキュリティ修正が含まれる場合があります。

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

プロジェクトに特定の互換性要件がない限り、Solidityのドキュメントでは一般に、現在リリースされているコンパイラの使用が推奨されています。

また、Solidityコンパイラの既知のバグに関する公式一覧も確認してください。

ビルドプロセスではコンパイラのバージョンと最適化設定を固定してください。

同じソースコードを異なるコンパイラで再コンパイルすると、異なるバイトコードやガス使用量になる場合があります。

カスタムエラーを使う

カスタムエラーは一般に、長いリバート文字列よりもガス効率が高くなります。

リバート文字列はデプロイ用バイトコードを増やし、トランザクション失敗時にエンコードされたテキストを生成します。

カスタムエラーは簡潔なセレクターを使い、構造化されたパラメーターを含めることができます。

Solidityのカスタムエラードキュメントでは、コントラクトでカスタムエラーを定義して返す方法が説明されています。

ユーザー、ウォレット、開発者が失敗の理由を理解できるだけの情報は、エラーに残してください。

わずかなガス節約のために役立つ失敗情報を削除すると、アプリケーションのサポートや監査が難しくなる場合があります。

ループを最適化する

厳格な上限のないコレクションに応じて反復回数が決まるループは、コストが非常に高くなる可能性があります。

上限のないループは、最終的に1回のトランザクションで利用できるガス量を超える場合があります。

可能であれば、大きな処理を予測可能なバッチに分割してください。

実行中にキャッシュ情報が変わらない場合、ループ内で配列の長さや繰り返し使う値をキャッシュできます。

オーバーフローが数学的に起こり得ない場合、ループカウンターでunchecked算術処理を使えることがあります。

uncheckedコードには、テストと安全性を示す明確な説明を付けてください。

最新のコンパイラは一般的なループパターンを多く最適化するため、手動の変更が低コストだと決めつけず、測定してください。

外部コントラクトの呼び出しを減らす

外部コントラクト呼び出しでは、アカウントアクセス、引数のエンコード、戻り値の処理、呼び出し先コントラクトの実行にガスが必要です。

必要な値を安全に1回の呼び出しで取得できる場合、同じ外部関数を繰り返し呼び出さないようにしてください。

関連する複数の操作を1回の呼び出しや1つのトランザクションにまとめられる場合があります。

ただし、バッチ処理によってcalldataや実行の複雑さが増え、1つの処理が失敗したときにリバートされる作業量が増える場合があります。

外部呼び出しでは、リエントランシー、悪意のある戻り値、ガス消費、予期しない失敗などのセキュリティ上の考慮事項も生じます。

ガス最適化のために、戻り値の確認や安全な相互作用のパターンを削除してはなりません。

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

イベントは、オフチェーンのウォレット、インターフェース、分析システム、インデクサー向けにブロックチェーン上の活動を記録できます。

同じ情報を永続的なコントラクト状態として保存するより、コストが低い場合がよくあります。

将来のスマートコントラクト実行で情報を読み取ったり適用したりする必要がない場合、イベントが適しています。

トランザクション履歴、活動通知、説明用のメタデータはログに適している場合があります。

通常のEVM実行では過去のログを検索できないため、残高、権限、負債、担保、所有権をイベントだけに保存しないでください。

コントラクト自身が将来の判断に必要とする情報は、アクセス可能な状態として保持する必要があります。

コントラクトのデプロイコストを抑える

コントラクトのデプロイでは、初期化処理とランタイムバイトコードの保存にガスを消費します。

未使用の関数、重複するコード、埋め込みデータ、長いエラーメッセージはデプロイコストを増やす場合があります。

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

複数のコントラクト間で重複するバイトコードをライブラリで削減できる場合がありますが、外部ライブラリの呼び出しには実行時コストと依存関係が発生します。

類似したコントラクトを多数デプロイする場合、FactoryパターンやCloneパターンでデプロイコストを抑えられる可能性があります。

Proxyパターンでも実装コードを共有できますが、delegate callのオーバーヘッド、アップグレード権限、ストレージレイアウトのリスクが生じます。

デプロイ時のガスだけでなく、セキュリティとライフサイクルの要件に基づいてアーキテクチャを選択してください。

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

選択したEVMのバージョンに応じて、Solidityコンパイラが生成するバイトコードは異なる場合があります。

新しいEVMバージョンは、古いネットワークでは実行できない効率的な命令をサポートしている場合があります。

たとえば、EIP-3855では、値0をスタックに置くための簡潔な

命令が導入されました。

EIP-5656では、より効率的なメモリコピーのために

が導入されました。

正しいネットワーク向けに設定すると、最新のコンパイラはサポートされている命令を自動的に利用できます。

より新しいEVM向けにコンパイルしたコントラクトは、必要なアップグレードが有効になっていないネットワークでは失敗する場合があります。

そのため、開発者はデプロイ先チェーンと互換性のあるEVMを対象にする必要があります。

ガスの払い戻しを理解する

対象となる特定のストレージ操作を行うと、最終的な課金ガス量が払い戻しによって減る場合があります。

Ethereumの現行ルールでは、プロトコルレベルの払い戻しは総ガス使用量の20%が上限です。

EIP-3529では、対象ストレージの消去に対する払い戻しが減らされ、従来の

に対する払い戻しは廃止されました。

ストレージの消去で限定的なメリットが得られる場合はありますが、状態の作成と削除が無料になるわけではありません。

後から払い戻しを得るためだけに不要なデータを書き込まないでください。

払い戻しは実行後に適用されるため、ガス切れを防ぐことはできません。

は現在のガス最適化手法ではなく、EIP-6780によって動作が制限されています。

バッチ処理を慎重に検討する

複数の操作を1つのトランザクションにまとめると、トランザクションの基本コストを繰り返し支払わずに済む場合があります。

ウォレットでの確認回数を減らし、ユーザー体験を向上させることもできます。

ただし、各操作ではそれぞれ必要な計算と状態変更にガスがかかります。

大きなバッチではトランザクションのガス上限に近づいたり、全体が失敗した場合に高コストの処理がすべて取り消されたりする可能性があります。

一部の処理が失敗した際、バッチ全体をリバートするのか、一部だけ完了させるのかをアプリケーション側で定義してください。

広範なバッチ署名では、ユーザーが予想する範囲を超えた操作が許可される可能性があるため、認可を慎重に設計してください。

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

委任されたアカウントのロジックも、暗号資産を管理するその他のコントラクトと同様に慎重に確認する必要があります。

さらなる節約のためにLayer 2ネットワークを使う

スマートコントラクトの最適化ではアプリケーションに必要な計算量を削減し、適切なLayer 2ネットワークへのデプロイでは、その計算と関連データに対する支払額をさらに抑えられる場合があります。

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

DencunアップグレードではEIP-4844を通じてBlobが導入され、Rollup向けの独立した一時データ市場が設けられました。

Layer 2の手数料が低くてもガス最適化が不要になるわけではありません。同じネットワークでは、非効率なコントラクトの方が効率的なコントラクトよりもリソースを無駄にし、コストも高くなります。

ブリッジのセキュリティ、出金ルール、流動性、ファイナリティ、ネットワーク固有の手数料計算も評価する必要があります。

時期尚早な低レベル最適化を避ける

開発者は、通常のSolidityコードを測定する前に、インラインアセンブリや複雑なビット操作から始めるべきではありません。

コンパイラは、明確な高水準の実装から効率的なバイトコードをすでに生成している場合があります。

アセンブリは特定の操作でガスを削減することがありますが、言語レベルの保護機能の一部を回避します。

アセンブリの誤りは、メモリ破損、エンコードの誤り、安全でない呼び出し、ユーザー資産の損失につながる可能性があります。

低レベルの最適化には、読みやすい参照実装と、動作が同等であることを証明するテストが必要です。

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

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

攻撃者が暗号資産を盗めるなら、最も低コストなコントラクトでも有用とはいえません。

ガス使用量を下げるだけの理由で、アクセス制御、入力検証、リエントランシー対策、スリッページチェック、期限、会計チェックを削除してはなりません。

到達可能なあらゆる条件でオーバーフローとアンダーフローが起こり得ない場合に限り、unchecked算術処理を使ってください。

圧縮ストレージはガスを節約する可能性がありますが、ビット単位の誤りが発生しやすくなる場合があります。

Proxyはデプロイコストを抑える一方で、アップグレードの中央集権的な制御やストレージ衝突のリスクをもたらす可能性があります。

オフチェーン署名でトランザクションをなくせる場合がありますが、ノンス、有効期限、リプレイ、ドメイン分離への対処が必要になります。

最適化の判断では、セキュリティ、可読性、アップグレード可能性、運用リスクも確認してください。

ガス最適化のテスト

すべての最適化について、元の実装と比較してテストする必要があります。

機能テストによって、両方のバージョンで同じ状態変更と出力が得られることを確認してください。

ガステストでは、平均的な使用量、サポートされる最大の使用量、失敗条件を測定してください。

ファジングテストによって、コストが高い、または正しくない実行経路を明らかにする特殊な入力を探索できます。

インバリアントテストでは、最適化後も重要な会計特性とセキュリティ特性が維持されることを確認できます。

本番環境で使用するコンパイラのバージョン、オプティマイザー設定、EVM対象でテストしてください。

後の開発で改善が意図せず失われないよう、ガススナップショットを保存してください。

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

よくある間違いは、小さな整数型にすれば必ずガスが減ると考えることです。

読み取り専用の外部データを、機能上の必要がないのにcalldataからmemoryへコピーすることも間違いです。

開発者が、アプリケーションの成長に伴って実行できなくなる上限のないループを、ストレージコレクションに対して作成することもあります。

ユーザーの各トランザクションで繰り返される小さなコストを無視し、ほとんど使われない関数だけを最適化するチームもあります。

デプロイ時と実行時のトレードオフをテストせずに、オプティマイザー設定を選ぶ場合もあります。

実際に高コストの操作を特定する前に、手書きのアセンブリを追加することもあります。

Ethereumのアップグレードで操作の価格が変更された後も、古いガス価格表に頼り続ける場合もあります。

最も危険な間違いは、見栄えのよいガスベンチマークを出すために必要なセキュリティチェックを削除することです。

ガス最適化戦略を作成する

ガス最適化戦略は、コントラクトの動作とセキュリティ要件を明確に定めるところから始めます。

開発チームは、実装を変更する前に完全なテストを作成してください。

次に、現実的な条件下でデプロイコストとトランザクションコストを測定します。

特にコストの高いストレージ操作、ループ、calldataのデータ量、外部呼び出しを優先的に検討してください。

低レベルでコードを書き換える前に、アーキテクチャの簡素化を検討します。

コンパイラ設定と対象EVMバージョンをテストし、記録してください。

すべての最適化について、機能、ガス、セキュリティのレビューを実施してください。

最終的なデプロイには、ツールと依存関係のバージョンを固定して再現可能なバイトコードを使用します。

よくある質問

ガス最適化を簡単に言うと何ですか？

ガス最適化とは、スマートコントラクトを安全に実行するために必要なブロックチェーン上の計算、ストレージ、トランザクションデータを削減することです。

ガス最適化でガス価格は下がりますか？

いいえ。ガス最適化で減るのはガス使用量です。ガス価格はネットワーク需要とトランザクションの手数料設定によって決まります。

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

不要な永続ストレージ操作を減らし、コントラクトのアーキテクチャを簡素化することで、通常は最も大きな節約が得られます。

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

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

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

読み取り専用の外部入力では、値全体をメモリにコピーする必要がないため、calldataの方が低コストになる場合があります。

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

いいえ。通常、複数の値を1つのストレージスロットにパッキングできる場合にのみ、意味のあるストレージ節約につながります。

Transient Storageとは何ですか？

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

Solidityオプティマイザーは常にコストを削減しますか？

いいえ。オプティマイザーの設定によっては実行時のガスを削減する一方でデプロイコストが増えるため、設定ごとに測定してください。

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

runs設定は、デプロイサイズの縮小と、繰り返し実行時のコスト低下のどちらを重視するかというコンパイラの判断に影響します。

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

カスタムエラーは通常、長いテキスト文字列の代わりに簡潔なセレクターとエンコード済みパラメーターを使うため、効率的です。

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

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

ストレージを消去するとガスが払い戻されますか？

対象となるストレージの消去で限定的な払い戻しが発生する場合がありますが、上限が適用され、ストレージコスト全額を回収することはできません。

ガスの払い戻しでガス切れを防げますか？

いいえ。ガスの払い戻しは実行後に計算されるため、トランザクション実行中にガスを追加することはできません。

バッチ処理で必ずガスを節約できますか？

いいえ。バッチ処理によってトランザクション基本コストの重複を減らせる一方で、calldata、複雑さ、失敗リスクが増える場合があります。

開発者は最適化にインラインアセンブリを使うべきですか？

インラインアセンブリは、測定で確認されたボトルネックに限って使ってください。重大なセキュリティや保守上のリスクを招く可能性があります。

Layer 2ネットワークを使えばガス最適化は不要ですか？

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

時間の経過とともにガスコストが変わるのはなぜですか？

Ethereumのアップグレードで、新しいオペコードの導入、既存操作の価格変更、calldataルールの変更、ネットワーク容量の拡大が行われる場合があります。

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

ガスレポート、トランザクションレシート、実行トレース、コンパイラ出力、自動スナップショット、現実的なテストを利用できます。

ガス使用量が最も少ない実装が常に最良ですか？

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

コントラクトを変更せずにユーザーがガスを最適化できますか？

ユーザーは需要の低い時間帯や適切なネットワークを選べますが、アプリケーションの根本的な実行効率を変更できるのはコントラクトの開発者だけです。

まとめ

ガス最適化とは、暗号資産のスマートコントラクトやトランザクションが消費するリソースを減らすエンジニアリング上のプロセスです。

各ガス単位の市場価格を直接変えるのではなく、ガス使用量を減らします。

大きな効果が得られることが多いのは、シンプルなアーキテクチャ、ストレージ操作の削減、効率的なデータロケーション、上限付きループ、外部呼び出しの削減です。

コンパイラによる最適化、constant、immutable、カスタムエラー、変数のパッキング、Transient Storage、適切なバッチ処理でも、さらなる節約につながる可能性があります。

開発者は最新のコンパイラを使い、既知のコンパイラバグを確認し、正しいEVMバージョンを対象にしてください。

すべての最適化について、成功するトランザクション、失敗、サイズの大きな入力、通常とは異なる実行経路を含めてテストする必要があります。

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

適切に最適化されたコントラクトは、安全で透明性と信頼性を備えた暗号資産機能を提供するために必要なオンチェーン処理だけを実行します。