[Spike] Message processing granularity mismatch

[willscott]

our view of state when processing messages is currently using the API exposed by lotus, which allows retrieval of state at block granularity.

There are edge cases where this can be insufficient. We believe it is possible for one block to contain two messages where the first creates a new actor (e.g. a multisig), and the second message calls a method or transfers value to that actor.

Block level state may not be able to fully pull apart such changes. (for this specific case of creation and then action, the state at the end of the block would allow us to learn type, but e.g. for diff'ing an actor's state, we may find edges where we fail to get a before state in the diff).

The MVP of this is a task that processes every message in order in a tipset and dumps the state of it to the database.

[placer14]

Option 1: Could Lotus expose a new API which provides resulting state root after a specific message application by providing a tipset key and a message CID and the API applies all messages starting with tipset key and up to msg CID. Risk: Might not want to cache all intermedia states during processing for this specific use? Also might not have bandwidth on lotus team to deliver promptly.

Option 2: StateComputeState usage and parsing entire tree. Risk: Wrong msg batch to apply...inconsistent w how Lotus processes.

Discussion with Lotus to decide on direction needed.

[willscott]

My sense is that the most natural computation we want on some message derivations (including multisig, and some miner actions) will involve the diff functionality @frrist has worked on within lotus.

For instance, to understand the impact of a windowPoSt, we would like to be able to call DiffDeadlines on the state of the relevant miner before and after the message is applied.
Currently, these actor state head's are only calculated at a tipset / block level.
To accurately learn them, we would currently need to use StateComputeState.

• Downsides of StateComputeState: lots of excess computation. potential to 'get it wrong' - e.g. not handling secpk vs bls messages properly as we load them into the computation.

Ask: an API to get either an actor state or a state root state at a message granularity: StateAtMessage(msgID, tipsetID) - ideally returning both pre and post state of the chain as that message is applied.

[iand]

This will be covered in the redesign work for putting visor functionality into Lotus. My current spike hooks into StateManager.ComputeTipSetState and gets a callback after each message is applied. This should allow us to perform the diffing we'd need to do.

[frrist]

This was addressed sometime ago. Lily handles this case gracefully by processing messages in the parent tipset and inspecting actor states in its child tipset.