-
bitcoin $99097.524802 USD
-3.18% -
ethereum $3190.458287 USD
-7.51% -
tether $0.999648 USD
-0.03% -
xrp $2.309178 USD
-4.17% -
bnb $921.186688 USD
-3.96% -
solana $144.106489 USD
-6.12% -
usd-coin $0.999837 USD
-0.02% -
tron $0.291415 USD
-1.32% -
dogecoin $0.163935 USD
-4.54% -
cardano $0.526269 USD
-4.77% -
hyperliquid $37.814277 USD
-2.92% -
bitcoin-cash $509.826264 USD
-1.40% -
chainlink $14.448349 USD
-5.83% -
stellar $0.267630 USD
-4.87% -
unus-sed-leo $9.178879 USD
0.52%
Solidity における不変の変数と定数とは何ですか?また、それらはどのようにガスを節約しますか?
Immutable variables in Solidity are set once in the constructor and save gas by avoiding costly storage writes, while constants are compile-time literals embedded directly in bytecode for zero-cost access.
2025/11/13 04:40
Solidity における不変変数を理解する
1. Solidity の不変変数はimmutableキーワードを使用して宣言され、コントラクト構築中に 1 回だけ割り当てることができます。一度設定すると、コントラクトのライフサイクル全体を通じて値を変更することはできません。
2. これらの変数はデプロイメント時に解決されるため、コンパイラは通常の状態変数に使用されるストレージ スロットではなく、コントラクトのメタデータに変数を配置することでストレージを最適化できます。
3. 不変変数は可変ストレージを占有しないため、イーサリアムで最も高価なオペコードの 1 つであるデプロイ後の SSTORE 操作の必要がなくなります。
4. 不変変数の値は通常、コンストラクター内で割り当てられるため、デプロイ時には既知であるが、同じコントラクトのインスタンス間で異なるパラメーターに最適です。
5. 不変を使用すると、意図が通知されるため、コードの明瞭さが向上します。開発者は、特定の値がデプロイ後に固定されることを知り、意図しない変更のリスクを軽減します。
ガスの最適化における定数の役割
1. 定数はconstantキーワードを使用して定義され、宣言時に値を割り当てる必要があります。それらの値は、コンパイル中にバイトコードにハードコーディングされます。
2. 定数値は EVM 命令に直接埋め込まれているため、定数値の読み取りにはストレージ アクセス コストがかかりません。これは、定数値を取得するときに SLOAD 操作が実行されないことを意味します。
3. 定数を使用する関数はその値をインライン展開し、コンパイル時に変数参照をそのリテラル値に事実上置き換えます。
4. このインライン化動作により、これらの値に永続ストレージを割り当てたり参照したりする必要がないため、実行ガスとコントラクト サイズの両方が削減されます。
5. 定数は、計算に使用されるプロトコル パラメーターや数学的係数など、すべての展開にわたって真に静的な値に最適です。
不変と定数の違い
1. どちらも実行時のストレージコストを回避することでガスを節約しますが、定数はコンパイル時に値がわかっている必要があるのに対し、不変は構築中に代入が可能です。
2. 定数は入力や外部状態に依存できません。数値、文字列、または定数入力を使用した純粋な関数呼び出しの結果など、コンパイル時の定数式である必要があります。
3. 不変変数により柔軟性が高まります。コンストラクターの引数を受け取ることができるため、実行時コストの削減の恩恵を受けながら、異なるコントラクト インスタンスに異なる値を持たせることができます。
4. ガス使用量の観点から見ると、定数の値はデプロイメント前に完全に解決されるため、通常、定数の方がわずかに優れた最適化が可能ですが、不変の場合は構築中に 1 回の初期化が必要になります。
5. どちらかのタイプを誤って使用すると (頻繁に変更される値を不変として宣言するなど)、柔軟性のない設計につながる可能性があるため、適切なユースケースの調整が不可欠です。
ガス節約の仕組みを解説
1. SLOAD を使用した EVM ストレージからの読み取りごとに少なくとも 2100 ガスが消費されますが、コード空間に格納されている値 (定数など) へのアクセスのコストはゼロに近くなります。
2. SSTORE を使用したストレージへの書き込みはさらにコストが高く、最初の書き込みで最大 20,000 ガス、その後の更新で 5,000 ガスがかかります。不変は構築後にこのコストを完全に回避します。
3. データをストレージからコードまたはコンストラクターによって初期化されたメモリ領域にシフトすることで、定数と不変の両方がスマート コントラクトの運用フットプリントを削減します。
4. 料金パーセンテージ、アドレス許可リスト、トークンキャップなどの構成値に大きく依存する契約では、これらが定数または不変として宣言されると、大きなメリットが得られます。
5. コンパイラの最適化では、これらの宣言を利用して冗長な操作を最小限に抑え、不要なチェックを取り除き、より無駄のないバイトコードを生成して、効率をさらに高めます。
よくある質問
コンストラクターの実行後に不変変数を変更できますか?いいえ。不変変数がコンストラクターに設定されると、変更することはできません。再割り当てを試みるとコンパイル エラーが発生します。
定数として宣言できる型に制限はありますか?はい。定数にできるのは、uint、int、bool、アドレス、文字列リテラル (いくつかの制限付き) などの値の型のみです。配列と構造体は、インライン アセンブリ内にあるか、新しいバージョンのコンパイラで処理される特殊なケースでない限り、定数として宣言できません。
不変変数はデプロイメントガスのコストを増加させますか?コンストラクター ロジックによりデプロイメント コストがわずかに増加する可能性がありますが、これは対話中の長期的な節約によって相殺されます。複数のトランザクションにわたる最終的な効果は、通常、総ガス消費量の大幅な削減です。
コンストラクターの外側で不変変数を代入しようとするとどうなりますか? Solidity コンパイラはエラーをスローします。不変変数の代入はコンストラクター コンテキストのみに制限され、その整合性と予測可能性が保証されます。
免責事項:info@kdj.com
提供される情報は取引に関するアドバイスではありません。 kdj.com は、この記事で提供される情報に基づいて行われた投資に対して一切の責任を負いません。暗号通貨は変動性が高いため、十分な調査を行った上で慎重に投資することを強くお勧めします。
このウェブサイトで使用されているコンテンツが著作権を侵害していると思われる場合は、直ちに当社 (info@kdj.com) までご連絡ください。速やかに削除させていただきます。
- 仮想通貨の大虐殺: 荒々しい市場での売却と清算を乗り切る
- 2025-11-14 16:50:01
- モハメッド・シラージの最初の呪文の悩み: インドのチームメイトの批判
- 2025-11-14 14:40:02
- BTC、ETH、アルトコインのおすすめ: 暗号通貨の状況をナビゲートする
- 2025-11-14 14:50:01
- コイントスの物語: テンバ・バヴマの賭けとインド対SAの対決
- 2025-11-14 12:50:01
- シャブマン・ギル、WTC 決勝、そしてコイントス: ニューヨーカーの見解
- 2025-11-14 15:05:01
- 飛行場が離陸: チェーン全体でイーサリアム DeFi の流動性を統合
- 2025-11-14 15:10:02
関連知識
スマート コントラクトにおけるサービス拒否 (DoS) 攻撃とは何ですか?また、その一般的な形式は何ですか?
2025-11-10 05:20:08
スマートコントラクトにおけるサービス拒否について理解する1. スマート コントラクトのコンテキストにおけるサービス拒否 (DoS) 攻撃とは、悪意のある攻撃者が正当なユーザーによるコントラクトの機能へのアクセスまたは使用を妨げるシナリオを指します。これは通常、攻撃者が重要な操作をブロックできるように...
トランザクション署名で使用される暗号化ナンスとは何ですか?
2025-11-11 05:59:39
ブロックチェーントランザクションにおける暗号化ナンスを理解する1. 暗号化ナンスは、ブロックチェーン ネットワーク内のトランザクション署名のコンテキストで 1 回だけ使用される乱数または擬似乱数です。その主な機能は、各トランザクションが一意であり、悪意のある行為者によって再実行できないことを保証する...
Solidity スマート コントラクトでは継承はどのように機能しますか?
2025-11-11 22:40:12
Solidity の継承: モジュール式スマート コントラクトの構築1. Solidity の継承により、あるコントラクトが別のコントラクトのプロパティと機能を採用できるようになり、コードの再利用と構造化設計が可能になります。派生コントラクトは、プライベートとしてマークされていない限り、基本コントラ...
外部所有アカウント (EOA) と契約アカウントの違いは何ですか?
2025-11-13 04:00:32
外部所有アカウント (EOA) について1. 外部所有アカウントは秘密キーによって直接制御されます。つまり、そのキーの所有者のみがアカウントからトランザクションを開始できます。 EOA には関連するコードがありません。これらは、ブロックチェーン上でトランザクションを送受信するために使用される単純なア...
ERC-2981 NFT ロイヤルティ標準とは何ですか?またどのように機能しますか?
2025-11-13 05:39:54
ERC-2981 NFT ロイヤルティ標準を理解する1. ERC-2981 標準は、非代替トークン (NFT) のロイヤルティ メカニズムを導入するイーサリアムのコメント要求です。ロイヤルティのサポートが組み込まれていない ERC-721 や ERC-1155 などの以前の NFT 標準とは異なり、...
Minimal Proxy Contract (EIP-1167) とは何ですか? また、導入時のガスをどのように節約しますか?
2025-11-12 11:39:42
最小プロキシ契約 (EIP-1167) とは何ですか? 1. イーサリアム改善提案 (EIP) 1167 に基づいて標準化されたミニマル プロキシ コントラクトは、呼び出しを既存の実装コントラクトに委任するように設計された軽量のコントラクトです。これは、ロジックを内部に保存せずに、すべての関数呼び出...
スマート コントラクトにおけるサービス拒否 (DoS) 攻撃とは何ですか?また、その一般的な形式は何ですか?
2025-11-10 05:20:08
スマートコントラクトにおけるサービス拒否について理解する1. スマート コントラクトのコンテキストにおけるサービス拒否 (DoS) 攻撃とは、悪意のある攻撃者が正当なユーザーによるコントラクトの機能へのアクセスまたは使用を妨げるシナリオを指します。これは通常、攻撃者が重要な操作をブロックできるように...
トランザクション署名で使用される暗号化ナンスとは何ですか?
2025-11-11 05:59:39
ブロックチェーントランザクションにおける暗号化ナンスを理解する1. 暗号化ナンスは、ブロックチェーン ネットワーク内のトランザクション署名のコンテキストで 1 回だけ使用される乱数または擬似乱数です。その主な機能は、各トランザクションが一意であり、悪意のある行為者によって再実行できないことを保証する...
Solidity スマート コントラクトでは継承はどのように機能しますか?
2025-11-11 22:40:12
Solidity の継承: モジュール式スマート コントラクトの構築1. Solidity の継承により、あるコントラクトが別のコントラクトのプロパティと機能を採用できるようになり、コードの再利用と構造化設計が可能になります。派生コントラクトは、プライベートとしてマークされていない限り、基本コントラ...
外部所有アカウント (EOA) と契約アカウントの違いは何ですか?
2025-11-13 04:00:32
外部所有アカウント (EOA) について1. 外部所有アカウントは秘密キーによって直接制御されます。つまり、そのキーの所有者のみがアカウントからトランザクションを開始できます。 EOA には関連するコードがありません。これらは、ブロックチェーン上でトランザクションを送受信するために使用される単純なア...
ERC-2981 NFT ロイヤルティ標準とは何ですか?またどのように機能しますか?
2025-11-13 05:39:54
ERC-2981 NFT ロイヤルティ標準を理解する1. ERC-2981 標準は、非代替トークン (NFT) のロイヤルティ メカニズムを導入するイーサリアムのコメント要求です。ロイヤルティのサポートが組み込まれていない ERC-721 や ERC-1155 などの以前の NFT 標準とは異なり、...
Minimal Proxy Contract (EIP-1167) とは何ですか? また、導入時のガスをどのように節約しますか?
2025-11-12 11:39:42
最小プロキシ契約 (EIP-1167) とは何ですか? 1. イーサリアム改善提案 (EIP) 1167 に基づいて標準化されたミニマル プロキシ コントラクトは、呼び出しを既存の実装コントラクトに委任するように設計された軽量のコントラクトです。これは、ロジックを内部に保存せずに、すべての関数呼び出...
すべての記事を見る














