Rigorous Store Testing and Benchmarking

[robert-zaremba]

We need more insights about store to know more about:

• slow paths
• operation pricing
• benchmarking different scenarios
• benchmarking different implementations (eg store and store/v2)

In the scope of this (without any order or priority):

• real world benchmark (only on the store level, so not involving blockchain transactions, but store operations and commits)
• crash tests - to find which scenarios are dangerous and causes instabilities
• under covering gas consumption issues - to find out if we need to upgrade the gas model for the store.

Ideally, these tests and benchmarks should be done on the store (commit store?) to be able to test the current (Stargate) implementation and the upcoming ADR-40 one.

[aaronc]

Let's leverage property tests for this. There are lots of invariants we can define. And we can do state machine testing too using the existing store and mem-db's as models.

[robert-zaremba]

Property testing will check logic correctness to some extend. They won't make a good benchmark, crash test and gas consumption inspection.

[aaronc]

Right, I'm just we should include property tests as part of what's considered rigorous

[robert-zaremba]

For crash tests I was thinking about a stochastic or genetic process which will try to find slow paths.