Consider a case of assets exchange with the following algorithm:
- Wait for an Asset transfer from an Account
- Get information about exchanging assets (base asset ID, target asset ID, exchange rate).
- Check that these assets exist and can be exchanged.
- Calculate the target currency amount by passing the retrieved exchange rate to the mathematical instruction as an argument
- 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:
- To have the ability to pass exchange-related data like 'exchanging asset ID' and etc. to the algorithm (from asset-store, for example).
- To be able to manipulate the given data. For example, to calculate the exchanged currency amount.
- To store new data. For example, to store the calculated amount.
- To load saved data and pass it as an argument for an ISI. E.g. passing the calculated amount to the `TransferAsset` ISI.
- 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:
- It should be persisted, so no one could change the order of the instructions.
- It should be guaranteed that the creator of the algorithm is not permitted to call these instructions by itself.
4 Comments
Nikita Puzankov
can you clarify what means violated?
Also let's try to formalize some terms and things:
Now some short and fast answers to questions:
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).
If you by "storage" you mean Asset, than Composite Iroha Special Instruction should have clean up steps and preconditions.
I think we can address this in Iroha Additional Requirements - related to custom data validation section.
If by "asset-stores" you mean assets - than composite Iroha Special Instruction should execute Iroha Query.
By `MintAsset` Iroha Special Instruction.
Vladislav Markushin
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.
Exactly.
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.
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.
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.
Nikita Puzankov
Ok, I will write a guide for this case to do not repeat it every time.