Cron and Reward messages are applied implicitly by the filecoin vm and are the entry point to a significant portion of specs-actor code. However their error model is different than that of explicit messages. Whereas explicit message failures are charged gas, rolled back and report back failures through the message receipt, any implicit message error causes a tipset to be rejected as invalid.
Implicit message failures are caused by state changes introduced through explicit messages.
- Implicit failures are bad for validator performance / simplicity — one block author can poison a whole tipset and then validators need to figure out which block contains the explict message that causes the implicit message by replaying other block combinations (potentially sped up by using heuristics)
- Implicit failures are bad for block author performance and simplicity — block authors should be vigilant about not publishing an explicit message causing a cron failure in order to be sure their block earns a reward. They need to potentially play several different message combinations / use heuristics to be sure that they are not publishing a message in their block that leads to a cron failure. The computational cost of this can’t be reflected in gas cost because currently the only way to handle these implict message failures is to omit the explicit message causing the problem.
- Implicit failures are bad for message sender UX. If authors and validators address the first two issues the only way to handle these failures is to leave the explict messages causing problems out of blocks entirely. In the case of user error the user will only see silence on the network, they will never get a response in a message receipt explaining what they’ve done wrong.
- Can messages from one epoch cause cron and reward failures in a future epoch? If so then it might become hard for block authors to predict the future failure. (I think the answer could be yes because cron messages are sometimes registered with a delay)
- Can messages from two different blocks in a tipset cause a cron/reward failure only in the case the two blocks are combined but not in the individual block? In this case block authors could be denied rewards even if they checked that the messages they published in their block do not cause cron/reward failures. For reward the answer is no because the reward implict message is applied per block. (For cron I think the answer is no for honest block authors because of message nonces)
- Are implicit message failures always straightforwardly linked to explicit messages? If so it seems like we should throw errors in the explicit message execution. Implict failures may potentially emerge from a combination of users acting "correctly" with no clear explicit message being the culprit that deserves to be rolled back.
- Are implicit message failures always recoverable? Is it possible for the filecoin state machine to come to a halt because the state is no longer able to support any correct cron ticks? Is it possible for a subset of filecoin state machine functionality to halt for the same reason, i.e. no more prove-commits can be processed after a certain state is hit.