Page Properties | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
...
Trigger is registered by Register<Trigger> instruction. Submitted inside of it as WASM blob.
We have to consider adding appropriate permissions for this instruction. And for public blockchain use case do this with democracy voting module
For private blockchain we might start with a simple permission that only user with corresponding Permission Token can register Triggers.
For public blockchain we need to consider two distinct limitations of Trigger registration:
- Any Trigger that can fail transaction execution - should be registered with democracy voting module
- Any periodic Trigger (time or block based) which is considered "system" level and does not pay fees (see Execution Limits section) - should be registered with democracy voting module
- In other cases users can freely register their own triggers if they can pay trigger registration fee (which might depend on WASM blob size)
Communication with other Triggers
Execution Limits
Trigger execution takes up
Misc
It might be good to provide Triggers with a way to `Unregister` themselves. Especially for public blockchain use cases.
Decisions
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
...
- 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]`
...