Summary: We use simulations to explore the performance implications of implementing storage rent in RSK.
There is some performance degradation, mainly VM execution, Trie GetValue and block execution are slower.
However, these contribute to a small portion of system time, which is dominated by key recovery from signature and block validation.
While further evaluation is needed, the results indicate that the “performance cost” of implementing rent is likely to remain small.
This is encouraging as we continue to explore the benefits of implementing storage rent e.g. improved resource use, better state caching, reducing gas arbitrage, improve security from IO attacks.
I don’t understand the basis to mention the second point: these activities dominates the block execution time, and they are under improvement. So, no decision could be based on the time employed in those activities.
For better state caching, there are many approaches to be implemented, without changing the consensus.
Although storage rent could be an improvement, I would recommend to apply it in the future, when more data were available on REAL use case in RSK mainnet; maybe, we could learn also from other early production implementation (I don’t anyone, yet)
Thanks @ajlopez! Of course, you are right … no decision should be based on that or any other isolated fact. In this simple experiment, I tried to quantify some of the costs of rent. Reference to other sources of system time use is just for context, not criticism.
Without data, it is hard to measure the costs or benefits of implementing storage rent. It is especially hard to get data about benefits without a real implementation (on mainnet, which provides actual economic incentives). Without that, we can only simulate some scenarios and speculate how users may respond. Or we will have to depend on indirect inferences from other projects that take the lead and implement some version of rent without actually calling it rent (e.g. Near protocol [0], or regenesis discussions in Eth2 [1]). Or one can take the lead – as RSK did with the Unitrie – learn from data, and iterate.
We do have a huge amount of information in the Ethereum blockchain. We can simulate usage patterns similar to Ethereum.
Sadly, we can’t wait for high congestion to hit RSK without storage rent, because we’ll fail to the same trap Ethereum has. The purpose of a protection measure (as storage rent is) is to do it before it’s too late. @ajlopez you proposal to stay still until the problem occurs is dangerous and blind because we know for sure the problem will eventually occur.
Finally, the RSK whitepaper states that RSK will implement some form of storage rent, so there is a social contract to move forward with the best version of it we can came up with, or provide an alternative and a strong reason for it. Absent another solution to state blow up (such as switching to full stateless clients), we should follow the roadmap and social contract to implement rent.
@shreemoy have you tried replaying this simulation with new versions? We recently integrated Native implementations of Key Recovery, which could be a considerable improvement in validation time, and could help you get a more clear result.
@patogallaiov Hi and thanks for the tip! That’s an incredible performance jump in the chart you shared. I’ll merge the recent changes into the experimental branch and run them again.
And remember that key_recover is actually included in validation time… the accurate charts would be like these ones (@raul can correct me if I’m wrong) :
