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.

Place in the WSV hierarchy

...

*- 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. There are several approaches to solve this problem:
    • 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 height
  • Execute atomically with the block commit, after block transactions were applied.
• 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)
  • Before (transaction execution)
    
    • Only for system level Triggers
    • Have
  • 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)

  ...

  • • )
      • 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
  • Triggers that are triggered by specific ISI call - ExecuteTrigger(Params)
    • Similar to smart contracts as they are in Ethereum blockchain

  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:

  ...

  For public blockchain we need to consider two distinct limitations of cases for Trigger registration :based on their purpose:

  1. System Level Triggers Any Trigger that can fail transaction execution (is system level) - should be registered with democracy voting module
  2. Any periodic Trigger (time or block based) which is considered "system" level and does not pay fees (see Execution Limits section) - should be registered with democracy voting module
  3. *
  4. User Level Triggers - In other cases 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.

  Communication with other Triggers

  ...