Background
Whitepaper gave some information about Triggers and initial requirements about this functionality, but a lot of open questions comes into play when implementation details were discussed.
The design of Iroha Triggers mainly takes inspiration from:
- Database triggers - Oracle example
- Substrate weight and fee handling use cases in `pre-dispatch` and `post-dispatch` stages of transaction processing
- Smart contracts in other blockchains
Problem
Currently we can submit transactions that can modify global state if they pass validation. These transactions can contain `Query`s inside of them, allowing them limited capability to execute logic on-chain.
Transactions can include:
- Iroha Special Instrucions
- (Unclear if needed and not yet implemented) WASM blobs
Independently of their content type they will have limited capability as they will only be able to execute the contained logic once.
Though as it is established in blockchain space current use cases require a more sophisticated functionality to efficiently support DeFi:
| Use Case | Needs * |
|---|---|
Swaps | Triggered by user; Does several additional state validations; Manages liquidity; |
Periodic Reward Distribution | Executed periodically; Distributes to all users satisfying certain condition; |
Customizable and modifiable transaction fees | Executed for each transaction; Have ability to disallow transaction execution; |
| Stable coins contracts | Executed periodically or triggered by user; Possibly check external conditions provided by oracle contracts; |
| Oracle smart contracts | Triggered by user; Aggregate data from external world; Provide data to other contracts |
*- Algorithms for all of these use cases need to be on chain for transparency and safety guarantees, which are provided by consensus.
Other use cases for permissioned blockchains might include:
| Use Case | Needs | Comments |
|---|---|---|
| Transaction Metadata Validation | Executed for each transaction; Have ability to disallow transaction execution; | |
| Transaction Set Instructions Validation for Account, Domain and Asset Definition metadata | Executed for each transaction; Have ability to disallow transaction execution; Have access to transaction ISI contents; | |
Permission Management | Executed for each transaction; Have ability to disallow transaction execution; Have access to transaction ISI contents; | We can let all permissions be customizable and upgrade-able during runtime if we use Triggers. |
Solution
To execute arbitrary logic on-chain for unrestricted number of times other popular blockchains have Smart Contracts. Our solution for introducing smart contract functionality is called Triggers.
This is how triggers are described in the whitepaper:
Triggers can be either based on time or on a confirmed transaction (event). This is very powerful and enables Turing complete computation for Iroha's smart contracts.
- Trigger at timestamp (every 5 minutes or after one hour)
- Trigger at blockchain (new block, reach of some height, etc.)
- Trigger at condition (new account, transfer of an asset, etc.)
Representation
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.
*- generally speaking any language could be used that can be compiled into WASM. But due to Rust being our primary development language it is suggested to focus on it.
Place in the WSV hierarchy
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.
Categories
- 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)
Permissions
Persistent State
- Provide a Store (key-value) for each trigger - way to keep data between executions.
- Provide a possibility to create technical accounts for Triggers where they might keep transferred funds.
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.
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
- Users will not be able to use Iroha Triggers in their business scenarios `[2; 8]`