...
- Time-based
- 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. There are several approaches to solve this problem:
- Leader might generate a transaction (and block) for time based triggers, and will be blamed if it does not do it in given time period
- This seems inconsistent with other Triggers which do not generate txs
- Time based triggers might be tied to block commit - in a sense that we guarantee that they will be executed atomically with the next closest block.
- For this we might need to introduce generating empty blocks, when no transactions were found in the given period.
- Leader might generate a transaction (and block) for time based triggers, and will be blamed if it does not do it in given time period
- Block number-based
- At block
- Each `n_blocks`
- For complex use cases Trigger might register itself again to execute at another height
- Execute atomically with the block commit, after block transactions were applied.
- Transaction-based (can have a condition of whether they need to execute, similar to Oracle `when` condition)
- Before (transaction execution)
- Only for system level Triggers
- Have the ability to check and fail or allow transaction
- Execute during block validation before each transaction
- After (transaction execution)
- After each
- After transaction that triggered a change in WSV that meets arbitrary condition - this is the most general option
- In both cases they have access to transaction contents and at least read access to WSV
- Execute after transaction when it is committed
- If they fail with error - it has no influence on transaction
- Before (transaction execution)
- Triggers that are triggered by specific ISI call - ExecuteTrigger(Params)
- Similar to smart contracts as they are in Ethereum blockchain
...