This introduces message prototypes to applicable API endpoints, which
allows us to invert control of message sending and give the user a
chance to intervene with an interactive ui.
Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>
This paves the way for better object lifetime management.
Concretely, it makes it possible to:
- have different stores backing chain and state data.
- having the same datastore library, but using different parameters.
- attach different caching layers/policies to each class of data, e.g.
sizing caches differently.
- specifying different retention policies for chain and state data.
This separation is important because:
- access patterns/frequency of chain and state data are different.
- state is derivable from chain, so one could never expunge the chain
store, and only retain state objects reachable from the last finality
in the state store.
The bug is applying all messages from given From address are priors
before appling the message that we are estimating.
If user tries replacing message in the middle with gas limit estimation
then message sequence is off and user will either get an execution error
or gas mis-esimation.
Resolves#5402
Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>
The aim is to put some negative pressure on gas-premium instead of
maintining status quo.
55th percentile instead of median should not make much difference for
block inclusion timing.
Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>
_Always_ (almost) use the tipset's parent state, instead of computing.
Exceptions:
* MinerGetBaseInfo. Fixing this would break things so we need to be
careful (although we could bump the API version, fix it, then fix the call
sites).
* StateReplay. This is replaying a message on top of the given tipset.
* GasEstimateGasLimit. This executes the message on-top-of the tipset's
computed state (unlike call which executes it on the tipset's parent state).
* Having this method and Call apply the message at different heights is really
weird.
This is terrible, but we don't (currently) update this in the miner info.
Q: Maybe we should delay this by a few epochs? Some pre-commits could fail if we
get a reorg.
