圖書館是否可以被迫接收 ETH 作為另一個合約的 selfdestruct() 的接收者或作為礦工獎勵?
在 Solidity 文件中庫部分的末尾,它說庫不能接收 Ether:
與合約相比,庫在以下方面受到限制:
- 他們不能有狀態變數
- 他們不能繼承也不能被繼承
- 他們無法接收乙太幣
- 他們不能被摧毀
payable
編譯器在庫中阻止了發送/接收 ETH(將使用者函式或備份函式標記為)的主要途徑——庫程式碼payable
甚至無法編譯。但是由於另一個合約呼叫 selfdestruct() 而發送到圖書館的 ETH 呢?或者如果圖書館的地址被指定為礦工獎勵的 coinbase 地址?在普通合約(不是庫)中,當通過這最後兩種方法將 ETH 發送到合約時,無法阻止接收 ETH。在這兩種特殊情況下,乙太坊客戶端是否有明確禁止圖書館接收 ETH 的程式碼?如果是這樣,它是一個“通用”塊,以某種方式阻止圖書館在任何情況下接收 ETH,還是專門針對這兩種情況的一個塊?
好吧,回答你的問題,是的!
selfdestruct
如果我們在或作為接收礦工使用它們,圖書館就能夠強行接收乙太幣。此外,這是永遠失去資金的好方法。沒有辦法讓他們回來。
我嘗試了以下程式碼並將其部署在 Rinkeby 上。庫獲得了乙太幣,但是當呼叫
send
函式嘗試提取餘額時,每次都失敗。我們可以在https://rinkeby.etherscan.io/address/0x96d41a99ddd9892eCfB8a923B083332EA7c83eCf中查看庫餘額
SelfDestruct
合約部署在:https : //rinkeby.etherscan.io/address/0xa55Bb46B5929269Db38fDF4E74e8FE032c4F5b29檢查交易,你會看到我是如何將乙太幣發送
0.001
到合約的,然後selfdestruct
是它,迫使它把餘額發送到圖書館。現在圖書館有餘額,但該
send
功能不起作用。庫中的balance
功能有效,它顯示了它自己的平衡。// SPDX-License-Identifier: MIT pragma solidity ^0.8.16; library LibraryToForciblySendFundsTo { function balance() public view returns(uint256) { return address(this).balance; } function send(address payable recipient) public { recipient.transfer(address(this).balance); } } contract SelfDestruct { uint256 public time; function updateTime() public { time = block.timestamp; } receive() external payable {} function destroy(address payable libraryAddress) public { selfdestruct(libraryAddress); } function balance() public view returns(uint256) { return address(this).balance; } }