mhofman
commented
1 month ago The main problem is how to advance time.
The system clock is global for a whole physical machine: VMs usually share it with the physical machine, and containers definitely share it with the host kernel.
On the opposite side we have time observed by vats, which is controlled by vat-timer. There are currently no specific plans to upgrade that vat. Furthermore having a time observed by vats being different from the chain time might cause confusion for tools sitting outside the chain and observing values written by vats that are disconnected from the chain time.
In production, the time observed by vats is derived from the chain time, so the least disruptive would be to tweak the chain time instead. I am not sure whether cosmos-sdk has any affordances to manually derive the chain time.
dckc
Problem to be solved
Upgrade16 had some auction timing bugs with timing that could have been detected in an A3P test if the test could time travel forward.
Unit tests in agoric-sdk have this ability through the ManualTimer service replacing the real one in bootstrap, but A3P tests are too high fidelity for that.
We need some other way to advance time.
Design
The test tooling could provide a way to advance the Linux system time.
Some other designs may need changes in agoric-sdk. This ticket tracks having the ability in the
@agoric/synthetic-chainsupport package.