Proposed future Arbiter architecture

[ts0yu]

Colin said I should post this here :)

[Autoparallel]

@kinrezC we should think about database stuff in here.

[0xJepsen]

@ts0yu I think this is a really good approach. I think Q3 this year we will be focussing on really cleaning up the code base. We have finished a simple sim for uniswap which we are just polishing up before we do a write up for.

[ts0yu]

Thanks. Regarding the database stuff @Autoparallel , I was thinking we should have some "Inspector" trait you could attach to the engine. The trait would have a log function, and this means users could adapt and change how their simulations return results.

[Autoparallel]

Yeah I think this is good as a trait. I think toggling on and off logging of quantities associated to agents would be very slick.

[Autoparallel]

I was just thinking... any time we have to do "pure math" (i.e., calling solstat or solmate functions) in the EVM, we could avoid doing transact_commit(). In fact, we could build an interface for these math functions that has it's own EVM that implements transact() only and is just used for this sole purpose.

[ts0yu]

The other thing to think about is how to make this "env agnostic"... So how could we make this available for anvil, revm, mainnet, and any other user defined state capture mechanism.

[Autoparallel]

My thought on this is building out very minimal ethers::middleware or client for revm. Doing this has other benefits as far as using bindings as well. This would be huge, but I'm not really sure how to do it. I spent a few hours in middleware hell and called it quits. I'd like to revisit it though.

This point is huge though. I agree strongly.