dApp 儲存（增長）問題

我的 dApp 允許使用者在購買每個 NFT 令牌時保存他們的 URL。顯而易見的設計將定義——

struct NFT {
   ...
   string url;
}

但是，URL 可能很長。為了給使用者省油，我修改了設計，只保存每個 NFT 中 URL 的雜湊值和另一個映射中的實際 URL，這基本上意味著——

struct NFT {
   ...
   uint urlKeccak256;
}
mapping(uint => string) private urlMap;

function saveUrl(string calldata _url) {
   ...
   uint _urlKeccak256 = uint(keccak256(abi.encode(_url)));
   urlMap[_urlKeccak256] = _url;

   NFT memory nft;
   nft.urlKeccak256 = _urlKeccak256;
}

雖然這種設計確實平均節省了汽油，但我的問題是：

由於沒有（有效或廉價的）方法可以從 urlMap 中刪除未使用的條目，如果 urlMap 的鏈上儲存不斷增長（可能達到數百 MB 甚至更多），是否會有未來的擔憂？

乙太坊不收取儲存數據的租金，因此在許多情況下，保存不再需要的儲存數據比刪除它更省氣。

自毀（又名自殺）操作碼應該通過刪除不再需要的合約的儲存來解決這個問題，但它導致的問題多於解決的問題，所以現在不鼓勵使用它。

因此，現在將垃圾數據留在儲存中是正常的，以防從 gas 成本的角度來看清理不合理。

引用自：https://ethereum.stackexchange.com/questions/78439