Gas Golfing

Gas Golfingとは？

Gas golfingとは、スマートコントラクトのコードに小規模で的を絞った変更を加え、ガス消費量を削減する手法です。

この用語は、開発者ができるだけ少ないソースコードで問題を解くプログラミング課題「コードゴルフ」に由来します。

暗号資産開発では、必ずしも文字数を最小限に抑えることが目的ではありません。

目的は、コントラクトに必要な動作を維持しながら、消費するブロックチェーンリソースが少ないバイトコードを生成することです。

Gas golfingは、主にEthereumや、Ethereum Virtual Machineを通じてスマートコントラクトを実行するその他のネットワークで用いられます。

開発者は、ストレージ操作の削減、計算の簡略化、revertデータの短縮、不要なメモリーコピーの回避、または低コストなEVM命令の選択によってコントラクトを最適化できます。

Gas golfingでは通常、アプリケーション全体を再設計するのではなく、細かな最適化に重点を置きます。

そのため、コントラクトのアーキテクチャ、トランザクションのバッチ処理、レイヤー2へのデプロイ、アプリケーション設計、オフチェーン計算などを含む一般的なガス最適化よりも範囲が狭い手法です。

Gas golfingによる変更を成功させるには、セキュリティ、正確性、可読性、互換性を維持する必要があります。

脆弱性を生んだり、安全に保守できないコントラクトになったりする場合、わずかなガス削減に意味はありません。

Gas Golfingと呼ばれる理由

「ゴルフ」は、スコアを低くすることを目指す点に由来します。

一般的なゴルフでは、打数が少ないほど良いとされます。

スマートコントラクトのGas golfingでは、最適化後のコードが同じ処理を安全に実行するなら、一般にガス消費量が少ないほど良いとされます。

開発者は、デプロイ時のガス消費量、実行時のガス消費量、バイトコードのサイズ、またはコントラクトの想定稼働期間全体の総コストを測定し、複数の実装を比較できます。

Gas-golfingの課題では、参加者に最小限のガスで関数を実装するよう求める場合があります。

実際の本番開発では、最もガス消費量の少ない実装が、最も安全で監査しやすいとは限らないため、事情はより複雑です。

この用語は非公式なものであり、Ethereumのプロトコル、トークン、トランザクション種別、公式のプログラミング規格を指すものではありません。

Gas Golfingの仕組み

Ethereumでは、Ethereum Virtual Machineが実行する各操作にガスコストが割り当てられています。

公式のEthereumのガスに関するドキュメントでは、ガスはトランザクションやスマートコントラクトの操作に必要な計算量を測る単位と説明されています。

算術演算、メモリーの使用、永続ストレージ、イベントログ、コントラクトの呼び出しや作成、トランザクションデータは、いずれもガス消費量に影響します。

Gas golfingでは、必要な結果を同じように得られる、より低コストな操作の組み合わせを探します。

たとえば、開発者は複数回のストレージ読み取りを1回に減らし、読み込んだ値をローカル変数で再利用することがあります。

また、長いrevert文字列をコンパクトなカスタムエラーに置き換える場合もあります。

より低いレベルで作業する開発者は、手作業で構築したメモリーコピーのループを、メモリーコピー専用のEVM命令に置き換えることがあります。

見た目上、Solidityのコードが短くなってもEVMでの実行コストが下がるとは限らないため、最終的な改善はコンパイル後のバイトコードで測定する必要があります。

Gas golfingとガス最適化の違い

ガス最適化とは、スマートコントラクトのデプロイと実行にかかるコストを削減する幅広い取り組みです。

Gas golfingは、通常、小規模なコードレベルの削減を重視する、より限定的な最適化手法です。

包括的なガス最適化プロジェクトでは、アプリケーションのストレージモデルを再設計したり、適切な計算をオフチェーンに移したり、レイヤー2ネットワークを利用したり、ユーザーごとの必要トランザクション数を削減したりすることがあります。

一方、Gas golfingでは、2種類のループ構造、エラー処理方法、または同じ値の読み込み方法を比較する場合があります。

一般に、アーキテクチャの最適化は細かなコード最適化よりも大きな削減効果をもたらします。

ただし、小さな削減でも、関数が数百万回実行される場合は大きな効果につながることがあります。

プロの開発者は、まずアーキテクチャレベルで不要な処理を取り除き、その後、重要な実行経路をGas golfingで最適化するのが望ましいでしょう。

Gas golfingとコードゴルフの違い

コードゴルフはソースコードの長さを最小限に抑えることを目指し、多くの場合、可読性や長期的な保守性を優先しません。

Gas golfingは、ブロックチェーン上での実行コストの最小化を目指します。

最も短いSolidityの式が、より長く明快な式より多くの命令にコンパイルされることもあります。

また、コンパイラーの最適化によって、複数の異なる書き方が同一のバイトコードに変換される場合もあります。

そのため、開発者はソースコードの文字数ではなく、コンパイル後の出力と実測したガスを比較する必要があります。

コードゴルフの解法は面白くても、価値ある暗号資産を管理するコントラクトには適さないことがあります。

本番環境のGas golfingでは、必ずセキュリティテスト、ドキュメント作成、レビューを行う必要があります。

Gas golfingとガス価格の引き下げ

Gas golfingは、トランザクションが消費するガス単位数を減らします。

ガス単位ごとに支払う市場価格を直接引き下げるものではありません。

トランザクション手数料は「請求されるガス量 × 実効ガス価格」で表せます。

Gas golfingによる変更は、この式の「請求されるガス量」を対象とします。

ネットワーク需要、プロトコルのベース手数料、ユーザーが設定する優先手数料は、実効ガス価格に影響します。

コントラクトが高度に最適化されていても、深刻なネットワーク混雑時には利用コストが高くなることがあります。

また、ガス価格が一時的に低くても、最適化が不十分なコントラクトでは無駄が残る可能性があります。

開発者がGas golfingを行う理由

Gas golfingにより、頻繁に呼び出されるスマートコントラクトの関数を利用するすべてのユーザーのコストを削減できる可能性があります。

トランザクションコストの低下は、分散型金融、トークン送金、ブロックチェーンゲーム、NFT操作、ガバナンスシステムをより利用しやすくする可能性があります。

初期化処理や実行時バイトコードのサイズが小さくなる場合、Gas golfingによってコントラクトのデプロイコストも削減できます。

自動化された暗号資産戦略では、取引手数料が期待リターンを直接減らすため、小さなガス削減が重要になる場合があります。

内部処理を何度も繰り返すプロトコルでは、個々の改善が小さくても、大きな削減につながることがあります。

ガス消費量が少なくなれば、他のトランザクションが利用できるブロック容量も増えます。

ただし、非現実的なテストケースで最小のベンチマーク値を出すことではなく、想定される使用状況を基に最適化する必要があります。

Gas golfingの前に測定する

細かな最適化に取り組む前に、開発者はガス消費量を測定する必要があります。

既存のコンパイラーが、不要に見える操作をすでに削除している場合があります。

古いSolidityバージョンでガスを削減できた変更が、現在のコンパイラーでは効果をもたらさないこともあります。

また、実行時のガス消費量は減っても、コントラクトのデプロイコストが増える変更もあります。

ガステストでは、ユーザーが最も頻繁に実行する関数を対象にする必要があります。

さらに、最小入力、サポート対象の最大入力、正常終了時、失敗時の各経路もテストする必要があります。

Solidityコンパイラーのドキュメントでは、コンパイラーの出力オプションとガス見積もりについて説明しています。

ループ、外部呼び出し、動的なブロックチェーン状態が実行に影響する場合、コンパイラーの見積もりが不完全なことがあります。

そのため、開発者はコンパイラーの出力に加え、実際のトランザクションテストや実行トレースも活用する必要があります。

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

Solidityのリリースでは、最適化、EVMサポート、言語機能、セキュリティ修正が定期的に追加されます。

公式のSolidity 0.8.36のリリース発表では、2026年7月時点の最新リリースとしてバージョン0.8.36が示されています。

このリリースには、セキュリティ修正と、実験的なSSA形式のコード生成パイプラインに関する追加の取り組みが含まれています。

あるコンパイラーバージョンで得られたGas-golfingの結果が、別のバージョンでも再現されるとは限りません。

開発者は、本番ビルドで使用するコンパイラーバージョン、オプティマイザー設定、EVMターゲット、依存関係のバージョンを固定する必要があります。

価値ある暗号資産を扱うコントラクトをデプロイする前に、Solidityコンパイラーの公式バグ一覧も確認してください。

ガス消費量を減らす目的だけでコンパイラーを更新し、アプリケーション全体を再テストしないと、予期しない動作やバイトコードの差異が生じることがあります。

手動で最適化する前にSolidityオプティマイザーを使う

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

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

手動でGas golfingを行う際は、オプティマイザーがすでに実行する処理を考慮する必要があります。

見た目が大きく異なる2つのSolidity関数が、最適化後には同一のバイトコードにコンパイルされることがあります。

オプティマイザーのruns設定は、デプロイコードの小型化と、繰り返し実行時のコスト削減とのトレードオフに影響します。

runsの値が小さいと、一般にデプロイサイズがより重視されます。

runsの値が大きいと、一般に実行時の繰り返し処理がより重視されます。

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

開発者は、従来から使われている値を測定なしに採用するのではなく、複数の設定をテストして比較する必要があります。

ストレージの読み取りをキャッシュする

永続ストレージへのアクセスは、EVMスタックやメモリー上ですでに利用可能な値を使うより高コストなことがよくあります。

よく使われるGas-golfing手法の1つは、ストレージ値を一度ローカル変数に読み込み、再利用することです。

Ethereumでは、EIP-2929に基づいてcoldアクセスとwarmアクセスのコストが適用されます。

通常、トランザクション内でストレージスロットに初めてアクセスする際は、同じスロットへの2回目以降のアクセスよりコストが高くなります。

コントラクトに正確なローカルコピーがすでにある場合は、warm状態のストレージ読み取りも回避できることがあります。

中間値を個別に書き込む代わりに、開発者がローカルで最終結果を計算し、ストレージへの書き込みを1回にまとめることもできます。

キャッシュした値を再利用する前に外部呼び出しが関連状態を変更する可能性がある場合、この方法は安全ではありません。

この手法を適用する前に、リエントランシー、コールバック、delegate call、継承された動作を考慮する必要があります。

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

永続状態への書き込みは、一般的なスマートコントラクト操作の中でも特にコストが高い処理の1つです。

要求された値がすでに保存されている場合、コントラクトはその値を書き込まないようにする必要があります。

既存の状態から安全に導出できる情報を記録することも避けるべきです。

関連する複数の値を、累積インデックスや会計上のチェックポイント1つで表現できる場合があります。

関数内で計算を行い、最終結果のみをストレージに反映することもできます。

こうした変更は、小さな算術式を書き換えるよりも大きな削減につながる場合があります。

簡素化した状態モデルでも、残高、権限、過去の会計記録、アップグレードを正しく扱えることを確認する必要があります。

ストレージ変数をパッキングする

Ethereumでは、コントラクトのストレージが32バイトのスロットに分割されています。

変数の順序と合計サイズが適切な場合、Solidityは複数の小さな値型変数を1つのスロットにパッキングできます。

Solidityのストレージレイアウトに関するドキュメントでは、変数の割り当てとパッキングについて説明しています。

適切なケースでは、必要なストレージスロット数を減らすことで、デプロイ時と実行時のガスを削減できます。

小さな整数型を個別に保存しても、自動的にガスが節約されるわけではありません。

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

パッキングは、まとめた値が頻繁に一緒に読み取られたり変更されたりする場合に特に有効です。

すでにデプロイ済みのアップグレード可能なコントラクトでは、ストレージ変数の順序を変更してはいけません。新しいレイアウトが既存データを誤って解釈する可能性があります。

定数とイミュータブル値を使う

通常の状態変数は、永続状態から値を読み取る必要がある場合にストレージコストを発生させます。

コンパイル時に値が決まっている場合は、

として宣言できます。

コンストラクターで選択され、デプロイ後に変更されない値は、

として宣言できます。

Solidityコントラクトのドキュメントでは、これらの値は変更可能な状態変数と同じような通常のストレージスロットを使用しないと説明されています。

固定アドレス、数学的な値、変更しない設定上限などが一般的な候補です。

アプリケーションで認可された更新プロセスが本当に必要な場合、その値をimmutableにするべきではありません。

必要な設定変更の柔軟性をなくしてガスを節約すると、運用上の制約が高コストになったり、危険になったりすることがあります。

読み取り専用の入力にはCalldataを使う

変更する必要のない外部関数の入力は、多くの場合、

に保持できます。

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

Solidityのデータロケーションに関するドキュメントでは、calldata、memory、storage、transient storageの違いを説明しています。

この手法は、読み取りのみを行う動的な外部入力で最も有効です。

値を変更したり、新しいメモリーデータを構築したりする必要がある場合は、memoryが必要です。

また、calldataのバイト数は基本ガスコストに含まれるため、開発者は不要なトランザクション入力も削減する必要があります。

値をよりコンパクトにエンコードするとcalldataのガスを節約できますが、比較時にはデコードに必要な計算も含めなければなりません。

カスタムエラーを使う

カスタムエラーは、長いエラー文字列と比べて、コントラクトのバイトコードやrevertデータのコストを削減できる場合があります。

カスタムエラーは、コンパクトな4バイトのセレクターを使い、構造化されたパラメーターを含めることができます。

公式のSolidityのカスタムエラーに関するドキュメントでは、カスタムエラーを失敗を通知するためのガス効率の高い方法として説明しています。

たとえば、長い文章を実行時バイトコードに埋め込まずに、呼び出し元のアドレスや必要残高をエラーに含められます。

カスタムエラーを使っても、条件の評価は必要なため、正常終了時の処理が無料になるわけではありません。

ウォレット、インターフェース、監査担当者、開発者が暗号資産のトランザクション失敗を診断できるよう、エラーは十分にわかりやすくする必要があります。

短絡評価を考慮して条件を並べる

Solidityのブール式では、最終結果がすでに確定した時点で評価を終了できます。

論理ANDの式では、最初にfalseとなる条件が見つかると、そこで評価を終了できます。

論理ORの式では、最初にtrueとなる条件が見つかると、そこで評価を終了できます。

低コストの条件によって結果が決まることが多い場合、その条件を高コストの条件より先に置くと、平均ガス消費量を減らせる可能性があります。

この手法を使う場合も、意図した論理動作や、revertする可能性または副作用のある関数に関する前提を維持する必要があります。

安全性やエラー通知に条件の順序が関係する場合、機械的に並べ替えてはいけません。

ループは慎重に最適化する

多くの要素を処理するループは、大量のガスを消費する場合があります。

ループの実行中にコレクションが変更されない場合、開発者は繰り返し参照する配列の長さをキャッシュできます。

各反復で使うストレージ値をキャッシュする方法もあります。

オーバーフローが数学的に起こり得ない場合、ループカウンターのインクリメントに

を使えることがあります。

最新のコンパイラーは一般的なインクリメントパターンをすでに最適化している場合があるため、選択したコンパイラーで削減効果を測定する必要があります。

最適化された最新のSolidityコードでは、前置インクリメントが後置インクリメントより常に低コストだという一般的な主張は、普遍的なルールとして信頼できません。

増え続けるストレージコレクションを上限のないループで処理するのは、細かなGas-golfingではなくアーキテクチャ上の問題です。

大規模な処理は、上限を設けたバッチに分割するか、ユーザーがそれぞれ独立した状態を処理する設計に改める必要があります。

証明がある場合に限りUnchecked演算を使う

Solidity 0.8以降では、通常、整数演算のオーバーフローとアンダーフローがチェックされます。

これらのチェックは一定のガスを消費しますが、重要な種類のプログラミングエラーを防ぎます。

ブロックを使うと、その中の演算に対する自動チェックが無効になります。

数学的な上限によってオーバーフローが起きないと証明できる状況では、ガスを節約できる場合があります。

上限が定められたループカウンターはよくある例ですが、安全性の根拠はループの設計によって異なります。

入力が通常は小さいと想定されるだけの理由で、Unchecked演算を使うべきではありません。

到達可能なすべての入力が安全である理由を示すテストと明確なドキュメントが必要です。

一時的な状態にはTransient Storageを使う

Transient storageはトランザクションの期間内だけ有効な状態を提供し、トランザクションの終了時に自動的に消去されます。

EthereumはEIP-1153を通じて、

と命令を導入しました。

トランザクションをまたいで保持する必要はないものの、呼び出し間で必要なデータには、Transient storageが永続ストレージより低コストな場合があります。

リエントランシーロックは、トランザクション単位の情報を使う一般的な例です。

後続のトランザクションでも必要となる永続的な残高、所有権、債務、設定をTransient storageで置き換えることはできません。

開発者は、呼び出し、delegate call、revertをまたいだTransient stateの動作を理解する必要があります。

実績のあるセキュリティ対策を低コストなTransient実装に置き換える場合は、十分なテストとレビューが必要です。

最新のEVM命令を使う

Ethereumのアップグレードにより、従来の高コストな操作の組み合わせを置き換える命令が導入されることがあります。

EIP-3855では、コンパクトな命令でゼロをスタックに追加する

が導入されました。

EIP-5656では、メモリーコピー専用の命令

が導入されました。

適切なEVMバージョンを選択していれば、最新のSolidityコンパイラーはサポート対象のEVM命令を自動的に使用できます。

通常、特定の命令を使わせるためだけに、コンパイラーが生成したコードを手書きのアセンブリに置き換えるべきではありません。

新しいEVMターゲット向けにコンパイルしたコントラクトは、必要な命令を有効化していないネットワークでは動作しない可能性があります。

そのため、Gas-golfingの結果には、測定に用いたコンパイラーとEVMターゲットを明記する必要があります。

外部呼び出しを減らす

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

同じトランザクション内で同じ値を返す呼び出しを繰り返さないことで、ガスを削減できる場合があります。

関連する複数の読み取りを、構造化された結果を返す1回の呼び出しにまとめられることもあります。

ただし、呼び出し構造の変更は、リエントランシー、エラー処理、コンポーザビリティ、コントラクト間の境界に影響することがあります。

戻り値と成功条件を引き続き正しく確認する必要があります。

安全でない前提を生む低コストの呼び出しは、適切な最適化ではありません。

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

オフチェーンアプリケーションだけが利用する情報では、イベントログの方が永続ストレージより低コストなことがよくあります。

イベントは、トランザクション履歴、分析、アクティビティフィード、ユーザーインターフェースの通知に活用できます。

将来のスマートコントラクト実行では、通常、過去のイベントログを検索できません。

そのため、残高、権限、所有権、担保など、コントラクトが強制的に管理する状態は引き続き参照できるようにする必要があります。

イベントを使ったGas golfingが適切なのは、削除するストレージ値が将来のオンチェーン判断に必要ない場合に限られます。

イベントを設計する際は、indexedイベントトピックやログデータのコストも考慮してください。

デプロイ時のバイトコードを削減する

Ethereumでは、デプロイ時にコントラクトの実行時バイトコードを保存する際、ガスがかかります。

未使用関数、重複ロジック、長いrevert文字列、不要な埋め込みデータを削除すると、デプロイコストを削減できます。

カスタムエラー、内部ライブラリー、共通実装、適切に設定したコンパイラー最適化によって、コードサイズを縮小できる場合があります。

Ethereumでは、EIP-170に基づき、通常のデプロイ済み実行時コードに上限があります。

初期化コードには、EIP-3860に基づく個別の計測と上限があります。

複数のコントラクトにコードを分割すると外部呼び出しのコストが繰り返し発生する可能性があるため、コントラクトが小さければライフサイクル全体のコストも必ず下がるとは限りません。

開発者は、デプロイコストと繰り返し発生する実行コストを合わせて評価する必要があります。

ガス返金の制限を理解する

以前のEthereumのGas-golfing手法には、ストレージの作成と後日の削除による返金に大きく依存するものがありました。

現在のEthereumルールでは、この方法は大幅に制限されています。

EIP-3529により、ストレージ消去による返金が削減され、従来の

返金が廃止されました。また、適用される返金は総ガス消費量の20%が上限です。

後で同額以上の返金を受け取ることを期待して、不要な状態を作成するべきではありません。

ガス返金は実行後に適用されるため、ガス不足による失敗を防ぐことはできません。

も返金をもたらさず、削除の動作が制限されているため、現代のGas-golfing手法ではありません。

Calldata golfingとEIP-7623

開発者は、コンパクトな型、ビットパッキング、独自エンコード、短い表現を使って、トランザクション入力をGas golfingすることがあります。

トランザクションのバイト数を減らせば、特に繰り返し値が多数削減される場合、基本ガスコストを下げられます。

ただし、PectraではEIP-7623が有効化され、実行量が比較的少ないデータ量の多いトランザクションに、より高いガス下限が導入されました。

コンパクトな形式に必要なデコード処理にもガスがかかります。

独自エンコードは、大規模で繰り返される処理ではコスト削減につながる可能性がありますが、小規模なトランザクションでは効果がないこともあります。

標準外のエンコードは、ウォレット、監査、連携、デバッグを難しくする可能性があります。

開発者は、現在のプロトコルルールに基づいて、エンコードとデコードの全処理をベンチマークする必要があります。

インラインアセンブリが適切な場合

インラインアセンブリを使うと、EVM命令、メモリー、ストレージ、呼び出し、戻りデータを直接制御できます。

高水準のSolidityでは特殊な処理を効率よく表現できない場合、ガスを削減できることがあります。

暗号処理、コンパクトなデータ解析、特殊なメモリー操作、頻繁に繰り返される低レベル関数などで、アセンブリの使用が検討されます。

一方で、アセンブリはSolidityが提供する型、メモリー、安全性に関する保護の多くを回避します。

アセンブリの誤りは、メモリーの破損、データの誤ったエンコード、戻り値の不適切な処理、暗号資産の盗難につながる可能性があります。

アセンブリの実装はすべて、明快な高水準の参照実装と比較する必要があります。

通常の入力、境界値、悪意のある入力、revert時に同じ動作をすることをテストで確認してください。

Gas golfingが危険になる場合

ガスコストをコントラクトのセキュリティや明瞭さより優先すると、Gas golfingは危険になります。

ガス節約のためにアクセス制御のチェックを削除すると、権限のないユーザーがコントラクトを操作できる可能性があります。

リエントランシーガードを削除すると、外部呼び出しの繰り返しによって残高が危険にさらされることがあります。

スリッページ制限や期限を削除すると、ユーザーは不利な暗号資産の約定条件にさらされる可能性があります。

複数の値を1つのパック済みワードにまとめると、ビットマスキングや型変換の誤りを招くことがあります。

標準エンコードを独自形式に置き換えると、署名、リプレイ、解析に関する脆弱性が生まれる可能性があります。

100ガスを節約してもユーザー資産を失う可能性が生じるなら、実用上の価値はマイナスです。

古くなったGas-golfingのアドバイス

SolidityやEVMが変化すると、Gas-golfingのアドバイスも古くなることがあります。

以前は手動で書き換える必要があったパターンを、コンパイラーが最適化するようになる場合があります。

ネットワークのアップグレードでオペコードのコストが変わったり、より効率的な命令が追加されたりすることがあります。

返金目的で

を使うという古い推奨は、現在のEthereumでは有効ではありません。

あるインクリメント形式が常に低コストだという主張は、最新の最適化済みバイトコードには当てはまらない場合があります。

非常に小さい整数型を使うという推奨も、ストレージパッキングが行われなければ、ガス節約につながらないことがあります。

開発者は、Gas-golfingの助言を採用する前に、最新のベンチマークと再現可能なコンパイラー設定を求める必要があります。

Gas-golfingの変更を評価する方法

まず、最適化後の実装が元の実装と同じ必要な動作をすることを確認する必要があります。

開発者は、デプロイ時のガス、正常終了時の実行ガス、失敗経路のガス、想定ライフサイクル全体のコストを比較する必要があります。

テストで使用したコンパイラー、オプティマイザー設定、EVMバージョン、ブロックチェーンの状態を明確にしてください。

ユニットテストで通常の関数動作を検証する必要があります。

ファズテストでは、予期しない入力や境界条件を検証します。

不変条件テストでは、重要な会計上の性質やセキュリティ上の性質が維持されていることを確認します。

実行トレースにより、要件が誤って省略されたのではなく、想定した操作から削減効果が得られていることを確認する必要があります。

人によるレビューで、変更後も理解しやすく保守可能かどうかを判断してください。

本番コントラクトにおけるGas golfing

本番環境のGas golfingは、頻繁に使われる関数と、測定によって特定されたボトルネックを対象にする必要があります。

数百万回実行される関数でわずかなコスト削減を実現するなら、慎重な実装に取り組む価値があります。

同程度の削減でも、一度しか使われない管理者向け関数では、複雑さを増す価値がない場合があります。

計画的なプロトコルアップグレードの一環でない限り、公開インターフェースと想定動作は維持する必要があります。

アップグレード可能なコントラクトでは、ストレージレイアウトと認可モデルを維持しなければなりません。

価値の高いコントラクトに大幅な低レベル最適化を施した場合は、独立したセキュリティレビューを受ける必要があります。

デプロイ済みバイトコードは、公開されたソースコードとビルド設定から再現できるようにしてください。

Gas golfingでよくある間違い

よくある間違いの1つは、コンパイル後のガス消費量ではなくソースコードの長さを比較することです。

本番環境で使う設定と同じオプティマイザー設定を有効にせずにテストするのも、よくある間違いです。

成功したトランザクションだけを測定し、コストが異常に高いrevert経路を見落とす場合があります。

ほとんど使われない関数を最適化する一方で、すべてのトランザクションで繰り返されるストレージ書き込みを見落とすことがあります。

ストレージパッキングの効果がないのに、小さい整数型を使うこともあります。

コンパイラーが生成したコードのコストを確認する前に、読みやすいSolidityをアセンブリに置き換えることもあります。

現在のEVMを反映していない古いガス料金表に依存する場合もあります。

最も重大な間違いは、最適化後のバージョンが同じ安全な動作をすることを証明せずに、ガス消費量の低下を受け入れることです。

FAQ

Gas golfingを簡単に説明すると？

Gas golfingとは、スマートコントラクトの意図した動作を変えずに、ガス消費量を削減する小規模なコード変更です。

Gas golfingはガス最適化と同じですか？

いいえ。Gas golfingは通常、限定的な細部の最適化を指します。ガス最適化には、アーキテクチャ、ストレージ設計、オフチェーン計算、バッチ処理、ネットワーク選択も含まれます。

Gas golfingはEthereumのプロトコル機能ですか？

いいえ。公式のオペコード、トランザクション種別、Ethereum規格ではなく、開発者が使う非公式な用語です。

Solidityのコードが短ければ、必ずガス消費量も少なくなりますか？

いいえ。ソースコードの長さから、コンパイル後のEVMバイトコードのサイズや実行コストを正確に予測することはできません。

Solidityオプティマイザーは自動的にGas golfingを実行できますか？

オプティマイザーは同様の変換を数多く実行しますが、効率的なストレージ、データフロー、コントラクトアーキテクチャの設計は、引き続き開発者が行う必要があります。

最も効果的なGas-golfing手法は何ですか？

最も効果的な手法はコントラクトによって異なりますが、繰り返されるストレージアクセスの削減は、細かな算術式の変更より大きな効果をもたらすことがよくあります。

小さい整数型は常に低コストですか？

いいえ。小さい整数型は、複数の値を1つのストレージスロットにまとめられる場合に最も有効です。

Calldataは常にmemoryより低コストですか？

読み取り専用の外部入力ではコピーを避けられるため、calldataの方が低コストなことがよくあります。ただし、適切なロケーションはデータの用途によって異なります。

カスタムエラーがGas golfingに役立つのはなぜですか？

長いrevert文字列を埋め込んで返す代わりに、コンパクトなセレクターとパラメーターを使えるためです。

ストレージ値のキャッシュは常にガスを節約しますか？

値の有効性が維持される場合はガスを節約できますが、外部呼び出しで状態が変化する可能性があると、キャッシュは安全でない場合があります。

Unchecked演算は安全な最適化ですか？

到達可能なすべての入力でオーバーフローやアンダーフローが起こらないと証明できる場合に限り、安全です。

Gas golfingではインラインアセンブリを使うべきですか？

メモリー、エンコード、セキュリティに重大なエラーを招く可能性があるため、インラインアセンブリは測定で確認されたボトルネックに限って使うべきです。

前置インクリメントは常に後置インクリメントより低コストですか？

いいえ。現在のコンパイラー最適化では同等のコードが生成されることがあるため、正確な結果を測定する必要があります。

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

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

Gas golfingでトランザクションを無料にできますか？

いいえ。すべてのトランザクションで、ネットワークの手数料ルールに基づき、必要な実行、データ、状態利用のコストが発生します。

Gas golfingでガス価格は下がりますか？

いいえ。Gas golfingで減らせるのはガス消費量です。ガス価格はネットワーク需要やトランザクション手数料の設定によって変動します。

ガス返金はGas-golfingの手法ですか？

条件を満たすストレージ消去で限定的な返金を受けられる場合がありますが、現行ルールでは返金に上限があり、以前のような返金を多用する手法は使えません。

Gas golfingによってセキュリティリスクが生じることはありますか？

あります。慎重なレビューを行わないと、過度な圧縮、Unchecked演算、アセンブリ、検証処理の削除によって脆弱性が生じる可能性があります。

Gas-golfingの結果はどのようにテストすべきですか？

コンパイラー設定を固定し、現実的な入力、実行トレース、ファズテスト、不変条件、セキュリティレビューを用いてテストします。

Gas golfingが有効なのはどのような場合ですか？

安全な変更により、ユーザーや自動化システムが頻繁に実行する関数のコストを削減できる場合に、特に有効です。

まとめ

Gas golfingとは、スマートコントラクトに的を絞った変更を加え、デプロイ時または実行時のガス消費量を削減する手法です。

ガス最適化に関連しますが、通常はアプリケーション全体の再設計ではなく、小規模なコードレベルの改善に重点を置きます。

一般的なGas-golfing手法には、ストレージ読み取りのキャッシュ、ストレージ書き込みの削減、変数のパッキング、calldataの利用、カスタムエラーの選択、ループの簡略化、最新のEVM機能の活用などがあります。

各手法の効果は、コンパイラーバージョン、オプティマイザー設定、EVMターゲット、入力値、ブロックチェーンの状態によって異なります。

以前のEthereum環境で効果があった手法が、現在のコンパイラーやプロトコルのルールでも有効とは限りません。

開発者は、Solidityソースコードの見た目や長さではなく、コンパイル後のバイトコードを測定する必要があります。

通常、低レベルの細かな最適化より先に、アーキテクチャの改善を検討するべきです。

インラインアセンブリやUnchecked演算は、削減効果を測定でき、安全性を証明できる場合に限って使う必要があります。

Gas-golfingによるすべての変更で、コントラクトの動作、セキュリティ、可読性、互換性を維持しなければなりません。

最良のGas-golfingの成果は、単にガス消費量を最小にすることではなく、必要な暗号資産機能を提供するための、安全なコストを最小限にすることです。