...
Also Registration process is different for them.
By wake up condition:
- Time-based - (System Level and User Level )
- At timestamp
- Each `duration`
- For complex use cases Trigger might register itself again to execute at another timestamp
- Time based Triggers seem to be difficult task for synchronization between peers. The following approach is suggested:
Recommendations to execute them should be added by the leader to the block (even if there are no transactions - leader should generate a block with trigger execution recommendations for them)
They are best effort - Iroha does not guarantee them to be executed at exact time. But it guarantees execution at closest possible time if network is operational.
If a leader does not produce a block with appropriate time based triggers in the defined time period after those trigger's selected timestamps - view change happens - similar to how if leader does not produce block for ordinary transactions
Next leader in this case will need to include the previous time based trigger in a block (when a view change happens it will be given a new time window to do this)
- Example: Periodic rewards, scheduled batch processing
- Block number-based - (System Level and User Level )
- At block
- Each `n_blocks`
- For complex use cases Trigger might register itself again to execute at another height
- Example: Per block rewards, scheduled batch processing
- Triggers that are triggered by specific ISI call - ExecuteTrigger(Params) - (System Level and User Level )
- Similar to smart contracts as they are in Ethereum blockchain
- Execute as part of the transaction instructions execution
- For System Level - only admin can call the Trigger or through democracy pallet
- Example: Swap with liquidity pool, locking funds (for bridges or stable coins for example)
- Event-based - (System Level and User Level )
- Triggered by events emitted from other triggers or transaction execution.
- The triggers react to the events emitted in the previous block as shown in the `Execution` section.
- If leader does not supply the needed trigger execution recommendations based on events from previous block -
the block will be rejected and the next leader will have to do this. - Leader has to produce a block with event based triggers in time, even if it will contain no transactions.
Or the view change will happen and the scenario proceeds similar to time based triggers. - Example: Reacting to currency flow, reacting to system events (events from system level triggers), keeping metadata in sync
...