ChenxingLi
commented
9 months ago There is an additional issue at the execution layer. Even if the whitelist entry has been stored in the snapshot and the delete_all_by_prefix behaves correctly, there remains a problem. If the relevant entry is absent in the cache, it still cannot be removed correctly.
Conflux utilizes a storage model that is based on a key-value database. The contract deletion process relies on the storage layer's interface named
delete_all_by_prefixto clear the storage and the whitelist for this contract.Conflux's storage consists of three main parts: Snapshot, intermediate set, and delta set. The key serialization logic for the last two sets differs from the snapshot, as elaborated in the Conflux Protocol Specification Sections 3.2.1 and 3.2.2.
There is a bug in the implementation. While the
delete_all_by_prefixlogic can accurately process data in the Snapshot, it fails to do so for the data in the intermediate and delta sets. This discrepancy leads to a specific issue: When attempting to kill a contract, whitelist entries written in the most recent 2000 to 4000 epochs (the most recent two snapshot periods) might not be correctly removed.The Ethereum community is actively pushing to eliminate the
SELFDESTRUCT(0xff)opcode (e.g., EIP-4758, EIP-6780). Deploying a new contract at the same address as a self-destructed contract is a rare and unusual behavior resulting from theSELFDESTRUCT(0xff)opcode. Conflux's sponsor mechanism should not make special accommodations for such corner cases. Instead, when a contract is deleted, its whitelist should be retained. If a new contract is subsequently deployed at the same address, the deployer and sponsors of the new contract should rightfully inherit the whitelist of the previous contract at that address.