make StateCompute not write the output state to the blockstore.

[raulk]

Related Issues

v1.20.3 began using StateCompute in the Eth API. Unfortunately, node operators reported a sharp increase in blockstore size. This was traced to StateCompute writing the output state to the blockstore. Badger is an LSM-tree + value log store, and will happily take the redundant write. The sharp increase was reported by the Glif team — the API endpoint that most wallets use, as well as the Codefi gas oracle, which pings it constantly with eth_feeHistory calls. These calls are special offenders since they call StateCompute over a sequence of tipsets.

Proposed Changes

Make StateCompute discard its output state. This won't have any effects since all state should already be present in the blockstore anyway. Also, it's only used by CLI and Shed tooling (beyond the Eth API). I've left a note in the relevant places.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[arajasek]

This won't actually achieve what we want it to -- the relevant bloat is coming from the state computation through the ExecutionTrace call on line 74, which will be unaffected by this change.

I think we need to modify ExecutionTrace to take an optional param that indicates whether state should be persisted or not, that gets passed down to the TipSetExecutor, which then decides whether or not to use a temp blockstore based on that. This is all fine to do, it shouldn't break any APIs.

[raulk]

Ah I see. This is a weird method. It computes the tipset and then applies the supplied extra messages. And we're supplying no messages. Looks like a debugging/development API that we are now using in production paths in the Eth API. Isn't there a method that just computes the state of a tipset? Anyway, changing...

[raulk]

Any reason not to use TipSetState instead of StateCompute (to also omit execution traces, which we don't need)?

EDIT: #10446 does that. But it'll make it harder to request no writes.

[raulk]

Superseded by #10457.