Here's what I'd like to be able to do with your tool.

• provide it with access to a JSON-RPC server where it can fetch the ethereum state "on demand" as it is needed.
  • $ ./predict --web3 http://localhost:8545 ...`
• execution modes:
  • re-execute a transaction from history referenced by it's hash
    • $ ./predict old-tx 0x<tx-hash>
  • execute a new "transaction" with manually specified fields for from/to/value/data
    • $ ./predict new-tx --from ... --to ... --value ... --data ...
  • raw execute some code
    • $ ./predict execute --code --from ... --to ... --value ... --data ...
• see detailed information on how the predictive algorithm worked
  • the full access list (what was accessed)
  • how many steps did the algorithm take (how many batches of state needed to be fetch).
    • the actual code that was executed probably represented as a sequence of program counters and maybe the actual opcodes that were executed in what order.
    • the actual state and accounts that were identified as being needed (including which ones we already had, and which ones needed to be fetchd)
    • maybe even fancier meta data about how each piece of state was determined to be needed.

$ ./predict ...
ROUND 0:
    opcodes: PUSH32 ... SLOAD ...
    new state access:
        ACCOUNT: ....
        STORAGE: ...
ROUND 1:
    ...
SUMMARY:
    rounds: 5
    state items: 100
    retrieval batches: 3, 22, 50, 25

One goal here is to be able to run this continuously against transactions in mainnet blocks to examine real world transaction access patterns and see how well the tool performs against real world transactions.