Ether を別のコントラクトに安全に送信するにはどうすればよいですか?

スマート コントラクトへの Ether の送信: 重要な考慮事項

1. 受信契約に、イーサを受け入れることができる支払い可能フォールバック機能または指定された支払い可能機能があることを確認します。これがないと、送金が元に戻り、資金が永久にロックされる可能性があります。

2. address(contract).call{value: amount}('') は、残りのガスをすべて転送し、組み込みの安全チェックが欠けているため、外部コントラクトと対話する場合は慎重に使用してください。このメソッドはコンパイル時のチェックをバイパスするため、適切に保護されていない場合、トランザクションが再入攻撃にさらされる可能性があります。

3. 古い Solidity バージョンの低レベル呼び出しよりも.transfer()または.send()の使用を優先します。これは、ガス転送を 2300 ユニットに制限し、受信中に悪意のあるコードが実行されるリスクを軽減するためです。 .send() は失敗時に元に戻すのではなく false を返すため、明示的なエラー処理が必要であることに注意してください。

4. Ether を送信するときは、独自のコントラクトに常にチェック - 効果 - インタラクション パターンを実装します。再帰的コールバック中に資金を枯渇させる可能性のある再入エクスプロイトを防ぐために、外部コントラクトを呼び出す前に状態変更が発生することを確認します。

5. ターゲット契約のソースコードが検証および監査されていることを確認します。コードを公開せずにコントラクトを展開すると、対話前にコントラクトの動作を個別に検証できないため、重大なリスクが生じます。

イーサ転送でよくある落とし穴を回避する

1. コントラクトが存在するからといって、コントラクトが Ether を受け取ることができるとは決して考えないでください。多くのコントラクトは、特定の条件が満たされない限り、フォールバック関数で復帰することにより、イーサの直接受信を明示的にブロックします。

2. Ether を転送するときの delegatecall の使用には注意してください。 delegatecall は呼び出し側コントラクトのコンテキストでコードを実行するため、これを値の転送と組み合わせると、予期しないストレージの変更や資金の損失が発生する可能性があります。

3. Web3 インターフェイス経由で Ether を送信するときは、ガス推定エラーに注意してください。一部のウォレットでは、受信者の契約に必要な追加の計算が考慮されていない可能性があり、一見十分な制限があるように見えてもガス欠エラーが発生することがあります。

4. 運用環境ではハードコーディングされたアドレスを避けます。代わりに、登録されたコントラクト参照またはデプロイメント中に初期化された不変変数を使用して、誤った転送の可能性を減らします。

5. 高価値の転送を実行する前に、メインネットと同じ構成を使用してテストネットでトランザクションをテストします。コンパイラのバージョンやネットワーク条件の違いにより、コントラクトの動作が予期せず変化する可能性があります。

契約間イーサフローのセキュリティ慣行

1. 可能な限りプッシュ支払いではなく、引き出しパターンを実装します。ユーザーが Ether を直接プッシュするのではなく、資金を引き出すことができるため、送信失敗やサービス妨害ベクトルへの曝露を最小限に抑えることができます。

2. 単一のコントラクト内で繰り返されるイーサ転送にレート制限を適用し、攻撃者が残高を操作したり、意図しない副作用を引き起こしたりするために繰り返しのインタラクションを強制する潜在的な悪用シナリオを軽減します。

3. 安全な転送のために OpenZeppelin のAddress.solライブラリを利用します。その関数 sendValueには自動成功チェックが含まれており、失敗した場合は元に戻り、安全な Ether ディスパッチが簡素化されます。

4. .send() を使用する場合は、サイレントエラーを監視します。失敗時に元に戻る.transfer()とは異なり、 .send() はブール値を返します。結果の確認を怠ると、気付かないうちに資金保持の問題が発生する可能性があります。

5. 公開アクセスが厳密に必要でない限り、onlyOwner やロールベースのコントロールなどの修飾子を使用して、イーサ送信関数へのアクセスを制限します。機能が制限されていないと、不正な資金分散に対する攻撃対象領域が増加します。

よくある質問

コントラクトが Ether を受け取ったものの、それを処理できない場合はどうなりますか?コントラクトに支払い可能なフォールバックまたは受信機能が欠けている場合、イーサを送信しようとするとトランザクションが元に戻されます。これにより送信者は偶発的な紛失から保護されますが、転送を開始する前に慎重な検証が必要です。

コントラクトを他の場所に送信した後、コントラクトは自己破壊してイーサを取り戻すことができますか?はい、 selfdestruct(address)オペコードを介して、コントラクトは、そのアドレスが通常 Ether を拒否する場合でも、残高を別のアドレスに強制的に送信できます。これは通常の受信ロジックをバイパスし、侵襲的な性質があるため、使用は控えめにする必要があります。

コンストラクター関数で msg.value を使用しても安全ですか?コンストラクターは、支払い可能としてマークされている場合、デプロイメント中に Ether を受け入れることができます。ただし、初期化時にロジック エラーが発生すると、資金がロックされたり、アップグレード パスがなく誤って割り当てられたりする可能性があるため、細心の注意が必要です。

EIP-1884 は契約への Ether 転送にどのような影響を与えますか? EIP-1884 により、SLOAD などの特定のオペコードのコストが増加し、イーサを受信するコントラクトのガス計算に影響を及ぼしました。以前は成功していたトランザクション、特に受信中に複雑なフォールバック ロジックに依存するトランザクションでは、ガスが不足する可能性があります。