Solidity needs to support the trie type, so that the amount of stored data is smaller and the search is faster. The gas of contract transactions will be reduced

[Marius-BC-Dev]

[cameel]

Can you elaborate? What use cases do you have in mind?

This sounds like something that could be implemented as a third-party library. We're currently working on adding generics to the language, which should make implementing such libraries in a reusable way even easier. I think that's a better approach than making more data structures a core part of the language.

[Marius-BC-Dev]

I have considered using a third-party library to implement this function. In the way of a third-party library, the size of the stored data cannot be reduced.

[Marius-BC-Dev]

For example, use map to store account balance, and modify it to use trie structure type to store data will be better. Because it can reduce the gas consumption of contract state data storage.

[cameel]

I don't really see why it would necessarily have to be more expensive when implemented as a separate data structure. Solidity might be missing some high-level syntax to do it nicely (then you should rather request those instead) but ultimately you can always implement things in inline assembly. Solidity ultimately generates assembly to handle maps too.

[Marius-BC-Dev]

I think you understand solidity's storage better than I do. In the map structure, each key uses a space for storage, etc. If the trie structure is used, the key can be partially shared, so the storage size and gas can be reduced.

[cameel]

each key uses a space for storage

Not really. For mappings keys are not stored at all. That's why you cannot enumerate the elements or copy the whole mapping.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.