Speedup: don't use EVM if no EVM agents

[trentmc]

Is your feature request related to a problem? Please describe. Some netlists, such as wsloop, don't need EVM. However EVM is nonetheless invoked as the simulation proceeds, because all agents store OCEAN on EVM-based wallets. Using EVM, even in this lightweight way, makes the run take much longer (at least 5x, maybe as much as 50x).

Describe the solution you'd like

• Each agent inherits from either EVM or non-EVM base agent. Has corresponding EVM or non-EVM wallet. That's all, don't even need to do anything at netlist level (!)

[LinuxIsCool]

To me, it looks like this implementation requires two components:

1. Netlist contains a 'use_evm' flag (boolean) use_evm = False (True by default)
2. A state variable on the simulation state object, set from the netlist
3. An implementation of non-EVM wallets for agents
4. A switch in the simulation engine or on the agents themselves that determines whether agents use EVM wallets or non-EVM wallets during simulations, according to the 'use_evm' flag that is set on the simulation state.

[trentmc]

Set priority to mid. Why: some teams are using tokenspice0.1 because they want to model Web3 Sustainability Loop. They can, but it's a bit of a shame that they can't use the main codebase (without slowdown), which is a lost opportunity to onboard them to that main codebase.

3. An implementation of non-EVM wallets for agents

Yes. We can either (a) refactor the caching, or (b) have two different AgentWallet implementations, one EVM centric and one not. (b) will be safer / less error prone.

[trentmc]

This should be done after #52 and #71, because they will likely change the architecture.

Also: people who really want this right now are mostly ones who want wsloop; for that they can use tokenspice0.1 repo.

[trentmc]

Benchmarking notes on running wsloop netlist, on my 3yo Lenovo laptop:

Runtimes with status quo in tokenspice/tokenspice:

• time_step = 1h, running a 1y sim takes 0.133h, ie 0.133 h/y. Therefore: 10y -> 1.33h, 20y -> 2.66h, 150y -> 20h.
• time_step = 1d, running a 6y sim takes 0.150h, ie 0.025 h/y. Therefore 10y -> 0.25h, 20y -> 0.50h, 150y -> 3.75h.
• time_step = 1d, running a 11.18y sim takes 0.283h, ie 0.025 h/y. Therefore it doesn't slow down (or barely slows) with longer sims. This makes sense, since it's mostly just tracking current state, and there are few lists to keep appending.

Runtimes with tokenspice/tokenspice0.1 [no EVM]:

• time_step default was 1 day (24h) [ref]. From my memory, running for 20 yrs took <1 min. I could double-check if needed. Therefore for 150 yrs, would take < 1.25h, and from memory it was <20 min.

Summary: with "pure" non-EVM, runtime is about 20x faster. For a 20-year sim it's 1 min vs 20 min.

Q: is doing this speedup worth it? A: yes. 1-min (vs 20 min) turnaround greatly helps workflows on "pure" non-EVM sims. And there is work on that in near term, including Ocean and other collaborators.

[trentmc]

Concern: If some agents see OCEAN on EVM, and some don't, then OCEAN supply could get mixed up. Does this affects calculations in wsloop for mkt_cap / supply?

Answer: No. Wsloop tracks OCEAN supply not in EVM, but inside SimState.

Details...

In assets/netlists/wsloop/SimState.py:

    def __init__(self..):
    ...
        self._total_OCEAN_minted: float = 0.0
        self._total_OCEAN_burned: float = 0.0
        self._total_OCEAN_burned_USD: float = 0.0
    ...

    def OCEANsupply(self) -> float:
        """Current OCEAN token supply"""
        return self.initialOCEAN() \
            + self.totalOCEANminted() \
            - self.totalOCEANburned()

    def initialOCEAN(self) -> float:
        return self.ss.INIT_OCEAN_SUPPLY

    def totalOCEANminted(self) -> float:
        return self._total_OCEAN_minted

    def totalOCEANburned(self) -> float:
        return self._total_OCEAN_burned

    def totalOCEANburnedUSD(self) -> float:
        return self._total_OCEAN_burned_USD

In assets/agents/MinterAgents.py is the following. It's the only place in code that total_OCEAN_minted is changed from its initial value of 0.0.

    state._total_OCEAN_minted += OCEAN
...
    state._total_OCEAN_minted += OCEAN

In assets/agents/OCEANBurnerAgent.py is the following. It's the only place in code that total_OCEAN_burned is changed from its initial value of 0.0.

    state._total_OCEAN_burned += OCEAN

Do note that AgentWalletEvm.__init__() calls globaltokens.mintOCEAN() and sends the minted token to the new agent. However that should be ok, it's not interacting with the rest of wsloop. Will be good to confirm once we have oceanv3 netlist running end-to-end with wsloop. Same for oceanv4.

[trentmc]

I've got it running in a branch now. Runtimes:

• time_step = 1d, running a 10y sim takes <1 min. We've re-achieved the speeds of before :)