| Page Properties | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
...
Corresponding to their meaning Triggers can be stored in 2 ways:
- Top Level Triggers - in the World entity
- They can operate on any data in WSV
- Domain Level Triggers - in the corresponding Domain
- Their access is restricted only to their Domain
Second option might be interesting for permission-ed blockchains.
...
Permissions
Persistent State
...
Complex Triggers (such as Swap triggers managing Liquidity Pools) might need to store data between their invocations. For this purpose Triggers will have following persistent storage:
- Key value Store (Similar to Account, Asset Definition, Domain and Tx metadata)
- On demand technical accounts where they might keep transferred funds.
- While of course technical accounts can be emulated with key value store.
This might complicate usage of Transfer, Mint and other currency related features while using Triggers.
This also looses the more strict definition of Currency and therefore is more error-prone.
Therefore is suggested to keep the technical accounts option.
- While of course technical accounts can be emulated with key value store.
Registration
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.
...
- 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]`
...