Background
Whitepaper gave some information about Triggers and initial requirements about this functionality, but a lot of open questions come 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 are Iroha Special Instructions that may be invoked based on condition. This is very powerful feature and enables Turing complete computation for Iroha's Special Instructions.
- Trigger at timestamp
- Trigger at blockchain
- Trigger at condition
Representation
As you can see in the quote from the whitepaper the Triggers were initially planned to be represented as ISI.
But 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.
Execution
1 - Leader creates a block out of transactions that it got from the queue
2 - Leader adds trigger execution recommendations to the created block
3 - Validators receive the block and check if they agree with leader trigger execution recommendations
Yes - if other checks also pass then validator votes for the block
No - validator does not vote for the block
4 - If block got enough votes - all peers execute block transactions and triggers in their order at block commit.
Triggers in Transaction Context - if System Level - have the ability to fail this transaction execution.
Other Triggers might just influence other transactions in a way that they are executed before them, but do not directly do anything to other transactions.
Trigger Failure Case
In the case that at Stage 2 leader notices Trigger failure. It should indicate in the execution recommendation that this Trigger failed and Trigger error code.
Validators will then check that they also have this trigger failing.
On block commit peers will not need to try to execute this trigger, as it was proven that it fails.
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
- Asset Definition Level Triggers
- Their access is restricted only to assets of this definition
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:
- Time-based
- At timestamp
- Each `duration`
- For complex use cases Trigger might register itself again to execute at another timestamp
- Time based Triggers seem to be difficult task for synchronization between peers. The following approach is suggested:
Recommendations to execute them should be added by the leader to the block (even if there are no transactions - leader should generate a block with trigger execution recommendations for them)
They are best effort - Iroha does not guarantee them to be executed at exact time. But it guarantees execution at closest possible time if network is operational.
If a leader does not produce a block with appropriate time based triggers in the defined time period after those trigger's selected timestamps - view change happens - similar to how if leader does not produce block for ordinary transactions
Next leader in this case will need to include the previous time based trigger in a block (when a view change happens it will be given a new time window to do this)
- Block number-based
- At block
- Each `n_blocks`
- For complex use cases Trigger might register itself again to execute at another height
- Transaction-based
- Before (transaction execution)
- Only for System Level Triggers
- Have the ability to check and fail or allow transaction
- After (transaction execution)
- After each
- After transaction that triggered a change in WSV that meets arbitrary condition - this is the most general option
- In both cases they have access to transaction contents and at least read access to WSV
- Have the ability to check and fail or allow transaction - if System Level
- Before (transaction execution)
- Triggers that are triggered by specific ISI call - ExecuteTrigger(Params)
- Similar to smart contracts as they are in Ethereum blockchain
- Execute as part of the transaction instructions execution
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 loosens 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.
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 cases for Trigger registration based on their purpose:
- System Level Triggers - should be registered with democracy voting module*
- User Level Triggers - users can freely register their own triggers if they can pay trigger registration fee (which might depend on WASM blob size)
*- democracy voting module is assumed to be similar to the one used in Substrate based chains for runtime upgrades.
For public blockchain use cases we can also introduce parachain like behavior for Triggers to be only registered for a fixed amount of time, after which they will need to be registered again.
This will prevent clogging blockchain with "dead" triggers - triggers that no longer have users.
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.
- Fees can be taken for each WASM instruction that is executed - the concept is known as `fuel` in WASM runtimes.
- If technical account does not have enough funds - changes made by Trigger are reverted.
- For Triggers called by ExecuteTrigger(_) we might consider the same approach that is used in Ethereum - take funds from the account that called it.
There is also a question of how to limit their `condition` execution if condition is also in WASM. Possibly fees will be also taken just for condition checks, but in lesser amount than for the actual execution.
Misc
It might be good to provide Triggers with a way to `Unregister` themselves. Especially for public blockchain use cases.
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).