Consider a case of assets exchange with the following algorithm:

  1. Wait for an Asset transfer from an Account
  2. Get information about exchanging assets (base asset ID, target asset ID, exchange rate).
  3. Check that these assets exist and can be exchanged.
  4. Calculate the target currency amount by passing the retrieved exchange rate to the mathematical instruction as an argument
  5. Make a transfer by passing the calculated amount of the target currency, recipient account ID (that is, the user who made the transfer in step 1), and the target asset ID as an argument in the AssetTransfer ISI.

Requirements for this case are the following:

  1. To have the ability to pass exchange-related data like 'exchanging asset ID' and etc. to the algorithm (from asset-store, for example).
  2. To be able to manipulate the given data. For example, to calculate the exchanged currency amount.
  3. To store new data. For example, to store the calculated amount.
  4. To load saved data and pass it as an argument for an ISI. E.g. passing the calculated amount to the `TransferAsset` ISI.
  5. To have a guarantee that all the stored data is consistent, so the user would not have to verify all the data by itself.

Additional requirements for the algorithm:

  1. It should be persisted, so no one could change the order of the instructions.
  2. It should be guaranteed that the creator of the algorithm is not permitted to call these instructions by itself.
  • No labels

4 Comments

  1. Nikita Puzankov

    the "contract" may be violated.

    can you clarify what means violated?

    Also let's try to formalize some terms and things:

    • "Asset transfer from a user" means `TransferAsset` Iroha Special Instructions submitted on behalf of some account?
    • Doesn't `TransferAsset` contains information about source and target assets identifications?


    Now some short and fast answers to questions:

    How will the user transfer information about the exchanging assets to the procedure

    I will first think about the need to introduce procedures for this case. As was discussed previously, Exchange can be implement via Iroha Special Instructions and Iroha Triggers (Event Listeners).

    What if the storage was not empty and the sender did not update/delete this information?

    If you by "storage" you mean Asset, than Composite Iroha Special Instruction should have clean up steps and preconditions.

    How to make sure that the information placed in the asset-stores is valid

    I think we can address this in Iroha Additional Requirements - related to custom data validation section.

    How will the information from the asset-stores get to any other ISI

    If by "asset-stores" you mean assets - than composite Iroha Special Instruction should execute Iroha Query.

    How the calculated information will be placed in the store

    By `MintAsset` Iroha Special Instruction.

    1. Vladislav Markushin

      can you clarify what means violated?

      My vision is that the procedure should be executed on behalf of its owner, not by a caller of the procedure. By "violate" I mean, that if the procedure owner would have access to its account, it could execute any instructions in any order with the same permissions. For example, one could "exchange" any assets with any price, because the account has the permissions for doing this.

      "Asset transfer from a user" means `TransferAsset` Iroha Special Instructions submitted on behalf of some account?

      Exactly.


      • Doesn't `TransferAsset` contains information about source and target assets identifications?

      It is, but in the case of the DEX we have additional information for external assets stored in asset-store.  Also, even if all the needed information was stored in the ISI, the other ISI (in our case the final `TransferAsset`) may want to somehow use it as an input later.

      Exchange can be implement via Iroha Special Instructions and Iroha Triggers (Event Listeners).

      Triggers may be a good solution, but again we need to make sure that the trigger owner is not allowed to execute ISIs by itself.


  2. Iurii Vinogradov

    > I will first think about the need to introduce procedures for this case. As was discussed previously, Exchange can be implemented via Iroha Special Instructions and Iroha Triggers (Event Listeners/

    For now, the trigger concept is not finalized as I understand. If you see how this case can be implemented via triggers, please describe it for us to understand if we have questions about it.

    > If you by "storage" you mean Asset, then Composite Iroha Special Instruction should have clean up steps and preconditions.

    As I understand these problems happen because we plan to pass arguments to the functions using assets as storage. For me, it looks like this step can be hidden inside the framework. 

    1. Nikita Puzankov

      Ok, I will write a guide for this case to do not repeat it every time.