...
Whitepaper gave some information about Triggers and initial requirements about this functionality, but a lot of open questions comes into play when implementation details were discussed.
Problem
Iroha Special Instructions can not provide the fully fledged toolbox for all possible use cases because they lack an ability to react on changes in Iroha state. Iroha Triggers provide this functionality and in addition to Iroha Special Instructions give users full-scale functionality for almost any business scenario.
Triggers execution, in contrast to transaction execution, depends on condition.
Triggers can be either based on time or on a confirmed transaction (event). This is very powerful and enables Turing complete computation for Iroha's smart contracts.
- Trigger at timestamp (every 5 minutes or after one hour)
- Trigger at blockchain
- Trigger atcondition
- (new block, reach of some height, etc.)
- Trigger at condition (new account, transfer of an asset, etc.)
Also, for For cases like Iroha Permissions Module it will be need we will need to be able to manage Triggers execution (order - for example to execute them before block/transaction/instruction or after block/transaction/instruction).
Order Book case
Users send bid and ask limit orders into the order book. Every order in the order book should be executed when counter order with the same price will be received. Speaking other word it should happen when bid meets ask at the same price. In this case limit order should be notified that there is a matching order and swap should be executed with resulting funds sent to the owners of both orders. Looks like this notification is reasonable to implement using triggers.
...
Because impure (I/O to 3rd party systems) Instructions and Triggers will not be supported by Iroha 2 - Iroha Events can be used to receive information by Cloud Events Consumers.
Solution
Iroha Triggers should be stored on the Blockchain. Other parts are represented in form of open questions with some alternatives:
Peer can be a place to store Iroha Triggers. We can register new Triggers by Register<Peer, Trigger> Iroha Special Instruction.
Because we depend on triggers a lot, we will have tight coupling between transactions processing and their execution. Every Iroha Special Instruction that changes Iroha state (domain related instructions category from Set of OOB ISIs) can Trigger, so we need to check Iroha Triggers that depend on conditions every instruction, Iroha Triggers that depend on blockchain every block and Iroha Triggers that depend on timestamp every block also.
Decisions
- Store Triggers under Peer entity
- Have three Triggers categories:
- Time-based
- Block-based
- Instruction-based
- Have an ability to configure trigger order:
- Before (instruction or block)
- After (instruction or block)
- Triggers will be build on top of Iroha Special Instructions
- For instruction-based Triggers condition will be of `Instruction::Execute(Query)` type
- All changes are declared
- Under World State View as a set of Iroha Special Instructions
- Inside World State View under Peer entity as a set of Iroha Special Instructions
- Inside "global" domain as Assets (which can be transformed into Iroha Special Instructions)
- When to check Trigger execution conditions?
- Every Instruction
- Every Transaction
- Every Block
- How to execute them?
- As additional set of instructions inside transaction
- As a set of instructions outside transaction
- As a new transaction
- This option will prevent halting problem inside one round (cyclic triggers)
Decisions
Alternatives
Concerns
Assumptions
Risks
Alternatives
- Store Triggers as Assets - to much complexity and runtime dependent code
- Execute Triggers sending new set of transactions - require networking communications, can end up in missing triggers
Concerns
- Some complexity for end users
- Open question about parameters propagation (condition → execution)
Assumptions
- We do not have impurity inside Iroha and all Triggers can be replayed on different peers resulting in the same state of each consensus participant
Risks
- Users will not be able to use Iroha Triggers in their business scenarios `[2; 8]`
Additional Information
- Set of OOB ISIs
- https://github.com/hyperledger/iroha/blob/iroha2-dev/docs/source/iroha_2_whitepaper.md#251-event-listeners
- Permissions
...