Time

[0xJepsen]

Okay i'm revisiting this after doing some more research on the libraries available that we could use for this. After some digging and reviewing a few libraries with @0xEstelle we have concluded that using desim would be the best approach. Desim is entirely native to rust but inspired by simpy which we are already familiar with. I think it is a great solution to desire to integrate a notion of relative time into our simulations.

[0xJepsen]

I think we will want to maybe first take a look here https://github.com/primitivefinance/arbiter/blob/83e61128031d7a223942eb96c663f87defe50683/lib/simulate/src/environment/sim_environment.rs#L15-L21 and see where we can fit this into our environment and what are all the processes we need to integrate into it to make things happen.

[0xJepsen]

Okay, so after looking more deeply into desim and getting some input on findings. We have decided that it may be more verbos than what we need and add unnecessary complexity for the core library and for our users. We have decided to build a time module to function as a time oracle instead. This time oracle will sample from the Poisson distribution configured with a "expected number of occurrences" of discrete events per block, where a discrete event is a simulation related transaction. For example in uniswap, a block can have an average number of uniswap related transactions (or discrete events) per block. This allows us to have an abstract notion of time in our simulations without needing to occupy or have a notion of blocksize in the simulation.

The planed implementation would be an environment configuration that would in environment.run() would check wether or not it would be needed to update the block, and would update the timestamp. The block update check would depend on the distribution sampling. We would want to expose the environment configuration to the end users to allow them to set an expected number of occurrences per block given their simulation needs.

[Autoparallel]

@0xJepsen Can we relink this issue now and consider closing it with a bit of updates to our block incrementing implementation?

[0xJepsen]

yep, its linked! Do you specifically mean adding block-times in a similar way?

[Autoparallel]

@0xJepsen I'm a bit confused, why did we close this issue? It has not been addressed yet. We still have no way to update or track block time in simulations.

[Autoparallel]

I see it was linked to #378 but I don't think we got this handled properly. It seems we should have created two issues:

• Add ability to update blocks.
• Add ability to update time.

[Autoparallel]

Closing to create a new issue.