Roman Shanin

> I think it'd require introducing some more event types Yes, currently we already have block separate block statuses (committed and applied), we should do the same thing for transaction...

> Also it might increase either disk space or p2p communications (how much?) since the state of a block (validated/applied) should be tracked as well. Not sure why this would...

> > Also it might increase either disk space or p2p communications (how much?) since the state of a block (validated/applied) should be tracked as well. > Not sure why...

> The other complication would be related to the error handling, i.e. when one happens during the state transition application. How would the peer realize whether it's a local or...

> I guess it should be rejected then (if A is a precondition for B, e.g. register an entity B references etc) I mean that it would be rejected if...

> With the suggested approach nodes would diverge silently (to consensus protocol) in case of bug which leads to non deterministic behavior across nodes. I think our current implementation is...

> We already have event recommendations that only determines the order of trigger executions. Afaik event recommendations rn are not used at all. We assume that due to iroha being...

> I'd suggest checking state.height() before spawning threads to apply blocks so that they are in order We should definitely apply blocks in order we can think of block on...

> Now my remaining concern is this Yes, in theory we could have partially async execution of blocks where some parameters are updated on commit, but we have to search...

Checked Tendermint consensus, by looking at it's interface to interact with blockchain ([ABCI](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/abci/README.md)) it uses synchronous block and transaction execution. Moreover it's block header might include application state hash to...