Deleting a struct which contains a mapping is dangerous

Photo by Kelly Sikkema on Unsplash

In Solidity, a struct is a complex data type that allows you to group together variables of different data types. And a mapping is a data structure that allows you to store key-value pairs.

The security implications of deleting a struct that contains a mapping are subtle, but important to understand in the context of Ethereum smart contracts.

When you delete a struct in Solidity, it will not delete the mapping within it. The delete keyword in Solidity sets every field in the struct to its default value. For integers, strings, arrays, and other simple data types, this means they will be set to zero, an empty string, or an empty array, respectively.

However, for mappings, the delete keyword has no effect. This is because mappings are implemented as hash tables and the Ethereum Virtual Machine (EVM) does not keep track of which keys have been used in the mapping. As a result, it doesn't know how to "reset" a mapping. Therefore, when you delete a struct, the mapping within it will still retain its old data.

This can lead to potential security issues, particularly if you’re not aware of this behavior. For example, let’s say you have a struct that contains sensitive data within a mapping. If you delete the struct assuming that all data within it will be erased, the data in the mapping will still persist, potentially leading to unintended access or misuse.

Time for an Example

Suppose you have a contract that manages user data, with a struct that contains user information and a mapping that maps user ids to whether they are active or not.

pragma solidity ^0.8.0;

contract UserData {
    struct UserInfo {
        string name;
        uint age;
        mapping(uint => bool) isActive;
    }

    mapping(address => UserInfo) public users;

    function addUser(address _user, string memory _name, uint _age) public {
        UserInfo storage user = users[_user];
        user.name = _name;
        user.age = _age;
        user.isActive[0] = true;
    }

    function removeUser(address _user) public {
        delete users[_user];
    }
}

In this contract, addUser function is used to add a new user, and removeUser function is used to delete a user.

However, if you call removeUser function, it will not delete the isActive mapping within the UserInfo struct. This means that even after a user has been deleted, their isActive data will still persist in the contract.

If there’s a function that reads the isActive mapping, it could potentially access the deleted user's data.

To verify this, let’s add a function isActive:

function isActive(address _user, uint _id) public view returns (bool) {
    return users[_user].isActive[_id];
}

You’ll find that even after calling removeUser, calling isActive with the same _user and _id will still return true.

This is a potential security issue if the isActive data is sensitive and should be deleted along with the user.

Conclusion

In conclusion, the intricacies of data deletion in Solidity, specifically when dealing with structs containing mappings, can pose potential security and efficiency issues. The persistent nature of mappings, even after a parent struct’s deletion, is a design feature of Solidity that developers must acknowledge to avoid data leaks or misuse. While the delete keyword resets most variables to their default state, mappings, implemented as hash tables, do not adhere to this behavior. The Ethereum Virtual Machine (EVM) does not keep track of keys used in a mapping, hence it does not know how to "reset" it, leading to data persistence even after a supposed deletion.

Understanding these nuances is crucial for developers when managing sensitive data and calculating gas costs. Ensuring proper data management is a fundamental aspect of creating secure and efficient smart contracts. Misunderstandings about these concepts can result in higher-than-expected operation costs, and more seriously, exposure of sensitive data. As the blockchain development field continues to evolve, cultivating a deep understanding of these language-specific behaviors is critical for building secure, robust, and efficient decentralized applications.

Disclaimer: This article was written in cooperation with an LLM (Large Language Model) #transparentai