スマート コントラクトからストレージ変数を読み取る方法は?

Ethereum スマート コントラクトのストレージ レイアウトを理解する

1. Ethereum にデプロイされたすべてのスマート コントラクトは、永続ストレージ スロットに状態を維持します。永続ストレージ スロットはそれぞれ 32 バイト幅で、スロット 0 から順にインデックスが付けられます。

2. コンパイラは、型のサイズと効率性を考慮したパッキング ルールを考慮して、状態変数の宣言順序に基づいて格納場所を割り当てます。

3. 構造体、配列、およびマッピングは複雑さをもたらします。動的配列はスロットに長さを格納し、keccak256 で計算されたオフセットにデータを格納します。マッピングでは、keccak256(キー、スロット) を使用してストレージ位置を導出します。

4. 0.8.0 より前の Solidity バージョンでは、変数境界を越えてより厳密なパッキングが可能でしたが、新しいバージョンではより厳密な位置合わせが強制され、手動スロット計算の精度に影響を及ぼします。

5. コントラクトの継承はレイアウトに影響します。基本コントラクトからの変数が下位のスロットを占有し、その後に線形順序で派生コントラクトからの変数が続きます。

eth_getStorageAt による直接オンチェーン読み取り

1. JSON-RPC メソッドeth_getStorageAt は、コントラクト アドレス、スロット インデックス、およびブロック識別子を使用して、特定のストレージ スロットから生の 32 バイト値を取得します。

2. スロット インデックスは手動で計算するか、コントラクトのメタデータ ファイルやビルド情報ファイルにある Solidity 生成のストレージ レイアウト JSON などのコンパイル アーティファクトから抽出する必要があります。

3.hardhat -storage-layoutやSrither-print-storageなどのツールは、AST とバイトコードを解析することでスロット マッピングを自動化し、人的エラーを削減します。

4. infura または Alchemy エンドポイントを使用してクエリを実行する場合、レート制限とアーカイブ ノード要件が適用されます。特に、契約のアップグレードまたは自己破壊前の履歴スロット値に適用されます。

5. 16 進数でエンコードされた応答にはデコードが必要です。uint256 値は左詰めで表示され、アドレスは最後の 20 バイトで右詰めされ、ブール値は 0x01 または 0x00 にマップされます。

複合型を手動でデコードする

1. 静的配列の場合、各要素は適合する場合は 1 つのスロットを占有します。それ以外の場合、要素は標準の配置ルールに従って連続するスロットにあふれます。

2. 動的配列データは keccak256(slot) で始まり、最初の 32 バイトが配列の長さを保持し、後続のスロットには keccak256(slot)+1 から始まる要素が連続して格納されます。

3. マッピングではキーごとに keccak256 を再計算する必要があります。mapping (address => uint256) 公的残高の場合、アドレス 0xAbc… のスロットは keccak256(abi.encodePacked(0xAbc…, slot_index)) です。

4. ネストされた構造は複雑さを増します。たとえば、構造体へのマッピングでは、最初にマッピング スロットを計算し、次にそのベースを基準とした構造体フィールド オフセットを適用する必要があります。

5. 構造体の内部のオフセットは、トップレベルの変数と同じルールに従います。uint128 + uint128 は 1 つのスロットにパックされますが、uint256 を追加すると、アライメントの制約により新しいスロットが強制的に作成されます。

鋳造と鋳造による実際の検査

1. Cast storageコマンドはコントラクト アドレスとスロット番号を受け入れ、ABI またはレイアウトが提供されている場合は値を自動的にフェッチし、オプションでデコードします。

2. --watch を使用すると、キャストはブロック全体でのストレージの変更を監視します。これは、リエントラントやフラッシュ ローンの副作用をリアルタイムで観察するのに役立ちます。

3. Foundry のforge Inspection は、変数名、タイプ、スロット番号、バイト オフセットを含む完全なストレージ レイアウトを出力します。手動による ABI 解析は必要ありません。

4. ソース コードが利用できない場合は、リバース エンジニアリングが必要になります。トランザクション トレース内の SSTORE オペコードを分析すると、どのスロットがいつ書き込まれたかが明らかになります。

5. web3.py または ethers.js を活用したカスタム スクリプトは、複数のスロットのバッチクエリ、テーブルとしての出力のフォーマット、Transparent や UUPS などの既知のプロキシ パターンとの相互参照が可能です。

よくある質問

Q: ソース コードを知らなくても、コントラクトからストレージを読み取ることはできますか? A: はい。バイトコード分析、オペコード トレース、または OpenZeppelin プロキシや ERC-20 天びんの一般的なスロット パターンなどのヒューリスティックを使用します。しかし、文脈がなければ解釈は曖昧なままです。

Q: 存在することがわかっているゼロ以外の値に対して eth_getStorageAt がゼロを返すのはなぜですか? A: 考えられる原因としては、間違ったスロットのクエリ、古いブロック番号の使用、実装に転送せずにプロキシをターゲットにする、初期化されていないメモリ (デフォルトはゼロ) の読み取りなどが挙げられます。

Q: ストレージ読み取りをオフチェーンで実行するとガスがかかりますか? A: いいえ。eth_getStorageAtは無料の RPC 呼び出しです。ガスコストは、トランザクションまたはビュー関数内で実行されるオンチェーン読み取りにのみ適用されます。

Q: コンパイラのバージョン間でストレージ スロット番号を信頼しても安全ですか? A: 保証されません。Solidity の更新により、レイアウト アルゴリズムが変更される可能性があります。展開中に使用されるコンパイラの正確なバージョンと最適化設定を常に確認してください。