Eugene audit 2021 05 11

[evgenykuzyakov]

I've decided to comment inline.

Overall I didn't find anything major. I think the biggest issue is remove_all_storage. This is a protocol level decision that led to the removal of prefix deletion or iterations. The recent protocol change also restricted account deletion if the storage usage exceeds 10Kb (beyond the contract). This is done to prevent key iteration.

    /// Removes all storage for the given address.
    pub fn remove_all_storage(_address: &Address) {
        // FIXME: there is presently no way to prefix delete trie state.
        // NOTE: There is not going to be a method on runtime for this.
        //     You may need to store all keys in a list if you want to do this in a contract.
        //     Maybe you can incentivize people to delete dead old keys. They can observe them from
        //     external indexer node and then issue special cleaning transaction.
        //     Either way you may have to store the nonce per storage address root. When the account
        //     has to be deleted the storage nonce needs to be increased, and the old nonce keys
        //     can be deleted over time. That's how TurboGeth does storage.
    }

Without an ability to remove old storage from the account may result in a storage draining in a longer run that is not covered by the protocol yet. I'd recommend addressing this issue asap, which may require a hardfork of existing addresses/contracts.

Potential implementation is:

#[allow(dead_code)]
pub fn storage_to_key_nonced(address: &Address, storage_nonce: u32, key: &H256) -> [u8; 57] {
    let mut result = [0u8; 57];
    result[0] = KeyPrefix::Storage as u8;
    result[1..21].copy_from_slice(&address.0);
    result[21..25].copy_from_slice(&storage_nonce.to_le_bytes());
    result[25..].copy_from_slice(&key.0);
    result
}

[joshuajbouw]

Thanks @evgenykuzyakov for looking into this.

[artob]

@evgenykuzyakov Thanks for that! We are addressing your comments both for the current milestone as well as the roadmap going forward.

[birchmd]

@evgenykuzyakov I don't understand what you mean here. Could you elaborate further?