Page Properties | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
...
Second option might be interesting for permission-ed blockchains.
Categories
By purpose:
- System Level - Influence the whole blockchain system rules and features
- Can fail transactions
- Do not pay fees for execution*
- Permissions are not checked for them (can freely modify WSV state)
- User Level - Provide services to users and other apps
- Pay fees for execution*
- Act on behalf of their technical accounts and their permissions
*- for more on this see Execution Limits
By wake up condition:
- Have the following Triggers categories:Time-based
- At timestamp
- Each `duration`
- For complex use cases Trigger might register itself again to execute at another timestamp
- Block number-based
- At block
- Each `n_blocks`
- For complex use cases Trigger might register itself again to execute at another height
- 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
- Have an ability to configure trigger order for Transaction Based triggers:
By purpose:
- System Level - Influence the whole blockchain system rules and features
- Can fail transactions
- Do not pay fees for
- execution
- )
- Pay fees for execution*
- Act on behalf of their technical accounts and their permissions
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]`
...