| Page Properties | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
...
Second option might be interesting for permission-ed blockchains.
Categories
By wake up condition:
- Have the following Triggers categories:
- Time-based
- Block number-based
- Transaction-based (can have a condition of whether they need to execute, similar to Oracle `when` condition)
- Triggers that are triggered by specific ISI call - ExecuteTrigger(Params)
- Have an ability to configure trigger order for Transaction Based triggers:
- Before (transaction execution) - have the ability to check and fail or allow transaction
- After (transaction execution)
By purpose:
- System Level - Influence the whole blockchain system rules and features
- User Level - Provide services to users and other apps
Permissions
Persistent State
...
- 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
- For triggers we assume that time on different peers in some sync state with delays less or equal to block build time
Risks
- Users will not be able to use Iroha Triggers in their business scenarios `[2; 8]`
...