...
| Page properties | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
|
...
- Database triggers - Oracle exampleSubstrate weight and fee handling use cases in `pre-dispatch` and `post-dispatch` stages of transaction processing
- Smart contracts in other blockchains
- Event driven architecture
...
Other use cases for permissioned blockchains might include (these use cases are proposed to be handled outside of the context of triggers, see `Outside of Triggers Scope` section):
| 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. |
...
- Triggers can decide to emit events
- Events will be automatically emitted for WSV changes
- The events are based on WSV diff after particular transaction execution.
- Examples: AccountCreated(_), AcccountMetadataFieldSet(_), AccountBalanceChanged(_) etc.
Events emitted during execution of entities in the current block are added to the block. Though Triggers can react to them only in the next block.
...
4 - If block got enough votes - all peers execute block transactions and triggers in their order at block commit.
...
.
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.
...
- 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)
- In comparison with Substrate based chains: Similar to runtime in Substrate
- User Level - Provide services to users and other apps
- Pay fees for execution*
- Act on behalf of their technical accounts and their permissions
- In comparison with Substrate based chains: Similar to smart contracts in Substrate
*- for more on this see Execution Limits
Also Registration process is different for them.
By wake up condition:
- Time-based - (System Level and User Level )
- At timestamp
- Each `duration`
- For complex use cases Trigger might register itself again to execute at another timestamp
- We should limit the granularity of possible timestamps, as network has a limit of how fast it can produce and commit blocks
- 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)
- Example: Periodic rewards, scheduled batch processing
- Block number-based based - (System Level and User Level )
- At block
- Each `n_blocks`
- For complex use cases Trigger might register itself again to execute at another height
- Might not be needed as there are already time based triggers, and block time is not fixed in Iroha v2.
- Example: Per block rewards, scheduled batch processing
- Before (transaction execution)
- Before each Have the ability to check and fail or allow transaction
- Have access to all transaction data
- Allows introducing additional permission level for private blockchains
- Example: Transaction metadata validation, prohibiting particular instructions, permissions based on instruction inspection
- After (transaction execution)
- After each
- Have the ability to check and fail or allow transaction
- Have access to all transaction data and WSV diff after execution
- Allows introducing additional permission level for private blockchains
- Example: Permissions based on changes to WSV
- Similar to smart contracts as they are in Ethereum blockchain
- Execute as part of the transaction instructions execution
- For System Level - only admin can call the Trigger or through democracy pallet
- Example: Swap with liquidity pool, locking funds (for bridges or stable coins for example)
- Triggered by events emitted from other triggers or transaction execution.
- The triggers react to the events emitted in the previous block as shown in the `Execution` section.
- If leader does not supply the needed trigger execution recommendations based on events from previous block -
the block will be rejected and the next leader will have to do this. - Leader has to produce a block with event based triggers in time, even if it will contain no transactions.
Or the view change will happen and the scenario proceeds similar to time based triggers. - Example: Reacting to currency flow, reacting to system events (events from system level triggers), keeping metadata in sync
...
The following topics are proposed not to be handled with Triggers but instead considered separately. Both of the topics need a separate RFC, but they are mentioned here in the context of their relation to Triggers.
In Triggers we wanted to both of these as part of Transaction Based Triggers (After/Before Transaction) - this proposal effectively removes this type of Triggers from design.
Instruction and Query Permissions
...
Instead it is proposed to have Permissions as WASM plugin which is not a Trigger, but a separate part of the system. This will allow us to upgrade them at runtime, without the complexity that might be there with Triggers.
It is possible to either migrate current permission system simply to WASM and provide instructions to update them, or we can work on diff based permissioning - which will check WSV diffs after instruction/transaction/trigger execution.
Network Fees
We also considered using Triggers for handling network fees (transaction and trigger fees), but again there is a following issue.
...
Instead it is proposed to have either a highly configurable system where fee configuration can be done at runtime, or again do it through a separate WASM plugin (if fee handling logic might be changed at runtime).
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).