ガス効率が高く最適化された Solidity コードを作成するにはどうすればよいですか?

ガス消費パターンを理解する

1. Ethereum 仮想マシンのすべての操作は、単純な演算からストレージへの書き込みまで、確定的な量のガスを消費します。

2. メモリの割り当てと動的配列のサイズ変更により、固定サイズの構造に比べてガス コストが不釣り合いに高くなります。

3. 外部関数呼び出しでは、メッセージの受け渡し、スタックのコピー、EVM コンテキストの切り替えによりオーバーヘッドが発生します。

4. SLOAD および SSTORE 操作は、特にストレージ スロットを繰り返し変更する場合に最もコストがかかる命令の 1 つです。

5. 適切な境界チェックを行わずにストレージの読み取りまたは書き込みが含まれる場合、ループの反復によりガス使用量が指数関数的に増幅されます。

ストレージレイアウトの最適化

1. 複数の小さな変数を 1 つの 256 ビット ストレージ スロットに詰め込むことで、SSTORE 呼び出しが減り、展開と実行時のガスが節約されます。

2. 状態変数をサイズの降順で宣言する(uint256 の前、uint128 の前、uint64 の前) ことで、より厳密なパッキングが可能になり、暗黙的なパディング ギャップが回避されます。

3. コンストラクターで一度初期化された定数にimmutableを使用すると、デプロイメント後のストレージへの書き込みが完全に排除されます。

4. 転送が行われないプレーンアドレスにpayable アドレスを置き換えると、不要な型変換のオーバーヘッドが削除されます。

5. アライメントを考慮せずにサイズが混在するフィールドを含む構造体を回避すると、スペースが無駄になり、アクセスごとのガスが増加します。

実行時の計算を最小限に抑える

1. ループ境界をオフチェーンで計算するか、メモリにキャッシュすると、反復内でストレージ検索が繰り返されるのを防ぎます。

2. オーバーフローが数学的に不可能な算術演算にチェックなしの { ... }を使用すると、安全性チェックがスキップされ、操作ごとにガスが最大 40% 削減されます。

3. Assert () よりも require ()を優先すると、無効な入力でのガスコストが低くなり、早期に失敗することが保証されます。

4. 複雑なロジックをライブラリに移動し、delegatecall を使用すると、コントラクト間でのバイトコードの重複を回避できます。

5. 小さなヘルパー関数を手動でインライン化すると呼び出しオーバーヘッドを減らすことができますが、より高い最適化レベルではコンパイラの最適化によりこれが自動的に処理される場合があります。

コンパイラーとツールチェーンの活用

1. --optimize --optimize-runs=200で Solidity オプティマイザーを有効にすると、一定のフォールディングとジャンプの並べ替えにより、デプロイされたバイトコードのサイズとランタイム ガスが大幅に削減されます。

2. 0.8.24 などの最新のコンパイラ バージョンを使用すると、古いリリースでは利用できなかった組み込みチェックやより積極的なインライン化戦略がロック解除されます。

3. solc --asmなどのツールを使用して生成されたオペコードを分析すると、冗長 DUP や不要な SWAP などの隠れた非効率性が明らかになります。

4. Foundry のforge Inspection を統合すると、テスト中にストレージ スロットの衝突や予期しないメモリ割り当てを特定するのに役立ちます。

5. forge test --gas-reportを介してガス スナップショットを実行すると、メインネットのデプロイ前にホットスポットが公開されます。

よくある質問

Q: ビュー関数を使用すると、発信者のガス料金はすべて不要になりますか? A: いいえ。ビュー関数は、RPC 経由で外部から呼び出される場合にはガスを消費しませんが、同じトランザクション内の非ビュー関数から内部的に呼び出される場合には依然としてガスがかかります。

Q: 内部ロジックで require(msg.sender == owner) を msg.sender == owner に安全に置き換えることはできますか? A: 安全ではありません。 require を削除すると明示的な復帰が排除され、制御されたエラー処理の代わりにサイレントエラーや意図しない動作が発生します。

Q: オフチェーンのインデックス作成のために、イベントを発行するか、マッピングにデータを保存する方が良いですか? A: イベントはストレージへの書き込みよりも安価であり、インデックス作成の目的には十分です。オンチェーンアクセスが必要でない限り、イベントと状態変数の両方に同一のデータを保存すると、追加のメリットが得られずにガスが無駄になります。

Q: delete arr[i] で配列要素を削除しても、契約ガス全体のコストが減らないのはなぜですか? A: deleteキーワードは値をリセットするだけで、配列の長さを縮小したり、ストレージ スロットを再利用したりすることはありません。動的アレイは容量を保持するため、真のクリーンアップを行うには手動でシフトするか、プッシュ/ポップ パターンを使用する必要があります。