...
With the recent decision to introduce WASM. It is suggested to use it for Triggers. So that Triggers can be written in Rust* and compiled into WASM.
This way Triggers will benefit from a high level language features of an already established language and will be able to solve all the listed use cases with ease.
As discussed previously, solving listed use cases with ISI was impossible or very difficult and needed significant work on the language design side.
...
*- democracy voting module is assumed to be similar to the one used in Substrate based chains for runtime upgrades.
Communication with other Triggers
Generally Triggers can communicate with other Triggers by changing the WSV state and also by calling other triggers through ExecuteTrigger ISI.
ExecuteTrigger ISI might be designed to return some value, therefore introducing a class of `Library Triggers` that are used by other Triggers for various features.
Execution Limits
Trigger execution uses validators' processing resources and therefore has to be limited for the network to stay operational.
Limits would mainly apply to User Level triggers as they are registered freely and are not part of the system itself.
The following is proposed:
- Limit max number of WASM instructions that can be executed per Trigger
...
- Take network fees for Trigger execution:
- In general case fees can be taken from the Trigger's technical account balance.
- If technical account does not have enough funds - Trigger is not executed
- For Triggers called by ExecuteTrigger(_) we might consider the same approach that is used in Ethereum - take funds from the account that called it.
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
Concerns
- Some complexity for end users
- Open question about parameters propagation (condition → execution)
Assumptions
- 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
...
Implementation Considerations
The scope of work proposed here is huge. It might be good to approach it iteratively, focusing on use cases needed for permission-ed blockchains at first (e.g. start with System Level triggers that check transactions).