[WIP] Dynamic gas based on trie size

[avalkov]

Description

Charge gas based on contract trie size when executing SSTORE and SLOAD opcodes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[cffls]

This might be extremely expensive. The largest contract on mainnet is ~92G.

[avalkov]

Thanks for comment, its just PoC exploration. We will most likely have background task or we will sync from genesis and calculating state size growth only via SetState.

[avalkov]

With utility I made just for this, I managed to iterate the whole db for like 48 hours.

[cffls]

Curious how would it be possible to calculate the trie state diff on the fly per SSTORE?

[avalkov]

Not exactly state diff but for example if you sync from genesis you can use https://github.com/0xPolygon/bor/blob/master/core/state/state_object.go#L222 to track the state growth per account in which case heavy function like storageTrieSize wont be needed at all. Ofcourse storageTrieSize accounts for some metadata generated on disk, which we can account for with some formula too.

[git20260111]

1. According to https://www.bnbchain.org/en/blog/bnb-smart-chain-annual-storage-report-2024, the top 20 contracts account for approximately 20% of the Trie Nodes. The top contracts in this statistic are also present on Polygon. The first contract hash: 0xe9dae3d797a6bf53395810df9d7048f18ac98f1bd211dc87dfad3532aa88d237, which is 0x2ab0e9e4ee70fff1fb9d67031e44f6410170d00e, is also on Polygon. This contract airdropped XEN tokens to almost every address on Polygon, resulting in approximately 1 billion Trie Nodes. I have previously written code to traverse all the trie nodes, which took about 10 hours each time. Using geth db inspect for statistics also takes approximately 10 hours.
2. My suggestion is to create a precompiled contract , periodically runs statistical code offline, and store the trie node information of the top N contracts in the precompiled contract. This information can then be used to calculate the gas consumption of SSTORE and SLOAD operations.
3. Calculating trie nodes within state_object.go would prevent nodes from verifying blocks in stateless mode. Storing the trie node information in a precompiled contract, however, would allow it to work in stateless mode.
4. Furthermore, I think this dynamic gas adjustment could be applied at the contract level, meaning the gas consumption of the entire contract would be multiplied by this adjustment factor, rather than being limited to just SSTORE and SLOAD operations. This would allow for penalizing contracts that consume a large amount of system resources but use relatively few SSTORE and SLOAD operations. This approach would also be simpler to implement.
5. This mechanism can be used to penalize certain contracts, causing them to consume more gas and thus limiting their misuse. It can also be used to reward certain contracts (whose state will be pre-loaded), effectively dividing their gas consumption by a certain value.