2020-08-25 RFC: Triggers discussion meeting notes

Nikita Puzankov

• Ales Zivkovic  How we are going to handle the external values?
  • Yuriy Vinogradov We can separate triggers and off-chain functionality to put the data into the blockstore and use it in triggers.
  • Even if we will remove triggers from the system, the problem will consist
  • Ales Zivkovic I am asking because of the previously existing components. Anton Khvorov can provide the details
  • Yuriy Vinogradov We can use bridges as off-chain information receivers. By making their generic, we can use them for different uses. 
• 武宮誠 Are triggers consumed when used?
  • Triggers are stored in the "peer" entity. There are special instructions for registration of triggers
  • 武宮誠 For many use cases, there should be triggers with one-time usage. There is a potential exploit when the trigger can be used indefinitely and use too many resources. We should provide the possibility to use permissions
  • We can add additional trigger which will unregister existing triggers
  • 武宮誠 It is fine to have one additional trigger, but how you will force people to create triggers?

武宮誠

Nikita Puzankov

• The idea of triggers is very near to Iroha special instructions
  • Trigger is the structure which is a composition of 2 entities:
    • Condition
    • Transaction for execution (set of ISIs)
• Evgeniy: We can use additional parameters for the triggers to store "enabled" state, and perform garbage collection after they are disabled
  • We need to write down the scenario to comments
• 武宮誠 : Few words about the syntax for conditions: will it be like a batch
  • It will be like ISI DSL approach
  • 武宮誠 Let's create a list of examples
  • 武宮誠 We need to also consider the possibility of a chain of executions triggered one by one
  • It is one of our open questions – should triggers be able to be executed by other triggers?
    • Current proposal – do not fire any triggers as a result of transactions, which executed by triggers.
    • We need to have comments to add such possibility
    • There should be also the possibility to execute the trigger by explicit ISI
    • There is a possibility – to have some 
    • 武宮誠 : It is quite a hard question, for Turing-completeness we need to think about allowing triggering triggers from other triggers
    • 武宮誠 We just probably need to wait for another block to execute trigger from another trigger, which will give us possibility to handle the situation
• Yuriy Vinogradov We may need to have loops in triggers
  • Nikita Puzankov There is no possibility to have an infinite loop in the ISI, as it is counter-effective for execution
  • Yuriy Vinogradov The particular use case – distribution of tokens, which can take millions of executions of the trigger.
  • Evgeniy Zhukov: Probably we can use some safe recursion with formal verification
  • Nikita Puzankov We need to have requirements and model for verification
  • 武宮誠 For initial release we can limit complexity by limiting that Triggers cannot trigger triggers, then we can go deeper into the research of languages and safety
  • Ales Zivkovic There is not about requirements, there is a non-functional security requirements. We need to develop protection from the hacker.
  • Nikita Puzankov Yes, we can start with the limited functionality and then add additional security protection to caver extended functionality.