...
But almost all requirements stay open with this solution.
The problematic
The main problem is how Iroha Special Instructions with only World State View as input can be triggered by World State View changes and where to store such Iroha Special Instructions.
World State View by itself held all information needed for the triggering but the current ISI model doesn't provide a way to use them instead of "hardcoded" entities.
If we will be able to make new Out of the Box set of ISI - `ListenerInstruction` with possible variants like `On{trigger: Box<Instruction>, generators: Box<Fn(?)→[Instruction]}` we will be able to store them on the Peer and execute on every `WorldStateView:put` which will result in a new set of generated instructions. This brings us to the next question - what this triggered instructions should know about their triggers - if nothing than we are good with current `ISI::execute` signature. But if we need to pass some information, we should store this info. And to do not change good (in my humble opinion) signature of `ISI::execute` we should store this trigger-related information in generated Instructions. Which means that for cases where we need this information we need special Iroha Special Instructions =)
Let's try to simplify these thoughts:
| No Format |
|---|
BLOCK --> WorldStateView
WorldStateView --check triggers & generate [ISI]--> WorldStateView::Vec<ListenerInstruction>
WorldStateView --execute instructions--> BLOCK
WorldStateView --send new transaction--> Iroha |
This approach fits almost all our requirements, the problem is to not send new transactions on validation stage and prevent execution of I\O related instructions multiple times.
The second one should be moved into separate RFC because it also implied to regular ISI.
The first one should be addressed here.