1. Current validation + commit of blocks:
1. block is received by a node
2. sumeragi clones the wsv (we'll call it wsv')
3. every transaction is validated on the wsv' (during validation every instruction is also executed on wsv')
4. if validation is successful:
4.1. cloned wsv' is destroyed
4.2. every transaction is executed on the original wsv
4.3. block is applied
5. otherwise:
5.1. cloned wsv is destroyed
5.2. block is not applied
In this setup we're executing every instruction/transaction twice, once on the wsv and once on the wsv'. We can improve this
2. Proposed validation + commit:
1. block is received by a node
2. sumeragi clones the wsv (we'll call it wsv')
3. every transaction is validated on the wsv' (during validation every instruction is also executed on wsv')
4. if validation is successful:
4.1. original wsv is destroyed
4.2. every transaction is executed on the original wsv
4.3. block is applied
5. otherwise:
5.1. cloned wsv is destroyed
5.2. block is not applied
I see no issue if this block is `CommittedBlock`, i.e. if the block has passed consensus. Because then execution follows immediately after validation.
However, we can deploy this tactic during validation as well. During validation, every node would keep the wsv' clone until the end of the round. Only then can it decide which wsv to take
3. Validator becomes Executor
as a consequence of the proposed flow, validator is now responsible for execution.
It will validate, execute and return validation result(Result<(), DenialReason>).
Iroha will then inspect the returned value and decide which wsv to continue using.
4. Executor as smart contract
This will open the door to affect the execution in the Executor.
Executor can make arbitrary changes to the wsv not only execute the transactions listed in the block.
Iroha will have no way to know what has happened to the wsv in the Executor since it is user defined.