Page History

...

*- 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

Generally the following holds true for Trigger execution

1. Triggers are automatically executed on each of the peers when their corresponding condition is met (see Categories).
2. Triggers do not generate any new transactions or blocks.

Though there might be exceptions for time based Triggers - see Categories.

1 - Leader creates a block out of transactions that it got from the queue

Image Added

2 - Leader adds trigger execution recommendations to the created block

Image Added

3 - Validators receive the block and check if they agree with leader trigger execution recommendations

1. Yes - if other checks also pass then validator votes for the block

2. 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.Execution Diagram WIP

Place in the WSV hierarchy

...

• 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. There are several approaches to solve this problem: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)

    • Leader might generate a transaction (and block) for time based triggers, and will be blamed if it does not do it in given time period
      • This seems inconsistent with other Triggers which do not generate txs
    • Time based triggers might be tied to block commit - in a sense that we guarantee that they will be executed atomically with the next closest block.For this we might need to introduce generating empty blocks, when no transactions were found in the given period.

• Block number-based
  • At block
  • Each `n_blocks`
  • For complex use cases Trigger might register itself again to execute at another heightExecute atomically with the block commit, after block transactions were applied.
• Transaction-based
  
  • Before (transaction execution)
    
    • Only for system level System Level Triggers
    • Have the ability to check and fail or allow transactionExecute during block validation before each 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
    • Execute after transaction when it is committed
    • If they fail with error - it has no influence on transactionHave the ability to check and fail or allow transaction - if System Level
• 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:

...