This is aproposal for an additional flag --manual-stateless-deal and a
corresponding API endpoint ClientStatelessDeal. This allows firing off
an offline-style deal against a miner without keeping further track of
it locally.
Not keeping any local state introduces the limitation of requiring free
storage deals, as there is nothing to tie the payment channel setup to.
Rationale/need for this type of flow is the case of incredibly large
sets of data nd deals, where the client and providers have prearranged
payment ahead of time, and the client has a separate-from-lotus database
of deal inventory. This way the client can use their lotus node merely
as a network gateway, without running into any limitations currently
present in both lotus as a whole and go-fil-markets in particular.
Specific context for this work is filecoin-discover, where the requirement
is to onboard ~ 12,000,000 individual deals against a pool of miners
with whom the client has prearranged a relationship.
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.
