Thanks for all the clarifications 
In case it wasn’t clear, that’s what I intended for the ClaimAdded (receipt) log.
I want to push back a bit on this philosophical point as it has practical implications. State execution can be modelled as a Platonic ideal, and in such a model not be a consensus game. In reality state execution is arguably a consensus game (see also “Background on consensus” in this post) for several reasons:
- Higher-level consensus: There is a higher-level consensus game in choosing which execution rules to run in the first place, e.g. Ethereum vs Ethereum Classic or Byzantium vs Constantinople.
- Specification ambiguity: Even if all clients intend to run the same execution rules, the act of specifying the rules (e.g. in EIPs, yellow paper, etc.) is generally ambiguous. Edge cases will be unspecified or over-specified (i.e. contradictorily specified), and different clients will handle some cases differently.
- Implementation bugs: Even if all clients intend to run the same execution rules, and the rules are perfectly specified, implementations will have bugs. See for example Consensus bug in geth v1.4.19 and v1.5.2.
- Censorship: This execution scheme emphasises another notion of locality to execution, namely that light clients may come to different conclusions when evidence is censored.
Points 2) and 3) are bad for executors because it can lead to a significant portion of deposits to be slashed. Execution risk being financially borne by executors via slashing may deter some executors from participating in the first place.