如何安全地將以太幣發送到另一個合約？

將以太幣發送到智能合約：關鍵考慮因素

1. 驗證接收合約是否具有應付後備功能或能夠接受以太幣的指定應付功能。如果沒有這一點，任何轉賬都將恢復，並可能永久鎖定資金。

2. 與外部合約交互時請謹慎使用address(contract).call{value: amount}('') ，因為它會轉發所有剩餘的gas並且缺乏內置的安全檢查。此方法會繞過編譯時檢查，如果沒有適當保護，可能會使您的事務遭受重入攻擊。

3. 在舊版 Solidity 中，優先使用.transfer()或.send()而不是低級調用，因為它們將 Gas 轉發限制為 2300 個單位，從而降低了接收期間惡意代碼執行的風險。請注意， .send()在失敗時返回 false，而不是恢復，需要顯式錯誤處理。

4. 在發送以太幣時，始終在您自己的合約中實現檢查-效果-交互模式。確保在調用外部合約之前發生狀態更改，以防止在遞歸回調期間可能耗盡資金的重入漏洞。

5. 確認目標合約的源代碼經過驗證和審計。未發布代碼的已部署合約會帶來重大風險，因為它們的行為在交互之前無法獨立驗證。

避免以太幣傳輸中的常見陷阱

1. 永遠不要假設合約僅僅因為它存在就可以接收以太幣。許多合約通過恢復回退功能來明確阻止直接以太坊接收，除非滿足特定條件。

2. 轉發 Ether 時請謹慎使用 delegatecall。由於 delegatecall 在調用合約的上下文中執行代碼，因此將其與價值轉移相結合可能會導致意外的存儲修改和​​資金損失。

3. 通過 web3 接口發送 Ether 時，注意 Gas 估算錯誤。一些錢包可能無法考慮接收者合約所需的額外計算，即使看似有足夠的限制，也會導致氣體耗盡故障。

4. 避免在生產環境中硬編碼地址。相反，使用註冊的合約引用或在部署期間初始化的不可變變量來減少錯誤傳輸的可能性。

5. 在執行高價值傳輸之前，使用與主網相同的配置在測試網上測試交易。編譯器版本或網絡條件的差異可能會意外地改變合約行為。

合約間以太流的安全實踐

1. 盡可能採用提款模式，而不是推送付款。讓用戶提取資金，而不是直接將以太幣推送給他們，從而最大限度地減少發送失敗和拒絕服務向量的風險。

2. 對單個合約內的重複以太傳輸應用速率限制，以減輕攻擊者強制重複交互以操縱餘額或觸發意外副作用的潛在濫用情況。

3. 利用 OpenZeppelin 的Address.sol庫進行安全傳輸。其函數 sendValue包括自動成功檢查並在失敗時恢復，從而簡化了安全的以太調度。

4. 使用.send()時監視靜默失敗。與失敗時恢復的.transfer()不同， .send()返回一個布爾值；忽視檢查其結果可能會導致未被注意到的資金保留問題。

5. 使用 onlyOwner 或基於角色的控件等修飾符限制對 Ether 發送功能的訪問，除非嚴格需要公共訪問。不受限制的功能增加了未經授權的資金分散的攻擊面。

常見問題解答

如果合約收到以太幣但無法處理它會發生什麼？如果合約缺少應付回退或接收功能，任何發送以太幣的嘗試都會導致交易恢復。這可以保護髮件人免受意外丟失的影響，但需要在開始傳輸之前仔細驗證。

合約可以在發送到其他地方後自毀並回收以太幣嗎？是的，通過selfdestruct(address)操作碼，合約可以強制將其餘額發送到另一個地址，即使該地址通常拒絕以太幣。這會繞過正常的接收邏輯，由於其侵入性，應謹慎使用。

在構造函數中使用 msg.value 安全嗎？如果標記為應付，那麼構建者可以在部署期間接受以太幣。然而，需要格外小心，因為初始化中的任何邏輯錯誤都可能導致資金被鎖定或錯誤分配，而沒有升級路徑。

EIP-1884 如何影響以太幣向合約的傳輸？ EIP-1884 增加了某些操作碼（如 SLOAD）的成本，這會影響接收以太坊的合約的 Gas 計算。之前成功的交易現在可能會耗盡 Gas，尤其是那些在接收過程中依賴於復雜後備邏輯的交易。